I am reading a thread running concurrently about CLI, and I have very
much trouble figuring out why anyone would want to perturb a language
like C++ with things like gcnew, etc.

Is garbage collection necessary?  Is it a problem we should even
solving by extending the entire language?

I have about 70,000 lines of C++ code in one of my projects and there
is not *one* place where I feel the need to garbage collect.  One of
the virtues of C++ is that it provides a highly regular facility for
(optimal) management of the the lifetime of objects.  I use this
facility with great pleasure and ease of mind.  It puzzle's me that
this facility is not good enough for others.

Can anyone provide an example why the normal mechanisms in C++ are not
sufficient for object life-time management?

-Chaud Lapin-

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

unoriginal_username@yahoo.com (Le Chaud Lapin) writes:

 > I am reading a thread running concurrently about CLI, and I have very
 > much trouble figuring out why anyone would want to perturb a language
 > like C++ with things like gcnew, etc.
 >
 > Is garbage collection necessary?  Is it a problem we should even
 > solving by extending the entire language?
 >
 > I have about 70,000 lines of C++ code in one of my projects and there
 > is not *one* place where I feel the need to garbage collect.  One of
 > the virtues of C++ is that it provides a highly regular facility for
 > (optimal) management of the the lifetime of objects.  I use this
 > facility with great pleasure and ease of mind.  It puzzle's me that
 > this facility is not good enough for others.
 >
 > Can anyone provide an example why the normal mechanisms in C++ are not
 > sufficient for object life-time management?

Garbage collection can sometimes be very helpful and allows some
useful coding idioms.  That said, I agree with you that extending the
language so intrusively is probably utterly unneccessary.  The only
strong reason Microsoft had to do it, IIUC, was that the layout of
their .NET objects differs from that of their C++ objects.

I still believe most of what I wrote in this thread:
http://tinyurl.com/3tbot


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Le Chaud Lapin wrote:
 > Is garbage collection necessary?

It is desirable, because it is desired. Many programmers feel
profound relief at not having to deal with endless varieties
of smart pointers and worrying about object lifetimes. No one
is forcing you to use it if you choose not to; indeed that is
one of the strengths of the mixed C++/CLI model.

 > Is it a problem we should even solving by extending the entire
  > language?

It is a problem that Microsoft has chosen to solve by extending
the existing language. You don't get to veto their work, but you
don't have to use it if you don't want to, just like you don't
have to use Java.

 > It puzzles me that this facility is not good enough for others.
  > Can anyone provide an example why the normal mechanisms in C++
  > are not sufficient for object life-time management?

Some programs are organized as sets of interacting agents, and
it's not always clear where the top of the deletion hierarchy
should go. It's also exteremly annoying that factories involve
issues of lifetime management from the outset.

In any case, GC is a feature which is deemed desirable, and manual
lifetime management is a feature which is deemed undesirable, at
least in the common cases where only memory is at issue. Microsoft
is providing what their customers and their own developers want.
You may tell people that they should not want what they do, but
there is far more profit to be made by satisfying people rather
than scourging them.



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Le Chaud Lapin" <unoriginal_username@yahoo.com> wrote in message
news:fc2e0ade.0407131134.c322501@posting.google.com...
> I am reading a thread running concurrently about CLI, and I have very
> much trouble figuring out why anyone would want to perturb a language
> like C++ with things like gcnew, etc.
>
> Is garbage collection necessary?  Is it a problem we should even
> solving by extending the entire language?

Well, GC is just another tool.
I guess the same could once have asked the same about multiple inheritance.
MI has now found many uses in C++ beyond its original
purpose for object-oriented programming.

> I have about 70,000 lines of C++ code in one of my projects and there
> is not *one* place where I feel the need to garbage collect.  One of
> the virtues of C++ is that it provides a highly regular facility for
> (optimal) management of the the lifetime of objects.  I use this
> facility with great pleasure and ease of mind.  It puzzle's me that
> this facility is not good enough for others.

Many C++ users already use garbage collection in the form of
boost::shared_ptr (or an equivalent class).

You may have noted that boost provides an associated weak_ptr
which is needed to support up-links in addition to tree-like
structures. Yet, a GC mechanism based on reference
counting (such as shared_ptr is) won't work when multiple
objects are in a symmetric cyclic relationship.
I.e. a->b  b->c  c->a    ( where -> means holds a reference to ).

Different GC strategies (i.e. mark and sweep when more memory is needed):
 - may be easier to use (we have many Qs here regarding collections of ptrs)
 - have different performance characteristics (can be faster in many cases)
 - are probably less error-prone
 - may not be possible to implement in portable C++

I am a big fan of scoped resource management (which does much more
than memory management, as everyone here knows), but I don't think we
can deny that GC is useful to several real users and problems
(i.e. novices, and large programs with complex in-memory OO structures).

> Can anyone provide an example why the normal mechanisms in C++ are not
> sufficient for object life-time management?

There probably isn't any undisputable example.
But just because all object-oriented programming idioms can be
implemented in C using function pointers, do you consider
that virtual functions are useless ?


Jouant l'avocat du diable,
Ivan
-- 
http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

unoriginal_username@yahoo.com (Le Chaud Lapin) wrote in message news:<fc2e0ade.0407131134.c322501@posting.google.com>...

> Can anyone provide an example why the normal mechanisms in C++ are not
> sufficient for object life-time management?

Anything involving cyclic reference graphs is hard to manage using the
C++ mechanisms. Doesn't happen very often but when it does, it's a
pain.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1089758068.132848@master.nyc.kbcfp.com>...
> In any case, GC is a feature which is deemed desirable, and manual
> lifetime management is a feature which is deemed undesirable, at
> least in the common cases where only memory is at issue. Microsoft
> is providing what their customers and their own developers want.
> You may tell people that they should not want what they do, but
> there is far more profit to be made by satisfying people rather
> than scourging them.

Please note the word Garbage in following post is a short hand of word
Garbage Collection.

I believe a true C++ programmer will not appreciate so call Mixed Mode
(C++ + Garbage) as well as a true .NET programmer who likes Garbage. 
It is fine for MS to provide such Garbage for mixed programmers of C++
and .NET

However, to put Garbage on top of C++ and make it an ISO standard will
not be fine with me.  A C++/CLI ISO standard means majority of C++
programmers appreciate Mixed Mode.  As a true C++ programmer, I cannot
accept such thing.  C++ community is not about MS programmers. 
Satisfying MS programmer does not constitute a C++/CLI ISO standard.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen wrote:
> Le Chaud Lapin wrote:
>  > Is garbage collection necessary?
> 
> It is desirable, because it is desired. Many programmers feel
> profound relief at not having to deal with endless varieties
> of smart pointers and worrying about object lifetimes. No one
> is forcing you to use it if you choose not to; indeed that is
> one of the strengths of the mixed C++/CLI model.
> 
>  > Is it a problem we should even solving by extending the entire
>   > language?
> 
> It is a problem that Microsoft has chosen to solve by extending
> the existing language. You don't get to veto their work, but you
> don't have to use it if you don't want to, just like you don't
> have to use Java.
> 
>  > It puzzles me that this facility is not good enough for others.
>   > Can anyone provide an example why the normal mechanisms in C++
>   > are not sufficient for object life-time management?
> 
> Some programs are organized as sets of interacting agents, and
> it's not always clear where the top of the deletion hierarchy
> should go. It's also exteremly annoying that factories involve
> issues of lifetime management from the outset.
> 
> In any case, GC is a feature which is deemed desirable, and manual
> lifetime management is a feature which is deemed undesirable, at
> least in the common cases where only memory is at issue. Microsoft
> is providing what their customers and their own developers want.
> You may tell people that they should not want what they do, but
> there is far more profit to be made by satisfying people rather
> than scourging them.

Nobody is scourging anybody.  The complaint (if you read it again,
you'll see it) is about extending the _language_ to include GC.  As
far as I can see, every small bit put in the language makes it more
and more complex and fewer and fewer compilers get everything right.

Yes, everybody is free not to use any part of the language in which
they feel no need.  However, sheer existence of those things in the
language makes it quite complex already.  If unnecessary complication
of the language can be avoided, it should be.

Do not read any more into that.

Victor

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Le Chaud Lapin" <unoriginal_username@yahoo.com> wrote in message
news:fc2e0ade.0407131134.c322501@posting.google.com...
> I am reading a thread running concurrently about CLI, and I have very
> much trouble figuring out why anyone would want to perturb a language
> like C++ with things like gcnew, etc.
>
> Is garbage collection necessary?  Is it a problem we should even
> solving by extending the entire language?
>


For me, memory is only one type of resource, belong to a larger set of
files, sockets, database connections, or any other type of gizmo which must
be initialized before use, and cleaned up at end-of-life.  Garbage
collection only solves a fraction of my resource management problem, and so
I must have an additional type of management anyway.  Constructors and
destructors were the biggest reason I switched to C++ from C, some years
back.

<snip>

> Can anyone provide an example why the normal mechanisms in C++ are not
> sufficient for object life-time management?

I see no point to two types of life-time management.


Robert Kindred

>
> -Chaud Lapin-


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

David Eng wrote:
> I believe a true C++ programmer will not appreciate

We'll see, won't we?

> However, to put Garbage on top of C++ and make it an
 > ISO standard will not be fine with me.

Fortunately, you have no say in this. Such an attitude
is pure obstructionism, and it benefits no one. You need
not use this ISO standard if you do not want to, but to
deny people who do want it the ability to have it is
arrogance it its worst.

 > A C++/CLI ISO standard means majority of C++ programmers
 > appreciate Mixed Mode.

No, such a standard means that some party has been willing
to do the work to bring such a standard about. Whether the
majority of C++ programmers will appreciate it remains to
be seen, but it certainly seems that this is your fear.

> C++ community is not about MS programmers. 

Correct. And the C++ standard is not being altered.

> Satisfying MS programmer does not constitute a C++/CLI ISO standard.

Incorrect. Standards are designed by people who care about the things
being standardized. Satisfying MS programmers and by extension other
programmers in the same environment is precisely the point.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1089758068.132848@master.nyc.kbcfp.com>...
> Le Chaud Lapin wrote:
>  > Is garbage collection necessary?
> 
> It is desirable, because it is desired. Many programmers feel
> profound relief at not having to deal with endless varieties
> of smart pointers and worrying about object lifetimes. No one
> is forcing you to use it if you choose not to; indeed that is
> one of the strengths of the mixed C++/CLI model.

There is a bit of the "Little Old Woman Who Swallowed The Fly"
syndrome going on here.  One bad habit leads to another.  If may be
somewhat critical...

Laziness makes one unwilling to exercise diligence in forthought when
"finding the classes".  Lack of forethought causes deferrment of
commitment to the form of a primitive set.  Lack of commitment to form
implies heavy use of polymorphism and the PIMPL idiom on the
(not-yet-fully-cooked) primitive set.  Polymorphism means virtual
functions, which often eliminates the oppotunity for clumpability
(objects that behave very much like scalars), unless the programmer
decides to backtrack and define the meanings of assignment and copying
manually.  This in turn leads to a siuation where most of the objects
created are held via pointers, which requires the programmer to be
constantly cognizant of memory management.  The programmer then begins
to make the same mistake he made in non OO-languages like C,
forgetting to invoke delete at "good" points in program, and out of
frustration, creates a smart pointer which...oddly enough...recaptures
a bit of the very feature that was forsaken..automatic memory
management.  But then it is realized that smart pointers are not
perfect.  They have flaws and do not give that nice scalar feel under
all circumstanaces, so they are redesigned over and over with
incremental success, while never quite achieving perfection, until
mild disillusionment sets in.

Enter garbage collection, the "Botox" for memory management.  No
matter how careless you have been with your your face (design), Botox
will come up behind you and clean up the mess.

> In any case, GC is a feature which is deemed desirable, and manual
> lifetime management is a feature which is deemed undesirable, at
> least in the common cases where only memory is at issue. Microsoft
> is providing what their customers and their own developers want.
> You may tell people that they should not want what they do, but
> there is far more profit to be made by satisfying people rather
> than scourging them.

I cannot help but think that, as senior programmers, we have a
responsibility to teach good practices to younger programmers and
refrain from encouraging Botox as a solution. We should be focusing on
the root of the problem, which might be overuse and/or abuse of
polymorphism.

This is not to say that there is no need for polymorphism.  Ovbiously
there is.  I am only saying that we should not be too quick to make
every object polymorphic.  It causes unnecessary perturbation of a
perfectly good model.  And yes, there are many younger programmers
these days who are heading down this path -

"Oh what the heck, I might as well make all of them virtual..I'm going
to access objects via pointer anyway..and copying..I won't even think
about that..doesn't make sense for this situation...now that I think
about it...it never makes sense for any code i
write...hey...polymorphism is neat...i'm just going to use PIMPL and
access-via-pointer from now on....and just use 'new' all the
time...can't wait until garbage collection comes about...then i can
get rid of these smart pointers"

-Chaud Lapin-

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1089758068.132848@master.nyc.kbcfp.com>...
 > Le Chaud Lapin wrote:
 >  > Is garbage collection necessary?
 >
 > It is desirable, because it is desired. Many programmers feel
 > profound relief at not having to deal with endless varieties
 > of smart pointers and worrying about object lifetimes.

It would be rather naive to think that GC absolves you from lifetime
issues. That may lead to "memory leak"-like behaviour, such as
long-lived references holding on to what should be short-lived
structures, or GC "thrashing" - allocating many or large objects,
which subsequently needs garbage collection.

I experienced the latter when working on some image transformation
functions in Java, and due to the way the standard library API was
desiged, it created a new BufferedImage object each time (each
redraw), for each transformation, leading to massive thrashing, where
the GC made the program slow to a crawl.

I had to do some manual optimisation, making sure to reuse objects,
etc. Not my idea of "relief at not ... worrying about object
lifetimes"!

Had the lifetime management been explicit, this issue wouldn't have
been hidden away until it became a problem. Lifetime management would
have had to be considered from the start.

Moreover, GC only takes care of memory, so any other resource (file
handles, graphics contexts, etc.) must still be handled manually.
Given that Java have no stack allocation of objects, you get these
awkward try-finally blocks, which gets really convoluted if you need
to manage more than one resource.

In contrast, RAII provides an elegant solution to this.

 >  > It puzzles me that this facility is not good enough for others.
 >   > Can anyone provide an example why the normal mechanisms in C++
 >   > are not sufficient for object life-time management?
 >
 > Some programs are organized as sets of interacting agents, and
 > it's not always clear where the top of the deletion hierarchy
 > should go. It's also exteremly annoying that factories involve
 > issues of lifetime management from the outset.

Is there any reason this can't be handled by something like
boost::shared_ptr?

I know it doesn't "collect" cycles, but GCs may have their own set of
problems, as mentioned above.

Regards,

Terje

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Ivan Vecerina" <please_use_web_form@ivan.vecerina.com> wrote in message news:<cd2jjp$m0f$1@newshispeed.ch>...
 > "Le Chaud Lapin" <unoriginal_username@yahoo.com> wrote in message
 > news:fc2e0ade.0407131134.c322501@posting.google.com...
 > I am a big fan of scoped resource management (which does much more
 > than memory management, as everyone here knows), but I don't think we
 > can deny that GC is useful to several real users and problems
 > (i.e. novices, and large programs with complex in-memory OO structures).

Me too.

Incidentally, it's not the experts I am worried about. It's the
(impressionable) novices.  I remember some of my students kept asking
why they should write this:

{
     Foo foo;
}

Instead of this:

{
    Foo *foo = new Foo;
    delete foo;
}

In spite of all the practical answers I could give, there was one that
is practically intangible:  the first method is more regular.  This
answer was  meaningless to most beginners but obvious to an expert who
has an acute appreciation of form.  My concern is that GC will
encourage novices to get comfortable with the pointer method.  My
students had no prior experience with Java, but like moths to a flame,
they were fascinated with "really making stuff" out of the blue.  The
new operator was more sexy to them than the plain-old stack object.
And of course, Java programmers might not think twice about using the
second method if GC were available.

 > There probably isn't any undisputable example.
 > But just because all object-oriented programming idioms can be
 > implemented in C using function pointers, do you consider
 > that virtual functions are useless ?

Yes they are, those silly virtual functions!  I attach to all my
classes an array of 128 pointers that I fill in manually at
construction time. Just kidding.

No, VF's are very useful.  I guess the test of the virtue of any
technique is, "Is it really warranted, or are you using it because it
solves a problem that should have been avoided in the first place."
An example of doing something that should have been avoided would be
using Foo * instead of Foo in the example of above.

 > Jouant l'avocat du diable,

Et un agreable avocat en effet. :)

-Chaud Lapin-

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Terje Sletteb? wrote:
> I know it doesn't "collect" cycles, but GCs may have their own set of
> problems, as mentioned above.

I just want to remind that C++/CLI has been designed to support best of
*both* worlds. Thanks to deterministic destruction of stack objects you
can rely on RAII in C++/CLI as you did in C++, even if object is in fact
created on GC heap. You can also can just "throw" objects into GC and
forget about them - but in that case you would need to use "handle"
(which is GC equivalent of pointer) instead of stack object. And as we
learned in the past, using pointers might be sometimes sub-optimal - the
same applies to handles. Bad thing about handles is that you may not
"delete" it in order to s(t)imulate destruction of object on GC heap,
but you may still "Dispose" it (use the idiom that all C# programmers
know and dislike, possibly implemented with help of RAII). I do not
quite like this assymetry (or maybe I'm wrong in this point?). BTW:
there is strong reason to believe that allocations on GC heap will be
significantly faster than allocations on unmanaged heap (ie. the one
known from C and C++ standard), as GC is allowed to move objects on GC
heap "in the background" in order to provide fastest possible response
time for allocation requests.

In fact what C++/CLI is doing is fixing regression introduced into older
GC languages (Java, C# being two of them), where "deterministic"
destruction requires use of idioms, sometimes leading to convulted code
(as you pointed out). C++ has always been good at providing
deterministic destruction, and is not going to loose it when used in CLI
environment - from POV of C# programmer it's bringing back deterministic
destruction from level of idiom to level of language construct (ie.
stack variable), while from POV of C++ programmer it's just providing
another (faster) heap and means to communicate with other CLI programs.


B.



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

> Enter garbage collection, the "Botox" for memory management.  No
> matter how careless you have been with your your face (design), Botox
> will come up behind you and clean up the mess.

If you are going to employ GC for memory resources, why stop there?
Why not employ GC techniques for all OS resources, e.g. file handles?

Stephen Howe



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

mike.capp@gmail.com (Mike Capp) wrote in message news:<ffc27447.0407140104.14d927b4@posting.google.com>...
> unoriginal_username@yahoo.com (Le Chaud Lapin) wrote in message news:<fc2e0ade.0407131134.c322501@posting.google.com>...
> 
> > Can anyone provide an example why the normal mechanisms in C++ are not
> > sufficient for object life-time management?
> 
> Anything involving cyclic reference graphs is hard to manage using the
> C++ mechanisms. Doesn't happen very often but when it does, it's a
> pain.

Anything involving cyclic ownership, you mean. Ordinary (non-owning)
cyclic references have never been a problem.

Cyclic ownership seems pretty flawed as a concept, so it's not much of
a problem that it isn't easily supported in C++. But it is true that
with garbage collection one is usually able to avoid thinking about
ownership issues, especially in small to medium-sized systems, since
the simplistic "reference == ownership" model suffices.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1089758068.132848@master.nyc.kbcfp.com>...
> Le Chaud Lapin wrote:
>  > Is garbage collection necessary?
> 
> It is desirable, because it is desired.

Only by those that desire it. I believe many of them already have Java
and a whole variety of other garbage-collected languages. If that's
your argument, I will argue with equal validity that it is
undesirable, because it is not desired.

> Many programmers feel
> profound relief at not having to deal with endless varieties
> of smart pointers and worrying about object lifetimes.

Many programmers feel relief at not having to use anything more
advanced than Visual Basic. If many programmers have the relief
requirements that you mentioned then they can already relieve
themselves just fine in a great variety of ways.

> No one
> is forcing you to use it if you choose not to; indeed that is
> one of the strengths of the mixed C++/CLI model.

In that case, I motion that my homebrewed personal library be added to
C++, because no one would force you to use it if you choose not to.
Anyone else want their's added? What's that? You have to be a billion
dollar corporation for anyone to listen to you? Crap.

>  > Is it a problem we should even solving by extending the entire
>   > language?
> 
> It is a problem that Microsoft has chosen to solve by extending
> the existing language.

Guess what comes after embrace and extend.

> You don't get to veto their work, but you
> don't have to use it if you don't want to, just like you don't
> have to use Java.

Java is not really a potential future part of C++. Although if
Microsoft started trying to make it such, I cringe at the thought of
what some of the more mindless people around here these days would do.

> In any case, GC is a feature which is deemed desirable,

Or alternatively, it is a feature which is deemed undesirable.

> and manual
> lifetime management is a feature which is deemed undesirable,

Or again alternatively, it is a feature which is deemed desirable.

> Microsoft
> is providing what their customers and their own developers want.

No, they're providing what Microsoft wants. Those that want garbage
collection already have it, both with C++ libraries and with plenty of
other languages.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9oYoVB8FYP9YqDcRAgkvAJ45aQp9OsX9/S/n8KYR2J/nDSj3mACfdD6H
3HJS8moABlPyqAPfcXNqIbM=
=eH6B
-----END PGP SIGNATURE-----

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1089839810.865972@master.nyc.kbcfp.com>...
> David Eng wrote:
> > However, to put Garbage on top of C++ and make it an
>  > ISO standard will not be fine with me.
> 
> Fortunately, you have no say in this.

Why, because he does not agree with you? Would you be happier about
him having a say as long as he agreed with you?

> Such an attitude
> is pure obstructionism

More accurately, it's a disagreement, for which ad hominen attacks are
now apparently a valid and ethical persuasive strategy. Screw the
details, anyone that doesn't agree with you is a backwards dirty hippy
luddite.

> You need
> not use this ISO standard if you do not want to, but to
> deny people who do want it the ability to have it is
> arrogance it its worst.

What happens when "this ISO standard" becomes the ISO C++ Standard?
'Love it or leave it' is not the most ingenious argument.

>  > A C++/CLI ISO standard means majority of C++ programmers
>  > appreciate Mixed Mode.
> 
> No, such a standard means that some party has been willing
> to do the work to bring such a standard about. Whether the
> majority of C++ programmers will appreciate it remains to
> be seen, but it certainly seems that this is your fear.

You insinuate that the majority appreciating something is all that
matters. Life is so replete with counterexamples that bringing any
amount of them up is pointless if the argument is not prima facie
bullcrap.

> > C++ community is not about MS programmers. 
> 
> Correct. And the C++ standard is not being altered.

Yet. As I have mentioned previously, that is almost certainly the
biggest issue, the alteration of the very C++ Standard itself.
Separate standards can be lived with, if that is what this remains.
Insertion of this into the C++ Standard itself is a whole different
cookie, one that would make a heck of a lot of non-Microsoft
programmers unhappy, and probably looking at other languages.

> > Satisfying MS programmer does not constitute a C++/CLI ISO standard.
> 
> Incorrect. Standards are designed by people who care about the things
> being standardized. Satisfying MS programmers and by extension other
> programmers in the same environment is precisely the point.

Well then heck, I'm sure we'd have their eternal gratitude if we
inserted MFC into C++ too. We might as well go for it, Microsoft and
by extension other programmers in the same environment's satisfaction
being precisely the point. While we're concentrating on their
happiness, I am sure that they would be even more satisfied if we just
made C++ a symbolic link to C# or Visual Basic.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9o5KVB8FYP9YqDcRApikAJ9xraYBimNpGBNQ48MTdLyx+6gOqQCdEN0l
Yo3urqQuRmah69B8a3GeQEU=
=CBbj
-----END PGP SIGNATURE-----

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

> Is garbage collection necessary?  Is it a problem we should even
> solving by extending the entire language?

Perhaps the answer is to do what D has done and what Bjarne suggested, i.e.
make it an optional component. If it was optional then both worlds are
satisfied.

Stephen Howe



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Le Chaud Lapin wrote:
 > My concern is that GC will encourage novices

Programming languages exist so that programmers
can create useful programs. Leaving out a useful
feature for the sake of the ignorant is ridiculous.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Victor Bazarov wrote:
> Nobody is scourging anybody.  The complaint (if you read it again,
> you'll see it) is about extending the _language_ to include GC.

And the response was to people complaining about extending the
language.

> As far as I can see, every small bit put in the language makes it more
> and more complex and fewer and fewer compilers get everything right.

That's a marketing advantage for the few who do :-)

> If unnecessary complication of the language can be avoided, it should be.

Well, that's the rub, isn't it. One person's unnecessary is another
one's vital. As far as I can see, Microsoft is approaching this in
the time-honored way that Strostrup himself used - add features to
the language as users request them, gain experience, and formalize.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Le Chaud Lapin wrote:
> I am reading a thread running concurrently about CLI, and I have very
> much trouble figuring out why anyone would want to perturb a language
> like C++ with things like gcnew, etc.
> 
> Is garbage collection necessary?  Is it a problem we should even
> solving by extending the entire language?
> 
> I have about 70,000 lines of C++ code in one of my projects and there
> is not *one* place where I feel the need to garbage collect.  One of
> the virtues of C++ is that it provides a highly regular facility for
> (optimal) management of the the lifetime of objects.  I use this
> facility with great pleasure and ease of mind.  It puzzle's me that
> this facility is not good enough for others.
> 
> Can anyone provide an example why the normal mechanisms in C++ are not
> sufficient for object life-time management?


Here is a text from a page aimed to be informative that I am preparing 
for my site regarding this issue.


CLI is an existing standard about multilingual Virtual Machine (VM) 
environments together with its own assembly (machine) language. There 
are two mainstream CLI Virtual Machines today. .NET framework in Windows 
and Mono in GNU/Linux. CLI also describes a minimal API that 
CLI-compliant Virtual Machines have. There are also other experimental 
ones like Rotor for FreeBSD.

C++/CLI is an upcoming standard that describes C++ extensions for 
working inherently in all CLI environments. Code written in C++/CLI will 
be portable to all CLI compliant VMs. If a program is written in mixed 
mode, by using both ISO C++ and C++/CLI extensions, naturally it will be 
only compilation-portable to the other CLI environments (as is the case 
with ISO C++ code today).

However if a program is written in C++/CLI only, its executable can be 
portable to any other CLI VM as it is, without any need to use a C++ 
compiler provided by the platform for recompilation from source code to IL.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 > It is desirable, because it is desired.

Only by some C++ programmers. My guess would be that majority do not want
this. They want some degree of manual control over memory allocation. And
with the additional of template container classes to the standard library,
manual memory allocation seems rare these days.
Does anyone use new[] with the addition of vector and others these days?

  Many programmers feel
 > profound relief at not having to deal with endless varieties
 > of smart pointers and worrying about object lifetimes.

I feel no such relief. I would be wondering about

(i) destruction issues - does my destructor get called? What if my class is
managing some critical resource and it is vital that it is freed at once.
There is no problem with straight C++. We know when the destructor is
called. Would finalisers be necessary to add to the language?
(ii) If the GC decides to go into a huddle while it reclaims memory. This
could come at a inconvenient point in my program.
(iii) And the issue about the fact that if GC is used manage memory as a
resource, why not extend that technique for other resources?
(iv) Then there is the question of C++ being used in a limited enviroment -
ROM and EPROM programmers - would the compiler vendors be forced to supply a
GC even if the programmers did not want it?

I am sure that there are programs where GC would be a plus rather than a
minus but I and others would not like the choice to use a GC forced on me.
And with C++'s roots in C and with the degree of control C++ programmers
have over their enviroment, I can't see a non-optional GC becoming part of
ISO C++.

If you want GC in C++, I would suggest championing an optional (optional is
the key word - most C++ programmers could live with optional) GC as Bjarne
Stroustrup has suggested in a thread. If you are serious about this,
something along the lines of

(i) Writing a paper for the ISO C++ committee on this.
(ii) The GC would have to such that for all those that decide not to use it,
they don't pay for it.
(iii) Researching how Walter Bright has made GC an optional part of D would
be interesting.
(iv) Researching the Boehm-Demers-Weiser GC might be useful
(v) Then there is the issue of what C++ idioms would have to restricted in
order for "defined behaviour" to occur for GC.
(vi) The other set of points I raised would also need addressing.

 > In any case, GC is a feature which is deemed desirable, and manual
 > lifetime management is a feature which is deemed undesirable, at
 > least in the common cases where only memory is at issue. Microsoft
 > is providing what their customers and their own developers want.

No I don't think MS did it for those reasons. It is political decision of
theirs.
It remains to be seen whether long-term it is successful. The jury is still
out. TTBOMK, MS now recognises the limitations of COM programming and AFAIK,
there is no serious development of it. Perhaps, given time, .NET will go the
same way?

I think MS developed the .NET environment to combat the threat to Windows of
the Java VM which bears all the hallmarks of a fledgling OS - look at the
services it provides. And .NET enviromnment has GC because Java has GC.

Stephen Howe



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Stephen Howe wrote:

 > If you are going to employ GC for memory resources, why stop there?
 > Why not employ GC techniques for all OS resources, e.g. file handles?

Garbage collection with thread locks - good luck!

-- 
Gerhard Menzl

Humans may reply by replacing the obviously faked part of my e-mail
address with "kapsch".

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1089920102.540148@master.nyc.kbcfp.com>...
 > Victor Bazarov wrote:
 > > Nobody is scourging anybody.  The complaint (if you read it again,
 > > you'll see it) is about extending the _language_ to include GC.
 >
 > And the response was to people complaining about extending the
 > language.
 >
 > > As far as I can see, every small bit put in the language makes it more
 > > and more complex and fewer and fewer compilers get everything right.
 >
 > That's a marketing advantage for the few who do :-)
 >
 > > If unnecessary complication of the language can be avoided, it should be.
 >
 > Well, that's the rub, isn't it. One person's unnecessary is another
 > one's vital. As far as I can see, Microsoft is approaching this in
 > the time-honored way that Strostrup himself used - add features to
 > the language as users request them, gain experience, and formalize.

Perhaps one could also see this from a different perspective: To
ensure that C++ isn't left behind in the .NET/CLI, for those who want
to use that. As has been pointed out in this thread, only MSVC is
supporting the C++/CLI extensions, and you're free to use or not use
the extensions.

Herb Sutter, in his keynote at the ACCU conference 2004
(http://www.accu.org/conference/presentations/Sutter_-_Is_C++_Relevant_on_Modern_Environments_%28keynote%29.pdf)
said he felt it was important that C++ be a first class citizen in
..NET, and that the C++/CLI extensions is a response to the criticism
of the clumsiness of the earlier way of doing this, Managed C++.

Regards,

Terje

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Tommy McDaniel wrote:
 >>> C++ community is not about MS programmers.
 >>
 >> Correct. And the C++ standard is not being altered.
 >
 > Yet. As I have mentioned previously, that is almost certainly the
 > biggest issue, the alteration of the very C++ Standard itself.
 > Separate standards can be lived with, if that is what this remains.

C++ standard (ISO/IEC 14882) is not going to be altered. The only ISO
standarization C++/CLI is going to receive is separate document (be it
separate standard or technical report to existing C++ standard) issued
by some ISO committee (possibly WG21). I'm not in position to guarantee
that, but if you bother to read posts by C++ committee members published
here, you will find that too. And if you know proposed C++/CLI little
more, you will know that there is no way it could be used to alter
existing C++ standard, as its roots and foundations are very different
(eg. definition of execution environment). Thus for a long, long time
(possibly forever) it's going to be separate from C++ standard.

I think that should be clear by now, but "C++ standard with CLI
bindings" is such an abomination in eyes of many "hard-core C++
programmers" that no doubt we have to see yet more posts similar to this
one...


B.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Stephen Howe wrote:

> Only by some C++ programmers. My guess would be that majority do not want
> this. They want some degree of manual control over memory allocation. And
> with the additional of template container classes to the standard library,
> manual memory allocation seems rare these days.
> Does anyone use new[] with the addition of vector and others these days?



You can have manual memory control in a CLI environment by using ISO C++ 
or managed objects in the stack.


> I feel no such relief. I would be wondering about
> 
> (i) destruction issues - does my destructor get called? What if my class is
> managing some critical resource and it is vital that it is freed at once.
> There is no problem with straight C++. We know when the destructor is
> called. Would finalisers be necessary to add to the language?


Finalizers are the destructors of the managed classes and are 
implemented as regular destructors and are called when the object is 
destroyed as usual.


Example:


ref class whatever
{
  // ...
  public:
  // ...
  ~whatever() { // ... }

  // ..
};


// ...


void f()
{
  // Managed object in the stack
  whatever x;

  // ...
// x is destroyed when x reaches the end of scope
}


// Managed object in the GC heap
// It is destroyed by the garbage collector
whatever ^p=gcnew whatever;


// Managed object in the unmanaged heap
// Must be destroyed explicitly
whatever *p=new whatever;

// ...

delete p;


// A vector of whatever handles
vector<whatever ^>array;


// A vector of whatever pointers
// (whatevers in the unmanaged heap)
vector<whatever *>array;



You can also work in mixed ISO C++ and C++/CLI mode.





> (ii) If the GC decides to go into a huddle while it reclaims memory. This
> could come at a inconvenient point in my program.


I do not get what you mean, but you can also invoke garbage collection 
manually (but it is not very usual thing to do).



> (iii) And the issue about the fact that if GC is used manage memory as a
> resource, why not extend that technique for other resources?


The most easy answer is because this is the CLI standard. It describes a 
multilingual VM machine together with its own assembly language.

C++/CLI is an upcoming set of standardised extensions to work inherently 
and portably in CLI environments.



> (iv) Then there is the question of C++ being used in a limited enviroment -
> ROM and EPROM programmers - would the compiler vendors be forced to supply a
> GC even if the programmers did not want it?



No! C++/CLI is a standard of ISO C++ extensions to take advantage of a 
CLI where available! You can also use ISO C++ in a CLI  environment as 
usual.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <40f7814d$1@news.kapsch.co.at>, Gerhard Menzl 
<gerhard.menzl@spambucket.net> writes
>Stephen Howe wrote:
>
> > If you are going to employ GC for memory resources, why stop there?
> > Why not employ GC techniques for all OS resources, e.g. file handles?
>
>Garbage collection with thread locks - good luck!

Good point, but that does not preclude extending GC to deal with more 
than just memory. Your point highlights the need for deterministic 
destruction to support some C++ idioms.


-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <c0fba064.0407150536.224aa46e@posting.google.com>, Tommy 
McDaniel <tdmj@hotmail.com> writes
>> In any case, GC is a feature which is deemed desirable,
>
>Or alternatively, it is a feature which is deemed undesirable.

Well in the case of GC it wasn't deemed undesirable by the languages 
creator. His reason for not having GC in the original language was that 
it can always be added but once there it cannot be taken away. Almost 
ten years ago he brought a proposal to WG21 to add a feature test to C++ 
for use by those wanting to support and use GC.

I would apply the same rule to GC that is applied to other features of 
the language, 'the user should not have to pay for what they do not 
use'. Making GC optionally available in C++ is fine with me.

Now how does that differ from adding libraries? Very simply, I can use 
any library that I like (barring problems with IPR) whether it is or is 
not part of the Standard. As long as the library is portable, my program 
will be as portable as it was without the use of the library. When it 
comes to the core language, I can only use those things that are in the 
Standard or lock my work to vendor provided extensions (which I try to 
avoid)



-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <40f68c2d$0$6444$ed9e5944@reading.news.pipex.net>, Stephen 
Howe <stephenPOINThoweATtns-globalPOINTcom@eu.uu.net> writes
>> Enter garbage collection, the "Botox" for memory management.  No
>> matter how careless you have been with your your face (design), Botox
>> will come up behind you and clean up the mess.
>
>If you are going to employ GC for memory resources, why stop there?
>Why not employ GC techniques for all OS resources, e.g. file handles?
>
>Stephen Howe

That is a good question, and one that I have often thought about. 
Perhaps someone more knowledgeable than I can explain why not.

-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Stephen Howe wrote:

 > Perhaps the answer is to do what D has done and what Bjarne suggested, i.e.
 > make it an optional component. If it was optional then both worlds are
 > satisfied.


It is optional. C++/CLI is a standardised set of extensions that help
you take advantage of a CLI VM where there is one available. It is not a
part of ISO C++ but a separate standard.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

I have made a page specifically to give useful information (essentially
what I know so far) about the upcoming C++/CLI standard.


http://www23.brinkster.com/noicys/cppcli.htm


Any additions or even corrections are welcome.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Francis Glassborow wrote:

 >>If you are going to employ GC for memory resources, why stop there?
 >>Why not employ GC techniques for all OS resources, e.g. file handles?
 >>
 >>Stephen Howe
 >
 >
 > That is a good question, and one that I have often thought about.
 > Perhaps someone more knowledgeable than I can explain why not.


The answer is simple: Because the CLI standard does not include that
stuff and C++/CLI is for working with CLI machines. What you are talking
about, is a possible future addition in the CLI standard but it has
nothing to do with the C++/CLI standard.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Francis Glassborow wrote:
 > That is a good question, and one that I have often thought about.
 > Perhaps someone more knowledgeable than I can explain why not.

Many GC systems provide cleanup handlers which can be specified
per object and are invoked when the object is about to be collected.
Those can be, and are, used to handle resources other than memory.

The reason not all resources can be dealt with in this way is
twofold. First, some resources are scarce and must be deallocated
as soon as possible, so waiting for GC is not suitable. Second,
some resources perform desirable actions upon deallocation, and
those effects are needed at a deterministic point.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Bronek Kozicki" <brok@rubikon.pl> wrote in message news:<a3314$40f7a7a2$3e6fced2$24443@nf1.news-service-com>...
> Tommy McDaniel wrote:
>  >>> C++ community is not about MS programmers.
>  >>
>  >> Correct. And the C++ standard is not being altered.
>  >
>  > Yet. As I have mentioned previously, that is almost certainly the
>  > biggest issue, the alteration of the very C++ Standard itself.
>  > Separate standards can be lived with, if that is what this remains.
> 
> C++ standard (ISO/IEC 14882) is not going to be altered. The only ISO
> standarization C++/CLI is going to receive is separate document (be it
> separate standard or technical report to existing C++ standard) issued
> by some ISO committee (possibly WG21). I'm not in position to guarantee
> that, but if you bother to read posts by C++ committee members published
> here, you will find that too.

Really? Doing what you suggest is exactly what has brought up my
concerns and seems to indicate that you are wrong. I started worrying
about this issue after reading this post:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=5b15f8fd.0404190306.303d2978%40posting.google.com&rnum=8.
Look at the last paragraph. A member of the committee (I think),
Dietmar Kuehl, states in talking about C++0x, and I quote, "My
personal expectation is that we will effectively bring the core
language in line with the C++/CLI binding currently standardized by
ECMA." How can you say that the C++ Standard is not going to be
altered, when a committee member has said that not only might it be,
but they expect it to be? It doesn't sound like C++/CLI is necessarily
going to just remain a separate document, per at least one C++
committee member.

> Thus for a long, long time
> (possibly forever) it's going to be separate from C++ standard.

That is not what committee members are saying.

> I think that should be clear by now, but "C++ standard with CLI
> bindings" is such an abomination in eyes of many "hard-core C++
> programmers" that no doubt we have to see yet more posts similar to this
> one...

I think I have shown that it is actually far from clear, with there
being expectations from actual committee members that what you see as
so clear is actually completely wrong. I know that Dietmar Kuehl does
not own C++, but one has to think that he has those expectations for a
reason (that is better than complete wild self-delusion). There are
going to continue to be similar posts about people concerned about
this because, contrary to what you think, there is in fact good reason
for concern. I truly wish you were completely right and I were 100%
wrong, but that does not seem to be the case.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA+SKMVB8FYP9YqDcRAilwAJsE+AyQOwQ6t2oLqalgowB+8NpZpACeO67z
VoKXypm6kSGyEYhM84cYVrI=
=5TFT
-----END PGP SIGNATURE-----

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <1089990333.947535@master.nyc.kbcfp.com>, Hyman Rosen 
<hyrosen@mail.com> writes
>Francis Glassborow wrote:
> > That is a good question, and one that I have often thought about.
> > Perhaps someone more knowledgeable than I can explain why not.
>
>Many GC systems provide cleanup handlers which can be specified
>per object and are invoked when the object is about to be collected.
>Those can be, and are, used to handle resources other than memory.

Indeed, but that still makes garbage collection mean 'recover unused 
memory'. Why define garbage as specifically memory? Why not include 
file-handles and other limited resources and force a garbage collection 
round whenever one of those resources becomes exhausted?

>
>The reason not all resources can be dealt with in this way is
>twofold. First, some resources are scarce and must be deallocated
>as soon as possible, so waiting for GC is not suitable.
Only if GC is limited to memory and that was the thrust of my question. 
What is so special about memory?

>Second,
>some resources perform desirable actions upon deallocation, and
>those effects are needed at a deterministic point.

Indeed which only shows that GC in any form is not the universal answer. 
But I think GC could be extended beyond its traditional memory handling.


-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 > >> In any case, GC is a feature which is deemed desirable,
 > >
 > >Or alternatively, it is a feature which is deemed undesirable.
 >
 > Well in the case of GC it wasn't deemed undesirable by the languages
 > creator.

None-the-less, Tommy was absolutely correct in pointing out the
circularity and hence logical pointlessness of Hyman's comment. In
fact, Hyman quoted a portion of Le Chaud Lapin's post that he implied
he was answering

Le Chaud Lapin wrote:
  > Is garbage collection necessary?

which clearly asks nothing about "desirability". The question seemed
very clear, is it necessary? He was not asking for a survey of those
who do or do not want C++ to be gargabe collected.

Tommy also pointed at a few other logical flaws in Hyman's post which
seemed concerned mostly with feelings, desires, profit, and
satisfaction rather than any answers to Le Chaud Lapin's more
technical post.

 > I would apply the same rule to GC that is applied to other features of
 > the language, 'the user should not have to pay for what they do not
 > use'. Making GC optionally available in C++ is fine with me.

I think that is generally an excellent criteria. However, isn't the
evaluation of "pay for" sometimes more difficult than simply whether a
computers resources are used even if the feature is unused?

For example, consider Stroustrup's infamous April fools joke about
overloading various characters and colors. It seemed none of those
suggestions would impose any compiler or code overhead, right? Yet,
wouldn't we all "pay for" such a language extension in many and
various ways?

So, can you give an answer to the following

Le Chaud Lapin wrote:
 > Can anyone provide an example why the normal mechanisms
 > in C++ are not sufficient for object life-time management?

I would really like to know of such a case. Elsewhere in the thread
someone mentioned factory methods. Doesn't auto_ptr serve pretty well
for that purpose?

Thank you,

Keith

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 2004-07-17 10:07, Hyman Rosen wrote:
 > Francis Glassborow wrote:
 > > That is a good question, and one that I have often thought about.
 > > Perhaps someone more knowledgeable than I can explain why not.
 >
 > Many GC systems provide cleanup handlers which can be specified
 > per object and are invoked when the object is about to be collected.
 > Those can be, and are, used to handle resources other than memory.
 >
 > The reason not all resources can be dealt with in this way is
 > twofold. First, some resources are scarce and must be deallocated
 > as soon as possible, so waiting for GC is not suitable. Second,
 > some resources perform desirable actions upon deallocation, and
 > those effects are needed at a deterministic point.

The biggest single reason why memory is special in the context of
garbage collection is that resources are referenced by (values in)
memory. Hence memory as a resource is self-referential in nature,
while other resources generally are not. Memory is more complex than
other resources because of cascaded references (referenced memory
may itself reference other memory) and possible circular references,
and at the same time simpler or in the sense that with memory the
"medium" of the reference is the same as the resource being
referenced. Or in other words, memory is self-contained with regard
to garbage collection, while other resources are not.

Of course this doesn't mean that garbage collection cannot be extended
to handle any kind of resources and any conceptual dependencies
between them, but memory will always have a unique role in this.

As an example, conservative garbage collection for (Unix-style) file
descriptors wouldn't make much sense because their values (small
integer values) are too common in memory. You'd have to turn file
descriptors into handles to a seperate file descriptor heap, or
something like that.

-- Niklas Matthies

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Stephen Howe wrote:
 >>Enter garbage collection, the "Botox" for memory management.  No
 >>matter how careless you have been with your your face (design), Botox
 >>will come up behind you and clean up the mess.
 >
 >
 > If you are going to employ GC for memory resources, why stop there?
 > Why not employ GC techniques for all OS resources, e.g. file handles?

Don't all modern operating systems already implement garbage collection
on the process level?  So if a program forgets to release some memory or
close a file, the OS will clean up on process termination.

Going beyond the process level would require a tighter coupling between
the OS kernel, or whoever is dishing out all these resources, and the
garbage collector; perhaps another stack for each resource type being
allocated.  Legacy reasons probably limit the possibility of an
implementation.

(Note:  I am not an expert in garbage collection or OS implementations,
so I could be completely wrong in my ideas.)

    -- MJF

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Tommy McDaniel wrote:


 > Really? Doing what you suggest is exactly what has brought up my
 > concerns and seems to indicate that you are wrong. I started worrying
 > about this issue after reading this post:
 > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=5b15f8fd.0404190306.303d2978%40posting.google.com&rnum=8.
 > Look at the last paragraph. A member of the committee (I think),
 > Dietmar Kuehl, states in talking about C++0x, and I quote, "My
 > personal expectation is that we will effectively bring the core
 > language in line with the C++/CLI binding currently standardized by
 > ECMA." How can you say that the C++ Standard is not going to be
 > altered, when a committee member has said that not only might it be,
 > but they expect it to be? It doesn't sound like C++/CLI is necessarily
 > going to just remain a separate document, per at least one C++
 > committee member.



Check this: http://www23.brinkster.com/noicys/cppcli.htm






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom@eu.uu.net> wrote in
message news:40f68c2d$0$6444$ed9e5944@reading.news.pipex.net...
 > > Enter garbage collection, the "Botox" for memory management.  No
 > > matter how careless you have been with your your face (design), Botox
 > > will come up behind you and clean up the mess.
 >
 > If you are going to employ GC for memory resources, why stop there?
 > Why not employ GC techniques for all OS resources, e.g. file handles?

One danger is that you may run out of a resource before it gets a chance to
be GCed. Consider for example a loop opening and closing files. If the file
handles aren't returned to the OS immediately after being used, the OS would
quickly run out of file handles in such a loop.

Another problem area are thread locks, as has been mentioned. Here, the
problem is not just running out of them, but holding onto a lock way too
long, locking up the whole system.

I guess the reason one can "get away with" GC for memory, is that there's
typically quite a lot of it (except perhaps on embedded systems), so the
system may get a chance to GC, before the system is brought to a halt.

Another area where GC may work well, is for "short-lived" scripts, such as
websites using PHP. In fact, in that case, no cleanup at all (before the
script terminates) may also work well.

Regards,

Terje



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Tommy McDaniel wrote:
 > I think I have shown that it is actually far from clear, with there
 > being expectations from actual committee members that what you see as
 > so clear is actually completely wrong. I know that Dietmar Kuehl does
 > not own C++, but one has to think that he has those expectations for a
 > reason (that is better than complete wild self-delusion). There are

I'm definitely not in position to comment on what C++ Committee members
are saying, but I encourage you to read more recent posts by others
members : Francis Glassborow and Herb Sutter.


B.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Francis Glassborow wrote:
 > Indeed, but that still makes garbage collection mean 'recover unused
 > memory'. Why define garbage as specifically memory? Why not include
 > file-handles and other limited resources and force a garbage collection
 > round whenever one of those resources becomes exhausted?

Oh, that's what you meant? That's easy to explain. GC, defined loosely,
is the ability to reclaim a resource once it becomes known that it will
not be used again. With memory, you have a built-in data structure, the
pointer, which addresses it, and a reasonable substitute for ideal GC,
which is to make memory available for collection once it is inaccessible.
The other resources have no such properties. One could design a language
where file handles, say, had a special form, but how would a collector
determine that a file handle would never again be used by a program? It
would boil down to the handle becoming inaccessible, and then you're back
to memory garbage collection.

Also, I don't believe that moder GC involves waiting until a resource is
nearly exhausted before trying to reclaim it.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Terje Sletteb�" wrote:
 >
 > "Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom@eu.uu.net> wrote in
 > message news:40f68c2d$0$6444$ed9e5944@reading.news.pipex.net...
 >  > > Enter garbage collection, the "Botox" for memory management.  No
 >  > > matter how careless you have been with your your face (design), Botox
 >  > > will come up behind you and clean up the mess.
 >  >
 >  > If you are going to employ GC for memory resources, why stop there?
 >  > Why not employ GC techniques for all OS resources, e.g. file handles?
 >
 > One danger is that you may run out of a resource before it gets a chance to
 > be GCed. Consider for example a loop opening and closing files. If the file
 > handles aren't returned to the OS immediately after being used, the OS would
 > quickly run out of file handles in such a loop.

I ran into that issue working on another form of GC (not all GC is
Boehm style).  Actually it was memory I was running out of but that
isn't the issue, resources are resources.  I resolved it by putting having
the resource allocator block if no resources were available and unblock
later when they did become available.  That seemed like a cleaner solution
than returning a resource not available and going through a tedious and
pointless exercise to recover from that when in most cases there is no
practical means of recovery.  This is for multi-threaded situations.
Obviously, blocking a single threaded program would be a form of deadlock
in this case and you'd want a mechanism or api that would deal with that.

 >
 > Another problem area are thread locks, as has been mentioned. Here, the
 > problem is not just running out of them, but holding onto a lock way too
 > long, locking up the whole system.

There are alternatives here as well.  Not all synchronization involves the
use of locks.

In fact Java, which uses locks and GC, had to come up with JSR-166
because there are situations that are problematic for locks and GC
to handle.

Joe Seigh

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Keith H Duggar wrote:
 > None-the-less, Tommy was absolutely correct in pointing out the
 > circularity and hence logical pointlessness of Hyman's comment. In
 > fact, Hyman quoted a portion of Le Chaud Lapin's post that he implied
 > he was answering
 >
 > Le Chaud Lapin wrote:
 >   > Is garbage collection necessary?
 >
 > which clearly asks nothing about "desirability". The question seemed
 > very clear, is it necessary? He was not asking for a survey of those
 > who do or do not want C++ to be gargabe collected.

The implication of an "is it necessary" question is that the thing
should be included only if the answer is "yes". But we don't do things
only because they are necessary, we also do them because we want to.
So no, garbage collection is not necessary, but it is desired by a good
fraction of the programming community, and CLI/C++ will make it available
to people who want both garbage collection and C++. People who find it
undesireable don't get any veto power over this, but can only choose not
to use it.

 > Tommy also pointed at a few other logical flaws in Hyman's post which
 > seemed concerned mostly with feelings, desires, profit, and
 > satisfaction rather than any answers to Le Chaud Lapin's more
 > technical post.

LCL's question is irrelevant. Necessity is not the only, or even main,
thing that drives prgramming language design. In any case, he did not
point out any logical flaws in what I said. He just ranted against
Microsoft, told people who want GC in C++ to go away, and demanded
that someone else pay to have his pet features become a standard.

 > So, can you give an answer to the following
 > Le Chaud Lapin wrote:
 >  > Can anyone provide an example why the normal mechanisms
 >  > in C++ are not sufficient for object life-time management?

It's not so much a matter of sufficiency as of ease. Without GC,
you've got to be extra careful to manage lifetime issues. You
can't just hand out a pointer to an object for fear it will be
squirreled away somewhere. Interfaces become cluttered with
smart pointer parameters, with everyone rolling their own
implementations.

Not that long ago, the code base of GCC went through extensive
changes as a garbage collection mechanism was built in to the
compiler implementation.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Peter Dimov wrote:
 > the simplistic "reference == ownership" model suffices.

What GC does is entirely remove the need for the concept of
ownership when it comes to memory.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Stephen Howe wrote:
 > If it was optional then both worlds are satisfied.

If it is optional then portable programs can't rely on it.
That make sit almost useless.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <40FA7A03.1CD727D8@xemaps.com>, Joe Seigh <jseigh_01@xemaps.com>
writes
>I ran into that issue working on another form of GC (not all GC is 
>Boehm style).

And I think that is the crux of the problem. Those whose experience of GC is
limited to its use in C and C++ almost always think of conservative GC
algorithms such as those used by Boehm as being the way GC works. That is
just the best that we can do as a fix for code that was written for
compilers that provided no support for GC.


-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project
ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <VnDKc.15439$F8.12156@nwrdny02.gnilink.net>, Hyman Rosen
<hyrosen@mail.com> writes
>Stephen Howe wrote:
> > If it was optional then both worlds are satisfied.
>
>If it is optional then portable programs can't rely on it.
>That make sit almost useless.

There are two kinds of optional here.

1) Optional for the implementation
2) Optional for the user

Consider new(nothrow), that is compulsory for the implementation but no
programmer has to use it. There is no reason that C++ should not support GC
(with implementations required to provide that support) in such a way that
programmers have to make their use of GC visible to the compiler (as, for
example, gcnew() does)


-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project
ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

> The implication of an "is it necessary" question is that the thing
> should be included only if the answer is "yes".

Or the question is as is and he simply wanted examples of
cases that require garbage collection.

> LCL's question is irrelevant.

Irrelevant to whom? to what? It was his question thus it
seems relevant to him. And since he is the OP it seems relevant
to this thread.

> In any case, he did not
> point out any logical flaws in what I said.

It seems he did though he did so by example. Perhaps this
will help you spot them as Tommy did.

argument : It is desirable, because it is desired.
flaw     : tautology
           red herring
           circular argument
           begging the question
           argumentum ad populum (appeal to public)

argument : Many programmers feel profound relief at not
           having to deal with endless varieties of smart
           pointers and worrying about object lifetimes.
flaw     : red herring
           argumentum ad populum
           argumentum ad numerum (appeal to numbers)

argument : No one is forcing you to use it if you choose
           not to
flaw     : red herring
           straw man

argument : It is a problem that Microsoft has chosen to solve
           by extending the existing language.
flaw     : red herring
           complex question
           argumentum ad verecundiam (appeal to authority)

argument : Microsoft is providing what their customers and
           their own developers want.
flaw     : begging the question
           dicto simpliciter (generalization)

and throughout your post argumentum ad nauseam (repetition).

Keith

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Keith H Duggar" <duggar@mit.edu> wrote in message
news:b47de02.0407191203.5be408a@posting.google.com...
 > > The implication of an "is it necessary" question is that the thing
 > > should be included only if the answer is "yes".
 >
 > Or the question is as is and he simply wanted examples of
 > cases that require garbage collection.

I think this may also be "stabbed down", as a similar request in this
thread. People may then quickly point out that all you really "need" is a
Turing-complete system, and that's a very modest requirement.

It may be better to approach it from the angle to ask: What kind of systems
or problems are hard to handle using non-garbage collection techniques
(including smart pointers), and which are easier to handle with garbage
collection?

I think this is the crux of the issue - why garbage collection? What
problems does it solve, or solve better, that we can't solve using the
existing language features?

This may bring the discussion in a more constructive direction, and which
also seems to be in the spirit of the OP.

Anyone care to pick up the gauntlet? :)

Regards,

Terje



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hi,

Niklas Matthies wrote:
[...]
 > Of course this doesn't mean that garbage collection cannot be extended
 > to handle any kind of resources and any conceptual dependencies
 > between them, but memory will always have a unique role in this.

And this is what bothers me a little bit.

Treating memory in a special way is like closing your way to further
evolution of your code.
Let's suppose the situation where you wrote a class containing only
memory-based members (no external resources requiring deterministic
cleanup). You checked it in and your fellows started reusing it all over
the place. Considering the fact that the class is memory-oriented,
people relied on GC to have it cleaned up (we have gigs of RAM nowadays,
so who cares when this single object will get collected, etc. - this
kind of reasoning).
If your class is good, it is also popular, which means that it is used
in gazillion of places.

Then you decide to encapsulate some reference to some resource other
than memory (like DB statement) inside the class (after all,
*encapsulation* is about hiding, so nobody's going to be affected,
right?). And this is where you lose, because there is no way to
automagically enforce deterministic destruction of all those objects.
Once you allow the class to be GCed, it is doomed to be GCed forever.
All this happened because you thought there is something special or
unique about memory.

In my humble opinion, differentiating between resources is a subtle way
to undermine encapsulation. Using GC all over the place is like giving a
clear message to the world that you will *never* need anything stronger.

I'm a fan of deterministing destruction driven by scoping rules. I have
never found the above scenario bothering me in practice, since relying
on deterministic destruction (even when it is apparently not deadly
needed) does not close me the way to use constructs that could require
it in the future.

I agree that GC can be a good tool in hands of Those Who Know how to
make a good out of it (I admit that I don't know) and I will never make
any campaign against it in C++. But I also believe that it is not a
silver bullet and, as our great C++ tradition requires ;), GC is (will
be) yet another tool to shoot your leg off. And the biggest problem is
that many people seem to expect too much from this tool.

I'm just afraid to see students/grads fooling around while plugging GC
everywhere they could.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
news:Ja$9oIPp3P+AFwb4@robinton.demon.co.uk...
 > In article <1089990333.947535@master.nyc.kbcfp.com>, Hyman Rosen
 > <hyrosen@mail.com> writes
 > >Francis Glassborow wrote:
 > > > That is a good question, and one that I have often thought about.
 > > > Perhaps someone more knowledgeable than I can explain why not.
 > >
 > >Many GC systems provide cleanup handlers which can be specified
 > >per object and are invoked when the object is about to be collected.
 > >Those can be, and are, used to handle resources other than memory.
 >
 > Indeed, but that still makes garbage collection mean 'recover unused
 > memory'. Why define garbage as specifically memory? Why not include
 > file-handles and other limited resources and force a garbage collection
 > round whenever one of those resources becomes exhausted?

Could you explain the benefit of such an approach over using "cleanup
handlers" to dispose of arbitrary resources?  I'm having a hard time
thinking of one, especially considering the fact that, in my experience,
virtually every resource is represented as some sort of object.  In short,
what if we asked the question "why" instead of "why not?"

-- 
David Hilsee



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Keith H Duggar" <duggar@mit.edu> wrote in message
news:b47de02.0407191203.5be408a@posting.google.com...
 > > In any case, he did not
 > > point out any logical flaws in what I said.
 >
 > It seems he did though he did so by example. Perhaps this
 > will help you spot them as Tommy did.
 >
 > argument : It is desirable, because it is desired.
 > flaw     : tautology
 >            red herring
 >            circular argument
 >            begging the question
 >            argumentum ad populum (appeal to public)
 >
 > argument : Many programmers feel profound relief at not
 >            having to deal with endless varieties of smart
 >            pointers and worrying about object lifetimes.
 > flaw     : red herring
 >            argumentum ad populum
 >            argumentum ad numerum (appeal to numbers)
 >
 > argument : No one is forcing you to use it if you choose
 >            not to
 > flaw     : red herring
 >            straw man
 >
 > argument : It is a problem that Microsoft has chosen to solve
 >            by extending the existing language.
 > flaw     : red herring
 >            complex question
 >            argumentum ad verecundiam (appeal to authority)
 >
 > argument : Microsoft is providing what their customers and
 >            their own developers want.
 > flaw     : begging the question
 >            dicto simpliciter (generalization)
 >
 > and throughout your post argumentum ad nauseam (repetition).

If someone could use formal logic to prove that it is always better to use
GC than to not use GC, then I would be utterly shocked.  In this discussion,
we are not probing for any "universal truth" on GC.  I just wanted to point
out that these "logical flaws" don't mean that his points should be
discarded without consideration.  However, I do think that the term "logical
flaw" was accidentally misused.

-- 
David Hilsee



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<_9DKc.15289$F8.3331@nwrdny02.gnilink.net>...
 > Keith H Duggar wrote:
 >  > Tommy also pointed at a few other logical flaws in Hyman's post which
 >  > seemed concerned mostly with feelings, desires, profit, and
 >  > satisfaction rather than any answers to Le Chaud Lapin's more
 >  > technical post.
 >
 > LCL's question is irrelevant. Necessity is not the only, or even main,
 > thing that drives prgramming language design. In any case, he did not
 > point out any logical flaws in what I said. He just ranted against
 > Microsoft, told people who want GC in C++ to go away, and demanded
 > that someone else pay to have his pet features become a standard.

For the record, have not pointed out any flaws in your argument, nor
ranted against Microsoft, nor told anyone to go away (I am a firm
believer in getting things out in the open and debating them), nor
demanded anything.  However, if I may take a quick stab at Microsoft,
I would not be suprised if they were very interesting making the
language more sluggish.  :)

 >  > So, can you give an answer to the following
 >  > Le Chaud Lapin wrote:
 >  >  > Can anyone provide an example why the normal mechanisms
 >  >  > in C++ are not sufficient for object life-time management?
 >
 > It's not so much a matter of sufficiency as of ease. Without GC,
 > you've got to be extra careful to manage lifetime issues.

As several have pointed out, this is not a good reason for adding GC,
because there are many places in the language where one has to be
"careful".  If obviating prudence is a goal, then the goal should be
sought universally, something not practical in C++ if the language is
to retain its fundamental character.

What is more important than growing the primitive set is keeping the
primtive set regular.  Regularity of the primitive set is one of our
bastions against complexity.  It allows our systems to scale.

C++ presents us a primitive set that is already strongly regular.  If
the primitive set is of low virtue, it should be scrapped.  If it is
of high virtue, an addition should be complemetary so as to maintain
the orthogonality of the set, thus preserving its high virtue.  If the
addition is redundant,  a case should be made against the existing
primitive demonstrating its insuficiency, in which case, the defective
incumbent should be supplanted, if possible.  However, doing a
comparative analysis often reveals that those who seek a perturbation
of the virtuous primitve set either does not not fully appreciate the
roles of the incumbents, or is seeking to construct a system that will
ultimately have low virtue.

-Chaud Lapin-

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen wrote:

> It's not so much a matter of sufficiency as of ease. Without GC,
> you've got to be extra careful to manage lifetime issues. You
> can't just hand out a pointer to an object for fear it will be
> squirreled away somewhere. Interfaces become cluttered with
> smart pointer parameters, with everyone rolling their own
> implementations.

And with GC, you've got to be even more careful to manage lifetime 
issues. You can't just entrust class destructors with resource clean-up 
for fear they might be called at an inappropriate time. Interfaces 
become cluttered with Dispose calls, with everyone developing their own 
idea what exactly is destroyed when, if at all.

-- 
Gerhard Menzl

Humans may reply by replacing the obviously faked part of my e-mail 
address with "kapsch".

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Keith H Duggar wrote:
> Or the question is as is and he simply wanted examples of
> cases that require garbage collection.

OK. Assuming you're right, he might want to investigate why GCC
went to garbage collection after decades of using C-style memory
allocation techniques.

He also says in the same post that "I have very much trouble
figuring out why anyone would want to perturb a language like
C++ with things like gcnew" which I count as being on the
"change is bad" side of the ledger.

> argument : It is desirable, because it is desired.
> flaw     : tautology
>            red herring
>            circular argument
>            begging the question
>            argumentum ad populum (appeal to public)

That is, it is desirable to have a programming language
which supports GC becuase there are many programmers who
desire it. No logical flaw in that, and no logical flaw
in a company giving its programmers and customers what
they want. Rather, good business sense.

> argument : Many programmers feel profound relief at not
>            having to deal with endless varieties of smart
>            pointers and worrying about object lifetimes.
> flaw     : red herring
>            argumentum ad populum
>            argumentum ad numerum (appeal to numbers)

You keep implying that appealing to the public and to
numbers in programming language design is a logical flaw.
No one has made you, or anyone else, lord and master of
what language programmers may use. Generally, programmers
or their organizations choose what language they want to
use, and therefore appealing to them is very much the point.
And it is not a red herring - it addresses the issue that
necessity is not the only criterion for adding GC to a
languge.

> argument : No one is forcing you to use it if you choose
>            not to
> flaw     : red herring
>            straw man

This addresses those people who do not want GC to be part of
C++. They cannot prevent others from adding it, but they are
free not to use itthemselves.

> argument : It is a problem that Microsoft has chosen to solve
>            by extending the existing language.
> flaw     : red herring
>            complex question
>            argumentum ad verecundiam (appeal to authority)

The authorities in this case are people who are extremely
respected in the design and theory of C++. There is not much
in the way of argument against them that their design is
flawed or unworkable, merely that some find it, and GC in
general, unappealing.

> argument : Microsoft is providing what their customers and
>            their own developers want.
> flaw     : begging the question
>            dicto simpliciter (generalization)
> 
> and throughout your post argumentum ad nauseam (repetition).

Yes. And to repeat again, many programmers want GC, because it
relieves them of a burdensome and unnecessary responsibility.
GC is not a new concept, and is present in many other languages.
As a programming language, C++ confers many advantages not present
in other languages. Therefore, combining C++ and GC might result
in a language with the adevantages of both. Microsoft has chosen
to attempt such an integration, and has come up with a language
design which is logically coherent and minimally invasive of its
host language. It is choosing to standardize this design so that
its semantics will be public and unambiguous. It is a separate
standard from its host language, and anyone who does not want to
use it or implement it is free not to. Microsoft has done the work
itself; it has not demanded that others pay for its efforts (except
for those who will become customers of its implementation). C++ is
an open language - no one has the right to prevent another from
making these sorts of additions and changes, unlike Java for example.
The arguments that this is unacceptable simply because Microsoft is
the source is of course also flawed - it's appeal to anti-authority,
if you will.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Le Chaud Lapin wrote:
> For the record, have not pointed out any flaws in your argument, nor
> ranted against Microsoft, nor told anyone to go away (I am a firm
> believer in getting things out in the open and debating them), nor
> demanded anything.  However, if I may take a quick stab at Microsoft,
> I would not be suprised if they were very interesting making the
> language more sluggish.  :)

Sorry my antecedent wasn't clear. I was talking about Tommy, not you.

> As several have pointed out, this is not a good reason for adding GC,
> because there are many places in the language where one has to be
> "careful".  If obviating prudence is a goal, then the goal should be
> sought universally, something not practical in C++ if the language is
> to retain its fundamental character.

No, this is not correct. A solution to a problem does not have to be
universally applicable to be useful. GC eliminates worrying about
object lifetimes and ownership in many cases, and relegates the burden
of dealing with those to the system. Where cases arise that this is
insufficient, they can then be dealt with in other ways, and indeed the
merging of C++ and GC facilitates this.

If I may make a perhaps silly counter argument, people use computers
quite successfully for numeric calculation despite the fact that the
numbers representible in typical programming languages form an
infitesimal subset of all possible numbers.

> What is more important than growing the primitive set is keeping the
> primtive set regular.  Regularity of the primitive set is one of our
> bastions against complexity.  It allows our systems to scale.

And "a foolish consistency is the hobgoblin of small minds". It is
difficult to know a priori whether C++/CLI is irregular in the way
you suggest. C++ itself has separte classes of pointers to data,
pointers to functions, and pointers to members. Memory may be
allocated through malloc, new, and new[]. Declarations ambiguosly
declare data or functions. Over a decade after its standardization
there are still almost no compilers which implement the full language.
Attempting to halt further changes on the grounds of irregularity are
almost laughable.

In any case, we have a compnay which is very kindly doing the specification
and implementation of this new feature set, so we will have experience to
guide us in whether the results are useful, beautiful, and virtuous. This is
the same way in which most of C++ was designed, except for the bad parts.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Maciej Sobczak wrote:
> Then you decide to encapsulate some reference to some resource other
> than memory (like DB statement) inside the class (after all,
> *encapsulation* is about hiding, so nobody's going to be affected,
> right?). And this is where you lose, because there is no way to
> automagically enforce deterministic destruction of all those objects.
> Once you allow the class to be GCed, it is doomed to be GCed forever.
> All this happened because you thought there is something special or
> unique about memory.

But unless you designed your original class to disallow dynamic
allocation altogether, there is nothing to stop users from new'ing
as many of these objects as they want and keeping them around as
long as they want, and there is nothing to stop them from leaking
should the users write the code that way.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <u-OdneMKRrs8EmHdRVn-pg@comcast.com>, David Hilsee 
<davidhilseenews@yahoo.com> writes
>Could you explain the benefit of such an approach over using "cleanup
>handlers" to dispose of arbitrary resources?  I'm having a hard time
>thinking of one, especially considering the fact that, in my experience,
>virtually every resource is represented as some sort of object.  In short,
>what if we asked the question "why" instead of "why not?"

The advantage is consistency.  Memory only GC treats memory as if it 
were some special resource and forces programmers to consider 
deterministic finalisation of any object that owns some resource that is 
not memory. That results in two competing mechanisms and imposes extra 
complexity on the design of objects.

-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

<snip>

> argument : No one is forcing you to use it if you choose
>            not to
> flaw     : red herring
>            straw man
> 
> argument : It is a problem that Microsoft has chosen to solve
>            by extending the existing language.
> flaw     : red herring
>            complex question
>            argumentum ad verecundiam (appeal to authority)
> 
> argument : Microsoft is providing what their customers and
>            their own developers want.
> flaw     : begging the question
>            dicto simpliciter (generalization)
> 

<snip>

Simply asserting that some argument is a "red herring" or "straw man"
without justification does not further the debate, neither does the
pretentious use of Latin terms from rhetoric.

Cheers,

Dave

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 2004-07-20 07:59, Maciej Sobczak wrote:
> Niklas Matthies wrote:
> [...]
> > Of course this doesn't mean that garbage collection cannot be extended
> > to handle any kind of resources and any conceptual dependencies
> > between them, but memory will always have a unique role in this.
>
> And this is what bothers me a little bit.
>
> Treating memory in a special way is like closing your way to further
> evolution of your code.

Not really. The only assumption is that _references_ to any resources
are held in memory, or held by other resources referenced by memory,
and so on in a recursive fashion. In other words, the requirement is
that the roots of the complete resource dependency graph reside in
memory.

When this condition is met, it follows that a resource becomes
collectible only by losing its last (direct or indirect) in-memory
reference. The (garbage-)collection of the C++ object containing the
reference-to-non-memory-resource can trigger a finalizer method which
can then perform the release of this reference. (And of course this
can be abstracted away by having a smart_resource_reference type whose
finalizer releases the reference.) Thus it's only a local change in
the implementation of the C++ object representing the resource.

-- Niklas Matthies

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Ioannis Vranos wrote:
> Stephen Howe wrote:
<snip> 
>> (i) destruction issues - does my destructor get called? What if my class is
>> managing some critical resource and it is vital that it is freed at once.
>> There is no problem with straight C++. We know when the destructor is
>> called. Would finalisers be necessary to add to the language?
> 
> Finalizers are the destructors of the managed classes and are 
> implemented as regular destructors and are called when the object is 
> destroyed as usual.

Finalisers are quite different from destructors and conflating the two
can lead to serious bugs.  See Boehm's 2002 paper "Destructors,
Finalizers, and Synchronization"
<http://www.hpl.hp.com/techreports/2002/HPL-2002-335.pdf>.

C# somewhat mixes up the two by having finaliser declarations that
look like C++ destructor declarations, and ISTR that the same
mistake was made in Managed C++.

Most .NET classes do not need either destructors or finalisers but
those that hold non-memory resources should provide a standard means
to release them explicitly by implementing the IDispose interface,
roughly corresponding to a C++ destructor, as well as having
finalisers.

C++/CLI distinguishes the two, using a "!" rather than a "~" for
finaliser declarations.  Any ref class in C++/CLI with a non-trivial
destructor implicitly implements the IDispose interface.

<snip> 
> // Managed object in the GC heap
> // It is destroyed by the garbage collector
> whatever ^p=gcnew whatever;
<snip>

If I am not mistaken, the GC will finalise p if it has a finaliser
but its destructor will not be called implicitly.  So long as
"whatever" does not hold non-memory resources this shouldn't be a
problem.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Stephen Howe wrote:
<snip>
> It remains to be seen whether long-term it is successful. The jury is still
> out. TTBOMK, MS now recognises the limitations of COM programming and AFAIK,
> there is no serious development of it. Perhaps, given time, .NET will go the
> same way?
<snip>

COM isn't dead; it's just changed.  COM became COM+ became COM+ 2.0
which was renamed and expanded into .NET.  You can still use old COM
components in .NET, though they will of course be unmanaged.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

{Moderator's note: this is moving considerably off-topic. Please either
discontinue this thread or set up a Followup-To: header directing it to
a more appropriate forum when replying. Thank you. -mod/dk}

> If someone could use formal logic to prove that it is always better to use
> GC than to not use GC, then I would be utterly shocked.

Nobody, myself included, mentioned formal logic. (Your statement is an
example of a red herring.)

Logical flaws (logical fallacies, flaws in reasoning) do apply to
informal logic and thus to the arguments in this thread.
 
> In this discussion, we are not probing for any "universal truth" on GC.

Another red herring. No one implied a probe for "universal" truth.
However, the guidelines of logic and argumentation are useful for any
debate such as this one. They help us all to avoid common fallacies
and focus instead on making sounds arguments and using sound reasoning
rather than slinging poorly constructed thoughts around. And thus they
expedite our search for a "coherent" truth and mutual understanding.

> I just wanted to point out that these "logical flaws" don't mean
> that his points should be discarded without consideration.

I agree completely. To do so would be an example of argumentum ad
logicam. This is an example why awareness of basic logical fallacies
is important for all of us engaged in debate.

> However, I do think that the term "logical
> flaw" was accidentally misused.

I think this may help you judge whether it was in fact "accidentally
misused"

http://en.wikipedia.org/wiki/Logic#Formal_and_informal_logic

There are a number of excellent resources regarding logic (informal is
what I have in mind of course) and the common fallacies. I recommend
brushing up on them as I think you will find them a most useful aid in
reasoning.

Keith

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <HQ4Lc.24957$F8.20552@nwrdny02.gnilink.net>, Hyman Rosen 
<hyrosen@mail.com> writes
>Over a decade after its standardization
>there are still almost no compilers which implement the full language.
>Attempting to halt further changes on the grounds of irregularity are
>almost laughable.

Well let us be fair and not exaggerate. The final document that became 
the first C++ Standard in 1998 was agreed in 1997, seven years is not 
more than a decade:-)


-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Gerhard Menzl <gerhard.menzl@spambucket.net> writes:

> Hyman Rosen wrote:
>
>> It's not so much a matter of sufficiency as of ease. Without GC,
>> you've got to be extra careful to manage lifetime issues. You
>> can't just hand out a pointer to an object for fear it will be
>> squirreled away somewhere. Interfaces become cluttered with
>> smart pointer parameters, with everyone rolling their own
>> implementations.
>
> And with GC, you've got to be even more careful to manage lifetime 
> issues. You can't just entrust class destructors with resource clean-up 
> for fear they might be called at an inappropriate time. Interfaces 
> become cluttered with Dispose calls, with everyone developing their own 
> idea what exactly is destroyed when, if at all.

And yet, there is a large category of applications where this sort of
thing almost never occurs.  There was no big outcry about GC before
Java came along, at least not that I remember.  The presence of GC in
Lisp and Python (and...) systems is not normally seen as a problem.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Francis Glassborow wrote:
> The advantage is consistency.  Memory only GC treats memory as if it 
> were some special resource and forces programmers to consider 
> deterministic finalisation of any object that owns some resource that is 
> not memory. That results in two competing mechanisms and imposes extra 
> complexity on the design of objects.

As someone already posted, it's the self-referential properties
of memory that make it so special. I can think of an analogy -
in a structured file system, you should be able to delete a
directory and have the system collect the space taken by all
files and subdirectories of that directory.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In message <u-OdneMKRrs8EmHdRVn-pg@comcast.com>, David Hilsee
<davidhilseenews@yahoo.com> writes
>"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
>news:Ja$9oIPp3P+AFwb4@robinton.demon.co.uk...
  <snip>
> > Indeed, but that still makes garbage collection mean 'recover unused
> > memory'. Why define garbage as specifically memory? Why not include
> > file-handles and other limited resources and force a garbage collection
> > round whenever one of those resources becomes exhausted?
>
>Could you explain the benefit of such an approach over using "cleanup
>handlers" to dispose of arbitrary resources?

Because it's garbage?

Because so many people get it wrong that it's hurting commerce and
industry?

Because it's a Quality Of Implementation issue?

These are the reasons given by garbage collection enthusiasts.

>I'm having a hard time
>thinking of one, especially considering the fact that, in my experience,
>virtually every resource is represented as some sort of object.  In short,
>what if we asked the question "why" instead of "why not?"

And this is the reason given by those who aren't enthusiastic.

Both are valid points of view, but saying that some kinds of garbage are
special is *not* valid.

  John
-- 
John Harris

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Man, I've been trying to reply to stuff for days, and after seeing
nothing pop up in a long time I finally looked to see if Google Groups
sends messages posted to both moderated and unmoderated groups only to
the moderated one, and indeed that is what it does. That would have
been a real fricking handy thing to tell people who are doing so
before they sit around for days wondering why the heck their posts
aren't even showing up on unmoderated groups. Since I'm invariably
silenced by the comp.lang.c++.moderated censors (seems to be the
popular thing to do these days if you don't tow the party line
regarding garbage collection), I'll have to start posting the exact
same thing to both groups separately. What a great piece of brilliance
this system is.

Hyman Rosen <hyrosen@mail.com> wrote in message news:<9w4Lc.24933$F8.7083@nwrdny02.gnilink.net>...
> Keith H Duggar wrote:
> > Or the question is as is and he simply wanted examples of
> > cases that require garbage collection.
> 
> OK. Assuming you're right, he might want to investigate why GCC
> went to garbage collection after decades of using C-style memory
> allocation techniques.

That's not an example of a problem that requires garbage collection.
He could ask the Java monkeys until he turns blue in the face why they
personally prefer garbage collection, but that is still not an example
of a problem that requires garbage collection. You are the one
advocating garbage collection ueber alles here; you provide the
examples. He asked here, not the GCC people.

> He also says in the same post that "I have very much trouble
> figuring out why anyone would want to perturb a language like
> C++ with things like gcnew" which I count as being on the
> "change is bad" side of the ledger.

Count it as whatever you want to. The rest of us will count it as
being on the "things like gcnew are bad" side of the ledger; actually,
that can be refined to being on the "things like gcnew are bad for
C++" side of the ledger.

> > argument : It is desirable, because it is desired.
> > flaw     : tautology
> >            red herring
> >            circular argument
> >            begging the question
> >            argumentum ad populum (appeal to public)
> 
> That is, it is desirable to have a programming language
> which supports GC

Bzzt, wrong answer. There is not "a" programming language which
supports garbage collection, there are a buttload of programming
languages which support garbage collection, including C++ with
appropriate libraries.

> becuase there are many programmers who
> desire it.

There are also many programmers who do not desire it. Many programmers
don't like anything that hurts their heads more than Visual Basic and
probably want MFC inserted into C++, but now I am just repeating stuff
I already told you. Reread and try again.

> No logical flaw in that, and no logical flaw
> in a company giving its programmers and customers what
> they want. Rather, good business sense.

Already discussed. Reread and try again.

> > argument : Many programmers feel profound relief at not
> >            having to deal with endless varieties of smart
> >            pointers and worrying about object lifetimes.
> > flaw     : red herring
> >            argumentum ad populum
> >            argumentum ad numerum (appeal to numbers)
> 
> You keep implying that appealing to the public and to
> numbers in programming language design is a logical flaw.
> No one has made you, or anyone else, lord and master of
> what language programmers may use.

Meaning that they don't have to use bad old C++, they can use any of
the garbage collected languages out there. Or even garbage collection
libraries for C++.

> > argument : No one is forcing you to use it if you choose
> >            not to
> > flaw     : red herring
> >            straw man
> 
> This addresses those people who do not want GC to be part of
> C++. They cannot prevent others from adding it, but they are
> free not to use itthemselves.

Thank you for pointing that out, no one had seen you mention it over
and over and over and .... This was already discussed. Reread and try
again.

> > argument : It is a problem that Microsoft has chosen to solve
> >            by extending the existing language.
> > flaw     : red herring
> >            complex question
> >            argumentum ad verecundiam (appeal to authority)
> 
> The authorities in this case are people who are extremely
> respected in the design and theory of C++. There is not much
> in the way of argument against them that their design is
> flawed or unworkable, merely that some find it, and GC in
> general, unappealing.

And weren't you the same guy who was all about appealing to people
about three paragraphs up?

> > argument : Microsoft is providing what their customers and
> >            their own developers want.
> > flaw     : begging the question
> >            dicto simpliciter (generalization)
> > 
> > and throughout your post argumentum ad nauseam (repetition).
> 
> Yes. And to repeat again, many programmers want GC, because it
> relieves them of a burdensome and unnecessary responsibility.

Already discussed. Reread and try again.

> GC is not a new concept, and is present in many other languages.

That's nice. So?

> As a programming language, C++ confers many advantages not present
> in other languages.

Yes, why not take this unique blend of studliness and turn it into C#
or Java.

> Therefore, combining C++ and GC might result
> in a language with the adevantages of both.

Or more likely, the disadvantages of both. C++ has already proven
itself for decades (roughly).

> It is choosing to standardize this design so that
> its semantics will be public and unambiguous.

You forgot the part about "so that it can later ignore the standard
and introduce incompatibility, as is its way."

> It is a separate
> standard from its host language

That does not mean that it will remain so. And as I have said, that is
the main issue in all of this.

> Microsoft has done the work
> itself; it has not demanded that others pay for its efforts (except
> for those who will become customers of its implementation).

You must think they grow their money on money trees. Just because they
did not pass around a 'CLI standardization invoice' does not mean that
people have not paid for it (those unfortunate enough to use their
stuff).

In any case, I think it is safe to say that you fully believe in the
logical legitimacy of argumentum ad nauseam (for those whining about
big words, "the false conception that a statement is likely to be true
if it has been repeated over and over many times, possibly by
different people," http://www.fact-index.com/a/ar/argumentum_ad_nauseam.html).

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/epuVB8FYP9YqDcRAuG2AJ9UHQOohen6x3TYPrsef2hZqtdJKgCeOXvq
qd1RERK+dkWxunimM8kpRIo=
=qyWO
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

david.boyle@ed.tadpole.com (Dave Boyle) wrote in message news:<30e6e0a8.0407200259.4d80fcdb@posting.google.com>...
> <snip>
> 
> > argument : No one is forcing you to use it if you choose
> >            not to
> > flaw     : red herring
> >            straw man
> > 
> > argument : It is a problem that Microsoft has chosen to solve
> >            by extending the existing language.
> > flaw     : red herring
> >            complex question
> >            argumentum ad verecundiam (appeal to authority)
> > 
> > argument : Microsoft is providing what their customers and
> >            their own developers want.
> > flaw     : begging the question
> >            dicto simpliciter (generalization)
> > 
> 
> <snip>
> 
> Simply asserting that some argument is a "red herring" or "straw man"
> without justification does not further the debate

The justifications for calling things as he did are obvious to anyone
with a half logical mind. Calling crap crap instead of going around
pretending it makes sense does in fact further the debate.

> neither does the
> pretentious use of Latin terms from rhetoric.

You mean calling things what they are called? It's bad enough how
things are reduced to retarded degrees by the mainstream media, but
this has to be the first time I have seen someone complain about
people using big words in a technical conversation. What the heck is
the world coming to?

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/ezuVB8FYP9YqDcRAoN6AJ988uozLAaM+P+V550ArPTmnGGUvgCeOCcV
vhr0FwQIa7A9AEOHPO+vtqQ=
=9uGS
-----END PGP SIGNATURE-----

Francis Glassborow wrote:
 > Well let us be fair and not exaggerate. The final document that became
 > the first C++ Standard in 1998 was agreed in 1997, seven years is not
 > more than a decade:-)

Yes, sorry, I was thinking 1989.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Gerhard Menzl wrote:
 > And with GC, you've got to be even more careful to manage lifetime
 > issues. You can't just entrust class destructors with resource clean-up
 > for fear they might be called at an inappropriate time. Interfaces
 > become cluttered with Dispose calls, with everyone developing their own
 > idea what exactly is destroyed when, if at all.

This is exactly why C++/CLI is perceived to be a good idea.
You get the benefits of GC and the benefits of RAII on a
class-by-class basis, by your own choice.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

M Jared Finder <hpalace@hpalace.com> wrote in message news:<2lt78iFfvmukU1@uni-berlin.de>...
 > Stephen Howe wrote:
 >  >>Enter garbage collection, the "Botox" for memory management.  No
 >  >>matter how careless you have been with your your face (design), Botox
 >  >>will come up behind you and clean up the mess.
 >  >
 >  >
 >  > If you are going to employ GC for memory resources, why stop there?
 >  > Why not employ GC techniques for all OS resources, e.g. file handles?
 >
 > Don't all modern operating systems already implement garbage collection
 > on the process level?  So if a program forgets to release some memory or
 > close a file, the OS will clean up on process termination.

Yes, this is true, most if not all of the heavy-weights prevent zombie
memory from hanging around after the process dies.  As Yoda might
say...the kernel ensures that the process *is* or *is not*, and that
all associated resources *are* or *are not*.  However, while a process
lives, it might:

(1) acquire resources
(2) use them
(3) no longer need them
(4) but not tell the kernel that they are no longer needed

GC is used to solely for this second scenario - determining within a
process as it lives if a resource is no longer needed, and if so,
forcing a relinquisment to the kernel.

-Chaud Lapin-

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1090358682.341761@master.nyc.kbcfp.com...
 > Francis Glassborow wrote:
 > > The advantage is consistency.  Memory only GC treats memory as if it
 > > were some special resource and forces programmers to consider
 > > deterministic finalisation of any object that owns some resource that is
 > > not memory. That results in two competing mechanisms and imposes extra
 > > complexity on the design of objects.
 >
 > As someone already posted, it's the self-referential properties
 > of memory that make it so special. I can think of an analogy -
 > in a structured file system, you should be able to delete a
 > directory and have the system collect the space taken by all
 > files and subdirectories of that directory.

Your point about the self-referential nature of memory makes me wonder how
GC for resources would work.  Most resources are represented by a handle,
which is held in memory.  If the resource GC wanted to determine that a
resource could be collected, then it seems that the resource GC would have
to determine if its handle is reachable, which is the same thing a memory GC
would do if it wanted to determine if it could release the memory that holds
the handle.  If that is true, then how is the resource GC any different from
the memory GC?  Am I missing something?  Is the key change in the way
finalization is defined for resources?  If so, how should it be defined, if
the "cleanup handler" approach is unacceptable?

-- 
David Hilsee



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"John G Harris" <news0@nospam.demon.co.uk> wrote in message
news:657x63C08X$AFw3Q@jgharris.demon.co.uk...
 > In message <u-OdneMKRrs8EmHdRVn-pg@comcast.com>, David Hilsee
 > <davidhilseenews@yahoo.com> writes
 > >"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
 > >news:Ja$9oIPp3P+AFwb4@robinton.demon.co.uk...
<snip>
 > >Could you explain the benefit of such an approach over using "cleanup
 > >handlers" to dispose of arbitrary resources?
 >
 > Because it's garbage?
 >
 > Because so many people get it wrong that it's hurting commerce and
 > industry?
 >
 > Because it's a Quality Of Implementation issue?
 >
 > These are the reasons given by garbage collection enthusiasts.

I was looking for a comparison.  How will this not be true if non-memory
resources have a GC?

After thinking about it a bit, I can see that there can be an advantage to
having resource-specific properties that a GC uses to determine lifetimes.
If one could specify the number of resources of a specific type that can be
created before the GC needs to be concerned about removing them, then it
might be easier to customize the behavior of the GC so it cleans up
resources of a certain type more frequently than those of other types.  I'm
not sure if that's really a benefit in the long run, though, because similar
functionality could be attained by simply ascribing those properties to
instances of certain classes.

-- 
David Hilsee



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

So far this thread seems lacking in concrete examples in
response to Lapin's original request. In contrast, there has
been a lot of discussion and posturing relating to desires,
feelings, accusations, rights, good business, C++/CLI
standardization, etc.

To quote Terje's excellent recast of Lapin's question:

 > It may be better to approach it from the angle to ask: What kind of systems
 > or problems are hard to handle using non-garbage collection techniques
 > (including smart pointers), and which are easier to handle with garbage
 > collection?
 >
 > I think this is the crux of the issue - why garbage collection? What
 > problems does it solve, or solve better, that we can't solve using the
 > existing language features?
 >
 > This may bring the discussion in a more constructive direction, and which
 > also seems to be in the spirit of the OP.
 >
 > Anyone care to pick up the gauntlet?

The only two sub-threads that even attempt to address this
are the two started by Ivan Vecerina and Mike Capp which discuss
circular ownership.

However, I'm having trouble seeing why circular ownership is such
a problem. Don't smart pointers (I had in mind boost::shared_ptr)
handle circular ownership well? If not, how so? Example?

Or can anyone provide concrete examples or references to examples of
other situations difficult to handle without garbage collection (GC)?

For example, I read the following wiki

http://c2.com/cgi/wiki?AlgorithmsThatDemandGarbageCollection

which claimed that a paper by William Pugh on concurrent skip-lists
used GC. Upon reading the paper I found no mention of GC; rather I
found an explicit mention of C with malloc and free which is clearly
not GC.

As a second example consider

http://www.hpl.hp.com/personal/Hans_Boehm/gc/example.html

which claims to give an example where GC is great and deterministic
destruction would cause lots of problems. However, it seems that
simply replacing the index table T of pointers with an index table
T' of share_ptr's would also solve this difficulty. And it is not
clear to me how GC would offer any advantage over this.

And please, let's try our best to confine this sub-thread to concrete
examples and technical points that aim to address the question as
recast by Terje in a constructive manner.

Keith

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

duggar@mit.edu (Keith H Duggar) wrote
 > > >> In any case, GC is a feature which is deemed desirable,
 >  > >
 >  > >Or alternatively, it is a feature which is deemed undesirable.
 >  >
 >  > Well in the case of GC it wasn't deemed undesirable by the languages
 >  > creator.
 >
 > None-the-less, Tommy was absolutely correct in pointing out the
 > circularity and hence logical pointlessness of Hyman's comment.

Like abortion, the issue of GC has nothing to do with facts.

 > In
 > fact, Hyman quoted a portion of Le Chaud Lapin's post that he implied
 > he was answering
 >
 > Le Chaud Lapin wrote:
 >   > Is garbage collection necessary?

 > which clearly asks nothing about "desirability". The question seemed
 > very clear, is it necessary? He was not asking for a survey of those
 > who do or do not want C++ to be gargabe collected.

The word "necessary" in this context is loaded.

Look at the standard and start asking yourself if various features are
"necessary."

Do we need unary operators? We could have handled memory management
(new, delete, *, &) differently. If the parens in sizeof() had been made
mandatory, we might not consider sizeof to be unary. I can't think of any
others that are "necessary". -x is the same as 0-x, +x is the same as x,
++x is the same as x+=1, etc.

Do we need all those math functions? Third party libraries do a fine job
for matrix math, statistics, etc. There's no reason (except C compatibility)
that we had to include sin, cos, tan, etc. in the library -- while certain
scientific programs need this, most business programs do not.

Do we need data type "float"? For C compatibility we could almost have left
this out -- it used to automatically convert into type double when you
called a function. What's float got that double hasn't got?

On the other hand, I've seen people argue that C++ is missing some important
features that are present in the oldest languages, such as Fortran and COBOL.
COBOL in particular can have numbers in Binary Coded Decimal, which C++
cannot process natively. Would you say that BCD is "necessary?" It surely
is for someone trying to rewrite a package in C++, using existing data files
written from COBOL.



The C++ language as it stands today does not have GC. The language is
viable. I think this leads to an obvious observation that it is not
"necessary."

Is it useful? Clearly it is. Would it's benefit outweigh it's costs? This
is not so obvious.

Does GC make sense for all platforms? If GC were added to the standard,
then any implementation that did not supply it would become non-standard --
which makes sense, because programmers would come to expect it, and running
programs written with this expectation in an environment without GC would
then lead to terrible consequences.

On the other hand, C++ has a reputation for being a tough language. Most of
this reputation is unfair, caused by programs using pointers and casts
where they shouldn't... so that the most trivial bug manifests itself in
difficult-to-trace ways. Adding GC wouldn't stop people from using pointers
when they shouldn't, or using casts when they shouldn't ... but it would
drastically reduce the bugs caused by these bad techniques.

So there are facts on both sides. GC is useful, but not to the point that
anyone should call "necessary."

Facts are not going to sway anybody on either side of this issue.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<HQ4Lc.24957$F8.20552@nwrdny02.gnilink.net>...
[snipped]
 > No, this is not correct. A solution to a problem does not have to be
 > universally applicable to be useful. GC eliminates worrying about
 > object lifetimes and ownership in many cases, and relegates the burden
 > of dealing with those to the system.

So do destructors.

 > Where cases arise that this is
 > insufficient, they can then be dealt with in other ways, and indeed the
 > merging of C++ and GC facilitates this.

Per my original post, I have not yet seen an example where destructors
are insufficient to solved memory reclamation, so to me, the
sufficiency of GC is irrelevant.  In those rare cylic reference
situations mentioned in this thread, my gut feeling is that the
reclamation problem can be solved entirely using the mechanisms of the
existing language.

 > > What is more important than growing the primitive set is keeping the
 > > primtive set regular.  Regularity of the primitive set is one of our
 > > bastions against complexity.  It allows our systems to scale.
 >
 > And "a foolish consistency is the hobgoblin of small minds". It is
 > difficult to know a priori whether C++/CLI is irregular in the way
 > you suggest.

I disagree with this.  One does not need to go into the cave to infer
that a bear lives in it.  One only need look at the scratch marks on
the tree bark near the entrance.

The architect uses his imagination to imagine what his creation would
be like before comitting to it.  This is why so many pet proposals get
rejected.  The architect sees clearly that an artifact will have poor
virtue without actually experiencing it.  The ability to this do this
depends on the vision of the architect, and the absurdity of the
proposal.

 > C++ itself has separte classes of pointers to data,
 > pointers to functions, and pointers to members. Memory may be
 > allocated through malloc, new, and new[].

Malloc was good, but new was necessary.  Without new, there would be
no means of automatically invoking a constructor.  The same holds true
for delete.  new[] was created as a distinct mechansim after
considering the overall design space, again, to maintain regularity.
Again, the architect exercised vision in making this determination.

 > Declarations ambiguosly
 > declare data or functions. Over a decade after its standardization
 > there are still almost no compilers which implement the full language.

C++ is not perfect, but imperfection is not a reason to make it even
less perfect.  The perennial question is, "Will it be more or less
virtuous if GC is added?"

 > Attempting to halt further changes on the grounds of irregularity are
 > almost laughable.

I never said the language should remain static.  I said that if an
addition is made, care should be taken to preserve the functional
orthogonality of the primitive set.  Adding GC would be redundant.

 > In any case, we have a compnay which is very kindly doing the specification
 > and implementation of this new feature set, so we will have experience to
 > guide us in whether the results are useful, beautiful, and virtuous. This is
 > the same way in which most of C++ was designed, except for the bad parts.

"feature set", "managed code"...I will not deny the manipulative power
of Microsoft.  What is remarkable is that they employ the same basic
strategy with repeated success:

1. identify the threat (in this case, C++)
2. taint it somehow and skew it toward their (proprietary) tool set
3. apply euphemisms to the foul smelling parts for Wall Street types

Perhaps it is time that we started giving them a taste of their own
medicine.  After all, giants are vulnerable too, and I can think of
several major achille's heels of Microsoft. I can think of one that
would give companies like Sun, Nokia, IBM, Yahoo, and Google enormous
penetration into the desktop market even as the Redmond Giant spews
out new OS's.

If we do not defend the virtue of our creations, who will?

-Chaud Lapin-

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 2004-07-20 21:22, Niklas Matthies wrote:
 > On 2004-07-20 07:59, Maciej Sobczak wrote:
:
 >> Treating memory in a special way is like closing your way to further
 >> evolution of your code.
 >
 > Not really. The only assumption is that _references_ to any resources
[...]

I noticed that my follow-up doesn't quite correspond to what you
wrote... Sorry for that.

I'm still not sure what exactly your concern is though, and whether
you think there is a way to garbage-collect without treating memory
specially.

For a resource to be garbage-collected, it must be determined whether
it is still referenced by the program. There's pretty much only one
way a program can reference a resource, and that's by having a
reference of some sort stored in memory. So memory is inherently
special, as far as I can see.

Furthermore, such a reference becomes stale when the memory it is
stored in becomes unreachable by the program. In other words: when the
memory becomes collectable. Therefore it is natural (to a degree) that
garbage-collection of non-memory resources can only happen as a
consequence of memory garbage collection--or of explicit object
destruction.

If we accept this, then it also follows that the detection of a
non-memory resource shortage should trigger memory garbage collection
so that any desired non-memory resources become collected along the
way. This is a bit unfortunate because this procedure doesn't directly
focus on the specific type of resource which has run short, but just
collects any resources it can get in the hope that there are some of
the desired type among them.

With regard to deterministic destruction, there's no a-priori reason
why a class shouldn't be able support both deterministic destruction
and destruction induced by the garbage collector (i.e. finalization).
Of course there are all the well-known problems with finalization,
but basically this "only" means that there are some additional
restrictions on finalizers compared to C++ destructors, and that
finalizer methods often cannot be directly used for deterministic
destruction because they may need to acquire a lock on some resource
which the current thread already has a (seperate) lock on.
But a class could provide both finalizer and deterministic destructor,
hence I don't see a lock-in of a class to GC usage. There may or may
not be a lock-in of specific instances depending on how the garbage
collector works.

There's just one caveat that if destruction and memory deallocation
are to be decoupled, then the garbage collector will need some way to
determine whether the object was already (deterministically) destroyed
(or perhaps the finalizer will need it if finalizers and destructors
are not the same method).

BTW, I stumbled over this[1] interesting article which talks about
about some problems with finalization in the .NET CLR and how they try
to provide more guarantees for finalizers.

    [1] http://blogs.msdn.com/cbrumme/archive/2004/02/20/77460.aspx

-- Niklas Matthies

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

John G Harris wrote:
> In message <u-OdneMKRrs8EmHdRVn-pg@comcast.com>, David Hilsee
><davidhilseenews@yahoo.com> writes
>>"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
>>news:Ja$9oIPp3P+AFwb4@robinton.demon.co.uk...
>  <snip>
>> > Indeed, but that still makes garbage collection mean 'recover unused
>> > memory'. Why define garbage as specifically memory? Why not include
>> > file-handles and other limited resources and force a garbage collection
>> > round whenever one of those resources becomes exhausted?
<snip> 
>>I'm having a hard time
>>thinking of one, especially considering the fact that, in my experience,
>>virtually every resource is represented as some sort of object.  In short,
>>what if we asked the question "why" instead of "why not?"
> 
> And this is the reason given by those who aren't enthusiastic.
> 
> Both are valid points of view, but saying that some kinds of garbage are
> special is *not* valid.

Some resources - e.g. files - *are* special, in that they are not
process-local and they have identity.  (Processes do usually contend
for memory, but one chunk of free memory is as good as any other.)
Files are different; if a process is slow to close a file then that
can have a serious impact on other processes.  If the file is used by
several processes following a locking protocol, other processes may be
blocked unnecessarily.  If the user or administrator wants to remove
the disk that the file's on, this is impossible or unsafe as long as
it's open.

Maybe an OS-level garbage collector could solve this, but that's not
something that can be expected from a C++ implementation!

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

David Abrahams wrote:
> And yet, there is a large category of applications where this sort of
> thing almost never occurs.  There was no big outcry about GC before
> Java came along, at least not that I remember.  The presence of GC in
> Lisp and Python (and...) systems is not normally seen as a problem.

I od not know for sure, but maybe these languages are not being used in
enterprise systems (ES) as much as Java is? I mean that ES is just one
area where resources footprint has well seen consequences. When early
adopters of .NET stared using C# in ES they also noticed that GC became
big problem (I have heard reports about applications spending 60% of
their CPU time in GC) *if* used without taking care of calling Dispose
at the right time. This is what C++/CLI is going to fix (from point of
view of .NET developer) when trying to apply deterministic destruction
(ie. C++ stack variables) in GC world.


B.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

David Abrahams wrote:

 > Gerhard Menzl <gerhard.menzl@spambucket.net> writes:
 >
 >>And with GC, you've got to be even more careful to manage lifetime
 >>issues. You can't just entrust class destructors with resource
 >>clean-up for fear they might be called at an inappropriate time.
 >>Interfaces become cluttered with Dispose calls, with everyone
 >>developing their own idea what exactly is destroyed when, if at all.
 >
 >
 > And yet, there is a large category of applications where this sort of
 > thing almost never occurs.  There was no big outcry about GC before
 > Java came along, at least not that I remember.  The presence of GC in
 > Lisp and Python (and...) systems is not normally seen as a problem.

I hope you have noted that my reply to Hyman contained a tinge of parody.

There is no doubt that for certain applications resource leaks are not 
an issue. People have just become used to zap their web browsers once an 
applet starts to behave funny. I know I have. But how many 
mission-critical, 24/7 systems employ garbage collection? This is not 
intended to sound polemic; I am genuinely interested.


-- 
Gerhard Menzl

Humans may reply by replacing the obviously faked part of my e-mail 
address with "kapsch".

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen wrote:


 > This addresses those people who do not want GC to be part of
 > C++. They cannot prevent others from adding it, but they are
 > free not to use it themselves.

Incorrect. Once garbage collection is enforced through the interfaces of 
major vendors, you don't have a choice anymore. Saying that anyone is 
free not to use it is like saying that you are free to write portable 
C++ programs without using exceptions.

-- 
Gerhard Menzl

Humans may reply by replacing the obviously faked part of my e-mail 
address with "kapsch".

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen wrote:

 > But unless you designed your original class to disallow dynamic
 > allocation altogether, there is nothing to stop users from new'ing
 > as many of these objects as they want and keeping them around as
 > long as they want, and there is nothing to stop them from leaking
 > should the users write the code that way.

The difference being that in GC-based environments users of your class 
are more or less bound to new as many objects as they want and to keep 
them around as long as the garbage collector sees fit. And please don't 
get me started about Dispose() & kin.

-- 
Gerhard Menzl

Humans may reply by replacing the obviously faked part of my e-mail 
address with "kapsch".

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

John G Harris wrote:

 > Both are valid points of view, but saying that some kinds of garbage
 > are special is *not* valid.

I think that (as has been pointed out already) distinguishing between 
scarce resources, which require timely release, and plentiful resources, 
for which occasional cleanup is sufficient, *is* valid. For the first 
type, garbage collection is a no-no. Thread locks are the most obvious 
example, but there are other examples. I remember that in ancient 
versions of Windows it was of prime importance that certain graphical 
resources were held as short as possible, or the GUI would start to 
behave in a funny way. Naturally, the second type is suitable for 
garbage collection. But while memory is the most obvious example, there 
are embedded systems where it is not the abundant resource which to 
squander we have get used to on personal computers. On such systems, 
issues like fragmentation may rule out dynamic memory allocation (and 
hence garbage collection) altogether.

Note that this distinction is not binary; it rather defines a continuum. 
Depending on the degree of scarcity, garbage collection may work 
perfectly fine, reasonably well, poorly, or not at all. One thing is for 
sure: you can build any system, no matter how scarce its resources are, 
using deterministic clean-up only whereas mandatory garbage collection 
for all resources would make certain applications simply impossible to 
build.

-- 
Gerhard Menzl

Humans may reply by replacing the obviously faked part of my e-mail 
address with "kapsch".

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <fc2e0ade.0407201356.6cee063a@posting.google.com>, Le Chaud 
Lapin <unoriginal_username@yahoo.com> writes
>Yes, this is true, most if not all of the heavy-weights prevent zombie
>memory from hanging around after the process dies.  As Yoda might
>say...the kernel ensures that the process *is* or *is not*, and that
>all associated resources *are* or *are not*.  However, while a process
>lives, it might:
>
>(1) acquire resources
>(2) use them
>(3) no longer need them
>(4) but not tell the kernel that they are no longer needed
>
>GC is used to solely for this second scenario - determining within a
>process as it lives if a resource is no longer needed, and if so,
>forcing a relinquisment to the kernel.

That is a common misconception. In theory it is possible that a released 
resource is returned to the host OS, in practice it often isn't. Again, 
we often consider that using dynamic allocation of storage involves the 
OS. It can, and often does but that is not a requirement of C++. It is 
perfectly possible for the OS to hand a process a heap when it starts 
and when that is exhausted there is no facility for a second helping. 
However it is much more common that a process continues to acquire extra 
memory when it needs it but never returns that acquired memory until the 
process terminates. In fact, from the process viewpoint that is a much 
more efficient mechanism because what it once used it is likely to want 
to use again.

The problem with GC is that it is essentially a process level mechanism. 
It would be nice if we had some way that an OS could go round all 
running processes and ask them to hand back any unused resources but I 
am not aware of any OS that actually does that.

Co-operative GC might be quite a useful tool in our modern long running 
multi-tasking systems but we should not assume we already have it. And 
it would not be up to a language standard to provide it.



-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hi,

Niklas Matthies wrote:

> I'm still not sure what exactly your concern is though, and whether
> you think there is a way to garbage-collect without treating memory
> specially.
> 
> [...] So memory is inherently
> special, as far as I can see.

Yes, but only from the GC's point of view.
My point was to show that memory is not at all special from the *design* 
point of view, since the memory-oriented object may always become 
oriented towards additional types of resources (for example by embedding 
into the object a handle to external resource).

This is the problem: GC, for the technical resons pointed by you and 
other posters, views memory as a special (self-referential, etc.) 
resource. I, as a designer, want to treat all resources in a consistent way.
This difference means that I anticipate design problems with classes 
that were somewhere used with GC.

This also requires more emphasis: classes that -->were<-- used.
I do not care whether it is possible to have both destructors and 
finalizers. That's not the point. The point is that if *somebody* used 
your class with GC, you will not be able to enforce deterministic 
destruction of *those* objects, because you may not be even able to 
modify the source code where your class was used.

This means that once you say: "hey, people, look what a cool class there 
is for use with GC", you will not be able to say later: "hey, people, 
I've changed something *inside*, so please use only deterministic 
destruction with this class".
Nobody's going to fix the existing, GC-oriented code.

This is plain broken encapsulation.

I've seen this problem in practice, in Java code.
There was a class that was instantiated in a loop (not directly - there 
was a few function calls in between, so not everybody was aware that the 
class is instantiated in a loop).
No problem, GC occasionally collected the objects, and nobody cared.

Then a developer added a reference to the DB resource (a cursor) to one 
of the methods of the class. Of course, the finalizer method cleaned it 
up, as in every well-behaved class.

Guess what happened next?
The DB server *occasionally* (once for many runs of the program) run 
short of cursor handles. Occasionally, because most of the time the 
program balanced just below the limit of the number of active cursors.
It took a lot of debugging to discover it. The solution was to put 
additioinal code *outside* of the class, in the loop, to force the 
object to clean up after himself (let's call it "explicit" deterministic 
destruction), bypassing the GC, so that the number of active cursors was 
kept to minimum.
In other words, the internal change in the class required the user code 
to be changed as well.

I can imagine that such intrusion into existing code is not always possible.

In C++ code, if the stronger deterministic destruction was used from the 
ground up, there would never be any problem.

This is why I consider GC to be dangerous.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Keith H Duggar wrote:
> The only two sub-threads that even attempt to address this
> are the two started by Ivan Vecerina and Mike Capp which discuss
> circular ownership.

No, you have not paid attention to the posts where I point out
that GCC uses garbage collection internally. They use a form where
roots must be marked, and their source files have special notations
(macros and such) to guide the garbage collector.

It makes sense that a compiler has many circular ownership issues,
since things like mutually recursive structures are likely represented
by data structures which point to each other.

 > Don't smart pointers (I had in mind boost::shared_ptr)
 > handle circular ownership well? If not, how so? Example?

No, they do not, as you can see from
<http://www.boost.org/libs/smart_ptr/shared_ptr.htm>:
     "Because the implementation uses reference counting,
      cycles of shared_ptr instances will not be reclaimed."

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Le Chaud Lapin wrote:
 > In those rare cylic reference situations mentioned in this thread,
 > my gut feeling is that the reclamation problem can be solved entirely
 > using the mechanisms of the existing language.

Well, sure. They're all Turing complete. That's not the point.
The point is how easy it is to do so, as opposed to not having
to worry about it.

I will point once again to GCC, which implements garbage collection
for itself, and involves special markups in the source to guide the
collector. Here's a page with some description:
<http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html>
Another message from back in 1999:
<http://gcc.gnu.org/ml/gcc/1999-09n/msg00207.html>

> I disagree with this.  One does not need to go into the cave to infer
> that a bear lives in it.  One only need look at the scratch marks on
> the tree bark near the entrance.

You may be afraid of a posisble bear in the cave. That does not give
you the right to prevent other people from entering the cave, but you
may keep suggesting to them that it's a bad idea. This is well-worn
ground in C++. Look back on the fights over multiple-inheritance for
an example.

> new[] was created as a distinct mechansim after considering the overall
 > design space, again, to maintain regularity. Again, the architect exercised
 > vision in making this determination.

Poor vision. new[] does not maintain regularity. It exists as a hack so that
allocation of single objects does not require the bit of extra space to record
an array size. After all, what is the conceptual difference between allocating
one object and allocating an array of size one? My doubts about the bear in the
cave are now increasing.

> I said that if an addition is made, care should be taken to preserve the
 > functional orthogonality of the primitive set.  Adding GC would be redundant.

If C++ had functional orthogonality then class function templates could be
virtual. In fact, C++ is full of features that exist or don't exist for
reasons of convenience and implementability and efficiency and because no
one thought of them, and GC will be just another one of those things.

> "feature set", "managed code"...I will not deny the manipulative power
> of Microsoft.  What is remarkable is that they employ the same basic
> strategy with repeated success:
> 
> 1. identify the threat (in this case, C++)
> 2. taint it somehow and skew it toward their (proprietary) tool set
> 3. apply euphemisms to the foul smelling parts for Wall Street types

This is just incredibly silly. I now realize that the cave is empty.
I'm going in. Why in the world you think that Microsoft considers C++
to be a threat I don't know, given that all of their own products are
written in it, as well as the APIs that others use to access their
products. You are obviously incapable of judging C++/CLI on technical
merits because you are blinded by your hatred of its creator.

> If we do not defend the virtue of our creations, who will?

If you protect your virtue with enough diligence, you will never
have children. You cannot see that Microsoft is doing its best to
improve C++. It remains to be seen whether the attempt is successful,
but that is clearly the motive.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Keith H Duggar wrote:
> 
> However, I'm having trouble seeing why circular ownership is such
> a problem. Don't smart pointers (I had in mind boost::shared_ptr)
> handle circular ownership well? If not, how so? Example?

Reference counting by itself cannot handle circular ownership.  In
practice I haven't found this to be a problem since dtors are usually
aware of the data structure and can take that into account by breaking
any cyclic reference loops if required .

> 
> Or can anyone provide concrete examples or references to examples of
> other situations difficult to handle without garbage collection (GC)?
> 
> For example, I read the following wiki
> 
> http://c2.com/cgi/wiki?AlgorithmsThatDemandGarbageCollection
> 
> which claimed that a paper by William Pugh on concurrent skip-lists
> used GC. Upon reading the paper I found no mention of GC; rather I
> found an explicit mention of C with malloc and free which is clearly
> not GC.

There are lock-free algorithms that use some form of GC (Boehm style
isn't the only form) to defer deletion of resources until after they
are no longer being references.  The other forms besides Boehm style
are reference counting, M. Michael's SRM pointers, and McKenney's
RCU (Read, Copy, Update).

They let you do things like safely iterate a linked list that is being
concurrently modified, albeit with slightly altered semantics.

Joe Seigh

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

David Abrahams <dave@boost-consulting.com> wrote in message news:<u4qo2sdsq.fsf@boost-consulting.com>...
> Gerhard Menzl <gerhard.menzl@spambucket.net> writes:
> 
> And yet, there is a large category of applications where this sort of
> thing almost never occurs.  There was no big outcry about GC before
> Java came along, at least not that I remember.  The presence of GC in
> Lisp and Python (and...) systems is not normally seen as a problem.

There may not have been the outcry of today, though I remember lots of
discussion about it and certainly there have been GC engines that have
worked with C++ for a long while (with limitations).  Many of these
discussions were in the early '90s. It was one of the big features
that Eiffel, Sather, and Smalltalk brought to the table when compared
with C++ of long ago (as well as generics for that matter).  I believe
that almost all of those who came from OO backgrounds wanted GC. 
Every OO language but C++ at the time passed objects by reference
rather than value.  And GC fits in wonderfully with that model.

joe

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

David Hilsee wrote:
> 
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1090358682.341761@master.nyc.kbcfp.com...
>  > As someone already posted, it's the self-referential properties
>  > of memory that make it so special. I can think of an analogy -
>  > in a structured file system, you should be able to delete a
>  > directory and have the system collect the space taken by all
>  > files and subdirectories of that directory.
> 
> Your point about the self-referential nature of memory makes me wonder how
> GC for resources would work.  Most resources are represented by a handle,
> which is held in memory.  If the resource GC wanted to determine that a
> resource could be collected, then it seems that the resource GC would have
> to determine if its handle is reachable, which is the same thing a memory GC
> would do if it wanted to determine if it could release the memory that holds
> the handle.  If that is true, then how is the resource GC any different from
> the memory GC?  Am I missing something?  Is the key change in the way
> finalization is defined for resources?  If so, how should it be defined, if
> the "cleanup handler" approach is unacceptable?
> 

Unix files are typically GC'd by reference counting the number of open file
descriptors and hard links to the files.  The restriction of not being able
to hard link to a file directories, which link (refer) to other files, prevents
self references or circular references and allows reference counting to work.
Reference counted gc may apply to other types of system resources as well.
Some explicit action, e.g. closing a file descriptor, is need to tell the
system a reference is being dropped.

Joe Seigh

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Keith H Duggar wrote:
<snip>
> Or can anyone provide concrete examples or references to examples of
> other situations difficult to handle without garbage collection (GC)?
> 
> For example, I read the following wiki
> 
> http://c2.com/cgi/wiki?AlgorithmsThatDemandGarbageCollection
> 
> which claimed that a paper by William Pugh on concurrent skip-lists
> used GC. Upon reading the paper I found no mention of GC; rather I
> found an explicit mention of C with malloc and free which is clearly
> not GC.

You need to read <ftp://ftp.cs.umd.edu/pub/skipLists/concurrent.pdf>
and not <ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf>.

> As a second example consider
> 
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/example.html
> 
> which claims to give an example where GC is great and deterministic
> destruction would cause lots of problems.

Actually it says that "explicit deallocation appears to be necessarily
much more expensive", not that it's problematic.

> However, it seems that simply replacing the index table T of
> pointers with an index table T' of share_ptr's would also solve this
> difficulty. And it is not clear to me how GC would offer any
> advantage over this.
<snip>

Copying shared_ptrs is slow, relative to copying raw pointers.  I
think a solution using a table of shared_ptr would not be as slow as
the solution that page suggests in the absence of GC, but it *is*
currently necessary to acquire and release a lock every time you copy
a shared_ptr (unless you're using the version meant for single-
threaded programs, of course).

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Gerhard Menzl wrote:
 > But how many mission-critical, 24/7 systems employ garbage collection?
 > This is not intended to sound polemic; I am genuinely interested.

I believe many 24/7 operations are now using Enterprise Java Bean
systems from BEA or IBM or JBoss, and obviously those servers are
using garbage collection.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Gerhard Menzl wrote:
> Incorrect. Once garbage collection is enforced through the interfaces of 
> major vendors, you don't have a choice anymore. Saying that anyone is 
> free not to use it is like saying that you are free to write portable 
> C++ programs without using exceptions.

Once major vendors have decided to adopt any feature
you no longer have that choice. Such a case is a sign
of the success of the feature.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Gerhard Menzl wrote:
> The difference being that in GC-based environments users of your class 
> are more or less bound to new as many objects as they want and to keep 
> them around as long as the garbage collector sees fit. And please don't 
> get me started about Dispose() & kin.

This might be a good time for old-timers like myself to remind
everyone that Pascal (at least in some versions) had a type of
garbage collection in the form of Mark/Release. When Release
was executed, all memory allocated since the most recent Mark
call was freed.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Francis Glassborow wrote:
> It would be nice if we had some way that an OS could go round all 
> running processes and ask them to hand back any unused resources but I 
> am not aware of any OS that actually does that.
> 
> Co-operative GC might be quite a useful tool in our modern long running 
> multi-tasking systems but we should not assume we already have it. And 
> it would not be up to a language standard to provide it.

Your paragraphs contradict each other. For a process to know what
resources are unused, its programming language must define how to
determine that.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Gerhard Menzl <gerhard.menzl@spambucket.net> writes:

> David Abrahams wrote:
>
>  > Gerhard Menzl <gerhard.menzl@spambucket.net> writes:
>  >
>  >>And with GC, you've got to be even more careful to manage lifetime
>  >>issues. You can't just entrust class destructors with resource
>  >>clean-up for fear they might be called at an inappropriate time.
>  >>Interfaces become cluttered with Dispose calls, with everyone
>  >>developing their own idea what exactly is destroyed when, if at all.
>  >
>  >
>  > And yet, there is a large category of applications where this sort of
>  > thing almost never occurs.  There was no big outcry about GC before
>  > Java came along, at least not that I remember.  The presence of GC in
>  > Lisp and Python (and...) systems is not normally seen as a problem.
>
> I hope you have noted that my reply to Hyman contained a tinge of parody.
>
> There is no doubt that for certain applications resource leaks are not 
> an issue. People have just become used to zap their web browsers once an 
> applet starts to behave funny. I know I have. But how many 
> mission-critical, 24/7 systems employ garbage collection? This is not 
> intended to sound polemic; I am genuinely interested.

Well of course nobody knows the answer ;-) But I can tell you that
many such systems are built with Python.  There's a whole server
technology called Zope, for example.

  "Zope is a high-performance application / web server, content
  management system. It is a complete, robust, scalable solution."

http://www.zope.com

I think this demonstrates that GC and "Enterprise Software" are not
incompatible.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1090439153.372661@master.nyc.kbcfp.com>...
> Gerhard Menzl wrote:
> > Incorrect. Once garbage collection is enforced through the interfaces of 
> > major vendors, you don't have a choice anymore. Saying that anyone is 
> > free not to use it is like saying that you are free to write portable 
> > C++ programs without using exceptions.
> 
> Once major vendors have decided to adopt any feature
> you no longer have that choice. Such a case is a sign
> of the success of the feature.

No, it is a sign that the vendors wanted to adopt the feature. In a
perfect world it would mean that it is because most people want the
feature (which in itself justifies nothing anyway), but I think such
joys as product activation, DRM, locked down hardware, the evils
associated with vendor lock-in, and Palladium generally prove that you
live in some kind of fantasy land. People have this unfortunate habit
of being mindless sheep, believe it or not.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/1w2VB8FYP9YqDcRAofPAJwIn9JPUW71hxDWk764EIzauuTGyQCfXmzy
Mk8Aq1abO55URDH3/Bj+MoQ=
=LTCM
-----END PGP SIGNATURE-----

allan_w@my-dejanews.com (Allan W) wrote in message news:<7f2735a5.0407201619.77bcdc51@posting.google.com>...
 > The word "necessary" in this context is loaded.
 >
 > Look at the standard and start asking yourself if various features are
 > "necessary."
 >
 > Do we need unary operators? We could have handled memory management
 > (new, delete, *, &) differently. If the parens in sizeof() had been made
 > mandatory, we might not consider sizeof to be unary. I can't think of any
 > others that are "necessary". -x is the same as 0-x, +x is the same as x,
 > ++x is the same as x+=1, etc.

If you defined necessary as "absolutely needed", then none of it is
"necessary".  classes, structs, pointers, arrays, deferencing... none
of it is needed.  All we need is the _asm operator and thep
preprocessor.  From it, we would be able to write any code we wanted.
Wow!  Think of the expressive freedom we would gain, and the code
would be very fast.

[snipped]

 > The C++ language as it stands today does not have GC. The language is
 > viable. I think this leads to an obvious observation that it is not
 > "necessary."
 >
 > Is it useful? Clearly it is. Would it's benefit outweigh it's costs? This
 > is not so obvious.

It is to many of us.

 > Does GC make sense for all platforms? If GC were added to the standard,
 > then any implementation that did not supply it would become non-standard --
 > which makes sense, because programmers would come to expect it, and running
 > programs written with this expectation in an environment without GC would
 > then lead to terrible consequences.

Writing such programs under such a model with or without GC already
leads to a terrible consequence.  The thing that is created has poor
form.

 > On the other hand, C++ has a reputation for being a tough language. Most of
 > this reputation is unfair, caused by programs using pointers and casts
 > where they shouldn't... so that the most trivial bug manifests itself in
 > difficult-to-trace ways. Adding GC wouldn't stop people from using pointers
 > when they shouldn't, or using casts when they shouldn't ... but it would
 > drastically reduce the bugs caused by these bad techniques.

No it would not. It would mask the bugs and mitigate their symptoms.
The bug is malformed code.  The symptom is memory leakage.  GC might
lessen the leakage, but the code would still be malformed, and
therefore the system would still be buggy and of low virtue, even
though it "worked".

Yet, you are correct to state that arguing might not sway us one way
or the other.  As I have stated in other post, most of these arguments
here are driven by our indivual character and perception of how the
world should be.

If I may generalize:

Some of us are people of principle.  Some of us are people of
practice.  Some of value intangibles like form, purity, elegance,
regularity, orthognality, universality, and retraint.  Some of us
value a large, sprawling, feature set with all the fixings.  Some of
us say, "Lord, make us fastidious in avoding making messes."  Some of
us say, "Lord, make the garbace collector fastidious in cleaning up
our messes."

This is why Space Shuttles and nuclear reactors blow up every now and
then.   The irrevance for form gradually becomes the norm as people of
principle grow to outnumber people of practice.  Duct tape becomes the
weapon of choice.  Over time, the mess becomes so intractable that
something slips through the cracks. Boom! Then sensibiity sets in. The
practical become apologetic and humble; the principle becomed digusted
and emboldened.  But the piety lasts just long enough that the penalty
of this fallacious mode of thought is no longer painful, at which
point the cycle repeats itself.

If you want a vituous system, engineer virtue.

-Chaud Lapin-

There is no silver bullet. - Fred Brooks

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Maciej Sobczak wrote:
 > This is why I consider GC to be dangerous.

This is because you are misinterpreting the paradigm of GC.
The purpose of GC is to allow you to treat certain resources
as infinite - the fact that behind the scenes scavengers are
reclaiming the resources and reusing them is irrelevant to
the paradigm. The proper mindset is that objects subject to
GC live forever, and therefore if they hold resources those
resources will also be held forever unless deterministically
released.

Finalizers are a sop thrown to people who don't understand
this, or people who want to manage resources that are abundant
enough so that they don't care if they occasionally run out,
or to people who want a just-in-case spot to do cleanup of
things that haven't already been done.

If failure to understand and incorrect usage led to the demise
of programming languages, C++ would have been DOA.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Gerhard Menzl wrote:

 > Hyman Rosen wrote:
 >
 >
 >  > This addresses those people who do not want GC to be part of
 >  > C++. They cannot prevent others from adding it, but they are
 >  > free not to use it themselves.
 >
 > Incorrect. Once garbage collection is enforced through the interfaces of
 > major vendors, you don't have a choice anymore. Saying that anyone is
 > free not to use it is like saying that you are free to write portable
 > C++ programs without using exceptions.
 >

Your post triggered two purely technical questions in my mind:

a) Is it possible to implement the Standard Library Containers using
automatic garbage collection? The answer may be "no" since the Standard
makes runtime guarantees for certain operations, and whenever garbage
collection kicks in, those guarantees could be violated.

Thus, if garbage collection is added as a feature, the standard might still
effectively rule out that vendors use it to implement the standard
interfaced we are using right now.

b) Is it possible/feasible to add garbage collection to C++ in such a way
that it obeys the design principle: if you don't use it, you don't pay for
it?


Best

Kai-Uwe Bux

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 07/21/2004 02:54 PM, Hyman Rosen wrote:
[snip]
 > No, you have not paid attention to the posts where I point out
 > that GCC uses garbage collection internally. They use a form where
 > roots must be marked, and their source files have special notations
 > (macros and such) to guide the garbage collector.
 >
 > It makes sense that a compiler has many circular ownership issues,
 > since things like mutually recursive structures are likely represented
 > by data structures which point to each other.
 >
 >  > Don't smart pointers (I had in mind boost::shared_ptr)
 >  > handle circular ownership well? If not, how so? Example?
 >
 > No, they do not, as you can see from
 > <http://www.boost.org/libs/smart_ptr/shared_ptr.htm>:
 >      "Because the implementation uses reference counting,
 >       cycles of shared_ptr instances will not be reclaimed."

However, can't these circular ownership issues be handled with
shared_ptr AND weak_ptr where the cycles are broken with the
weak_ptr's?  Furthermore, I would guess that an even more restrictive
sole_ptr/weak_ptr pair of classes could handle this compiler issue
since the sole_ptr (a shared_ptr which allows only one strong use_count)
would be used to connect the TREE of abstract syntax tree nodes and
any cycles could then be handled with the weak_ptr's.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 2004-07-21 19:52, Maciej Sobczak wrote:
 > Niklas Matthies wrote:
 >
 >> I'm still not sure what exactly your concern is though, and whether
 >> you think there is a way to garbage-collect without treating memory
 >> specially.
 >>
 >> [...] So memory is inherently special, as far as I can see.
 >
 > Yes, but only from the GC's point of view.
 > My point was to show that memory is not at all special from the
 > *design* point of view, since the memory-oriented object may always
 > become oriented towards additional types of resources (for example
 > by embedding into the object a handle to external resource).

But the object is a memory entity. Resource handles are inherently
memory bound. Handling the lifetime of a resource handle (value)
implies handling the lifetime of resource handle objects. This is
what makes memory special, regardless of whether garbage collection
is involved or not.

:
 > This also requires more emphasis: classes that -->were<-- used.
 > I do not care whether it is possible to have both destructors and
 > finalizers. That's not the point. The point is that if *somebody* used
 > your class with GC, you will not be able to enforce deterministic
 > destruction of *those* objects, because you may not be even able to
 > modify the source code where your class was used.

In the (common) case where it's not the responsibility of the class to
manage the lifetime of its instance, but the responsibility of the
client code, garbage collection is merely an additional way for client
code to handle object lifetime management (i.e. in C++ in addition to
heap destruction by a delete-expression, to "placement" destruction,
to implicit destruction when exiting a scope and to static lifetime).

By having objects garbage collected, the client code explicitly (or,
well, implicitly) states that it's fine that the objects (and hence
the resources they hold) are kept alive for some unspecified time
after the last reference goes away, until garbage collection kicks in
(or is exlicitly triggered).

 > This means that once you say: "hey, people, look what a cool class
 > there is for use with GC", you will not be able to say later: "hey,
 > people, I've changed something *inside*, so please use only
 > deterministic destruction with this class".
 >
 > I've seen this problem in practice, in Java code.
 > There was a class that was instantiated in a loop (not directly - there
 > was a few function calls in between, so not everybody was aware that the
 > class is instantiated in a loop).
 > No problem, GC occasionally collected the objects, and nobody cared.
 >
 > Then a developer added a reference to the DB resource (a cursor) to one
 > of the methods of the class. Of course, the finalizer method cleaned it
 > up, as in every well-behaved class.
 >
 > Guess what happened next?
 > The DB server *occasionally* (once for many runs of the program) run
 > short of cursor handles. Occasionally, because most of the time the
 > program balanced just below the limit of the number of active cursors.
 > It took a lot of debugging to discover it. The solution was to put
 > additioinal code *outside* of the class, in the loop, to force the
 > object to clean up after himself (let's call it "explicit" deterministic
 > destruction), bypassing the GC, so that the number of active cursors was
 > kept to minimum.
 > In other words, the internal change in the class required the user code
 > to be changed as well.

It seems to me that either the user code was broken from the beginning,
because the objects already did conceptually represent a (non-memory*)
resource and the user code didn't care about when the resource would
be released (or the class was broken because it didn't provide methods
for releasing the resource, so the user code didn't have much of a
choice in Java), or else what the class represents did change, so it's
no surprise that client code breaks.

*) any object inherently represents a memory resource, so there's no
question about that

:
 > This is why I consider GC to be dangerous.

GC doesn't magically solve all object lifetime issues, that much is
true. As with many tools, it can be dangerous in the hands of a naive
user. But I maintain that memory is special regardless. :)

-- Niklas Matthies

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 > The problem with GC is that it is essentially a process level mechanism.
 > It would be nice if we had some way that an OS could go round all
 > running processes and ask them to hand back any unused resources but I
 > am not aware of any OS that actually does that.

Windows (and I would guess OS/2 as well) does exactly that. Processes that
handles Windows messages will get fed WM_COMPACTING if system memory is low
under certain conditions.
Of course they are free to ignore it. Been around since 16-bit Windows.

Stephen Howe



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 > And please, let's try our best to confine this sub-thread to concrete
 > examples and technical points that aim to address the question as
 > recast by Terje in a constructive manner.
 >

1. ref-counting does not handle cyclic reference well. share_ptr has a
notion of weak_ptr which allows us to manually break the cycles if
any. But that is not a real solution to general cyclic ref problem. Of
course, one may claim that cyclic ref never appears in a good design,
which, for a functional design is true.

2. In the way many c++ code are written today, gc is not so necessary.
That is because people don't even think about certain thing when it is
so obviously impossible or difficult in c++ that we'll just say
"over-kill" or "not worth it".

To name a few:

A.
Immutable programming. Introduced by functional programming. Once an
object is created, its status is never changed. Instead, new objects
are created if you intend to set certain state, which, is called
functional update.

In such programming paradigm, exception safety is trivial, undo-redo
is trivial. Sharing of objects minimizes the need to copy objects. It
is automatically copy-on-write. And yet simpler and more efficient
than the copy-on-write available in c++ today.

I might be narrow-minded, but I never see one implementation in C++
that does it.

Some functional language implements it with ref-counting. But it
cannot be implemented with shared_ptr in C++. I'll get to the reason
later.

e.g.

interface ImmutablePoint{int getX(); ImmutablePoint setX(int x); ...}
class ImmutablePointImpl implements ImmutablePoint{
   public ImmutablePoint setX(int x){return new ImmutablePointImpl(x,
this.y);}
   ...
}

B.
Programming against interface. In a OO langauge with gc, it is a
recommended methodology.
As a result, modules talk to modules using "interface" with no
implementation detail. (unlike c++, where classes talk to classes
directly)

On the signatures of interfaces, are value types and interface types.
The actual class name that implements certain interface is very rarely
mentioned on a signature.

This minimizes coupling and pretty much does what "concept-model" does
in C++ today, except that it can deal with run-time polymorphism.

Like it or not, this methodology requires gc because it relies on
reference semantics.

And why can't we use sh_ptr for these?

1. Most most importantly, sh_ptr does not cover 'this' pointer.
In a method body, we don't have access to the shared_ptr object that
holds 'this'. As a result, 'this' has to be treated specially and we
cannot use 'this' for many things. Unfortunately, it is quite
detrimental to the "programming-against-interface" methodology. In
fact, I think I'd better off giving up the whole "interface" idea if I
cannot use 'this' freely.

e.g.
What if we want to change the ImmutablePoint example a little bit?

class ImmutablePointImpl implements ImmutablePoint{
   public ImmutablePoint setx(int x){
     if(x==this.x) return this;
     else return new ImmutablePointImpl(x, this.y);
}

It is not possible with shared_ptr.

2. shared_ptr clutters the signature. In a complex and ever evolving
OO system, objects tend to reference objects through interface
pointers.

There is a popular pattern "IOC" in Java world. All it says is you
don't create sub-objects, instead, declare a polymorphic pointer to it
and let the constructor accept it from the caller.

Imagine if we really do that, what will be the final object layout? An
object tree or even an object graph!
That means shared_ptr will show up almost everywhere. Isn't it
annoying to see share_ptr<A>, shared_ptr<B> everywhere?

3.
shared_ptr uses ref-counting. And ref-counting is known as a
sub-optimal implementation technique of garbage collection. If I end
up using shared_ptr for memory management, why not use some more
advanced and efficient algorithm?


Finally, I like the idea of an optional gc so that you can choose not
to use it. D, IMHO, is in the right direction.
However, I really don't see how it is possible to not let gc affect
the semantcis of at least part of the language.
With or without gc, the code is different, the entire deisgn can be
dramaticallhy different. GC, is not just a memory management method
any more, it is a matter of design styles and methodology.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 21 Jul 2004 16:14:46 -0400, Hyman Rosen <hyrosen@mail.com> wrote:

 >This might be a good time for old-timers like myself to remind
 >everyone that Pascal (at least in some versions) had a type of
 >garbage collection in the form of Mark/Release. When Release
 >was executed, all memory allocated since the most recent Mark
 >call was freed.

IIRC however mark/release was an *alternative* to new/dispose;
in other words either you decide to go for mark/release *OR*
for new/dispose. The "heap" with mark/release was just a global
stack independent from the stack used for functions.

I actually implemented something like mark/release the way
you intend in a C program I wrote long ago. That helped me
solving the problem of how to cleanup when discovering an
error during the reconstruction of a complex data structure
from a stream... calling the "destructor" was not an option
as the structure was not complete, and freeing all the memory
allocated since the load operation started was good enough
for my use. The other option would have been writing a lot
of ifs and maybe "goto Err" and that's not something I like.

Andrea

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 21 Jul 2004 15:12:25 -0400, Francis Glassborow
<francis@robinton.demon.co.uk> wrote:

 >The problem with GC is that it is essentially a process level mechanism.
 >It would be nice if we had some way that an OS could go round all
 >running processes and ask them to hand back any unused resources but I
 >am not aware of any OS that actually does that.

Once I implemented that sort of a "please free memory" broadcast
inside a program; there was a global limit on the allocated memory
and when approaching that limit all registered subsystems were
asked to free all "not-really-needed" memory.

I think the machinery is already available as signals...

Andrea

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 21 Jul 2004 15:10:34 -0400, Gerhard Menzl
<gerhard.menzl@spambucket.net> wrote:

 >Note that this distinction is not binary; it rather defines a continuum.
 >Depending on the degree of scarcity, garbage collection may work
 >perfectly fine, reasonably well, poorly, or not at all.

I'm not a GC fan (I'm more for the reference-count approach
when it's hard to clearly define who is responsible for a
resource), but I must say that IMO a lot of GC bad reputation
is a consequence of broken implementations.

I remember writing applets in which no matter what I could
try to do there was simply no way to give back anything when
the user was pressing "back" on (the) browser.
My impression was in such a case the JVM was simply stopped
and all the applet memory *leaked* at once... going back and
re-entering the page ten times was going to get the system
to trash mode.

I don't think that the very concept of GC is to blame for this.

Andrea

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <cdmndm$nir$1@news01.cit.cornell.edu>, Kai-Uwe Bux 
<jkherciueh@gmx.net> writes
> > Incorrect. Once garbage collection is enforced through the interfaces of
> > major vendors, you don't have a choice anymore. Saying that anyone is
> > free not to use it is like saying that you are free to write portable
> > C++ programs without using exceptions.
> >
>
>Your post triggered two purely technical questions in my mind:
>
>a) Is it possible to implement the Standard Library Containers using
>automatic garbage collection? The answer may be "no" since the Standard
>makes runtime guarantees for certain operations, and whenever garbage
>collection kicks in, those guarantees could be violated.
>
>Thus, if garbage collection is added as a feature, the standard might still
>effectively rule out that vendors use it to implement the standard
>interfaced we are using right now.
>
>b) Is it possible/feasible to add garbage collection to C++ in such a way
>that it obeys the design principle: if you don't use it, you don't pay for
>it?

Probably, in exactly the same way that it is possible to write a 
portable C++ program without using exceptions. Indeed one of the major 
motives for introducing new(nothrow) was to support such programs. Now 
whether a specific implementation removes all the exception handling 
code is a different issue bit a QoI one.

-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Lararbitrary wrote:

> On 07/21/2004 02:54 PM, Hyman Rosen wrote:
> [snip]
>  > No, you have not paid attention to the posts where I point out
>  > that GCC uses garbage collection internally. They use a form where
>  > roots must be marked, and their source files have special notations
>  > (macros and such) to guide the garbage collector.
>  >
>  > Itoptimisingse that a compiler has many circular ownership issues,
>  > since things like mutually recursive structures are likely represented
>  > by data structures which point to each other.
>  >
>  >  > Don't smart pointers (I had in mind boost::shared_ptr)
>  >  > handle circular ownership well? If not, how so? Example?
>  >
>  > No, they do not, as you can see from
>  > <http://www.boost.org/libs/smart_ptr/shared_ptr.htm>:
>  >      "Because the implementation uses reference counting,
>  >       cycles of shared_ptr instances will not be reclaimed."
> 
> However, can't these circular ownership issues be handled with
> shared_ptr AND weak_ptr where the cycles are broken with the
> weak_ptr's?  Furthermore, I would guess that an even more restrictive
> sole_ptr/weak_ptr pair of classes could handle this compiler issue
> since the sole_ptr (a shared_ptr which allows only one strong use_count)
> would be used to connect the TREE of abstract syntax tree nodes and
> any cycles could then be handled with the weak_ptr's.
> 

An arbitrary graph of similar objects pointing at each other cannot be
represented using a shared_ptr, weak_ptr mechanism. E.g node object which
contains a container of references to other node objects cannot be created
using shared_ptrs and weak_ptrs. In this case either some kind of arena
allocation is needed, or garbage collection. I've a feeling an optimising
compiler may be just such a case, although I do not know this for certain.

Ben
--- 

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Kai-Uwe Bux wrote:
> 
> Your post triggered two purely technical questions in my mind:
> 
> a) Is it possible to implement the Standard Library Containers using
> automatic garbage collection? The answer may be "no" since the Standard
> makes runtime guarantees for certain operations, and whenever garbage
> collection kicks in, those guarantees could be violated.

I don't think that this argument applies. Yes that standard makes runtime
guarantees, but they exclude everything not directly related to the
containers themselfs, as eg. page faults. If you are unlucky then
the operating system kicks in during a container operation and
schedules your task for later.
GC is not a property if the containers themselfs but of the underlying
memory model and as such has to be considered in the same category as
eg. page faults, interrupts etc. that is: outside the standard guaranteed
timeing.

> 
> Thus, if garbage collection is added as a feature, the standard might still
> effectively rule out that vendors use it to implement the standard
> interfaced we are using right now.

Don't think so.

> 
> b) Is it possible/feasible to add garbage collection to C++ in such a way
> that it obeys the design principle: if you don't use it, you don't pay for
> it?

Sure. MS managed C++ (AFAIK) does it by introducing keywords for classes
you want to have GC-ed. Don't use it - no overhead.

I still don't like the idea of GC. For me it is like cheating :-)

-- 
Karl Heinz Buchegger
kbuchegg@gascad.at

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1090425829.435727@master.nyc.kbcfp.com>...
> I will point once again to GCC, which implements garbage collection
> for itself, and involves special markups in the source to guide the
> collector. Here's a page with some description:
> <http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html>
> Another message from back in 1999:
> <http://gcc.gnu.org/ml/gcc/1999-09n/msg00207.html>

I took a look.  Words like "abomination" came to mind.  You imply that
it is too tedious for the programmer to engineer deterministic
resource reclamation using constructor/destructor, but it is OK to use
"special markups to guid the garbage collector". ?????  Can you not
see hypocrisy/absurdity in this?

[snipped]
> > new[] was created as a distinct mechansim after considering the overall
>  > design space, again, to maintain regularity. Again, the architect exercised
>  > vision in making this determination.
> 
> Poor vision. new[] does not maintain regularity. It exists as a hack so that
> allocation of single objects does not require the bit of extra space to record
> an array size. After all, what is the conceptual difference between allocating
> one object and allocating an array of size one? My doubts about the bear in
> thecave are now increasing.

I entirely agree with the implementation of new[].  I remember reading
the explanation in Stroustrup's book, and nodding my head, "Yes,
makses sense, exactly what I and probably any sensible person would
have done, all things considered".  The same could have been said
about not making destructors automatically virtual.  We could argue
until we are blue in the face about this, but to some people the best
answer is obvious before the debate begins.

> > "feature set", "managed code"...I will not deny the manipulative power
> > of Microsoft.  What is remarkable is that they employ the same basic
> > strategy with repeated success:
> > 
> > 1. identify the threat (in this case, C++)
> > 2. taint it somehow and skew it toward their (proprietary) tool set
> > 3. apply euphemisms to the foul smelling parts for Wall Street types
> 
> This is just incredibly silly. I now realize that the cave is empty.
> I'm going in. Why in the world you think that Microsoft considers C++
> to be a threat I don't know, given that all of their own products are
> written in it, as well as the APIs that others use to access their
> products. You are obviously incapable of judging C++/CLI on technical
> merits because you are blinded by your hatred of its creator.

C++ is a tool and a weapon.  You might not want your adversaries to
have it, but that does not mean you should not use it for yourself.

> If you protect your virtue with enough diligence, you will never
> have children. You cannot see that Microsoft is doing its best to
> improve C++. It remains to be seen whether the attempt is successful,
> but that is clearly the motive.

Microsoft is doing its best to eliminate its need to write its
component software in multiple languages, which is obviously one of
the fundamental reasons for the VM.  It' a major headache for them to
write an interface for every single component that resides in DLL. 
COM/DCOM was their first shot at doing this, and it worked somewhat,
but with very nasty-looking barely manageable code and a whole lot of
marketing.  Now DCOM has been superceded by .NET, and new language has
been added, but the principle is the same.

But I do not think this is the real reason Microsoft is perturbing
C++.  Those engineers are not dumb.  I know many of them would agree
in private with the arguments that most of us in this thread have put
forth - that GC is something that will cause more headache and
confusion than anything else in C++.

I believe that Microsoft is meddling with C++  because they know that
C++ is the language of choice for the serious software engineer, and
they want to force those engineers into the .NET arena through the
language, as C++ programmers are also those who are often the most
strong will and self-guided - not likely to jump onto every bandwagon
that comes along just because it's the new thing.

You can see evidence of the policy of grabbing the minds of
programmers in their tactics:

1.  They stifle the creative space of C++ by adding elements that
detract from its virtue, and use very subtle tactics to induce
programmers to use them.  If you use the Visual Studio Wizard to
create a simple, command-line-only "Hello, World" program, it
generates this:

#if _MSC_VER > 1000  // DEFINITELY NOT PORTABLE
#pragma once   
#endif // _MSC_VER > 1000 // DEFINITELY NOT PORTABLE

Gotcha! Now even the most innocent of programs is non-portable.  This
simple little  program, written in C++, will not compile on Unix.

2.  None of their own library header files are portable.  Microsoft
makes all their code non-portable, and call it C++, ingnoring that one
of the prime virtues of C++ is that it is supposed to be portable. 
There is no reason that even a Mutex class cannot have a portable
interface.  If you do not believe this, see my concurrent post in the
thread on multi-threading. But microsoft goes a step further.  They
make everything from CString to CDate heavily bound to Microsoft.

2.  They taint the minds of young programmers on what constitutes the
virtuous primitive set.  If you compare Windows code with "normal" C++
code (UNIX), they hardly look the same.  I know several senior
engineers who have to take pause when I tell them that ULONG is not a
fundamental type in C++, nor is UINT.  But of them actually regard
"unsigned int" with contempt, as if it is not a legitimate part of the
language.  Microsoft loves this mentality.  They spend much money and
time nurturing it.

3. They aggressively preempt virtuous artifacts with their own
Microsoft-oriented implementations.  MFC is such a kludge that some of
the best GUI programmers no longer use it or write their own class
libraries over the basic API to cope.  But Microsoft pushed hard make
it the preferred choice in writing code.  I have been throughtout the
guts of much of MFC, and let's just say I keep a can of air freshner
handy.  It also makes it very easy to disassemble a competitors
product if it is written almost entirely using a libary that you
wrote.

They gives us CArchive, claiming that it allows one to serialize the
funamental data types of C++.  This is not true.  It serializes a
typedef'ed subset of the fundamental types that are
Microsoft-specific.  Forget about using it on Unix.

They give us the Crypto API, another abomination.  People who do
research in crypto barf when they see Microsoft's way of doing it
(don't ask), yet Microsoft practically begs us to use it.

They wrote their own (non-portable) version of sockets, even though it
was entirely reasonsable and possible to stay with the Berekely model
within Windows.  After some pressure, they gave us both both their
stuff and the Berkeley code, but the like the Hello World program
mentioned, they force you to use *at least* one Microsoft specific
function to kick start us down the path of Microsoft-Only.

This is why it is so important that we keep their paws off C++.

-Chaud Lapin-

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen wrote:

> This is exactly why C++/CLI is perceived to be a good idea.
> You get the benefits of GC and the benefits of RAII on a
> class-by-class basis, by your own choice.

The problem I see is "on a class-by-class basis". Classes are not 
isolated, they are related by association, aggregation or containment. 
My ten months of experience Managed C++ have left the impression that 
reliable cleanup becomes even more of a hassle when those two paradigms 
are mixed and interact. While I hope that C++/CLI will improve a lot 
compared to the current mess, I don't think the full complexity of 
mixing GC and RAII, especially when it comes to exception-safety, have 
been thoroughly understood yet.

-- 
Gerhard Menzl

Humans may reply by replacing the obviously faked part of my e-mail 
address with "kapsch".

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 07/22/2004 06:28 AM, Andrea Griffini wrote:
> On 21 Jul 2004 16:14:46 -0400, Hyman Rosen <hyrosen@mail.com> wrote:
[snip]
> IIRC however mark/release was an *alternative* to new/dispose;
> in other words either you decide to go for mark/release *OR*
> for new/dispose. The "heap" with mark/release was just a global
> stack independent from the stack used for functions.
> 
> I actually implemented something like mark/release the way
> you intend in a C program I wrote long ago. That helped me
> solving the problem of how to cleanup when discovering an
> error during the reconstruction of a complex data structure
> from a stream... calling the "destructor" was not an option
> as the structure was not complete, and freeing all the memory
> allocated since the load operation started was good enough
> for my use. The other option would have been writing a lot

IIRC, cmm from di.unipi.it allows this by creating separate
heaps with different collection strategies.  "Performance
Tuning in a Customizable Collector"
( 
http://liinwww.ira.uka.de/cgi-bin/bibshow?e=Njtd0MODT0modt2::6c/vojrvf%7d865165&r=bibtex
)

describes use of TempHeap where all allocations are done temporarily
while the "Buchberger algorithm" is executed.  After this, TempHeap
is freed without the need for garbage collection:

   The last operation on the tempHeap is very fast: it involves just
   resetting a few internal variables to empty the heap.




      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Le Chaud Lapin wrote:
>I can't think of any
> > others that are "necessary". -x is the same as 0-x, +x is the same as x,

That's not entirely correct.

int foo(int);
void foo(char);

char x = 'x';

int i = sizeof(foo(+x)); // OK
int j = sizeof(foo( x)); // Not so much OK.

I seem to remember that EDG used to have a problem with this.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Larry Evans wrote:
> However, can't these circular ownership issues be handled with
> shared_ptr AND weak_ptr

This places the onus of determining ownership back on you.
In the case of true mutually recursive structures, like in
the compiler, issues of ownership are difficult. That is why
grabge collection is used.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Le Chaud Lapin wrote:
> If you want a vituous system, engineer virtue.

Since virtue is in the eye of the beholder, it becomes
very easy to mask a personal dislike by declaring it an
obvious lack of virtue.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1089990333.947535@master.nyc.kbcfp.com>...
> Many GC systems provide cleanup handlers which can be specified
> per object and are invoked when the object is about to be collected.
> Those can be, and are, used to handle resources other than memory.

Destructors.
 
> The reason not all resources can be dealt with in this way is
> twofold. First, some resources are scarce and must be deallocated
> as soon as possible, so waiting for GC is not suitable. Second,
> some resources perform desirable actions upon deallocation, and
> those effects are needed at a deterministic point.

Destructors.

-Chaud Lapin-

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In message <1090444546.445069@master.nyc.kbcfp.com>, Hyman Rosen
<hyrosen@mail.com> writes
>Maciej Sobczak wrote:
> > This is why I consider GC to be dangerous.
>
>This is because you are misinterpreting the paradigm of GC.
>The purpose of GC is to allow you to treat certain resources
>as infinite - the fact that behind the scenes scavengers are
>reclaiming the resources and reusing them is irrelevant to
>the paradigm. The proper mindset is that objects subject to
>GC live forever, and therefore if they hold resources those
>resources will also be held forever unless deterministically
>released.
  <snip>

File handles and database connections have no persistent memory, unlike
files, so you can't tell if you are reusing an old one or have been
given a brand new one. Therefore they are yet another kind of infinite
resource.

A really good implementation would include them in its garbage
collection.

  John
-- 
John Harris

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Le Chaud Lapin" <unoriginal_username@yahoo.com> wrote in message
news:fc2e0ade.0407220208.ca935b3@posting.google.com...

> I believe that Microsoft is meddling with C++  because they know that
> C++ is the language of choice for the serious software engineer, and
> they want to force those engineers into the .NET arena through the
> language, as C++ programmers are also those who are often the most
> strong will and self-guided - not likely to jump onto every bandwagon
> that comes along just because it's the new thing.

Force? They can entice, but they lack the policing power to force.

> You can see evidence of the policy of grabbing the minds of
> programmers in their tactics:
>
> 1.  They stifle the creative space of C++ by adding elements that
> detract from its virtue, and use very subtle tactics to induce
> programmers to use them.

How can you stifle by adding? How can you stifle by inducing?

>                         If you use the Visual Studio Wizard to
> create a simple, command-line-only "Hello, World" program, it
> generates this:
>
> #if _MSC_VER > 1000  // DEFINITELY NOT PORTABLE
> #pragma once
> #endif // _MSC_VER > 1000 // DEFINITELY NOT PORTABLE
>
> Gotcha! Now even the most innocent of programs is non-portable.  This
> simple little  program, written in C++, will not compile on Unix.

Just did for me. Perfectly portable. My code has all sorts of lines
like this. It has even more that turn things on only for Unix compilers,
or gcc, or ...

> 2.  None of their own library header files are portable.

Header files are seldom portable. Try moving Unix headers to Windows,
or even a different flavor of Unix, and you'll get diagnostics
galore more often than not. The purpose of library headers is to
support portable applications, not be portable in their own right.
(I except all the #ifdef machinery you dismissed above as an
attempt to sabotage portability -- we achieve limited portability
by filling our standard library headers with that sort of stuff.)

>                                                           Microsoft
> makes all their code non-portable, and call it C++, ingnoring that one
> of the prime virtues of C++ is that it is supposed to be portable.

Unix, Linux, and every other OS I know makes great quantities of
their code non-portable, for the simple reason that it is intended
to be part of a particular OS. I've found a prime virtue of C and
C++ is that it supports *swatches* of code that are worth making
portable. You'll be hard put to find a nontrivial program that is
100 per cent portable. (A few text-oriented, command-line driven
software tools spring to mind, but that's what we had in mind when
we began standardizing C 20 years ago.)

> There is no reason that even a Mutex class cannot have a portable
> interface.  If you do not believe this, see my concurrent post in the
> thread on multi-threading.

Right, except that no standards committee has endorsed an interface
for a Mutex class, so by definition none is currently portable.

>                           But microsoft goes a step further.  They
> make everything from CString to CDate heavily bound to Microsoft.

Why not? Most of these things predate any standards, and/or meet
needs that go beyond standards. Unix does the same sort of thing,
as does every other major OS.

> 2.  They taint the minds of young programmers on what constitutes the
> virtuous primitive set.  If you compare Windows code with "normal" C++
> code (UNIX),

So you *define* UNIX as "normal"? Kinda stacking the deck a bit, aren't
you?

>             they hardly look the same.  I know several senior
> engineers who have to take pause when I tell them that ULONG is not a
> fundamental type in C++, nor is UINT.

Nor is clockid_t, nor timer_t, nor all the gazillions of other things
in Unix headers that violate the C Standard.

>                                      But of them actually regard
> "unsigned int" with contempt, as if it is not a legitimate part of the
> language.  Microsoft loves this mentality.  They spend much money and
> time nurturing it.

As do Red Hat, Suse, IBM, SCO, etc. etc. nurturing their own
proprietary solutions. Microsoft is guilty of being more successful
at winning mindshare and making money, but...

> 3. They aggressively preempt virtuous artifacts with their own
> Microsoft-oriented implementations.  MFC is such a kludge that some of
> the best GUI programmers no longer use it or write their own class
> libraries over the basic API to cope.

MFC also predates any relevant standards. As did H-P STL. Both seem to
be falling into disuse, as improved and standardized alternatives
become available.

>                                        But Microsoft pushed hard make
> it the preferred choice in writing code.  I have been throughtout the
> guts of much of MFC, and let's just say I keep a can of air freshner
> handy.  It also makes it very easy to disassemble a competitors
> product if it is written almost entirely using a libary that you
> wrote.

Also true for glibc, neh?

> [additional paranoid drivel snipped]

> This is why it is so important that we keep their paws off C++.

Okay, I got that you don't like Microsoft, and that you don't like
them hanging around school playgrounds. You've thrown a lot of, uh,
concepts against the wall but, IMO, none have stuck. So now how are
you going to save the world and keep Microsoft's paws off C++?

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"P.J. Plauger" <pjp@dinkumware.com> wrote in message news:<E1Bnmmk-0005fn-00@chx400.switch.ch>...
> "Le Chaud Lapin" <unoriginal_username@yahoo.com> wrote in message
> news:fc2e0ade.0407220208.ca935b3@posting.google.com...
> 
> > I believe that Microsoft is meddling with C++  because they know that
> > C++ is the language of choice for the serious software engineer, and
> > they want to force those engineers into the .NET arena through the
> > language, as C++ programmers are also those who are often the most
> > strong will and self-guided - not likely to jump onto every bandwagon
> > that comes along just because it's the new thing.
> 
> Force? They can entice, but they lack the policing power to force.

Kind of like Vito Corleone making offers you couldn't refuse. Ever
heard of vendor lock-in?

> >                           But microsoft goes a step further.  They
> > make everything from CString to CDate heavily bound to Microsoft.
> 
> Why not? Most of these things predate any standards, and/or meet
> needs that go beyond standards. Unix does the same sort of thing,
> as does every other major OS.

Whoa, whoa there Charlie. UNIX and every other major OS vendor are not
trying to do what Microsoft is trying to do. It doesn't matter if UNIX
and every other major OS vendor puts on a Mexican sombrero and does a
rain dance every night at midnight; as I said, they are not trying to
do what Microsoft is trying to do. You continually brought up everyone
besides Microsoft in your post as if someone were arguing for their
forms of garbage collection but not Microsoft's.

> >             they hardly look the same.  I know several senior
> > engineers who have to take pause when I tell them that ULONG is not a
> > fundamental type in C++, nor is UINT.
> 
> Nor is clockid_t, nor timer_t, nor all the gazillions of other things
> in Unix headers that violate the C Standard.

He did not argue that only Microsoft has non-standard things in their
libraries. Even if he had, which he did not, he was talking about the
cluelessness of programmers ingrained into Microsoft's 'one true way,'
not the fact that they have non-standard things. Also, we are
discussing C++, not C.

> >                                      But of them actually regard
> > "unsigned int" with contempt, as if it is not a legitimate part of the
> > language.  Microsoft loves this mentality.  They spend much money and
> > time nurturing it.
> 
> As do Red Hat, Suse, IBM, SCO, etc. etc. nurturing their own
> proprietary solutions.

Hold your horses there. I can partly see where you come from with the
last two, but what part of the GPL makes solutions from the first two
proprietary? Even more specifically, what proprietary extensions to
GCC do they (or any of the four for that matter) have? But we are a
mile off course with this red herring here anyway. None of the
companies you mentioned are trying to do what Microsoft is, so what I
said about sombreros and rain dances applies to them too.

> Microsoft is guilty of being more successful
> at winning mindshare and making money, but...

They are also guilty, in the actual sense of guilty, of illegal
maintenance of a monopoly, forging illegal secret contracts, other
antitrust violations, etc. You make it sound like they are some kind
of geniuses instead of a company that has done more to screw true
innovation over than probably any other company on earth.

> >                                        But Microsoft pushed hard make
> > it the preferred choice in writing code.  I have been throughtout the
> > guts of much of MFC, and let's just say I keep a can of air freshner
> > handy.  It also makes it very easy to disassemble a competitors
> > product if it is written almost entirely using a libary that you
> > wrote.
> 
> Also true for glibc, neh?

Again, no one is talking about glibc, at least until they try to do
the same things Microsoft is.

> > This is why it is so important that we keep their paws off C++.
> 
> Okay, I got that you don't like Microsoft, and that you don't like
> them hanging around school playgrounds. You've thrown a lot of, uh,
> concepts against the wall but, IMO, none have stuck. So now how are
> you going to save the world and keep Microsoft's paws off C++?

Well, if everyone else sold C++ libraries to Microsoft it would be a
lost cause trying to keep their paws off anything. Fortunately, that
is not the case.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBALAZVB8FYP9YqDcRAgqDAJsFo5hYF/UTv0PofvMLQvCfsCpgmwCfZfPJ
N45rx9Qg2MtUksXVfQvIOwg=
=iBZz
-----END PGP SIGNATURE-----

"P.J. Plauger" <pjp@dinkumware.com> wrote in message news:<E1Bnmmk-0005fn-00@chx400.switch.ch>...
 > "Le Chaud Lapin" <unoriginal_username@yahoo.com> wrote in message
 > news:fc2e0ade.0407220208.ca935b3@posting.google.com...
 >
 > > I believe that Microsoft is meddling with C++  because they know that
 > > C++ is the language of choice for the serious software engineer, and
 > > they want to force those engineers into the .NET arena through the
 > > language, as C++ programmers are also those who are often the most
 > > strong will and self-guided - not likely to jump onto every bandwagon
 > > that comes along just because it's the new thing.
 >
 > Force? They can entice, but they lack the policing power to force.

Kind of like Vito Corleone making offers you couldn't refuse. Ever
heard of vendor lock-in?

 > >                           But microsoft goes a step further.  They
 > > make everything from CString to CDate heavily bound to Microsoft.
 >
 > Why not? Most of these things predate any standards, and/or meet
 > needs that go beyond standards. Unix does the same sort of thing,
 > as does every other major OS.

Whoa, whoa there Charlie. UNIX and every other major OS vendor are not
trying to do what Microsoft is trying to do. It doesn't matter if UNIX
and every other major OS vendor puts on a Mexican sombrero and does a
rain dance every night at midnight; as I said, they are not trying to
do what Microsoft is trying to do. You continually brought up everyone
besides Microsoft in your post as if someone were arguing for their
forms of garbage collection but not Microsoft's.

 > >             they hardly look the same.  I know several senior
 > > engineers who have to take pause when I tell them that ULONG is not a
 > > fundamental type in C++, nor is UINT.
 >
 > Nor is clockid_t, nor timer_t, nor all the gazillions of other things
 > in Unix headers that violate the C Standard.

He did not argue that only Microsoft has non-standard things in their
libraries. Even if he had, which he did not, he was talking about the
cluelessness of programmers ingrained into Microsoft's 'one true way,'
not the fact that they have non-standard things. Also, we are
discussing C++, not C.

 > >                                      But of them actually regard
 > > "unsigned int" with contempt, as if it is not a legitimate part of the
 > > language.  Microsoft loves this mentality.  They spend much money and
 > > time nurturing it.
 >
 > As do Red Hat, Suse, IBM, SCO, etc. etc. nurturing their own
 > proprietary solutions.

Hold your horses there. I can partly see where you come from with the
last two, but what part of the GPL makes solutions from the first two
proprietary? Even more specifically, what proprietary extensions to
GCC do they (or any of the four for that matter) have? But we are a
mile off course with this red herring here anyway. None of the
companies you mentioned are trying to do what Microsoft is, so what I
said about sombreros and rain dances applies to them too.

 > Microsoft is guilty of being more successful
 > at winning mindshare and making money, but...

They are also guilty, in the actual sense of guilty, of illegal
maintenance of a monopoly, forging illegal secret contracts, other
antitrust violations, etc. You make it sound like they are some kind
of geniuses instead of a company that has done more to screw true
innovation over than probably any other company on earth.

 > >                                        But Microsoft pushed hard make
 > > it the preferred choice in writing code.  I have been throughtout the
 > > guts of much of MFC, and let's just say I keep a can of air freshner
 > > handy.  It also makes it very easy to disassemble a competitors
 > > product if it is written almost entirely using a libary that you
 > > wrote.
 >
 > Also true for glibc, neh?

Again, no one is talking about glibc, at least until they try to do
the same things Microsoft is.

 > > This is why it is so important that we keep their paws off C++.
 >
 > Okay, I got that you don't like Microsoft, and that you don't like
 > them hanging around school playgrounds. You've thrown a lot of, uh,
 > concepts against the wall but, IMO, none have stuck. So now how are
 > you going to save the world and keep Microsoft's paws off C++?

Well, if everyone else sold C++ libraries to Microsoft it would be a
lost cause trying to keep their paws off anything. Fortunately, that
is not the case.

Tommy McDaniel

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Le Chaud Lapin wrote:

 > Hyman Rosen <hyrosen@mail.com> wrote in message
 > news:<1089990333.947535@master.nyc.kbcfp.com>...
 >>convenienttsystems provide cleanup handlers which can be specified
 >> per object and are invoked when the object is about to be collected.
 >> Those can be, and are, used to handle resources other than memory.
 >
 > Destructors.
 >
 >> The reason not all resources can be dealt with in this way is
 >> twofold. First, some resources are scarce and must be deallocated
 >> as soon as possible, so waiting for GC is not suitable. Second,
 >> some resources perform desirable actions upon deallocation, and
 >> those effects are needed at a deterministic point.
 >
 > Destructors.
 >
 > -Chaud Lapin-
 >

Of course, if you *really* want to write robust software like that used in
nuclear reactors and rockets then relying on destructors to clean up
resources is also the wrong thing to do as most resources have failure
conditions on release which are just as important as failure to obtain the
resource in the first place. This means you need to write explicit resource
deallocation code, and maybe rely on destructors in the fall back case.

Of course this in turn leads to code that could that could be written just
as easily in non deterministic destruction languages. IMHO, RAII is mainly
useful in the intermediate situation i.e you want to release the resource,
but nobody will die if you don't!

Of course in this sort of situation c#'s "using" and lisp's with-open-file
etc aren't really that bad alternatives, just less convenient ones.

Ben
---

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Andrea Griffini wrote:

 > I'm not a GC fan (I'm more for the reference-count approach
 > when it's hard to clearly define who is responsible for a
 > resource), but I must say that IMO a lot of GC bad reputation
 > is a consequence of broken implementations.
 >
 > I remember writing applets in which no matter what I could
 > try to do there was simply no way to give back anything when
 > the user was pressing "back" on (the) browser.
 > My impression was in such a case the JVM was simply stopped
 > and all the applet memory *leaked* at once... going back and
 > re-entering the page ten times was going to get the system
 > to trash mode.
 >
 > I don't think that the very concept of GC is to blame for this.

I don't think I said so. What I was trying to point out is that when you
need to free resources at a precisely specified point of time, or as
fast as possible, garbage collection is simply the wrong tool.

Putting your household garbage in a bin that will be emptied every three
or four days is fine. You definitely don't want to treat radioactive
waste like that.

-- 
Gerhard Menzl

Humans may reply by replacing the obviously faked part of my e-mail
address with "kapsch".

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <c0fba064.0407222226.6fe5e509@posting.google.com>, Tommy 
McDaniel <tdmj@hotmail.com> writes
> > As do Red Hat, Suse, IBM, SCO, etc. etc. nurturing their own
> > proprietary solutions.
>
>Hold your horses there. I can partly see where you come from with the
>last two, but what part of the GPL makes solutions from the first two
>proprietary? Even more specifically, what proprietary extensions to
>GCC do they (or any of the four for that matter) have? But we are a
>mile off course with this red herring here anyway. None of the
>companies you mentioned are trying to do what Microsoft is, so what I
>said about sombreros and rain dances applies to them too.

I would have thought that all those companies are doing exactly what MS 
are doing, trying to make a profit. However in the case of SCO, I think 
there is strong evidence that they are trying to do something much worse 
than MS have ever done.

However almost everything you post here comes with a premise that MS are 
fundamentally motivated in ways that you think evil. If commercialism is 
evil then OK.

In the case of C++/CLI, indeed in the case of CLI and CLR, I think MS 
have been good citizens and relinquished their proprietary rights (just 
as AT&T were when they released various IPRs to allow C++ to be 
standardised.) I have no idea what the motives of their upper management 
maybe -- other than to make stacks of money which is surely what their 
stockholders want.

There is also other evidence that MS wants to be a better citizen such 
as their taking proposals for a set of 'secure' functions for the C 
library to WG14. It would have been so much easier had they just 
implemented such a library themselves and marketed their tools as 
providing better facilities for safe programming (and, of course, 
demanding IPR fees for anyone else copying them).

I have all kinds of reservations about various large companies including 
MS but that does not prevent me from carrying on a technical debate with 
their representatives, and even sometimes winning such debates. Of 
course such would be impossible if I spent my time describing my 
'opponents' as evilly motivated.

Now there are many real technical issues concerning both C++/CLI and 
future releases of the C++ Standard. Let us spend time and effort trying 
to understand those and thereby make a positive contribution.

-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Le Chaud Lapin wrote:
> Destructors.
> Destructors.

Sigh. Yes, destructors. Which will exist as in their present
form in C++/CLI, alongside their finalizer brethren.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Tommy McDaniel" <tdmj@hotmail.com> wrote in message
news:c0fba064.0407222226.6fe5e509@posting.google.com...

> "P.J. Plauger" <pjp@dinkumware.com> wrote in message
news:<E1Bnmmk-0005fn-00@chx400.switch.ch>...
>  > "Le Chaud Lapin" <unoriginal_username@yahoo.com> wrote in message
>  > news:fc2e0ade.0407220208.ca935b3@posting.google.com...
>  >
>  > > I believe that Microsoft is meddling with C++  because they know that
>  > > C++ is the language of choice for the serious software engineer, and
>  > > they want to force those engineers into the .NET arena through the
>  > > language, as C++ programmers are also those who are often the most
>  > > strong will and self-guided - not likely to jump onto every bandwagon
>  > > that comes along just because it's the new thing.
>  >
>  > Force? They can entice, but they lack the policing power to force.
>
> Kind of like Vito Corleone making offers you couldn't refuse. Ever
> heard of vendor lock-in?

Of course I have, and it's getting harder all the time for vendors to
lock in their clientele -- yes, even for Microsoft. Remember, the
issue here is whether you have to use all these interesting (or
ugly, or sneakily enticing) alternatives that Microsoft provides
with VC++. If you have an economic (or aesthetic, or perverse)
incentive to write pure Standard C++, you can do a pretty good job
of it and still compile with VC++. Or you can go to Borland, or
Comeau, or MinGW, or several other sources of C++ development tools
for Windows and thumb your nose at Microsoft's offerings.

Corleone still has more "policing power" than Microsoft, if you
care to notice.

>  > >                           But microsoft goes a step further.  They
>  > > make everything from CString to CDate heavily bound to Microsoft.
>  >
>  > Why not? Most of these things predate any standards, and/or meet
>  > needs that go beyond standards. Unix does the same sort of thing,
>  > as does every other major OS.
>
> Whoa, whoa there Charlie. UNIX and every other major OS vendor are not
> trying to do what Microsoft is trying to do.

Really, how do you know? Looks to me like they're all trying to make
money and increase market share. If not, their stockholders should
be informed...

>                                             It doesn't matter if UNIX
> and every other major OS vendor puts on a Mexican sombrero and does a
> rain dance every night at midnight; as I said, they are not trying to
> do what Microsoft is trying to do.

Wouldn't matter if the top management at Microsoft did that either --
it would be equally ineffective. Whatever it is they're trying to do.

>                           You continually brought up everyone
> besides Microsoft in your post as if someone were arguing for their
> forms of garbage collection but not Microsoft's.

Oh, you're thinking about garbage collection. The OP was casting
a much broader net of aspersions, and I was trying to address them
all. As for Microsoft's new offering of GC, you don't *have* to
use it, you know. It's just an enticement, not an offer you can't
refuse. The Boehm collector, for one example, is free. It's been
available for years. And it's not locked in to VC++.

>  > >             they hardly look the same.  I know several senior
>  > > engineers who have to take pause when I tell them that ULONG is not a
>  > > fundamental type in C++, nor is UINT.
>  >
>  > Nor is clockid_t, nor timer_t, nor all the gazillions of other things
>  > in Unix headers that violate the C Standard.
>
> He did not argue that only Microsoft has non-standard things in their
> libraries.

Perhaps not, but he seemed to see something pernicious in the fact
that Microsoft *did* offer non-standard things. Just wondering why
it ain't pernicious when others do it.

>           Even if he had, which he did not,

Gotcha.

>                                            he was talking about the
> cluelessness of programmers ingrained into Microsoft's 'one true way,'
> not the fact that they have non-standard things.

I've been meeting clueless programmers for over 40 years now. And
watching companies try to make money off them (sometimes even by
actually helping them). You can't blame companies for wanting to
do that, or for succeeding. *Maybe* you can blame programmers for
being clueless, since thats fixable.

>                                                Also, we are
> discussing C++, not C.

"We" have been wandering all over the map. But FWIW, if you include
the Standard C++ header <time.h> in a program on many Unix systems,
you get those nonstandard type definitions I mentioned above, among
many others. Vendor lock-in?

>  > >                                      But of them actually regard
>  > > "unsigned int" with contempt, as if it is not a legitimate part of
the
>  > > language.  Microsoft loves this mentality.  They spend much money and
>  > > time nurturing it.
>  >
>  > As do Red Hat, Suse, IBM, SCO, etc. etc. nurturing their own
>  > proprietary solutions.
>
> Hold your horses there. I can partly see where you come from with the
> last two, but what part of the GPL makes solutions from the first two
> proprietary?

Uh, finish your milk and cookies and go to bed. Or if you choose to
grow up a bit, spend some time perusing the web sites of those
virtuous companies advancing the cause of GPL for the Good of
Humanity (TM). They are all companies with a growing list of
proprietary add-ons and services, and they are all trying to find
new ways to get customers to favor their particular packaging of
"free, universally available, uniform" code over others. Vendor
lock-in?

>             Even more specifically, what proprietary extensions to
> GCC do they (or any of the four for that matter) have?

GCC sits atop a C library and various other software tools. You'd
be surprised at how much variation exists between all the different
GCC "resellers". We have to live with it every day. Vendor lock-in?

>                                                        But we are a
> mile off course with this red herring here anyway. None of the
> companies you mentioned are trying to do what Microsoft is, so what I
> said about sombreros and rain dances applies to them too.

I'm sure it does, since I *still* don't know what Microsoft is
trying to do that differs so much from their competitors.

>  > Microsoft is guilty of being more successful
>  > at winning mindshare and making money, but...
>
> They are also guilty, in the actual sense of guilty, of illegal
> maintenance of a monopoly, forging illegal secret contracts, other
> antitrust violations, etc. You make it sound like they are some kind
> of geniuses instead of a company that has done more to screw true
> innovation over than probably any other company on earth.

Microsoft was found guilty of using its monopoly power in one
arena to gain unfair advantage in another, as I understand the
situation and the law. AT&T and IBM have signed consent decrees
to get out of similar binds. That makes them all stupid or clumsy,
in my book -- because all three companies were fully capable of
staying within the law and still beating their competition. But
it's a childish oversimplification to treat any large company as
homogeneous, in its motives, methods or opportunities.

Microsoft does indeed do ingenious things, from time to time,
but that was not my main point. I was merely observing that:

a) they don't have a lock on how software gets developed, not
even under Windows, and

b) all the evidence cited for their putative underhandedness
applies equally well to all software tools vendors trying to
make a profit and/or win mindshare.

When you view the world through dung-colored glasses, everything
looks brown.

>  > >                                        But Microsoft pushed hard make
>  > > it the preferred choice in writing code.  I have been throughtout the
>  > > guts of much of MFC, and let's just say I keep a can of air freshner
>  > > handy.  It also makes it very easy to disassemble a competitors
>  > > product if it is written almost entirely using a libary that you
>  > > wrote.
>  >
>  > Also true for glibc, neh?
>
> Again, no one is talking about glibc, at least until they try to do
> the same things Microsoft is.

And I maintain they are, in their own way. But I still don't fully
see your shadowy image of "what Microsoft is trying to do".

>  > > This is why it is so important that we keep their paws off C++.
>  >
>  > Okay, I got that you don't like Microsoft, and that you don't like
>  > them hanging around school playgrounds. You've thrown a lot of, uh,
>  > concepts against the wall but, IMO, none have stuck. So now how are
>  > you going to save the world and keep Microsoft's paws off C++?
>
> Well, if everyone else sold C++ libraries to Microsoft it would be a
> lost cause trying to keep their paws off anything. Fortunately, that
> is not the case.

I'm assuming that's a swipe at Dinkumware. Fortunately, I don't
understand it either.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Tommy McDaniel wrote:
 > he was talking about the cluelessness of programmers ingrained
 > into Microsoft's 'one true way,'

You insult the creator of a platform and the people who program
for it, and you expect that your arguments will fall on receptive
ears? Not likely.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 07/23/2004 05:08 AM, Gerhard Menzl wrote:
[snip]
> I don't think I said so. What I was trying to point out is that when you
> need to free resources at a precisely specified point of time, or as
> fast as possible, garbage collection is simply the wrong tool.
"Eager" cyclic reference counting:

   A. D. Martinez, R. Wachenchauzer, and Rafael D. Lins.
   "Cyclic reference counting with local mark-scan"
   Information Processing Letters, 34:31--35, 1990.

collects garbage as soon as it becomes garbage after some processing. 
It works by doing a local mark-scan after each refcount decrement.
However, as you can imagine, it can take a LOT of time
( search for "exponential running time" on
http://citeseer.ist.psu.edu/383386.html
).

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 2004-07-23 15:46, Larry Evans wrote:
> On 07/23/2004 05:08 AM, Gerhard Menzl wrote:
> [snip]
>> I don't think I said so. What I was trying to point out is that
>> when you need to free resources at a precisely specified point of
>> time, or as fast as possible, garbage collection is simply the
>> wrong tool.
>
> "Eager" cyclic reference counting:
>
>    A. D. Martinez, R. Wachenchauzer, and Rafael D. Lins.
>    "Cyclic reference counting with local mark-scan"
>    Information Processing Letters, 34:31--35, 1990.
>
> collects garbage as soon as it becomes garbage after some processing. 
> It works by doing a local mark-scan after each refcount decrement.
> However, as you can imagine, it can take a LOT of time
> ( search for "exponential running time" on
> http://citeseer.ist.psu.edu/383386.html
> ).

And it still has the disadvantage that order of destruction within a
cycle is arbitrary.

-- Niklas Matthies

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

> > It would be nice if we had some way that an OS could go round all 
> > running processes and ask them to hand back any unused resources but I 
> > am not aware of any OS that actually does that.
> > 
> > Co-operative GC might be quite a useful tool in our modern long running 
> > multi-tasking systems but we should not assume we already have it. And 
> > it would not be up to a language standard to provide it.
> 
> Your paragraphs contradict each other. For a process to know what
> resources are unused, its programming language must define how to
> determine that.

Ah, I think I finally see the core misconception that leads you to
make many of
the statements you have in this thread and the CLI threads.

You believe that the programming language itself must define unused
resources.

This is absolutely false. Just consider this very simple example:

int main ( ) {

    int i = 0 ;
    // do something with i

    int j = 1 ;
    // do something with j

}

Integers i and j are resources (for example registers). C++ provides
no mechanism
for us to "indicate" that i is will never again used. Yet, it is
abundantly obvious that i and
j could very easily in fact use the same register. This depends of
course on the
commented regions. However, it requires no additional language
mechanisms
to enable the compiler (or perhaps optimizer) to realize i is never
used again yet the
program still "collects" the now garbage i-register and reuses it for
j.

This same principle can be extended to any level of complication.
Garbage collection
could be slapped on top of C++ with no additional changes to the
language. Of course,
language changes may help to facilitate or support GC; but, this is a
different and weaker
statement than the ones you are making. In other words, you
exaggerate.

Indeed, the same misconception appears in many of your posts (for
example the CLI
thread) where you push ardently for language changes to support
various
features and oppose the notion that the same could be done simply with
libraries
(in other words with the language as-is).

Isn't this reasoning obviously flawed? Or were you trying to make some
other point
that I entirely missed?

In any case, Francis' comment was in no way contradictory. If you
still don't believe
read Stephen and Andrea's posts where they discuss co-op GC
implementations
with no changes to the language.

Keith

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"P.J. Plauger" <pjp@dinkumware.com> wrote in message news:<E1BnzSn-000JKD-0I@trinity.supernews.net>...

 > Uh, finish your milk and cookies and go to bed.

Ok, I will but first I need to find my "P.J."s  :p

 > Or if you choose to
 > grow up a bit, spend some time perusing the web sites of those
 > virtuous companies advancing the cause of GPL for the Good of
 > Humanity (TM). They are all companies with a growing list of
 > proprietary add-ons and services, and they are all trying to find
 > new ways to get customers to favor their particular packaging of
 > "free, universally available, uniform" code over others. Vendor
 > lock-in?

There is one critical difference between these companies and
Microsoft.  The other companies feature-enhance the products.
Microsoft attempts to "feature-enhance" the standard.

 > GCC sits atop a C library and various other software tools. You'd
 > be surprised at how much variation exists between all the different
 > GCC "resellers". We have to live with it every day. Vendor lock-in?

There is nothing wrong with distinguishing a product in the market.
The first time I saw the _declspec (naked) qualifier in Visual C++, I
was ready to workship at the granite in Redmond.  It means that you
could theoretically write a whole operating system entirely in C/C++.
But it's non-standard, and that's how it should be.

-Chaud Lapin-

P.S.

Milk and cookies are a lot more palpable than somethings you might
find at the other end of the journey.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Le Chaud Lapin" <unoriginal_username@yahoo.com> wrote in message
news:fc2e0ade.0407232344.419a5bb6@posting.google.com...

>  > Or if you choose to
>  > grow up a bit, spend some time perusing the web sites of those
>  > virtuous companies advancing the cause of GPL for the Good of
>  > Humanity (TM). They are all companies with a growing list of
>  > proprietary add-ons and services, and they are all trying to find
>  > new ways to get customers to favor their particular packaging of
>  > "free, universally available, uniform" code over others. Vendor
>  > lock-in?
>
> There is one critical difference between these companies and
> Microsoft.  The other companies feature-enhance the products.
> Microsoft attempts to "feature-enhance" the standard.

Sorry, but that's yet another difference I can't see. Our company
has to live with various "standards" covering Unix, Posix, Linux,
X/Open, combined this/that/the other. Some are real, in the sense
that ISO has blessed them; others are the result of various ad hoc
consortia whose stated goal (in each case) is to increase market
share for their particular dialect. Every blessed one of these
promotes a host of "feature enhancements" to C and C++ which
pollutes the language and library namespaces. Result:

1) They make it ever harder to write portable code, because of
name collisions.

2) They make it even harder to port code written in a Unix/Linux
environment to any other OS, because of all the enticing extra
features offered in the guise of "standard" libraries.

Vendor lock-in?

>  > GCC sits atop a C library and various other software tools. You'd
>  > be surprised at how much variation exists between all the different
>  > GCC "resellers". We have to live with it every day. Vendor lock-in?
>
> There is nothing wrong with distinguishing a product in the market.
> The first time I saw the _declspec (naked) qualifier in Visual C++, I
> was ready to workship at the granite in Redmond.  It means that you
> could theoretically write a whole operating system entirely in C/C++.
> But it's non-standard, and that's how it should be.

Everything should be non-standard, until a duly authorized standards
forming body approves it as part of a standard. Not sure how that
contributes to your earlier diatribe, unless you've now decided that
Microsoft is evil because it participates in standards development.
A few years ago, people were damning the company for not participating
enough. Go figure.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 07/23/2004 06:55 PM, Niklas Matthies wrote:
> On 2004-07-23 15:46, Larry Evans wrote:
[snip]
>>"Eager" cyclic reference counting:
>>
>>   A. D. Martinez, R. Wachenchauzer, and Rafael D. Lins.
>>   "Cyclic reference counting with local mark-scan"
>>   Information Processing Letters, 34:31--35, 1990.
>>
>>collects garbage as soon as it becomes garbage after some processing. 
[snip]
> 
> And it still has the disadvantage that order of destruction within a
> cycle is arbitrary.

True; however, isn't this true of any GC method when the graph contains
cycles?  For example, the BW collector has a similar problem with
determining the order of finalizer code in presence of cycles:

   http://www.hpl.hp.com/personal/Hans_Boehm/gc/finalization.html

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Francis Glassborow <francis@robinton.demon.co.uk> wrote in message news:<ZE4ZflyM8OABFwcJ@robinton.demon.co.uk>...
 > I would have thought that all those companies are doing exactly what MS
 > are doing, trying to make a profit. However in the case of SCO, I think
 > there is strong evidence that they are trying to do something much worse
 > than MS have ever done.

It's one thing to lie about your own products.  I remember a certain X
Windows terminal vendor blatantly lying to at a trade show about the
length of the  diagonal, claiming 2 inches more in length.  The
"shrewd" salesman knew that no one bothered to bring measurement tape
to trade shows.  But Microsoft is more clever.  Instead of fighting
the competition, they leverage the momentum, and surreptitiously steer
it right toward One Microsoft Way, without regard to the true cost to
the consumer.  This is their strategy of gorrilla "innovation".  When
a novel technology pops up with great consumer appeal, they
aggressively race to embrace the technology and feign to be its
champion while simultaneously subverting and/or contorting it so as to
generate a dependency on their tools.

Other comapanies might be guilty of this, but Microsoft makes it
policy.

 > However almost everything you post here comes with a premise that MS are
 > fundamentally motivated in ways that you think evil. If commercialism is
 > evil then OK.

Commercialism is not evil.  Deceptive, subversive, monopolistic
practices are.  This is why every now and then a judge orders someone
to pay a $1 billion fine, which brings me to my next thought:

Since much of the world's communication, transportation, energy,
scientific and medical software is written in C++, one could say that
we have a collective dependency on it ensuring that it remains
portable, functional, and maintainable in the spirit of previously
written software.  If a company could be proven to have engaged in
subversive practices to contort the language so as to weaken its
effectiveness as a general too for their own financial gain, our
common loss would be enormous.  Whether this is grounds for a viable
law suit remains to be seen, but I am sure there are more than a few
motivated attorneys who would accept the charge.

 > In the case of C++/CLI, indeed in the case of CLI and CLR, I think MS
 > have been good citizens and relinquished their proprietary rights (just
 > as AT&T were when they released various IPRs to allow C++ to be
 > standardised.) I have no idea what the motives of their upper management
 > maybe -- other than to make stacks of money which is surely what their
 > stockholders want.

Ummm...no.  Your statement makes it seem as if the C++ community were
clamoring for CLI/CLR while Microsoft hoarded it, and through their
benevolence, reluctantly acquiesed.  Compare:

C++ was created, and the community saw that it was good, and we asked
that it be brought upon us, with deferrment to those who understood
best how it should be, Bjarne Stroustrup and friends, under the
auspices of a standards body.

CLR was created, and some saw that it was a
sorta-kinda-pseudo-interpreted-language-like-thingy, but Microsoft
told Wall Street that they would spend hundreds of millions of dollars
on a marketing campaign to ensure that it be brought upon us, with
deferrment to those who know what they wanted best, Microsoft,
ostensibly under the auspices of a "standards body". This one of the
oldest tricks in the book.  King Leopold of Belgium used it to usurp a
huge chunk of Africa, the Belgian Congo.

The very idea of a CLR in the context of C++ is absurd - one takes the
most portable language on Earth, creates a virual machine for it where
the machine code is portable, then add extensions to the language so
that it can compile to the portable machine code, but ultimately
result in a non-portable language.  And let us not forget all the
problems of trying to sandbox a language that was meant to access
hardware directly.

 > There is also other evidence that MS wants to be a better citizen such
 > as their taking proposals for a set of 'secure' functions for the C
 > library to WG14. It would have been so much easier had they just
 > implemented such a library themselves and marketed their tools as
 > providing better facilities for safe programming (and, of course,
 > demanding IPR fees for anyone else copying them).

Hmm... if I were a safe manufaturer, and there were perpetual breaches
of my safes, I too would share the responsibility for future safe
designs with the people who use them.  Makes them less likely to point
the finger next breach.

 > I have all kinds of reservations about various large companies including
 > MS but that does not prevent me from carrying on a technical debate with
 > their representatives, and even sometimes winning such debates. Of
 > course such would be impossible if I spent my time describing my
 > 'opponents' as evilly motivated.

This is not about good and evil.  I do not hate Microsoft.  But I do
want them to keep their paws off C++.

 > Now there are many real technical issues concerning both C++/CLI and
 > future releases of the C++ Standard. Let us spend time and effort trying
 > to understand those and thereby make a positive contribution.

The presumption here is that there are issues to be considered.  Many
of us are saying that there are not.  And as I have said before,
though we are relatively few, democracy should not prevail when
determining the direction of the language, as many of the people who
will be ultimately using C++.NET are impressionable young programmers,
and they might have not yet developed enough insight to make a
qualified assessment of the merits or demerits of perturbing the
language so drastically.

-Chaud Lapin-

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 2004-07-25 00:30, Larry Evans wrote:
 > On 07/23/2004 06:55 PM, Niklas Matthies wrote:
 >> On 2004-07-23 15:46, Larry Evans wrote:
 > [snip]
 >>>"Eager" cyclic reference counting:
 >>>
 >>>   A. D. Martinez, R. Wachenchauzer, and Rafael D. Lins.
 >>>   "Cyclic reference counting with local mark-scan"
 >>>   Information Processing Letters, 34:31--35, 1990.
 >>>
 >>>collects garbage as soon as it becomes garbage after some processing.
 > [snip]
 >>
 >> And it still has the disadvantage that order of destruction within a
 >> cycle is arbitrary.
 >
 > True; however, isn't this true of any GC method when the graph
 > contains cycles?

Yes, that was sort of what I was trying to say. Cycles are an inherent
problem, regardless of whether destruction is deterministic or not.
If a particular order of destruction is required, the programmer must
somehow give hints to the collection mechanism to communicate that
order. In a way, weak pointers are just that.

-- Niklas Matthies

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Let me state up front that when it comes to C++/CLI standard
I'm too ignorant to have an opinion at the moment. So please
take these questions as complete curiosity which they are.

> Everything should be non-standard, until a duly authorized standards
> forming body approves it as part of a standard.

Shouldn't a thing remain non-standard until that thing has
explored it's many possibilities, been tested by many,
evolved, survived, and otherwise matured to the point
where it and we can benefit most from its crystallization?

It seems that a "duly authorized ... body" should be the
instrument of and not the motivation for a standard.

Doesn't premature standardization in fact greatly hinder
innovation causing us to lose in the long term while perhaps
benefiting in the short term?

For example consider the premature wireless standardization
in Europe upon TDMA which has now become the poster child
of early standardization disasters (and government
interference). It was pure hubris for a small body of
bureaucrats to think that they could evaluate the "ideal"
choice without allowing the market to experiment thoroughly.

If C++/CLI is so fantastic why does it need to be
standardized to succeed? Shouldn't it simply plow over any
competition?

> A few years ago, people were damning the company [Microsoft]
> for not participating enough. Go figure.

I thought they were being damned for not *complying* enough?
At least, that's what I was damning when VC++ 6 came out.
(Broken for loops for example. And shall we mention template
problems?)

Keith

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Le Chaud Lapin wrote:

> C++ was created, and the community saw that it was good, and we asked
> that it be brought upon us, with deferrment to those who understood
> best how it should be, Bjarne Stroustrup and friends, under the
> auspices of a standards body.


Actually C++ was developed in AT&T who decided to let it become public 
and standardised.



> The very idea of a CLR in the context of C++ is absurd - one takes the
> most portable language on Earth, creates a virual machine for it where
> the machine code is portable, then add extensions to the language so
> that it can compile to the portable machine code, but ultimately
> result in a non-portable language.  And let us not forget all the
> problems of trying to sandbox a language that was meant to access
> hardware directly.



Check TC++PL 3, C.9.1 on page 844. Also GC is used in many C++ projects 
these days, even inside compiler implementations.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Francis Glassborow <francis@robinton.demon.co.uk> wrote in message news:<ZE4ZflyM8OABFwcJ@robinton.demon.co.uk>...
> In article <c0fba064.0407222226.6fe5e509@posting.google.com>, Tommy 
> McDaniel <tdmj@hotmail.com> writes
> > > As do Red Hat, Suse, IBM, SCO, etc. etc. nurturing their own
> > > proprietary solutions.
> >
> >Hold your horses there. I can partly see where you come from with the
> >last two, but what part of the GPL makes solutions from the first two
> >proprietary? Even more specifically, what proprietary extensions to
> >GCC do they (or any of the four for that matter) have? But we are a
> >mile off course with this red herring here anyway. None of the
> >companies you mentioned are trying to do what Microsoft is, so what I
> >said about sombreros and rain dances applies to them too.
> 
> I would have thought that all those companies are doing exactly what MS 
> are doing, trying to make a profit.

Why must you play word games? We are talking about garbage collection
and C++ here, not the infinite variety of things that all companies
do.

> However in the case of SCO, I think 
> there is strong evidence that they are trying to do something much worse 
> than MS have ever done.

With Microsoft's funding and behind the scenes backing. Which kind of
makes Microsoft guilty of SCO's crimes.

> If commercialism is 
> evil then OK.

Did anyone say or even imply anything of the sort? Why is the straw
man the most popular argument in these threads involving Microsoft?

> In the case of C++/CLI, indeed in the case of CLI and CLR, I think MS 
> have been good citizens and relinquished their proprietary rights

And the Greeks released all rights to their wonderful gift to the
Trojans.

> (just 
> as AT&T were when they released various IPRs to allow C++ to be 
> standardised.)

Microsoft != AT&T. Who cares what AT&T or anyone else did. We are
discussing Microsoft.

> I have no idea what the motives of their upper management 
> maybe -- other than to make stacks of money which is surely what their 
> stockholders want.

We do not have to be invited to their boardroom meetings to see from
their entire history that if there is a way to screw someone or
something they do not control and poses any kind of a threat to them
they will, for their own sake and no one else's.

> There is also other evidence that MS wants to be a better citizen such 
> as their taking proposals for a set of 'secure' functions for the C 
> library to WG14. It would have been so much easier had they just 
> implemented such a library themselves and marketed their tools as 
> providing better facilities for safe programming (and, of course, 
> demanding IPR fees for anyone else copying them).

The exact same could have been said about ECMA-234, "Application
Programming Interface for Windows"
(http://www.ecma-international.org/publications/standards/Ecma-234.htm),
back in 1995. Proof that Microsoft was trying to be a better citizen?
At least we have hindsight of their behavior since 1995 in this case,
foresight apparently being a rare ability.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBBKtGVB8FYP9YqDcRAilDAJ9CikRhNuuBpX458i9QJucoBg9x4wCfaLDx
mJvsumgf1kGNhoag//MeqCI=
=3hxs
-----END PGP SIGNATURE-----

On 2004-07-25 21:31, Keith H Duggar wrote:
:
 > If C++/CLI is so fantastic why does it need to be standardized to
 > succeed? Shouldn't it simply plow over any competition?

The standard ensures that competitors of Microsoft can implement it.
A past criticism towards Microsoft has always been that they obscure
their technologies and make hidden adjustments all the time so that
it's impossible for competitors to implement a compatible alternative.

But of course it's not for completely altruistic reasons that they try
to get things standardized now. It's because standards helps getting a
higher acceptance. More developers will use C++/CLI when they know
it's standardized, because the standard means that the use of C++/CLI
does _not_ mean vendor lock-in as it would be with a proprietary
technology.

- Niklas Matthies

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Keith H Duggar" <duggar@mit.edu> wrote in message
news:b47de02.0407251106.3ba7e7c9@posting.google.com...

 > Let me state up front that when it comes to C++/CLI standard
 > I'm too ignorant to have an opinion at the moment. So please
 > take these questions as complete curiosity which they are.
 >
 > > Everything should be non-standard, until a duly authorized standards
 > > forming body approves it as part of a standard.
 >
 > Shouldn't a thing remain non-standard until that thing has
 > explored it's many possibilities, been tested by many,
 > evolved, survived, and otherwise matured to the point
 > where it and we can benefit most from its crystallization?

That's my preference, yes.

 > It seems that a "duly authorized ... body" should be the
 > instrument of and not the motivation for a standard.

That's my preference, yes.

 > Doesn't premature standardization in fact greatly hinder
 > innovation causing us to lose in the long term while perhaps
 > benefiting in the short term?

That's a real possibility, yes.

 > For example consider the premature wireless standardization
 > in Europe upon TDMA which has now become the poster child
 > of early standardization disasters (and government
 > interference). It was pure hubris for a small body of
 > bureaucrats to think that they could evaluate the "ideal"
 > choice without allowing the market to experiment thoroughly.

That's my belief too, yes.

 > If C++/CLI is so fantastic why does it need to be
 > standardized to succeed?

Nobody said it did. There's more than one reason to take
a chance on early standardization.

 >                         Shouldn't it simply plow over any
 > competition?

That's one approach, yes.

 > > A few years ago, people were damning the company [Microsoft]
 > > for not participating enough. Go figure.
 >
 > I thought they were being damned for not *complying* enough?
 > At least, that's what I was damning when VC++ 6 came out.
 > (Broken for loops for example. And shall we mention template
 > problems?)

There was no C++ Standard when V6 came out. So it's a bit
unfair to characterize for loops as broken when they behaved
the way they always had in C and C++. Similarly, templates
were evolving rapidly even as V6 was being frozen, tested,
and packaged. You can gripe about bugs, perhaps, but I
found Microsoft reasonably quick to fix those. Griping about
their trailing a moving target, however, is another matter.

Nevertheless, people had opinions about how closely Microsoft
should have been tracking the still changind draft C++ Standard
through the release of V6 and beyond. For whatever reason(s),
however, Microsoft chose during that period not to participate
so actively in the development of either the C++ or the revised
C standards. They've since become more active (once again).

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"P.J. Plauger" <pjp@dinkumware.com> wrote in message news:<E1BnzSn-000JKD-0I@trinity.supernews.net>...
> "Tommy McDaniel" <tdmj@hotmail.com> wrote in message
> news:c0fba064.0407222226.6fe5e509@posting.google.com...
> 
> > "P.J. Plauger" <pjp@dinkumware.com> wrote in message
>  news:<E1Bnmmk-0005fn-00@chx400.switch.ch>...
> >  > "Le Chaud Lapin" <unoriginal_username@yahoo.com> wrote in message
> >  > news:fc2e0ade.0407220208.ca935b3@posting.google.com...
> >  >
> >  > > I believe that Microsoft is meddling with C++  because they know that
> >  > > C++ is the language of choice for the serious software engineer, and
> >  > > they want to force those engineers into the .NET arena through the
> >  > > language, as C++ programmers are also those who are often the most
> >  > > strong will and self-guided - not likely to jump onto every bandwagon
> >  > > that comes along just because it's the new thing.
> >  >
> >  > Force? They can entice, but they lack the policing power to force.
> >
> > Kind of like Vito Corleone making offers you couldn't refuse. Ever
> > heard of vendor lock-in?
> 
> Of course I have, and it's getting harder all the time for vendors to
> lock in their clientele -- yes, even for Microsoft.

That is real easy to say, isn't it.

> Or you can go to Borland, or
> Comeau, or MinGW, or several other sources of C++ development tools
> for Windows and thumb your nose at Microsoft's offerings.

Until Microsoft is done making their extensions to C++ part of the
language itself that you cannot get away from.

> Corleone still has more "policing power" than Microsoft, if you
> care to notice.

Corleone did not have quite so many so brainlessly entranced into a
view that whatever he said or did was the dictum of the Almighty God
himself.

> >  > >                           But microsoft goes a step further.  They
> >  > > make everything from CString to CDate heavily bound to Microsoft.
> >  >
> >  > Why not? Most of these things predate any standards, and/or meet
> >  > needs that go beyond standards. Unix does the same sort of thing,
> >  > as does every other major OS.
> >
> > Whoa, whoa there Charlie. UNIX and every other major OS vendor are not
> > trying to do what Microsoft is trying to do.
> 
> Really, how do you know?

If they are all trying to get their own forms of garbage collection
and virtual machines, or any other of their own extensions for that
matter, into C++, I would appreciate someone letting me know. We
cannot discuss it if we do not know about it.

> Looks to me like they're all trying to make
> money and increase market share. If not, their stockholders should
> be informed...

Ding ding ding, we have a winner (at long stinking last). I have not
been invited to Microsoft strategic planning sessions lately, but you
can bet your butt that, in the end, this is all about their bank
accounts and their further domineering of stuff they domineer (or do
not domineer yet and just want to domineer), not interest in helping
C++. Just because screwing the world for their own gain is profitable
for them and their shareholders does not mean that the rest of us have
to like it or take it.

> >                                             It doesn't matter if UNIX
> > and every other major OS vendor puts on a Mexican sombrero and does a
> > rain dance every night at midnight; as I said, they are not trying to
> > do what Microsoft is trying to do.
> 
> Wouldn't matter if the top management at Microsoft did that either --
> it would be equally ineffective. Whatever it is they're trying to do.

OK, here is what I meant in simpler language: what "UNIX and every
other major OS vendor" does is irrelevant. Forget the specifics about
sombreros and rain dances.

> >                           You continually brought up everyone
> > besides Microsoft in your post as if someone were arguing for their
> > forms of garbage collection but not Microsoft's.
> 
> Oh, you're thinking about garbage collection.

Indeed, as the title of the thread would indicate.

> As for Microsoft's new offering of GC, you don't *have* to
> use it, you know. It's just an enticement, not an offer you can't
> refuse.

Well, you would not have to use my homebrewed libraries either if they
were put into C++. They would just be an enticement, not an offer you
can't refuse. Yet somehow I have a feeling you would be a lot less
supportive of the average bear than you are of Microsoft, for purely
technical reasons, of course.

> >  > >             they hardly look the same.  I know several senior
> >  > > engineers who have to take pause when I tell them that ULONG is not a
> >  > > fundamental type in C++, nor is UINT.
> >  >
> >  > Nor is clockid_t, nor timer_t, nor all the gazillions of other things
> >  > in Unix headers that violate the C Standard.
> >
> > He did not argue that only Microsoft has non-standard things in their
> > libraries.
> 
> Perhaps not, but he seemed to see something pernicious in the fact
> that Microsoft *did* offer non-standard things. Just wondering why
> it ain't pernicious when others do it.

I cannot speak for him and will not even bother trying, but if I had
to throw something out there I would guess that it is a lot less
pernicious to live life on the non-standard side of things when you
are not trying to get stuff stuck into C++ and do not have a track
record of ignoring standards you could not control unless you were
forced not to than it is when those things are true.

> >                                            he was talking about the
> > cluelessness of programmers ingrained into Microsoft's 'one true way,'
> > not the fact that they have non-standard things.
> 
> I've been meeting clueless programmers for over 40 years now. And
> watching companies try to make money off them (sometimes even by
> actually helping them). You can't blame companies for wanting to
> do that, or for succeeding. *Maybe* you can blame programmers for
> being clueless, since thats fixable.

Both the clueless programmers and those who take advantage of their
cluelessness are reprehensible. You cannot put the blame for the
companies' actions on the programmers. The clueless are responsible
for their cluelessness, but those taking advantage of it for their own
ends are also responsible for their own actions.

> >  > >                                      But of them actually regard
> >  > > "unsigned int" with contempt, as if it is not a legitimate part of
>  the
> >  > > language.  Microsoft loves this mentality.  They spend much money and
> >  > > time nurturing it.
> >  >
> >  > As do Red Hat, Suse, IBM, SCO, etc. etc. nurturing their own
> >  > proprietary solutions.
> >
> > Hold your horses there. I can partly see where you come from with the
> > last two, but what part of the GPL makes solutions from the first two
> > proprietary?
> 
> Uh, finish your milk and cookies and go to bed. Or if you choose to
> grow up a bit, spend some time perusing the web sites of those
> virtuous companies advancing the cause of GPL for the Good of
> Humanity (TM). They are all companies with a growing list of
> proprietary add-ons and services

So much for veiling insults. They would even be a lot more convincing
if you were right. I do not know if it is still true, but I know that
Red Hat had (and probably still has) a policy of releasing all of
their software under the GPL. So for the second time I ask you, what
exactly is proprietary about the GPL? Especially from the point of
view of someone who seems to think Microsoft does things the 'right'
way.

> and they are all trying to find
> new ways to get customers to favor their particular packaging of
> "free, universally available, uniform" code over others.

So? No one said those software companies did not sell software. I
should also bring up that we are three miles off course on a red
herring, since it would not matter if they were Satan incarnate, as
they are not pushing for their own forms of garbage collection to be
standardized (and if they were, we still would not be talking about
them anyway).

> Vendor
> lock-in?

Nope. It is hard to be locked in when you have the source code and the
full rights afforded by the GPL, BSD license, or whatever other
license a particular piece of open source software might be under.

> >             Even more specifically, what proprietary extensions to
> > GCC do they (or any of the four for that matter) have?
> 
> GCC sits atop a C library and various other software tools. You'd
> be surprised at how much variation exists between all the different
> GCC "resellers". We have to live with it every day. Vendor lock-in?
> 
> >                                                        But we are a
> > mile off course with this red herring here anyway. None of the
> > companies you mentioned are trying to do what Microsoft is, so what I
> > said about sombreros and rain dances applies to them too.
> 
> I'm sure it does, since I *still* don't know what Microsoft is
> trying to do that differs so much from their competitors.

Garbage collection (you know, the topic of this thread) ring a bell?

> >  > Microsoft is guilty of being more successful
> >  > at winning mindshare and making money, but...
> >
> > They are also guilty, in the actual sense of guilty, of illegal
> > maintenance of a monopoly, forging illegal secret contracts, other
> > antitrust violations, etc. You make it sound like they are some kind
> > of geniuses instead of a company that has done more to screw true
> > innovation over than probably any other company on earth.
> 
> That makes them all stupid or clumsy,
> in my book -- because all three companies were fully capable of
> staying within the law and still beating their competition.

You state your opinion as if it were fact. So, they all broke the law
for the fun of long, expensive antitrust trials, not because they
needed to, huh?

> But
> it's a childish oversimplification to treat any large company as
> homogeneous, in its motives, methods or opportunities.

Companies typically have one CEO, one COO, one ... that typically
determine what course the company ultimately takes. Companies do not
just bounce through Wonderland without one group of top leadership
running the show. And yes, that top group is likely to be fairly
homogenous.

> b) all the evidence cited for their putative underhandedness
> applies equally well to all software tools vendors trying to
> make a profit and/or win mindshare.

Anyone have the secret proposal from all these other companies to add
garbage collection (and, more broadly speaking, a virtual machine) to
C++? Or, for that matter, transcripts from their secret trials that
clearly shows that they did the same stuff Microsoft was busted for
(the effects of which one would think would be visible to a blind man,
but apparently not)?

> >  > >                                        But Microsoft pushed hard make
> >  > > it the preferred choice in writing code.  I have been throughtout the
> >  > > guts of much of MFC, and let's just say I keep a can of air freshner
> >  > > handy.  It also makes it very easy to disassemble a competitors
> >  > > product if it is written almost entirely using a libary that you
> >  > > wrote.
> >  >
> >  > Also true for glibc, neh?
> >
> > Again, no one is talking about glibc, at least until they try to do
> > the same things Microsoft is.
> 
> And I maintain they are, in their own way. But I still don't fully
> see your shadowy image of "what Microsoft is trying to do".

Earlier in your post you figured out we were talking about garbage
collection, and then you forgot again. And no, glibc is not trying to
add garbage collection to C++ (not the least of the reasons why being
that glibc is a C library, not a C++ one).

> >  > > This is why it is so important that we keep their paws off C++.
> >  >
> >  > Okay, I got that you don't like Microsoft, and that you don't like
> >  > them hanging around school playgrounds. You've thrown a lot of, uh,
> >  > concepts against the wall but, IMO, none have stuck. So now how are
> >  > you going to save the world and keep Microsoft's paws off C++?
> >
> > Well, if everyone else sold C++ libraries to Microsoft it would be a
> > lost cause trying to keep their paws off anything. Fortunately, that
> > is not the case.
> 
> I'm assuming that's a swipe at Dinkumware. Fortunately, I don't
> understand it either.

Not understanding is fortunate? It was not intended to be very subtle.
But here it is in easier language: your company, Dinkumware, is, and I
quote your webpage, "the folks who supply the Standard C++ library
that ships with Microsoft VC++, and we've done so for the past seven
years." Trying to convince you to take a stand contrary to Microsoft
is probably about as likely to succeed as, uh, trying to convince
Microsoft to take a stand contrary to Microsoft. If this is not a
conflict of interest, I would like someone to show me what is (besides
Sutter being a Microsoft employee, but let us focus here).

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBBMD9VB8FYP9YqDcRAutkAJwOUY+nwO3j562M2Qet1sePpj2C9QCeJGAb
lV7z/k3VplmnRxM4giCSDEo=
=k7h4
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"P.J. Plauger" <pjp@dinkumware.com> wrote in message news:<E1BoKya-0004xC-00@chx400.switch.ch>...
> "Le Chaud Lapin" <unoriginal_username@yahoo.com> wrote in message
> news:fc2e0ade.0407232344.419a5bb6@posting.google.com...
> 
> >  > Or if you choose to
> >  > grow up a bit, spend some time perusing the web sites of those
> >  > virtuous companies advancing the cause of GPL for the Good of
> >  > Humanity (TM). They are all companies with a growing list of
> >  > proprietary add-ons and services, and they are all trying to find
> >  > new ways to get customers to favor their particular packaging of
> >  > "free, universally available, uniform" code over others. Vendor
> >  > lock-in?
> >
> > There is one critical difference between these companies and
> > Microsoft.  The other companies feature-enhance the products.
> > Microsoft attempts to "feature-enhance" the standard.
> 
> Sorry, but that's yet another difference I can't see.

You seriously cannot see the difference between a product and a
standard? That is a rather incredible accomplishment around these
parts.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBBMMaVB8FYP9YqDcRAkayAKCM5r5HYRcQ4+5DJEFsgGjwBwTtiACfXLOG
TKD1o2Rd9wsEBBYzQc0Y5Qo=
=7qwz
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1090594415.609651@master.nyc.kbcfp.com>...
> Tommy McDaniel wrote:
>  > he was talking about the cluelessness of programmers ingrained
>  > into Microsoft's 'one true way,'
> 
> You insult the creator of a platform and the people who program
> for it, and you expect that your arguments will fall on receptive
> ears?

Well, not the ears of the aforementioned clueless programmers or of
Microsoft, but fortunately neither has yet officially bought C++ (not
counting the C++ committee convener and secretary, but I will leave
that alone, for now), making buttering up one's opinions of them
unnecessary. If your only response to things has finally degraded to
'that was mean,' you should just hang them up.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBBMWvVB8FYP9YqDcRAkQJAJ9RtF3aKH2LmC05oxWjIuwcexi3TwCfbbcq
Turq/09kj/UcRihn3tVSKlk=
=2hHP
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"P.J. Plauger" <pjp@dinkumware.com> wrote in message news:<E1BoKya-0004xC-00@chx400.switch.ch>...
> "Le Chaud Lapin" <unoriginal_username@yahoo.com> wrote in message
> news:fc2e0ade.0407232344.419a5bb6@posting.google.com...
> 
> >  > Or if you choose to
> >  > grow up a bit, spend some time perusing the web sites of those
> >  > virtuous companies advancing the cause of GPL for the Good of
> >  > Humanity (TM). They are all companies with a growing list of
> >  > proprietary add-ons and services, and they are all trying to find
> >  > new ways to get customers to favor their particular packaging of
> >  > "free, universally available, uniform" code over others. Vendor
> >  > lock-in?
> >
> > There is one critical difference between these companies and
> > Microsoft.  The other companies feature-enhance the products.
> > Microsoft attempts to "feature-enhance" the standard.
> 
> Sorry, but that's yet another difference I can't see.

You seriously cannot see the difference between a product and a
standard? That is a rather incredible accomplishment around these
parts.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBBMMaVB8FYP9YqDcRAkayAKCM5r5HYRcQ4+5DJEFsgGjwBwTtiACfXLOG
TKD1o2Rd9wsEBBYzQc0Y5Qo=
=7qwz
-----END PGP SIGNATURE-----

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Tommy McDaniel" <tdmj@hotmail.com> wrote in message
news:c0fba064.0407260034.2a3fe6e2@posting.google.com...

> > >  > Or if you choose to
> > >  > grow up a bit, spend some time perusing the web sites of those
> > >  > virtuous companies advancing the cause of GPL for the Good of
> > >  > Humanity (TM). They are all companies with a growing list of
> > >  > proprietary add-ons and services, and they are all trying to find
> > >  > new ways to get customers to favor their particular packaging of
> > >  > "free, universally available, uniform" code over others. Vendor
> > >  > lock-in?
> > >
> > > There is one critical difference between these companies and
> > > Microsoft.  The other companies feature-enhance the products.
> > > Microsoft attempts to "feature-enhance" the standard.
> >
> > Sorry, but that's yet another difference I can't see.
>
> You seriously cannot see the difference between a product and a
> standard? That is a rather incredible accomplishment around these
> parts.

You persist in quoting out of context and disregarding most other
rules of civilized discourse. I no longer feel obliged to reply
to your rants.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Tommy McDaniel wrote:

> Hold your horses there. I can partly see where you come from with the
> last two, but what part of the GPL makes solutions from the first two
> proprietary? Even more specifically, what proprietary extensions to
> GCC do they (or any of the four for that matter) have? But we are a
> mile off course with this red herring here anyway. None of the
> companies you mentioned are trying to do what Microsoft is, so what I
> said about sombreros and rain dances applies to them too.



Tell me, why do you feel so much pain about a separate from ISO C++, VM 
multilingual environment? Because it will hurt Java?






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"P.J. Plauger" <pjp@dinkumware.com> wrote in message news:<200407261344.i6QDiZUT084786@horus.isnic.is>...
> "Tommy McDaniel" <tdmj@hotmail.com> wrote in message
> news:c0fba064.0407260034.2a3fe6e2@posting.google.com...
> 
> > > >  > Or if you choose to
> > > >  > grow up a bit, spend some time perusing the web sites of those
> > > >  > virtuous companies advancing the cause of GPL for the Good of
> > > >  > Humanity (TM). They are all companies with a growing list of
> > > >  > proprietary add-ons and services, and they are all trying to find
> > > >  > new ways to get customers to favor their particular packaging of
> > > >  > "free, universally available, uniform" code over others. Vendor
> > > >  > lock-in?
> > > >
> > > > There is one critical difference between these companies and
> > > > Microsoft.  The other companies feature-enhance the products.
> > > > Microsoft attempts to "feature-enhance" the standard.
> > >
> > > Sorry, but that's yet another difference I can't see.
> >
> > You seriously cannot see the difference between a product and a
> > standard? That is a rather incredible accomplishment around these
> > parts.
> 
> You persist in quoting out of context

Examples? Getting cornered with your own statements does not mean you
were quoted out of context. In particular, you never made any
statements to the effect that this particular statement I quoted was
just a lie you were saying anyway, and there were no indications that
you were just trying to be sarcastic. All you did there was go on
about how you actually have to track other standards too (if I
remember correctly without looking up the exact words of your post).
It is hard to go around baselessly accusing people of misquoting you
whenever you corner yourself when your entire statements are there to
be read by anyone (literally one click away, at most, here on Google
Groups).

> and disregarding most other
> rules of civilized discourse.

Like what, disagreeing with you? Not caving intellectually at the
first sign that someone disagrees with me, strongly even? Other
examples?

> I no longer feel obliged to reply
> to your rants.

You were not obliged to start with. Funny that your desire left as
soon as I pointed out that statement you made. If you are just going
to bow out and hurl baseless accusations when it becomes convenient to
do so, it is just as well.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBBg1DVB8FYP9YqDcRAsG2AJ0R+Kj59YyliIoMl+hUFkkfY6La8gCfaZ83
hsOoCtvWI4yIiov0A94C1DE=
=ta3i
-----END PGP SIGNATURE-----

 > There is one critical difference between these companies and
 > Microsoft.  The other companies feature-enhance the products.
 > Microsoft attempts to "feature-enhance" the standard.

What exactly is wrong with that? If I happen to believe that my
"enhancement" is good for C++, why should I not try and persuade the C++
committee to add it to the standard? And the C++ committee members are
grown-ups, they will reject it if it does not fit in.

Stephen Howe



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 >  > I have all kinds of reservations about various large companies
including
 >  > MS but that does not prevent me from carrying on a technical debate
with
 >  > their representatives, and even sometimes winning such debates. Of
 >  > course such would be impossible if I spent my time describing my
 >  > 'opponents' as evilly motivated.
 >
 > This is not about good and evil.  I do not hate Microsoft.  But I do
 > want them to keep their paws off C++.

That is foolhardy.

I wish for Microsoft to propose as many ideas as they like.
And I wish for the standards C++ committee to treat each idea on merit and
to accept/reject on the basis of the criterion mentioned in D&E.

If MS coms up with a good idea, are you seriously suggesting that standards
C++ committee should reject it because it originates from MS?

Stephen Howe



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <410593d6$0$306$cc9e4d1f@news.dial.pipex.com>, Stephen Howe 
<sjhoweATdialDOTpipexDOTcom@eu.uu.net> writes
> > There is one critical difference between these companies and
> > Microsoft.  The other companies feature-enhance the products.
> > Microsoft attempts to "feature-enhance" the standard.
>
>What exactly is wrong with that? If I happen to believe that my
>"enhancement" is good for C++, why should I not try and persuade the C++
>committee to add it to the standard? And the C++ committee members are
>grown-ups, they will reject it if it does not fit in.

Even stronger than that, WG21 actively encourages proposers of ideas to 
implement them and test them in the field as a demonstration of both 
feasibility and demand.

-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<ce4m2n$1jse$1@ulysses.noc.ntua.gr>...
> Tommy McDaniel wrote:
> 
> > Hold your horses there. I can partly see where you come from with the
> > last two, but what part of the GPL makes solutions from the first two
> > proprietary? Even more specifically, what proprietary extensions to
> > GCC do they (or any of the four for that matter) have? But we are a
> > mile off course with this red herring here anyway. None of the
> > companies you mentioned are trying to do what Microsoft is, so what I
> > said about sombreros and rain dances applies to them too.
> 
> 
> 
> Tell me, why do you feel so much pain about a separate from ISO C++, VM 
> multilingual environment?

And this is why censorship is bad, mmmkay? Read, for example, this
reply to Francis Glassborow, which I fortunately posted separately to
comp.lang.c++ since it was censored from appearing in
comp.lang.c++.moderated:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=c0fba064.0407260115.5d0b0e02%40posting.google.com.
But in any case, note that the discussion about C++/CLI concerns
C++/CLI, not language-independent/CLI. I could not care less about its
interaction with other languages. But in any case, conversations of
this nature should ideally be held in an open forum like comp.lang.c++
instead of the tightly controlled comp.lang.c++.moderated. Half my
posts do not show up in the latter. One does not have to like what I
have to say about the subject (or what anyone else has to say for that
matter), but to prevent people from saying it at all? I was originally
not going to participate in the discussion at all in such a censored
forum, but finally convinced myself to go ahead as long as I
crossposted everything to comp.lang.c++ due to the importance of the
subject.

> Because it will hurt Java?

Now that is just plain funny. I do not like Java, at all. Look up my
past posts if you do not believe me. Nice try at imputing convenient
false motives to people though.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBBqCLVB8FYP9YqDcRAt/OAJ9JFRonmUXwFLXQG/fL+KJDNyrgZQCgiWty
rWnQ2E8DwMZ6VqEgaejSeG4=
=sH81
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Stephen Howe" <sjhoweATdialDOTpipexDOTcom@eu.uu.net> wrote in message news:<41059596$0$313$cc9e4d1f@news.dial.pipex.com>...
> >  > I have all kinds of reservations about various large companies
>  including
>  >  > MS but that does not prevent me from carrying on a technical debate
>  with
>  >  > their representatives, and even sometimes winning such debates. Of
>  >  > course such would be impossible if I spent my time describing my
>  >  > 'opponents' as evilly motivated.
>  >
>  > This is not about good and evil.  I do not hate Microsoft.  But I do
>  > want them to keep their paws off C++.
> 
> That is foolhardy.
> 
> I wish for Microsoft to propose as many ideas as they like.
> And I wish for the standards C++ committee to treat each idea on merit and
> to accept/reject on the basis of the criterion mentioned in D&E.
> 
> If MS coms up with a good idea, are you seriously suggesting that standards
> C++ committee should reject it because it originates from MS?

You act as if the opinions held by many about Microsoft are undeserved
and new to you. Rest assured that their history provides more than
enough reason for many people to have those opinions and not want to
have anything at all to do with them. But who needs history and 20+
year track records anyway. Poor poor Microsoft, they just get a bum
rap for no good reason at all.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBBqcQVB8FYP9YqDcRApi2AJ9yqzdBJPm20qFPTey4D2rUuZERtQCfSrk5
ZkuDwFyzF36X1pgdcWUBkVY=
=FItY
-----END PGP SIGNATURE-----

Tommy McDaniel wrote:

> Now that is just plain funny. I do not like Java, at all. Look up my
> past posts if you do not believe me. Nice try at imputing convenient
> false motives to people though.



Then why so much fierce reaction. C++/CLI is not part of the C++ 
standard, but a separate standard of extensions to help programmers to 
take advantage of the special characteristics of a CLI compliant VM when 
one is available. CLI is also an existing ECMA and ISO standard.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Francis Glassborow <francis@robinton.demon.co.uk> wrote in message news:<NQyc6bWjnjBBFwno@robinton.demon.co.uk>...
> In article <410593d6$0$306$cc9e4d1f@news.dial.pipex.com>, Stephen Howe 
> <sjhoweATdialDOTpipexDOTcom@eu.uu.net> writes
> > > There is one critical difference between these companies and
> > > Microsoft.  The other companies feature-enhance the products.
> > > Microsoft attempts to "feature-enhance" the standard.
> >
> >What exactly is wrong with that? If I happen to believe that my
> >"enhancement" is good for C++, why should I not try and persuade the C++
> >committee to add it to the standard? And the C++ committee members are
> >grown-ups, they will reject it if it does not fit in.

If being grown-up is all it took for objectivism to prevail, a lot of
problems in the world would not exist.  There would be no war right
now - everyone would agree where fault lied, and act accordingly. And
in any organization, even a democracy, some members have more
influence than others, by virtue of their stature, not the merit of
their ideas.

> Even stronger than that, WG21 actively encourages proposers of ideas to 
> implement them and test them in the field as a demonstration of both 
> feasibility and demand.

....before they become part of the standard.  Not after.

-Chaud Lapin-

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<ce6gu2$2r5d$1@ulysses.noc.ntua.gr>...
> Tommy McDaniel wrote:
> 
> > Now that is just plain funny. I do not like Java, at all. Look up my
> > past posts if you do not believe me. Nice try at imputing convenient
> > false motives to people though.
> 
> 
> 
> Then why so much fierce reaction.

Did you bother to read my post that I provided a link to? Is the only
reason you can conceive of for resisting this really that people are
just a bunch of undercover Java operatives?

> C++/CLI is not part of the C++ 
> standard, but a separate standard of extensions to help programmers to 
> take advantage of the special characteristics of a CLI compliant VM when 
> one is available. CLI is also an existing ECMA and ISO standard.

I addressed all of that in the same aforementioned post. Seriously,
read stuff like that next time.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBB0e7VB8FYP9YqDcRAlWxAJ4pT8b2OtvZgOImIYUffgnbirRevgCeJRod
BRSnOw0dZt5h3PL9BQzOIkU=
=Fqcd
-----END PGP SIGNATURE-----

Tommy McDaniel wrote:

> Did you bother to read my post that I provided a link to? Is the only
> reason you can conceive of for resisting this really that people are
> just a bunch of undercover Java operatives?


I have seen many like that around. Are you talking about the Win32 API 
related standard?


Except of the fact that I did not see any harm that it caused, I was 
ignoring its existence till some weeks ago that I came across it looking 
for something in the web.


Also a major difference in the case of CLI standard, is that there is 
already a non-MS CLI compliant implementation that exists also for 
Windows (competing with .NET) in addition to GNU/Linux, Mac OS X and Unix.

It is Mono: http://www.mono-project.com


Also upcoming C++/CLI standard, is a separate from ISO C++ standard and 
does not interfere with it.

As usual, ISO C++ code also works in a CLI VM.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

>  > Anyone care to pick up the gauntlet?

It has been several days now and the only concrete cases so far
presented are:

1) circular ownership
2) concurrency

Is that it? Is that the best GC advocates can come up with?

If so I for one greatly sympathize with Lapin's opinion that GC at
least as a language extension to C++ (especially as intrusively as
C++/CLI) is by far overkill.

Besides 2) concurrency doesn't seem to hold water so far. Some have
claimed (without demonstrating) that smart pointers have large
overhead in a concurrent environment. Well, so does GC. And I have
seen no evidence presented that smart pointer overhead is, on the
whole, any greater than GC overhead. Furthermore, the C++ language
doesn't even support concurrency (please note I said "support" not
"enable"). So perhaps this rather than lack of GC support is the
source of C++'s concurrency difficulties.

So is that it? Is circular ownership the best you can do?

Keith

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

>  > Anyone care to pick up the gauntlet?

Forgive me, I had forgotten about Ben's post which contained several
interesting points about "programming-against-interface", reference
counting being a sub-optimal GC algorithm (implying smart pointers are
not optimal), and code clutter.

I have not fully digested his points though some seem strong and I'd
like to see some commentary on them from the more knowledgeable folks
around here. So let me add as *possible* GC points of favor:

3) less code clutter (this one seems concrete and true though the
C++/CLI flavor seems to add some syntactic nastiness)

*4) more efficient algorithms than reference (though why does this
require a language change?)

*5) immutable-programming and/or programming-against-interface (I'm
not sure these are different since I really don't understand exactly
what programming-against-interface is and is not)

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 > Is that it? Is that the best GC advocates can come up with?

Further to that the GC advocates indicate that memory management is _such_ a
burden which is why GC is needed. Well, perhaps in the beginning of C++, GC
might have helped cope with all those new's/ new[]'s. With the injection of
the STL with vector,map, set and list and string, what need is there? Even
stringstream with its own internal memory management is better than dynamic
strstream's where you have to ensure the strstream is not frozen to ensure
delete[] kicks in the destructor.

It has been the best part of 10 months since I last used  new/new[]. And
even then, an examination of one my projects reveals I could have used
vector instead.

So I also ask, "Please put forward a concrete case where GC is required".

And please also answer why GC is necessary when it is the case that the
container classes has more or less killed the memory management burdens that
the average C++ programmer had to worry about (and I see this on a daily
basis at the office - a newbie C++ programmer tried to store char * strings
in a map and when I suggested using std::string instead, she reported that
all her problems vanished).

Stephen Howe



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <41083bf9$0$13117$cc9e4d1f@news.dial.pipex.com>, Stephen Howe 
<sjhoweATdialDOTpipexDOTcom@eu.uu.net> writes
>So I also ask, "Please put forward a concrete case where GC is required".

Required is probably too strong. However:

1) When writing multi-threaded code where assigning responsibility for 
resource release may overly complicate code.

2) When writing components that will be used by other languages which 
use GC.

3) When using components written in other languages that use GC.

In each case there may be alternative solutions but there still needs to 
be a solution and there is nothing inherently wrong or mistaken in 
considering GC in the list of available choices.

>

-- 
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Stephen Howe wrote:
>  > Is that it? Is that the best GC advocates can come up with?
> 
> Further to that the GC advocates indicate that memory management is _such_ a
> burden which is why GC is needed. Well, perhaps in the beginning of C++, GC
> might have helped cope with all those new's/ new[]'s. With the injection of
> the STL with vector,map, set and list and string, what need is there? Even
> stringstream with its own internal memory management is better than dynamic
> strstream's where you have to ensure the strstream is not frozen to ensure
> delete[] kicks in the destructor.

There is no question that the standard library and its containers have
made many issues go away.

On the other hand, the way that the standard library acheives this is
by making most of its classes behave like simple values; i.e.: nearly
all the standard classes and templates support copy and assignment.

Internally, these entities use the heap, they new and delete and manage.
When they copy, it's usually a deep copy.

There is a reason why the heap was introduced to algolic programming
languages over 30 years ago.  We often need to create objects that
survive a particular scope.  With the introduction of objects and
classes, we also add the necessity of creating an object that needs
to survive, and whose dynamic type differs from its static type (due
to inheritance).

If your code does not use the heap to create objects, then you must be
operating within a limited class of problems, where the libraries that
support you have encapsulated such needs.

> It has been the best part of 10 months since I last used  new/new[]. And
> even then, an examination of one my projects reveals I could have used
> vector instead.

As stated previously, the problem domain frequently dictates the form
of the solution.

Also, you have not mentioned what sort of libraries support you.  The
standard libraries are not sufficient to eliminate all uses of "new"
in all situations.  They do help quite a bit, but are not a total
solution.

Do you have any classes that inhibit copying? do you have any
containers that need to accomodate a class and its descendants?

> So I also ask, "Please put forward a concrete case where GC is required".

If is impossible to show a concrete case that REQUIRES GC in C++.  It is
only possible to parade a number of cases where GC is used.

Maybe all the problems that "require" GC have been solved in Java or
Python instead of C++.  That would account for the number of such
applications and frameworks.
-- 
Antoun Kanawati
antounk.at@comcast.dot.net
[remove .dot and .at before use]

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Stephen Howe wrote:

> It has been the best part of 10 months since I last used  new/new[]. And
> even then, an examination of one my projects reveals I could have used
> vector instead.

If you don't use new, how do you implement creational patterns like for 
example factories?

-- 
Peter van Merkerk
peter.van.merkerk(at)dse.nl

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
news:Hofek0MaGNCBFw8y@robinton.demon.co.uk...
> In article <41083bf9$0$13117$cc9e4d1f@news.dial.pipex.com>, Stephen Howe
> <sjhoweATdialDOTpipexDOTcom@eu.uu.net> writes
> >So I also ask, "Please put forward a concrete case where GC is required".
>
> Required is probably too strong. However:

I've stayed out of this because I don't have strong opinions (although I
share Dietmar's concerns about intrusive syntactic changes to the language).
But I'd like a little clarification on these points

> 1) When writing multi-threaded code where assigning responsibility for
> resource release may overly complicate code.

I don't understand the relationship with threading. To start with, since the
language doesn't support threads in the first place, how can the language
need to be modified to support this case? Next, I don't understand how
responsibility for resource release is connected to threads. Sure, you can't
use RAII if a resource is acquired in one thread and released in another,
since there is no common scope. But I don't see anything complicated about
assigning an acquired resource to the moral equivalent of a smart pointer
when it is passed to the final "owning" thread. How these resources are
passed from one thread to another is also outside the scope of the language,
isn't it?

> 2) When writing components that will be used by other languages which
> use GC.
>
> 3) When using components written in other languages that use GC.

These are two sides of the same coin, but I think 2 is much less compelling
than 3. If I am writing a component that will be used with another language,
it seems like a bad idea to mix memory models (witness even C-malloc and C++
new). So my component's memory/resource management should be entirely
self-contained, with the exception of the custom "glue" code. As an example,
how would GC help me write a Python package in C++ (assuming Python uses
GC... I don't know).

Since the same requirement should be levied in the other direction, 3 isn't
very compelling either.
--
<disclaimer>
Opinions posted are those of the author.
My company doesn't pay me enough to speak for them.
</disclaimer>
--
Jim Melton
Software Architect, Fusion Programs
Lockheed Martin IS&S
(303) 971-3846




      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 > > It has been the best part of 10 months since I last used  new/new[]. And
 > > even then, an examination of one my projects reveals I could have used
 > > vector instead.
 >
 > If you don't use new, how do you implement creational patterns like for
 > example factories?

To date, I have never needed to do so (but I will shortly).

Stephen Howe




      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Peter van Merkerk <merkerk@deadspam.com> wrote in message news:<2ms46rFpq4b7U1@uni-berlin.de>...
 > Stephen Howe wrote:
 >
 > > It has been the best part of 10 months since I last used  new/new[]. And
 > > even then, an examination of one my projects reveals I could have used
 > > vector instead.
 >
 > If you don't use new, how do you implement creational patterns like for
 > example factories?

How often do we really need factories?

Your question hints at the essence of several posts I have made with
regard to PIMPL, CLI, GC, smart pointers, and polymorphism.  These
things are all related, and I believe many of us abuse them.

In the case of C++ and GC, the pathology is:

A software engineer is presented with a opportunity for design.  He
does not have a clear idea of "where the classes are", but he has a
vague notion of how the system should be structured.  He also knows
that creativity is regarded more favorably than reuse by his peers
(when was the last time someone got a pat on the back for reuse?), and
so he commences to make classes for every concept that comes to mind,
regardless of whether it is appropriate for those concepts to have
distinct classes or not.  In the muddle of his proliferation, he
realizes that his system space lacks clear marks of delineation, and
that it would be premature to commit to the form of his primitives
("What if i goofed up?").  His solution is make all the classes
*abstract* so that "flexibility" is guaranteed in perpetuity.

Thus begins the pathology of a defective design:

Because the clases are abstract, the virtue of rigidity is lost - he
is not  able to contain the objects in the standard containers.
Because he is not  able to contain the objects but still needs the
facility of collection, he looks to 'new', and stores pointers to the
objects in the containers.  [Pointers to objects are not the same as
the objects they point to, and it is a common fallacy to insist
otherwise.]  He might use smart pointers to avoid manually deleting
objects when their pointers are removed from the container, or he
might not.  In any case, he finds himself using the 'new' operator
profusely, so much so that it soon becomes almost pointless to try to
recapture the virtue of rigidity of concrete classes in function
blocks by distinguishing between abstract and concrete on a
per-function-block basis.  After all, to do so would require some
forethought and discipline, the lack of which is precisely what got
him into the mess in the first place.  The result? Even objects that
are concrete are brought into existence using 'new', unnecessary but
"mentally convenient" and then delete'd before exiting the blocks.
Now comes the memory leaks. He hunts in vain through the mess of
'news' and 'deletes', trying to find the disparities.  A colleague
might come along and ridicule him for not having used smart pointers
in the first place, so he might go back and try to change to smart
pointers, but discover that they have their own semantic
irregularities.  He also notices that every time he tries to sythesize
macro class from micro classes via aggregation, it does not work very
well - those blessed virtues of C++; the compiler-generated functions
for copy, assignment, construction, and destruction; are G-O-N-E.  The
PIMPL idiom becomes a necessity.  So now even synthesis, a fundamental
operation of engineering, is cumbersome.  He has to write explicit
destructors for the macro classes to take care of deletion of the
micro objects being pointed to by variables in the macro class, or he
can use smart pointers and use 'new' in the macro destructor, but..the
abstract micro classes must have default constructors or their
arguments to their constructors must be available at the time of
construction of a macro object.....sigh.  The engineer succumbs to
mild disillusionment:  "I wish I had something that would relieve me
from worrying about this mess. C++ memory management really sucks!"

Here is what went wrong:

The *vast* majority of systems being designd in C++ today do not
actually require so many new classes.  Bonafide containment using
list<> & map<> are golden.  Very complex constructs that accurately
model the system space can be realized from these primitives.

The principle underlying this assertion could be described as

"Reachability In The System Space Should Be An Exponential Function of
the Size of the Primitive Set".

In other words, a basis set of primitives should have exponential
generative power for the number of systems that could be generated.
If an engineer finds himself inventing a distinct class set for each
new system, something is wrong.  If the correlation is quasi-linear,
something is still wrong.  You can also see how this works with food.
The next time you are at the supermarket, make a conscious assessment
of how many different foods there "really" are.  There are not many.
Milk generates cheese (brie, Muenster, cheddar, etc.), yogurt, ice
cream, butter, sour cream, and yes, milk.  Those Thai noodles that
some of us love so much actually comes from rice, as does the base of
sushi.

In any case, the remedy that the poor enginer had was something very
simple: a bit more forethought.

All he had to do was make most of his classes concrete, and when
higher-order structures were needed, synthesize them  from rigid and
quasi-rigid primitives like string<>, set<>, map<>, list<>,
polyarchy<>, associative_polyarchy<>.

Following this precept causes many of the "problems" disappear.  There
is no need to think about memory allocation, especially at block
scope. The heap is no longer "used".  There is no need to new, and
therefore no need to delete.  Since new and delete are no longer used,
memory leaks are not a problem.  In those cases where a object
absolutely had to be polymorphic, the new and delete would stand out.
Since the objects are concrete, assignment and copying are handled
automatically by the compiler.  The need for tinkering with the
constructor/destructor in a macro class for memory management on micro
classes becomes unnecessary.  And so on, and so on...

In other words, a little forethought goes a long way.

Early design choices affect later design options. One bad decision
begets another. This fact is one of the fundamentals of engineering,
and nothing will ever change that, certainly not GC.

Fortunately, a nursery rhyme was created to drive that point home to
children:

http://www.poppyfields.net/poppy/songs/oldwoman.html

-Chaud Lapin-

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 > Do you have any classes that inhibit copying?

Yes, quite a few. Most are similar to fstream in some fashion.

 > do you have any containers that need to accomodate a class and its
descendants?

No, most of my objects are homogeneous, assignable and copyable, perfect for
containers

 > If is impossible to show a concrete case that REQUIRES GC in C++.  It is
 > only possible to parade a number of cases where GC is used.

Allright, how about the weaker question:

"Is there a concrete case where GC is a better solution than manual memory
mangement?"

I can think of a case, and that is where you have some type of application
server that creates different size objects on the fly. If this is supposed
to create 1000's of objects whose lifetime is short-lived and destruction
maybe not in LIFO of FIFO patterns,  then new/delete could become a
bottleneck. I can see that a GC solution might be superior (as always,
empirical tests should check this out) if the class objects are
well-behaved.

Stephen Howe



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

duggar@mit.edu (Keith H Duggar) wrote in message news:<b47de02.0407251106.3ba7e7c9@posting.google.com>...
 >
 > > Everything should be non-standard, until a duly authorized standards
 > > forming body approves it as part of a standard.
 >
 > Shouldn't a thing remain non-standard until that thing has
 > explored it's many possibilities, been tested by many,
 > evolved, survived, and otherwise matured to the point
 > where it and we can benefit most from its crystallization?
 >
 > It seems that a "duly authorized ... body" should be the
 > instrument of and not the motivation for a standard.
 >
 > Doesn't premature standardization in fact greatly hinder
 > innovation causing us to lose in the long term while perhaps
 > benefiting in the short term?
 >
 > For example consider the premature wireless standardization
 > in Europe upon TDMA which has now become the poster child
 > of early standardization disasters (and government
 > interference). It was pure hubris for a small body of
 > bureaucrats to think that they could evaluate the "ideal"
 > choice without allowing the market to experiment thoroughly.
 >
 > If C++/CLI is so fantastic why does it need to be
 > standardized to succeed? Shouldn't it simply plow over any
 > competition?

A sharp observation. Creating a standard from scratch, to try to make
something standard, instead of standardising existing practice, does
seem to be putting the cart before the horse.

 > > A few years ago, people were damning the company [Microsoft]
 > > for not participating enough. Go figure.
 >
 > I thought they were being damned for not *complying* enough?

Again, correct. Microsoft hardly cared about standards conformance (or
showing up at standards meetings, or hanging out at the newsgroups),
until a few years ago.

However, it may be argued that this - as well as their more recent
interest in standards conformance - was driven by simple market
economics: Earlier, a lot of C++ programmers didn't really notice much
of the C++ conformance problems in MSVC, since they weren't really
pushing the language much. Those who were affected and did complain,
were a minority, if a vocal one (us! :) ).

However, now that several have gone to other languages (such as VB or
Java), those who still use C++ tend to be more enthusiasts, so again
those same economics now meant that it made sense to focus on
standards conformance, so they did.

The above chain of events was in fact told me by a senior Microsoft
emplyoyee of the MSVC team (about a year ago, just before MSVC 7.1
shipped), so it's not just loose speculation, but actually from the
horse's mouth.

Regards,

Terje

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1090425829.435727@master.nyc.kbcfp.com...
 > Le Chaud Lapin wrote:
 >  > In those rare cylic reference situations mentioned in this thread,
 >  > my gut feeling is that the reclamation problem can be solved entirely
 >  > using the mechanisms of the existing language.
 >
 > I will point once again to GCC, which implements garbage collection
 > for itself, and involves special markups in the source to guide the
 > collector. Here's a page with some description:
 > <http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html>
 > Another message from back in 1999:
 > <http://gcc.gnu.org/ml/gcc/1999-09n/msg00207.html>

Isn't GCC implemented more or less completely in C? It looks that way from
the source files.

If so, I don't think this is a compelling example for adding language
support for GC in _C++_, which does have features C doesn't have when it
comes to resource management.

Regards,

Terje



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Tommy McDaniel wrote:

 > Did you bother to read my post that I provided a link to? Is the only
 > reason you can conceive of for resisting this really that people are
 > just a bunch of undercover Java operatives?



I have seen many like that around. Are you talking about the Win32 API 
related standard?


Except of the fact that I did not see any harm that it caused, I was 
ignoring its existence till some weeks ago that I came across it looking 
for something in the web.


Also a major difference in the case of CLI standard, is that there is 
already a non-MS CLI compliant implementation that exists also for 
Windows (competing with .NET) in addition to GNU/Linux, Mac OS X and Unix.

It is Mono: http://www.mono-project.com


Also upcoming C++/CLI standard, is a separate from ISO C++ standard and 
does not interfere with it.

As usual, ISO C++ code also works in a CLI VM.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

In article <b0491891.0407291823.734faf94@posting.google.com>, Terje
Sletteb? <tslettebo@hotmail.com> writes
>> If C++/CLI is so fantastic why does it need to be
>> standardized to succeed? Shouldn't it simply plow over any
>> competition?
>
>A sharp observation. Creating a standard from scratch, to try to make
>something standard, instead of standardising existing practice, does
>seem to be putting the cart before the horse.

In general yes. However MS have a long track record for releasing new
versions of their proprietary tools which are incompatible with earlier
versions (look at the track record for VB). In that context it makes a
great deal of sense to get an independent referee.

It is notable that where TG39 TCs have standardised something different
from the current MS software releases that MS have undertaken to make
future releases conform. IOWs they do seem to be trying to hand over
responsibility and playing by the rules.

Of course regaining trust takes many years (as unfaithful lovers know
all to well) but while many might harbour suspicions we should still
encourage them on their current path and try to deter them from
backsliding (telling a drug-adict that they are just being devious, does
not help those who are genuinely trying to kick the habit).

If upper management really are being devious and using such people as
Herb Sutter and Stan Lippman as innocent fronts then time will tell and
the backlash on MS is not one I would wish to explain to the
shareholders.

I, for one, will give them the benefit of the doubt and I think if we
all did likewise the result might be that MS discovered that being good
citizens actually paid off on the bottom line as well.

>
>>> A few years ago, people were damning the company [Microsoft]
>>> for not participating enough. Go figure.
>>
>> I thought they were being damned for not *complying* enough?
>
>Again, correct. Microsoft hardly cared about standards conformance (or
>showing up at standards meetings, or hanging out at the newsgroups),
>until a few years ago.
>
>However, it may be argued that this - as well as their more recent
>interest in standards conformance - was driven by simple market
>economics: Earlier, a lot of C++ programmers didn't really notice much
>of the C++ conformance problems in MSVC, since they weren't really
>pushing the language much. Those who were affected and did complain,
>were a minority, if a vocal one (us! :) ).
>
>However, now that several have gone to other languages (such as VB or
>Java), those who still use C++ tend to be more enthusiasts, so again
>those same economics now meant that it made sense to focus on
>standards conformance, so they did.
>
>The above chain of events was in fact told me by a senior Microsoft
>emplyoyee of the MSVC team (about a year ago, just before MSVC 7.1
>shipped), so it's not just loose speculation, but actually from the
>horse's mouth.

Unfortunately that does not make the employee privy to upper
management's game plan. Those in the MSVC team have generally been much
more standards oriented than their managers.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Stephen Howe wrote:
> Allright, how about the weaker question:
> 
> "Is there a concrete case where GC is a better solution than manual memory
> mangement?"
> 
> I can think of a case, and that is where you have some type of application
> server that creates different size objects on the fly. If this is supposed
> to create 1000's of objects whose lifetime is short-lived and destruction
> maybe not in LIFO of FIFO patterns,  then new/delete could become a
> bottleneck. I can see that a GC solution might be superior (as always,
> empirical tests should check this out) if the class objects are
> well-behaved.

As I have pointed out already, Java, which already has GC, is incorporating
additional mechanisms, JSR-166, to deal with that as GC does not handle it
very well.

Joe Seigh

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Jim Melton wrote:
 > To start with, since the language doesn't support threads in the first place,
 > how can the language need to be modified to support this case?

Most implementations of the language do support threads.
We are speaking of those.

> Next, I don't understand how responsibility for resource release is connected
 > to threads.

It is connected to sharing. If an implementation wants to share structure
among many objects (for example, letting multiple strings point to the same
buffer), and also must properly manage the lifetime of that structure, then
in a multithreaded application it will have to acquire locks as the object
is shared and unshared and passed around, in order to maintain the knowledge
necessary to dispose of it. With GC, none of this needs to be done, and
structure may be freely shared, for free.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Le Chaud Lapin" <unoriginal_username@yahoo.com> wrote in message
news:fc2e0ade.0407291630.16931ede@posting.google.com...

[big snip]

> Here is what went wrong:
>
> The *vast* majority of systems being designd in C++ today do not
> actually require so many new classes.  Bonafide containment using
> list<> & map<> are golden.  Very complex constructs that accurately
> model the system space can be realized from these primitives.


How can you speak for the *vast* majority of system designers? From your
pathology example, it sounds like you work in a problem domain much
different from mine, and I don't consider mine to be unusual (perhaps I'm
wrong)? What sort of things do you work on, anyway?

I work on database drivers, engines, conversion utilities, etc., as well as
SDKs/frameworks for all of these (in C++, of course). In our problem space,
we tend to have to model fairly high-level things such as connections,
sessions, rowsets, relational & multidimensional metadata, etc. For most of
these, it makes no sense whatsoever to have value semantics. Once a
connection is created for example, it really makes no sense to be able to
copy it or assign another connection to it. Objects such as this must have a
strong identity.

Since we work on SDKs, such high-level classes must also be abstract. Not
because we want to impress our bosses, but because customers must be able to
fill in the implementation-specific blanks.

> All he had to do was make most of his classes concrete, and when
> higher-order structures were needed, synthesize them  from rigid and
> quasi-rigid primitives like string<>, set<>, map<>, list<>,
> polyarchy<>, associative_polyarchy<>.
>
> Following this precept causes many of the "problems" disappear.  There
> is no need to think about memory allocation, especially at block
> scope. The heap is no longer "used".  There is no need to new, and
> therefore no need to delete.  Since new and delete are no longer used,
> memory leaks are not a problem.  In those cases where a object
> absolutely had to be polymorphic, the new and delete would stand out.
> Since the objects are concrete, assignment and copying are handled
> automatically by the compiler.  The need for tinkering with the
> constructor/destructor in a macro class for memory management on micro
> classes becomes unnecessary.  And so on, and so on...


Once we get down to the low-level details, then we tend to model most things
as value types, and manage them with STL containers, exactly as you say -- 
and it works great. The key point here is that different design techniques
work better at different levels of conceptual granularity. You're right in
that the decision between using reference semantics and value semantics when
designing a class is crucial -- but this doesn't mean that reference
semantics are useless, as you seem to imply.

Now, to bring this back on topic. ;-)  In the past, I've had to opportunity
to try and move some of what we do into the .NET universe using C#. Our
experience with GC was mostly positive, although we made a few of the gaffes
that beginners often make (forgetting to call Dispose at the right time to
free the underlying DB connections... whoops). In terms of performance, it
worked quite well for the problem we were trying to solve. However, the
language itself forces you to use GC anyway, so it's not like we had a
choice. Now that we've had more experience with C++ and boost::shared_ptr,
we haven't felt any real need for GC. Wherever we have complex cyclical data
structures, we use an idiom that I think has been mentioned before in this
thread (the graph owns the nodes, and nodes just refer to each other) and it
works well enough for us.

But, contrary to what you say, the new operator (and polymorphism) is a
basic necessity.

-Bruce Johnston


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

> 3) less code clutter (this one seems concrete and true though the
> C++/CLI flavor seems to add some syntactic nastiness)
> 
I have yet to taste the CLI flavor.

> *4) more efficient algorithms than reference (though why does this
> require a language change?)

As I said, smart pointer at the lib level cannot cover 'this' and
'this' is part of the language.
So, reference counting or not, it's better done under the hood where
we can safely use 'this'. Does it have to be a language change? I'm
not sure.

It depends on what we define as a "language change". Java does not
have a keyword called "gc", and "gc" is really part of the runtime
environment. Is that a "language" stuff?


> 
> *5) immutable-programming and/or programming-against-interface (I'm
> not sure these are different since I really don't understand exactly
> what programming-against-interface is and is not)
> 

They are different.

Immutable programming is derived from functional programming, where no
side-effect can ever happen. All functional languages rely on gc to
achieve this.
Such functinonal style has the advantage of referential-transparency
as well as the possibility of maximal sharing of objects.



'interface', on the other hand, is an OO notion. Where each interface
is an abstract entity that has no implementation and only
specifications.

It can be mimicd by C++ abstract class with all pure virtuals.
Microsoft COM is an actual application of
'programming-against-interface' in a non-gc environment. But it turns
out to be a complex beast for exactly the same reasons that we can
find in C++.

As we all know, pure virtuals should be used sparingly because of
performance overhead, multi-inheritance complexity and object lifetime
complexity.

With gc present, however, at least the lifetime issue is gone. 

So, when we are not very concerned about performance overhead, as the
case in Java, use of 'interface' can become a very effective way of
decoupling modules and sub-modules. In fact it has proved to be the
start of almost every good OO design.



In an imperative OO language, one can benefit from the combination of
immutable and interface a lot.


I once wrote a pseudo-immutable hash table in Java and it was very
useful in writing a type-checker of a language. (It is not an
innovation. Haskell already has similar things for many years)

The signature is like this:

interface Dict{
  Dict put(Object key, Object val);
  Object get(Object key);
  Dict remove(Object key);
}
test code is:

Dict dict = DictFactory.instance().put("1", "a");
//dict = [1, a]
Dict dict2 = dict.put("2", "b"); 
//dict = [1,a], dict2 = [(1,a),(2,b)]
Dict dict3 = dict2.remove("1");
//dict = [1,a], dict2=[(1,a),(2,b)], dict3=[2,b]

The nice thing about this lib is that it is immutable interface yet
the implementation of put/get/remove is O(1).


I have several years of C++ experience and am still writing some c++
code lately, but I'd be very curious about whether someone can write a
similar thing in C++ without support from GC.
Folks with doubt toward GC, this is a good chance to show something.
:->
A pseudo-immutable container lib is a nice tool to have anyway.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

>  > If it was optional then both worlds are satisfied.
>
> If it is optional then portable programs can't rely on it.
> That make sit almost useless.

I meant optional by the programmer.
It would compulsory by the compiler vendor to supply a GC.

But let us talk about that last point:

In my time I have doen support for embedded ROM programmers and for some
processors, memory is very tight. If it was compulsory for C++ compiler
vendors to supply a GC, for some environments, available memory would be
even smaller as I would contend that a GC would take up more memory to
implement than implementing a heap.

So are you really condemning those environments where memory is tight no not
having a C++ compiler?

Stephen Howe






      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 23 Jul 2004 06:07:16 -0400, Ben <ben@transversal.com> wrote:
>
> Of course, if you *really* want to write robust software like that used
> in nuclear reactors and rockets then relying on destructors to clean up
> resources is also the wrong thing to do as most resources have failure
> conditions on release which are just as important as failure to obtain
> the resource in the first place. This means you need to write explicit
> resource deallocation code, and maybe rely on destructors in the fall
> back case.

Hmm, if memory de-allocation could fail, would safety-critical programmers
insist on explicit de-allocation routines (comparable to fclose()) and if
they did, would destructors still be useful?

(Harks back to the "why does GC usually only apply to memory?" question.)

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 28 Jul 2004 18:07:36 -0400, duggar@mit.edu (Keith H Duggar) wrote:
>>  > Anyone care to pick up the gauntlet?

For one thing, a common fundamental error that seems to be common in this
thread as well is that C++ has reference-counted smart pointers and so
doesn't need GC. This misses the fundamental point that using RC smart
pointers *is* a GC strategy.

>It has been several days now and the only concrete cases so far
>presented are:
>
>1) circular ownership
>2) concurrency
>
>Is that it? Is that the best GC advocates can come up with?

No -- although the above is actually more than enough. Cyclic structures
are very common, starting with linked lists. For GC schemes that don't
support them inherently (including reference counting), the workarounds
require explicit help from the programmer in the form of special actions
or restrictions on coding style, to distinguish between owning and
non-owning pointers for example. Such workarounds aren't required by GC
schemes that handle cycles seamlessly.

But besides the two you mention, other issues include:

  - the impact on the programmer (e.g., restrictions on coding style)

  - processing costs

  - space overhead costs

  - immediacy or latency of collection

  - heap occupancy

  - heap fragmentation

  - overhead on pointer mutations

  - locality of reference

  - allocation speed

And other issues.

For example, a compacting GC does very well on most of these, particularly
on locality of reference (the basic compaction strategies naturally keep
data that's allocated around the same time physically close in memory),
zero fragmentation, and best-possible allocation speed (same as stack).
Making it generational also helps other aspects, such as processing costs.

For a very good high-level discussion run (don't walk) to read:

  R. Jones and R. Lins. "Garbage Collection" (Wiley, 1996).

It includes chapters on the merits/drawbacks RC GC (like ISO C++ers are
used to), mark-sweep, mark-compact, copying GC, generational GC, and more.
In particular, it has a chapter each on GC in C and GC in C++.

Recommended reading for a general overview.

Herb

---
Herb Sutter (www.gotw.ca)

Convener, ISO WG21 (C++ standards committee)     (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal         (www.gotw.ca/cuj)
Visual C++ architect, Microsoft            (www.gotw.ca/microsoft)

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 > > To start with, since the language doesn't support
 > > threads in the first place, how can the language
 > > need to be modified to support this case?
 >
 > Most implementations of the language do support
 > threads. We are speaking of those.

Hyman, we are talking about standard C++. We are
not talking about various implementations and their
3rd party libraries or extensions.

Therefore, I believe you are wrong. If you don't think
so, then I challenge you to specify the STANDARD C++
libraries and keywords that you believe provide thread
support.

 > > Next, I don't understand how responsibility for
 > > resource release is connected to threads.
 >
 > It is connected to sharing. If an implementation wants
 > to share structure among many objects (for example,
 > letting multiple strings point to the same buffer), and
 > also must properly manage the lifetime of that structure,
 > then in a multithreaded application it will have to
 > acquire locks as the object is shared and unshared and
 > passed around, in order to maintain the knowledge
 > necessary to dispose of it.

In the example you have framed, locks, sharing, thread
safety, etc. and object lifetime/garbage collection are
completely separate issues. Either the two are confused
in your own mind or you attempting to obfusacted the issue
at hand, GC vs no GC, with the complexity of thread safety.

To make my objection concrete, you do not need to aquire
a lock to increment or decrement a reference count. So,
even in your own example of a shared buffer, the simple
shared_ptr will properly handle the LIFETIME of the buffer.
All this without GC.

As for acquiring locks when modifying the buffer, that
has nothing at all to do with GC or object lifetime.

 > With GC, none of this needs to be done, and
 > structure may be freely shared, for free.

I'm not sure what you me by "this". In any case, that
statement is also false. "This" still needs to be done
either manually or by the garbage collector.

GC is not a "magic" potion that infuses computers with
new powers that they didn't already posseses decades
ago. GC simply moves around responsibility for actions
that are no less necessary.

So can anyone explain in a clear way (perhaps with some
examples or references to examples) the reasoning behind
Mr. Glassborow's remark:

 > 1) When writing multi-threaded code where assigning
 > responsibility for resource release may overly
 > complicate code.

Also, for my part I agree with Jim Melton that these two
points

 > 2) When writing components that will be used by other
 > languages which use GC.
 > 3) When using components written in other languages
 > that use GC.

are not very compelling. Seems like an example of the
bandwagon fallacy.

Keith

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 07/30/2004 10:45 PM, Herb Sutter wrote:
[snip]

 >No -- although the above is actually more than enough. Cyclic structures
 >are very common, starting with linked lists. For GC schemes that don't
 >support them inherently (including reference counting), the workarounds
 >require explicit help from the programmer in the form of special actions
 >or restrictions on coding style, to distinguish between owning and
 >
 >
There have been a number of cycle collecting smart ptr methods prototyped
in boost.  Dimov had one as part of the proposal to the committe, there's
currently one at:

http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/managed_ptr/

and there was another one proposed on this news group not too long ago
called Smieciuch.

 >And other issues.
 >
 >
Yep.  RC whether cyclic or not has definite drawbacks.

 >For example, a compacting GC does very well on most of these, particularly
 >
 >
I'd like to hear from Boehm about the comparison between mark-sweep and
compacting.  I vaguely remember somewhere on his web page about there
not being that big an advantage.  Sorry I can't be more specific.

 >on locality of reference (the basic compaction strategies naturally keep
 >data that's allocated around the same time physically close in memory),
 >zero fragmentation, and best-possible allocation speed (same as stack).
 >Making it generational also helps other aspects, such as processing costs.
 >
 >For a very good high-level discussion run (don't walk) to read:
 >
 >  R. Jones and R. Lins. "Garbage Collection" (Wiley, 1996).
 >
 >

Got it.  The managed_ptr rc gc mentioned above implements the eager
version of
[Lins, 1992a], which is described in [Martinez et al.,1990]
  (see the books bibliography for the preceding references).

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Ben" <fishifish@gmail.com> wrote in message
news:c950b99a.0407301544.1ab81c57@posting.google.com...
 >
 > I once wrote a pseudo-immutable hash table in Java and it was very
 > useful in writing a type-checker of a language. (It is not an
 > innovation. Haskell already has similar things for many years)
 >
 > The signature is like this:
 >
 > interface Dict{
 >   Dict put(Object key, Object val);
 >   Object get(Object key);
 >   Dict remove(Object key);
 > }
 > test code is:
 >
 > Dict dict = DictFactory.instance().put("1", "a");
 > //dict = [1, a]
 > Dict dict2 = dict.put("2", "b");
 > //dict = [1,a], dict2 = [(1,a),(2,b)]
 > Dict dict3 = dict2.remove("1");
 > //dict = [1,a], dict2=[(1,a),(2,b)], dict3=[2,b]
 >
 > The nice thing about this lib is that it is immutable interface yet
 > the implementation of put/get/remove is O(1).

How were they implemented to achieve that? That could be useful to know, in
order to attempt a C++ version.

Regards,

Terje



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

> Hmm, if memory de-allocation could fail, would safety-critical programmers
> insist on explicit de-allocation routines (comparable to fclose()) and if
> they did, would destructors still be useful?

Yes but for non-GC, we don't get notified of failure either. If
free()/delete/delete [] fails we are none the wiser (except later when there
is a program crash because the heap is corrupt).

Stephen Howe



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 >  > The nice thing about this lib is that it is immutable interface yet
 >  > the implementation of put/get/remove is O(1).
 >
 > How were they implemented to achieve that? That could be useful to know,
in
 > order to attempt a C++ version.

Got to be hashing.

Stephen Howe



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Keith H Duggar" <duggar@mit.edu> wrote in message
news:b47de02.0407302022.2d72a42f@posting.google.com...
 > > > To start with, since the language doesn't support
 >  > > threads in the first place, how can the language
 >  > > need to be modified to support this case?
 >  >
 >  > Most implementations of the language do support
 >  > threads. We are speaking of those.
 >
 > Hyman, we are talking about standard C++. We are
 > not talking about various implementations and their
 > 3rd party libraries or extensions.
 >
 > Therefore, I believe you are wrong. If you don't think
 > so, then I challenge you to specify the STANDARD C++
 > libraries and keywords that you believe provide thread
 > support.

What is the point of discussing the benefits and drawbacks of using GC in
the real world if you artificially restrict the discussion? Considering only
what exists in the C++ standard is completely academic. Every implementation
of C++ exists in some real-world context with concerns that are broader than
just the language. Threading is usually one of those concerns, and it bites
those of us developing software in the real world from time to time, so it's
worth discussing. If the issue of thread-safety doesn't affect  you, please
try to empathize with those of us who are affected.

If you want to discuss only what's in the C++ standard, then I'm not sure
you're really interested in discussing GC per se, but rather the assertion
that language support for GC is a good idea. I'm not sufficiently
well-informed about initiatives such as C++/CLI to comment on the language
extension issue, so let's focus on the practical issues of GC and
threading....

 >  > It is connected to sharing. If an implementation wants
 >  > to share structure among many objects (for example,
 >  > letting multiple strings point to the same buffer), and
 >  > also must properly manage the lifetime of that structure,
 >  > then in a multithreaded application it will have to
 >  > acquire locks as the object is shared and unshared and
 >  > passed around, in order to maintain the knowledge
 >  > necessary to dispose of it.
 >
 > In the example you have framed, locks, sharing, thread
 > safety, etc. and object lifetime/garbage collection are
 > completely separate issues. Either the two are confused
 > in your own mind or you attempting to obfusacted the issue
 > at hand, GC vs no GC, with the complexity of thread safety.
 >
 > To make my objection concrete, you do not need to aquire
 > a lock to increment or decrement a reference count. So,
 > even in your own example of a shared buffer, the simple
 > shared_ptr will properly handle the LIFETIME of the buffer.
 > All this without GC.

In a multithreaded application where shared_ptrs are shared among threads,
you most definitely DO need to update the reference count atomically (using
a lock, atomic exchange, or whatever appropriate facilities the OS
provides). Otherwise you end up with a race condition and such nasty things
as memory leaks or double-deletion. If you want examples I can provide some.

 > As for acquiring locks when modifying the buffer, that
 > has nothing at all to do with GC or object lifetime.

I don't believe the original comment said anything about modifying the
buffer, but rather modifying the state information required to track the
lifetime of the buffer. When using ref-counting, this state information
(i.e. -- the reference count) can be updated from any participating thread
at any time (by participating, I mean any thread holding a shared_ptr to the
same object). Hence the need for locking and atomicity. With other types of
GCs such as generational compacting GCs (what the CLR implements), only the
background thread running the GC algorithm ever deals with the state
information, so there is no locking required. In effect, the state
information has thread affinity.

 >  > With GC, none of this needs to be done, and
 >  > structure may be freely shared, for free.
 >
 > I'm not sure what you me by "this". In any case, that
 > statement is also false. "This" still needs to be done
 > either manually or by the garbage collector.

The way I read it, "this" meant locking when reading and updating the
reference count. Without a reference count, no such locking is required.
Given the frequency with which shared_ptrs can be copied, the locking
overhead can be quite substantial. In a single-threaded program you can
disable the locking of course, and you are left with only the overhead of
incrementing, decrementing, and testing the reference count. However, with
GC, copying references has the same performance characteristics as copying
raw pointers. This is because no book-keeping is required until the GC
actually runs.

 > So can anyone explain in a clear way (perhaps with some
 > examples or references to examples) the reasoning behind
 > Mr. Glassborow's remark:
 >
 >  > 1) When writing multi-threaded code where assigning
 >  > responsibility for resource release may overly
 >  > complicate code.

I can't see how this statement applies to reference counting, except perhaps
in the case where the construction and destruction of an object must have
thread affinity. That's a smelly design, but I've seen it happen,
unfortunately. However, even GCs like the CLR's don't solve this problem,
since finalizers typically run on the GC's background thread.

Perhaps the statement refers to a set of practices even more basic than the
use of shared_ptr -- just using new and delete "in the raw". I can see how
manually writing the code that decides which thread gets to delete an object
would be quite laborious and error-prone.

-Bruce Johnston


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote:
> Also a major difference in the case of CLI standard, is that there is 
> already a non-MS CLI compliant implementation that exists also for 
> Windows (competing with .NET) in addition to GNU/Linux, Mac OS X and Unix.
> 
> It is Mono: http://www.mono-project.com

I have some concerns about Mono and the .NET standard that you may be
able to alleviate.

1. Isn't it true that the ECMA, the standards body that maintains the
   .NET-related patents, allows standardization of technologies that
   are patent-protected?  My concern here is that some day, Mono may
   run afoul of a patent, or multiple patents, Microsoft may choose to
   enforce if Mono becomes too much of a threat to Microsoft.

2. Isn't it likely that Mono will always be a step or two behind
   Microsoft when it comes to .NET-related technologies?  This leads
   me to conclude, whether correctly or incorrectly, that Mono will
   actualy serve primarily as a marketing tool for Microsoft, and
   that people will choose Microsoft over competitors simply because
   Microsoft can always boast its technology is the latest and
   greatest.  Not that there is necessarily anything wrong or evil
   about it, but since Microsoft already enjoys several monopoly
   positions in the market, I'm not sure it works out to be a long-
   term benefit to consumers in general.

3. Shouldn't Microsoft's pattern of abuses mean we should be skeptical
   of any technologies coming from Microsoft?  It seems to me that
   taking some time to examine and explore the effects .NET will have
   on the market is worthwhile.  Assuming the parts of .NET that have
   been "standardized" are a gift with no string attached seems rather
   naive given the pattern of abuses exhibited by Microsoft.

4. Isn't it true that many of the .NET libraries are Windows-centric
   and don't fit very well on competing platforms?  It seems to me
   this would always guarantee sub-optimal implementations on non-
   Windows platforms.  I'm specifically concerned about Windows.Forms,
   which I believe has been carefully not placed in the ECMA standard
   by Microsoft.

5. Is the subject of C++/CLI truly topical on comp.lang.c++?  Perhaps
   some new groups should be created for C++/CLI instead of polluting
   comp.lang.c++ with additional subjects.

Bruce Johnston wrote:
> 
> "Keith H Duggar" <duggar@mit.edu> wrote in message
> news:b47de02.0407302022.2d72a42f@posting.google.com...
(snip)
> 
>  >  > It is connected to sharing. If an implementation wants
>  >  > to share structure among many objects (for example,
>  >  > letting multiple strings point to the same buffer), and
>  >  > also must properly manage the lifetime of that structure,
>  >  > then in a multithreaded application it will have to
>  >  > acquire locks as the object is shared and unshared and
>  >  > passed around, in order to maintain the knowledge
>  >  > necessary to dispose of it.
(snip)
>  >  > With GC, none of this needs to be done, and
>  >  > structure may be freely shared, for free.
>  >
>  > I'm not sure what you me by "this". In any case, that
>  > statement is also false. "This" still needs to be done
>  > either manually or by the garbage collector.
> 
> The way I read it, "this" meant locking when reading and updating the
> reference count. Without a reference count, no such locking is required.
> Given the frequency with which shared_ptrs can be copied, the locking
> overhead can be quite substantial. In a single-threaded program you can
> disable the locking of course, and you are left with only the overhead of
> incrementing, decrementing, and testing the reference count. However, with
> GC, copying references has the same performance characteristics as copying
> raw pointers. This is because no book-keeping is required until the GC
> actually runs.

I think the original reference to locking was to the sharing itself, not
the particular mechanism to effect it.  Generally sharing is going to be
either a mutual exclusion or a reader/writer scheme.  These usually
involve locks.  But there are lock-free schemes as well, either entirely
lock-free or just reader lock-free.  The latter involve some pattern like
RCU (Read, Copy, Update) or COW (Copy On Write) by a writer thread and
some form of GC to determine when the usually immutable copies can be
deleted.  But that's a subset of the sharing usage patterns.

All forms of GC have overhead.  It's just in different places depending
on the type of GC and there are different tradeoffs because of this.  There
is work in implementing GC in areas where scalability is an issue, noteably
RCU which tries to reduce cache contention on SMP systems which can be
quite expensive.  Boehm style GC may have less overhead in pointer copying
but it has more overhead in other areas and that overhead may not scale
very well.  So you have to look at the overall environment and expected
usage patterns to determine which GC scheme may be most effective.

Also, since reference counting does have some form of overhead, it's only
used where it's needed, not for all references, just like locks are used
only for shared data, not for all data.  So your inference on the overall
performance impact of reference counting vs. Boehm style GC based on all
pointers being of one type or another isn't valid on that point either.

Joe Seigh


Joe Seigh

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Stephen Howe" <sjhoweATdialDOTpipexDOTcom@eu.uu.net> wrote in message
news:410c4306$0$26974$cc9e4d1f@news.dial.pipex.com...
> >  > The nice thing about this lib is that it is immutable interface yet
>  >  > the implementation of put/get/remove is O(1).
>  >
>  > How were they implemented to achieve that? That could be useful to
know,
> in
>  > order to attempt a C++ version.
>
> Got to be hashing.

Yes, that's the obvious answer if it behaved like a normal (associative)
map. But look at the code, again:

 > Dict dict = DictFactory.instance().put("1", "a");
 > //dict = [1, a]
 > Dict dict2 = dict.put("2", "b");
 > //dict = [1,a], dict2 = [(1,a),(2,b)]
 > Dict dict3 = dict2.remove("1");
 > //dict = [1,a], dict2=[(1,a),(2,b)], dict3=[2,b]

It appears to return a "new" _dictionary_ after each operation. Did you mean
that can be done with hashing, as well, and if so, how?

Regards,

Terje




      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Bruce Johnston" <c_kernel@hotmail.com> wrote in message
news:l7%Oc.148289$od7.79069@pd7tw3no...
> "Keith H Duggar" <duggar@mit.edu> wrote in message
>  >
>  > I'm not sure what you me by "this". In any case, that
>  > statement is also false. "This" still needs to be done
>  > either manually or by the garbage collector.
>
> The way I read it, "this" meant locking when reading and updating the
> reference count. Without a reference count, no such locking is required.
> Given the frequency with which shared_ptrs can be copied, the locking
> overhead can be quite substantial.

Modern processors typically have the ability to perform atomic operations
(such as "lock inc" for x86), and then the overhead doesn't have to be much.

I did a test just now on a Pentium II PC (test code given below, with
optimisations turned off), and timed the difference between "inc" and "lock
inc" on a memory location, and the latter was only 4-5 times slower than the
former. As an inc is normally very fast, the effect of the locking appears
to be just a few cycles.

The "lock" prefix ensures that the instruction is atomic, for both single-
and multi-processor computers. I've only tested it on a single-processor
computer. Perhaps someone else could test it on a multi-processor computer?

>From "IA-32 Intel � Architecture Software Developer�s Manual":

"Beginning with the P6 family processors [Pentium Pro and up], when the LOCK
prefix is prefixed to an instruction and the memory area being accessed is
cached internally in the processor, the LOCK# signal is generally not
asserted. Instead, only the processor�s cache is locked. Here, the processor
�s cache coherency mechanism insures that the operation is carried out
atomically with regards to memory."

Here's the test program, for anyone wanting to test for themselves:

#include <iostream>
#include <boost/timer.hpp>

#define OPCODE lock inc count // "inc count" or "lock inc count"

volatile int count=0; // This should ensure the value isn't cached in a
register

int main()
{
  boost::timer time;

  for(int i=0;i!=10000000;++i)
  {
    asm
    {
      OPCODE; // Unrolled loop, to reduce the effect of the loop bookkeeping
      OPCODE;
      OPCODE;
      OPCODE;
      OPCODE;
      OPCODE;
      OPCODE;
      OPCODE;
      OPCODE;
      OPCODE;
    }
  }

  std::cout << "time=" << time.elapsed() << ", count=" << count << "\n";
}

Regards,

Terje



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

nospam@nowhere.com wrote:

> I have some concerns about Mono and the .NET standard that you may be
> able to alleviate.


Or more specifically, you appear to have concerns about the CLI standard.


> 1. Isn't it true that the ECMA, the standards body that maintains the
>    .NET-related patents, allows standardization of technologies that
>    are patent-protected?  My concern here is that some day, Mono may
>    run afoul of a patent, or multiple patents, Microsoft may choose to
>    enforce if Mono becomes too much of a threat to Microsoft.


No CLI is a standard and is no one's patent. It is also an ISO standard.

C++/CLI will also become an ISO standard.




> 2. Isn't it likely that Mono will always be a step or two behind
>    Microsoft when it comes to .NET-related technologies?  This leads
>    me to conclude, whether correctly or incorrectly, that Mono will
>    actualy serve primarily as a marketing tool for Microsoft, and
>    that people will choose Microsoft over competitors simply because
>    Microsoft can always boast its technology is the latest and
>    greatest.  Not that there is necessarily anything wrong or evil
>    about it, but since Microsoft already enjoys several monopoly
>    positions in the market, I'm not sure it works out to be a long-
>    term benefit to consumers in general.



Both are CLI compliant VMs. Of course both provide system specific 
extensions and APIs. Mono provides APIs that .NET doesn't provide and 
vice versa. CLI also defines a minimal library that all CLI compliant 
VMs must provide.An example is System::Console class and its static methods.

CLI also defines an assembly language that all CLI compliant VMs should 
execute.



> 3. Shouldn't Microsoft's pattern of abuses mean we should be skeptical
>    of any technologies coming from Microsoft?  It seems to me that
>    taking some time to examine and explore the effects .NET will have
>    on the market is worthwhile.  Assuming the parts of .NET that have
>    been "standardized" are a gift with no string attached seems rather
>    naive given the pattern of abuses exhibited by Microsoft.



Well perhaps they have become better, I do not know. In any case a VM 
machine can't be prevented from being CLI compliant, since CLI is a free 
ECMA and ISO standard. The same applies for C#/CLI (which is C# 
essentially since C# has not a standard library of its own or a separate 
standard), and C++/CLI an upcoming standard of extensions to ISO C++.



> 4. Isn't it true that many of the .NET libraries are Windows-centric
>    and don't fit very well on competing platforms?  It seems to me
>    this would always guarantee sub-optimal implementations on non-
>    Windows platforms.  I'm specifically concerned about Windows.Forms,
>    which I believe has been carefully not placed in the ECMA standard
>    by Microsoft.


Yes so code depending on this API cannot be considered portable. However 
it can be source and *binary* portable to any CLI platform that provides 
the same APIs that are used. I guess Mono also provides the same Form 
facilities. In any case it does provide ADO .NET and ASP .NET.

In any case, only use of CLI library (via C++/CLI and IL assembly 
language) can guarantee source code and binary portability, while use of 
CLI and ISO C++ guarantees source code portability only.



> 5. Is the subject of C++/CLI truly topical on comp.lang.c++?  Perhaps
>    some new groups should be created for C++/CLI instead of polluting
>    comp.lang.c++ with additional subjects.


I think it should be topical in clc++ since it is a standard concerning 
C++. There is no meaning of discussing it separately since templates for 
example can be used with C++/CLI.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

"Terje Sletteb�" wrote:
> 
> "Bruce Johnston" <c_kernel@hotmail.com> wrote in message
> news:l7%Oc.148289$od7.79069@pd7tw3no...
> > The way I read it, "this" meant locking when reading and updating the
> > reference count. Without a reference count, no such locking is required.
> > Given the frequency with which shared_ptrs can be copied, the locking
> > overhead can be quite substantial.
> 
> Modern processors typically have the ability to perform atomic operations
> (such as "lock inc" for x86), and then the overhead doesn't have to be much.
> 
> I did a test just now on a Pentium II PC (test code given below, with
> optimisations turned off), and timed the difference between "inc" and "lock
> inc" on a memory location, and the latter was only 4-5 times slower than the
> former. As an inc is normally very fast, the effect of the locking appears
> to be just a few cycles.
> 
> The "lock" prefix ensures that the instruction is atomic, for both single-
> and multi-processor computers. I've only tested it on a single-processor
> computer. Perhaps someone else could test it on a multi-processor computer?
> 

You might take a look here http://www.rdrop.com/users/paulmck/rclock/
(I just noticed that McKenney put his Phd stuff online).  There's some stuff
on interlocked instruction performance in the presentation and probably
his disseration as well (I don't remember).

Joe Seigh

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

nospam@nowhere.com wrote in message news:<410cf8d6$0$65566$a1866201@newsreader.visi.com>...
> Ioannis Vranos <ivr@guesswh.at.grad.com> wrote:
> > Also a major difference in the case of CLI standard, is that there is 
> > already a non-MS CLI compliant implementation that exists also for 
> > Windows (competing with .NET) in addition to GNU/Linux, Mac OS X and Unix.
> > 
> > It is Mono: http://www.mono-project.com
> 
> I have some concerns about Mono and the .NET standard that you may be
> able to alleviate.
> 
> 1. Isn't it true that the ECMA, the standards body that maintains the
>    .NET-related patents, allows standardization of technologies that
>    are patent-protected?

I seem to remember the same thing. In fact, read
http://yro.slashdot.org/article.pl?sid=03/02/11/0048208&tid=109&tid=155&tid=17,
which seems to not only show it, but also show that Microsoft does in
fact have .Net patents (or at least had applied for them as of 2003,
and we know how the patent office doesn't give patents out like candy;
I do not know whether they have been granted yet, but that issue is
moot anyway).

>    My concern here is that some day, Mono may
>    run afoul of a patent, or multiple patents, Microsoft may choose to
>    enforce if Mono becomes too much of a threat to Microsoft.

Indeed. I remember seeing a quote from Microsoft a year or two ago
saying something along the lines of 'this is intellectual property,
and we always take protecting our intellectual property seriously.'
Another story is http://slashdot.org/article.pl?sid=01/07/20/1555256&tid=109,
although unfortunately the original article it links to is gone. How
long do you think Mono is going to last once its marketing value for
showing how 'crossplatform' Microsoft's crap is runs out and the
patent situation in Europe is set to their liking?

> 2. Isn't it likely that Mono will always be a step or two behind
>    Microsoft when it comes to .NET-related technologies?

Not only likely, but the only conceivable way things can work out,
unless Microsoft just never updates their stuff, and guess what the
chances of that are. People here are going to cry 'CLI is a standard,
CLI is a standard, CLI is a standard,' like that means anything once
Microsoft starts extending it and everyone is programming to their
implementations, thereby completely screwing over that whole
crossplatform thing and leaving C++ with a nonportable mess, but I
have lost all hope for making people have some sense. The fact that
they have already done it with the bastion of openness that is C#
(see, for example, http://developers.slashdot.org/developers/03/10/25/188234.shtml?tid=109&tid=126&tid=156&tid=187)
does not seem to matter. C# was a standardized bastion of openness
just recently, and now that everyone has told themselves that enough
to convince themselves, Microsoft is releasing their own new
specifications of the language? What happened to the fricking
standard? The same fate awaits all this CLI bullcrap. That people
cannot see this gives me thoughts involving forced neutering.

>    This leads
>    me to conclude, whether correctly or incorrectly, that Mono will
>    actualy serve primarily as a marketing tool for Microsoft, and
>    that people will choose Microsoft over competitors simply because
>    Microsoft can always boast its technology is the latest and
>    greatest.

It's kind of obvious, ain't it. Good luck trying to get anyone else
here to see that though.

>    Not that there is necessarily anything wrong or evil
>    about it, but since Microsoft already enjoys several monopoly
>    positions in the market, I'm not sure it works out to be a long-
>    term benefit to consumers in general.

The problem here is that people here are more or less flat out scared
of Microsoft. I have seen posts (from C++ committee members no less)
that basically say, and I kid you not, 'we have to do what Microsoft
wants or C++ will die.' Well heck, we might as well all just whip out
our Visual Basic and C# books. Where you went wrong there was when you
mentioned the concept of 'longterm;' I am afraid people here are not
paid to think about that.

> 3. Shouldn't Microsoft's pattern of abuses mean we should be skeptical
>    of any technologies coming from Microsoft?

If you were here I would buy you a drink. Not exactly the finest,
hardest-to-comprehend point, is it. But good luck getting anyone to
see it. Microsoft has pinky sweared that they have seen the light and
are now nice and fluffy like a bunny (and are not already giving the
brand new C# 'standard' the finger), so it must be true. Just the
concept that something from Microsoft should be treated differently
than things from most other companies causes massive shock around
these parts.

>    Assuming the parts of .NET that have
>    been "standardized" are a gift with no string attached seems rather
>    naive given the pattern of abuses exhibited by Microsoft.

You call it naive, I will call it stupid. Most others will call it
their belief.

> 5. Is the subject of C++/CLI truly topical on comp.lang.c++?  Perhaps
>    some new groups should be created for C++/CLI instead of polluting
>    comp.lang.c++ with additional subjects.

I cannot think of a better place to discuss it and, the fact is, it
will greatly affect C++ if the committee does not pull its head out of
a certain orifice. Myself, I started learning OCaml the other day. I
am completely serious about leaving C++ if they start putting
Microsoft crap in it. Between C and OCaml (and whatever else I want to
use), my needs should be pretty much taken care of. Take control of
your own fate, because I do not foresee heads this thick suddenly
seeing the light.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBDYivVB8FYP9YqDcRAk0gAJ9Dx2Ote/wXbbitLhhDA1kXlOreKgCfTMEf
HH6skAieK/IwL92x0KIPIH8=
=shMW
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<ceiv9o$8pf$1@ulysses.noc.ntua.gr>...
> nospam@nowhere.com wrote:
> 
> > I have some concerns about Mono and the .NET standard that you may be
> > able to alleviate.
> 
> Or more specifically, you appear to have concerns about the CLI standard.

Yes, but he mentioned Mono specifically, after you mentioned it first.

> > 1. Isn't it true that the ECMA, the standards body that maintains the
> >    .NET-related patents, allows standardization of technologies that
> >    are patent-protected?  My concern here is that some day, Mono may
> >    run afoul of a patent, or multiple patents, Microsoft may choose to
> >    enforce if Mono becomes too much of a threat to Microsoft.
> 
> No CLI is a standard and is no one's patent.

You might want to read
http://yro.slashdot.org/article.pl?sid=03/02/11/0048208&tid=109&tid=155&tid=17
before pursuing that line farther.

> It is also an ISO standard.

So is C#, regarding which you might want to read
http://developers.slashdot.org/developers/03/10/25/188234.shtml?tid=109&tid=126&tid=156&tid=187;
barely out of the standard oven and already getting the finger from
Microsoft. You might also want to read
http://slashdot.org/article.pl?sid=01/07/20/1555256&tid=109, regarding
'universally implementable' standards.

> > 2. Isn't it likely that Mono will always be a step or two behind
> >    Microsoft when it comes to .NET-related technologies?  This leads
> >    me to conclude, whether correctly or incorrectly, that Mono will
> >    actualy serve primarily as a marketing tool for Microsoft, and
> >    that people will choose Microsoft over competitors simply because
> >    Microsoft can always boast its technology is the latest and
> >    greatest.  Not that there is necessarily anything wrong or evil
> >    about it, but since Microsoft already enjoys several monopoly
> >    positions in the market, I'm not sure it works out to be a long-
> >    term benefit to consumers in general.
>
> CLI also defines an assembly language that all CLI compliant VMs should 
> execute.

Platform-independent assembly? How exactly is that better than, say,
any other programming language, considering that the job of compilers
and interpreters is to convert stuff a programmer writes into stuff a
particular computer can understand, and this platform-independent
assembly you speak of will by definition also have to compiled and/or
interpreted into something the local computer can understand?

> > 3. Shouldn't Microsoft's pattern of abuses mean we should be skeptical
> >    of any technologies coming from Microsoft?  It seems to me that
> >    taking some time to examine and explore the effects .NET will have
> >    on the market is worthwhile.  Assuming the parts of .NET that have
> >    been "standardized" are a gift with no string attached seems rather
> >    naive given the pattern of abuses exhibited by Microsoft.
> 
> Well perhaps they have become better, I do not know.

If that is not a solid foundation on which to rest the fate of your
programming language, I do not know what is.

> > 5. Is the subject of C++/CLI truly topical on comp.lang.c++?  Perhaps
> >    some new groups should be created for C++/CLI instead of polluting
> >    comp.lang.c++ with additional subjects.
> 
> I think it should be topical in clc++ since it is a standard concerning 
> C++. There is no meaning of discussing it separately since templates for 
> example can be used with C++/CLI.

I think your example sucks, but I agree.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBDZdsVB8FYP9YqDcRAkurAJ9n2rou0vrO0n9008oA3OciwtMp8QCeL+nB
rY711+CeNjxdJHqoOg5z/Yo=
=VKs+
-----END PGP SIGNATURE-----

Tommy McDaniel wrote:

>>No CLI is a standard and is no one's patent.
> 
> 
> You might want to read
> http://yro.slashdot.org/article.pl?sid=03/02/11/0048208&tid=109&tid=155&tid=17
> before pursuing that line farther.



Well the above URL says that .NET is patented. That is a different thing 
than CLI. NET is an ISO CLI compliant implementation, as Visual C++ 
compiler is (~98% currently) an ISO C++ compliant implementation. They 
can patent their compiler but not ISO C++.


> So is C#, regarding which you might want to read
> http://developers.slashdot.org/developers/03/10/25/188234.shtml?tid=109&tid=126&tid=156&tid=187;
> barely out of the standard oven and already getting the finger from
> Microsoft. 


Actually there will be an updated C#/CLI standard. But to tell you the 
truth I do not care for C# so much. :-)




> You might also want to read
> http://slashdot.org/article.pl?sid=01/07/20/1555256&tid=109, regarding
> 'universally implementable' standards.



Again who cares for C#? :-)




>>CLI also defines an assembly language that all CLI compliant VMs should 
>>execute.
> 
> 
> Platform-independent assembly? How exactly is that better than, say,
> any other programming language, considering that the job of compilers
> and interpreters is to convert stuff a programmer writes into stuff a
> particular computer can understand, and this platform-independent
> assembly you speak of will by definition also have to compiled and/or
> interpreted into something the local computer can understand?


Well a Virtual Machine is what its name specifies. A Virtual Machine 
with virtual registers, CPU etc. So it has a "virtual" assembly.

A book for this:

http://www.amazon.com/exec/obidos/tg/detail/-/0735615470/qid=1091414100/sr=1-7/ref=sr_1_7/102-2992266-3703320?v=glance&s=books


The ILASM this book describes is the current standardised CLI IL 
assembly language which you can also view if you download the CLI 
standard from ECMA (or buy it from ISO). The CLI standard defines the 
architecture and the assembly language.

A good thing about CLI is that it is more optimised than Java VM for 
example, since the programmer can define whether the produced "binary" 
is converted to *native* executable completely during program 
installation time, or function by function at execution time or remains 
as it is (bytecode) all the time.

Also you can have hybrid produces binary files which is the case when 
you use ISO C++ and C++/CLI for example.


Also templates can be used in C++/CLI and the produced file is binary 
portable provided that no native type is used in the program. For example:


template <class T>
void test(T ^whatever)
{
  // ...
}


ref class someclass
{
  // ...
};


someclass ^h=gcnew someclass;

test(h);

This is both source and binary portable.


Also there is interoperability with ISO C++ code, for example a function 
taking an int * can work with an int ^.


An object in the GC heap may be moved by the garbage collector at any 
time so if you want to pass an int ^ to a function getting an int * you 
can do:


void test(int *);

// ...


int ^h=gcnew int;

// ...


// Pins the object in the GC heap so as it cannot move around
// and p behaves like a pointer.
pin_ptr<int>p=h;


test(p);



This kind of low level stuff is able only in C++/CLI.

The above of course produces an hybrid executable since test() is a 
native function.


Together with the deterministic destruction with GC objects in the stack 
which should be the default for all C++ programs in CLI, the code is 
robust and efficient. I have seen in an MS site somewhere on-line that 
C++/CLI code alone is 25% or 35% (I do not recall the exact number) 
faster than C# code.




In any case you can use existing stuff with C++/CLI without a problem. 
Also if a template is written (provides specialisations for) CLI types 
then the binary is also portable. MS is going to provide specialisations 
of their C++ standard library for CLI types.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Tommy McDaniel wrote:


> Not only likely, but the only conceivable way things can work out,
> unless Microsoft just never updates their stuff, and guess what the
> chances of that are. People here are going to cry 'CLI is a standard,
> CLI is a standard, CLI is a standard,' like that means anything once
> Microsoft starts extending it and everyone is programming to their
> implementations, thereby completely screwing over that whole
> crossplatform thing and leaving C++ with a nonportable mess, but I
> have lost all hope for making people have some sense. The fact that
> they have already done it with the bastion of openness that is C#
> (see, for example, http://developers.slashdot.org/developers/03/10/25/188234.shtml?tid=109&tid=126&tid=156&tid=187)
> does not seem to matter. C# was a standardized bastion of openness
> just recently, and now that everyone has told themselves that enough
> to convince themselves, Microsoft is releasing their own new
> specifications of the language? What happened to the fricking
> standard? The same fate awaits all this CLI bullcrap. That people
> cannot see this gives me thoughts involving forced neutering.



C# 2 will also be a standard. However if .NET ceases to be CLI compliant 
for example, or whatever, we will still have ISO C++ (which is a 
separate standard) which we also use with platform specific stuff 
anyway, for example by making Windows applications with MFC, or 
X-Windows ones with QT.


> The problem here is that people here are more or less flat out scared
> of Microsoft. I have seen posts (from C++ committee members no less)
> that basically say, and I kid you not, 'we have to do what Microsoft
> wants or C++ will die.'


I haven't seen such a statement of the C++ committee which you must also 
keep in mind that consists of all major companies and the committee 
chairman at least in the past (for C++98 creation) was one from SUN! 
(yes the one that makes Java). MS has been there too.

So companies with opposite/hostile interests sit together to define a 
commonly accepted standard and the committee strives for consensus.



> Well heck, we might as well all just whip out
> our Visual Basic and C# books. Where you went wrong there was when you
> mentioned the concept of 'longterm;' I am afraid people here are not
> paid to think about that.
> 
> 
>>3. Shouldn't Microsoft's pattern of abuses mean we should be skeptical
>>   of any technologies coming from Microsoft?
> 
> 
> If you were here I would buy you a drink. Not exactly the finest,
> hardest-to-comprehend point, is it. But good luck getting anyone to
> see it. Microsoft has pinky sweared that they have seen the light and
> are now nice and fluffy like a bunny (and are not already giving the
> brand new C# 'standard' the finger), so it must be true. Just the
> concept that something from Microsoft should be treated differently
> than things from most other companies causes massive shock around
> these parts.


I think the truth is, that they have seen they cannot afford to ignore 
C++ programmers. In any case, C++ programmers do need C++/CLI to make 
Windows applications since .NET will be the MS future, and the API of 
Longhorn will not be Win32 but completely managed called Win FX (with 
its sub-APIs "Avalon" for GUI, etc).


Win FX will be the .NET of the time. Even Windows Explorer in Longhorn 
is managed (I suppose "hybrid"/mixed mode) so C++ must be able to use 
the .NET CLI VM.


If you want you may consider C++/CLI an MS thing, no problem, we still 
will have ISO C++ as a standard.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Le Chaud Lapin wrote:
 > I am reading a thread running concurrently about CLI, and I have very
 > much trouble figuring out why anyone would want to perturb a language
 > like C++ with things like gcnew, etc.

Not C++.  C++/CLI.

 > Is garbage collection necessary?  Is it a problem we should even
 > solving by extending the entire language?
 >
 > I have about 70,000 lines of C++ code in one of my projects and there
 > is not *one* place where I feel the need to garbage collect.  One of
 > the virtues of C++ is that it provides a highly regular facility for
 > (optimal) management of the the lifetime of objects.  I use this
 > facility with great pleasure and ease of mind.  It puzzle's me that
 > this facility is not good enough for others.
 >
 > Can anyone provide an example why the normal mechanisms in C++ are not
 > sufficient for object life-time management?

It is not necessarily a question of need.  While I am pretty sure people
will come up with data structures (nice, circular graphs etcc.) where one
will anyway implement something close to a garbage collector, I am pretty
sure that this is mostly about something else.  Something philosophical or
rather human.  And that is convenience.  Why should I write smart pointers
and make my life more difficult if I do not need that fine grain control
over memory allocation?  That is for the question why GC.

Why gcnew and the like?  As far as I understood it is for C++.  What?  Yep,
it is for C++.  In order for C++ to survive on .NET (and in Microsoft) it
has to bend closer to the .NET runtime.  At least it does not need to bend
all the way down as C# had to do...

IMHO the cold facts of life form these decisions.  People working with .NET
cannot use C++, because right now it is not only ugly (managed C++), but
outright inconvenient and schizophrenic, with C++ mostly being C++ and then
a separate world of the ".NET stuff", __showing __up __as __unreadable
__extensions.

Herb Sutter and the others (many others, forgive me for not listing
everyone) work(ed) very hard to make C++/CLI a desirable language for the
..NET developers.  And - they did not keep it a secret - that was the goal.
What they have tried to do is to mix C++ with the CLI on a way, that keeps
the good things of both worlds, while providing all the CLI features for the
C++ users.  You can get deterministic destruction in C++/CLI for your scarce
resources, but you also have GC if you want to.

Right now Herb and the other hard working members of that committee are
working their (beep) off to make C++ a (or rather the) language of choice on
the .NET platform, the platform, which also exists on Linux (mono).  Now
assuming this quest is successfull and C++ becomes (what it should be), the
most used language on .NET - or at least a very heavily used one - then, and
only then, C++ can affect the development of the CLI and it features.  Right
now, it has to "blend in" to the .NET family of languages, and that has its
price.  Today the price is few new keywords.  Unpleasant - as every
compromise is - but I am not at all so sure that it is as deadly wrong as
some people feel it to be.  But I am open to listen to any proof - I am
easily convinced with facts.  From gut feelings I onyl accept my own. ;-)

As for the gcnew etc., they do not affect (in theory) standard C++, except
that it would be pretty rude to start using it for something else.  So
nobody is forcing you to have or use GC.  The choice is yours.

-- 
WW aka Attila
:::
The early worm gets eaten by the bird, so sleep late.



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Bruce Johnston <c_kernel@hotmail.com> wrote in message news:<l7%Oc.148289$od7.79069@pd7tw3no>...
> 
> The way I read it, "this" meant locking when reading and updating the
> reference count. Without a reference count, no such locking is required.
> Given the frequency with which shared_ptrs can be copied, the locking
> overhead can be quite substantial. In a single-threaded program you can
> disable the locking of course, and you are left with only the overhead of
> incrementing, decrementing, and testing the reference count. However, with
> GC, copying references has the same performance characteristics as copying
> raw pointers. This is because no book-keeping is required until the GC
> actually runs.

This is correct. However the shared_ptr solution (assuming a fully
optimized shared_ptr vs a fully optimized collector) is still pretty
competitive for real-world C++ code, because there are ways to avoid
extra copies, the simplest being const&, and because C++ doesn't force
nearly everything to be a collected pointer, as Java and (to a lesser
extent) C# do. Typically, shared_ptr operations occupy a small
fraction of the total execution time.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote:
> I think the truth is, that they have seen they cannot afford to ignore 
> C++ programmers. In any case, C++ programmers do need C++/CLI to make 
> Windows applications since .NET will be the MS future, and the API of 
> Longhorn will not be Win32 but completely managed called Win FX (with 
> its sub-APIs "Avalon" for GUI, etc).

This comment seems rather alarmist.  Doesn't Windows XP still run most
DOS, Windows 3.x, Windows 9x, and Windows ME, and Windows NT programs
without modifications?  It seems to me C++ programmers can rely on
their C++ programs that use MFC, Qt, wxWidgets, etc. to keep working
for a long time, especially given that Longhorn itself isn't even due
out for a few years.  Even when Longhorn is out, it'll take the better
part of a decade to move everyone over to .NET, unless of course
Microsoft forces .NET via Windows Update, or something.

I'm very skeptical of claims that Microsoft will abandon the Win32 API
in favor of .NET solutions.  There is a huge amount of C++ code
written and it'll take companies years and years to rewrite it all in
..NET (or WinFX or Avalon or whatever - I have trouble keeping up with
all of Microsoft's APIs and plans).  In many cases, it simply won't be
worth the effort.

The evangelical nature of this topic sets off alarm bells in my head.
If Microsoft truly plans to force all their partners to rewrite their
apps with the latest Silver Bullet, it'll make a lot of people angry.
Most companies, especially in this new new economy, simply can't
afford to rewrite their massive C++ applications for Windows using the
latest Silver Bullet technologies.

pdimov@gmail.com (Peter Dimov) wrote in message news:<abefd130.0408020132.745d8149@posting.google.com>...
> Bruce Johnston <c_kernel@hotmail.com> wrote in message news:<l7%Oc.148289$od7.79069@pd7tw3no>...
> > 
> > The way I read it, "this" meant locking when reading and updating the
> > reference count. Without a reference count, no such locking is required.
> > Given the frequency with which shared_ptrs can be copied, the locking
> > overhead can be quite substantial. In a single-threaded program you can
> > disable the locking of course, and you are left with only the overhead of
> > incrementing, decrementing, and testing the reference count. However, with
> > GC, copying references has the same performance characteristics as copying
> > raw pointers. This is because no book-keeping is required until the GC
> > actually runs.
> 
> This is correct. However the shared_ptr solution (assuming a fully
> optimized shared_ptr vs a fully optimized collector) is still pretty
> competitive for real-world C++ code, because there are ways to avoid
> extra copies, the simplest being const&, and because C++ doesn't force
> nearly everything to be a collected pointer, as Java and (to a lesser
> extent) C# do. Typically, shared_ptr operations occupy a small
> fraction of the total execution time.
> 
I agree that this is very application dependent.

I would expect that for real multithreaded applications with small
average object size (say order of 50 bytes) a tracing collector will
win easily, at least in terms of execution time, over a
shared_ptr-like implementation.  The overhead associated with
reference count operations (varying between about 10 cycles on an
Itanium 2 to 150 to 200 cycles on a hyperthreaded P4, per atomic
operation, last I checked) is only part of the story.  The other
problem is that   memory allocators used with this kind of reference
counting usually either need synchronization on both allocation and
deallocation, or have serious restrictions on memory reuse by other
threads.  Modern tracing collectors can more easily avoid per-object
synchronization on allocation (and usually do), and automatically
avoid it on deallocation.  Even without reference counting overhead,
the tracing collector is likely to win FOR SMALL OBJECTS.

For much larger objects with little pointer assignment (say large bit
maps), the story is likely to be different.  Various forms of manual
optimization no doubt help reference counting as well.  (I haven't
been following the detailed strategies here, but in general these are
not free in that they can be error-prone and complicate the
programming model.  E.g. how you pass a pointer depends on what you
want to do with it.  Adding a cache which retains a pointer may force
global interface changes, if I understand things correctly.)

It's also worth remembering that if you really want reference
counting, there are other ways to implement it which perform better in
a multithreaded environment.  The standard technique is to add
reference count updates to a per-thread queue instead of performing
the increments and decrements immediately.  The queue can then be
processed by another thread.  This potentially adds a small delay
before destructor invocations on heap objects.  But in general you
need that to avoid deadlocks anyway.

Hans

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Larry Evans <cppljevans@cox-internet.com> wrote in message news:<10gma2jn5s54pbb@corp.supernews.com>...

> I'd like to hear from Boehm about the comparison between mark-sweep and
> compacting.  I vaguely remember somewhere on his web page about there
> not being that big an advantage.  Sorry I can't be more specific.
> 
There has been some interesting recent work on this, which generally
argues for compaction and sequential allocation.  See in particular
http://www.cs.utexas.edu/users/mckinley/papers/mmtk-sigmetrics-2004.ps.gz

Though this is clearly interesting, I personally don't think we have
the final answer yet.  I don't think the measurement results are
completely understood, and it would be nice to compare them to results
from other systems.  I also haven't yet seen a comparison that really
takes advantage of the fact that M/S collectors can avoid touching
pointer-free memory during GC, which I know from experience can be a
large advantage.

Hans

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

nospam@nowhere.com wrote:

> Ioannis Vranos <ivr@guesswh.at.grad.com> wrote:
> 
>>I think the truth is, that they have seen they cannot afford to ignore 
>>C++ programmers. In any case, C++ programmers do need C++/CLI to make 
>>Windows applications since .NET will be the MS future, and the API of 
>>Longhorn will not be Win32 but completely managed called Win FX (with 
>>its sub-APIs "Avalon" for GUI, etc).
> 
> 
> This comment seems rather alarmist.  Doesn't Windows XP still run most
> DOS, Windows 3.x, Windows 9x, and Windows ME, and Windows NT programs
> without modifications?  It seems to me C++ programmers can rely on
> their C++ programs that use MFC, Qt, wxWidgets, etc. to keep working
> for a long time, especially given that Longhorn itself isn't even due
> out for a few years.  Even when Longhorn is out, it'll take the better
> part of a decade to move everyone over to .NET, unless of course
> Microsoft forces .NET via Windows Update, or something.
> 
> I'm very skeptical of claims that Microsoft will abandon the Win32 API
> in favor of .NET solutions.  There is a huge amount of C++ code
> written and it'll take companies years and years to rewrite it all in
> .NET (or WinFX or Avalon or whatever - I have trouble keeping up with
> all of Microsoft's APIs and plans).  In many cases, it simply won't be
> worth the effort.
> 
> The evangelical nature of this topic sets off alarm bells in my head.
> If Microsoft truly plans to force all their partners to rewrite their
> apps with the latest Silver Bullet, it'll make a lot of people angry.
> Most companies, especially in this new new economy, simply can't
> afford to rewrite their massive C++ applications for Windows using the
> latest Silver Bullet technologies.



As far as I can imagine Win32 etc will remain supported by the OS but it 
will not support the latest features of Longhorn but only for backward 
compatibility. But probably the existing applications will need to be 
recompiled using /clr (for VC++ compiler) which makes an application to 
be compiled for .NET (and if it contains native code such as using 
Win32, the executable is hybrid).



In any case as far as I know even Windows Explorer is compiled with /clr 
in Longhorn since in a review I had read for an alpha built in the past, 
Windows Explorer was throwing .NET exceptions (and messages) whenever it 
crashed. :-)


Some quick info on Longhorn: 
http://www.winsupersite.com/showcase/longhorn_4074_talk.asp






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

 > > Got to be hashing.
 >
 > Yes, that's the obvious answer if it behaved like a normal (associative)
 > map. But look at the code, again:
 >
 >  > Dict dict = DictFactory.instance().put("1", "a");
 >  > //dict = [1, a]
 >  > Dict dict2 = dict.put("2", "b");
 >  > //dict = [1,a], dict2 = [(1,a),(2,b)]
 >  > Dict dict3 = dict2.remove("1");
 >  > //dict = [1,a], dict2=[(1,a),(2,b)], dict3=[2,b]
 >
 > It appears to return a "new" _dictionary_ after each operation. Did you mean
 > that can be done with hashing, as well, and if so, how?
 >
 > Regards,
 >
 > Terje
 >
 >
Yes. It is hashing. Actually this lib does not do the hashing by
itself. The underlying java.util.HashMap does all the hashing
algorithm.

The technique used here is called "delta-update". Basically, everytime
a new change is done to the pseudo-immutable collection, it makes the
change in the underlying collection, and records the undo-operations.

for the above code, the following graph may make it simpler:

step1:
   dict1: handle1 -> (1,a)
step2:
   dict2: handle2 -> (1,a)(2,b)
   dict1: handle1 -> {remove 2} -> handle2 -> ...
step3:
   dict3: handle3 -> (2,b)
   dict2: handle2 -> {put 1 a} -> handle3 -> ...
   dict1: handle1 -> {remove 2} -> handle2 -> ....

In case we need to go back to an older version, say, dict1, the lib
applies the undo operations sequentially and make dict1 directly
refering to the underlying container.


It is most efficient when the code keeps using the latest version and
occasionally goes back to an older version. (which is true for a type
checker).

And if some older version is not needed any more, just discard the
reference.


When the user code does not keep references to the older versions, I
expect the compiler to totally optimize away the creation of undo
objects. (at least theoretically it is possible).
With manual gc (such as shared_ptr), however, I don't see this
possible because the shared_ptr does side-effects at the user-code
level and getting rid of that is somewhat a hack. (one may disagree if
he/she feels ok with RVO though.)

This is another reason that I like gc: it makes certain semantics
transparent to programmers and hence gives a lot more space of
optimization to compilers.


Another example:

A tail call algorithm:

MyObj f(int i){
   ...
   return g(i-1);
}

With gc, this is true tail-call and compiler can easily make it a
'jmp'.

However, with shared_ptr version:

shared_ptr<MyObj> f(int i){
   return g(i-1);
}

dtor of shared_ptr has to be called after return, so it is not
tail-call any more.

This can kill lots of functional style programming too because many
functional paradiagm rely on direct or indirect recursions.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 08/02/2004 05:53 PM, Hans-J. Boehm wrote:
 > pdimov@gmail.com (Peter Dimov) wrote in message news:<abefd130.0408020132.745d8149@posting.google.com>...
[snip]
 > operation, last I checked) is only part of the story.  The other
 > problem is that   memory allocators used with this kind of reference
 > counting usually either need synchronization on both allocation and
 > deallocation, or have serious restrictions on memory reuse by other
 > threads.  Modern tracing collectors can more easily avoid per-object
 > synchronization on allocation (and usually do), and automatically
 > avoid it on deallocation.  Even without reference counting overhead,

Could you explain more why there's any difference between allocation and
deallocation for refcounted objects vs. tracing collectors.  The reason
I'm wondering is that if the overhead is allocated at the same time as
the object, then the only difference I can see is the size of the
overhead.  For mark-sweep, I guess the overhead is 1-bit (+ whatever is
needed for alignment). For refcount, the overhead is sizeof(long) or
whatever. IOW, for intrusive reference counting, couldn't the same
allocator for both be used except for the size of overhead?  It seems
this could also be used to implement christopher's refcounting method
for collecting cycles if the mark-sweep gc machinery could be adapted to
   provide an iterator over all allocated objects, which I guess it must
since it must sweep all the unmarked objects back into the "dustpan".



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Hans-J. Boehm" wrote:
 >

 > I agree that this is very application dependent.
 >
 > I would expect that for real multithreaded applications with small
 > average object size (say order of 50 bytes) a tracing collector will
 > win easily, at least in terms of execution time, over a
 > shared_ptr-like implementation.  The overhead associated with
 > reference count operations (varying between about 10 cycles on an
 > Itanium 2 to 150 to 200 cycles on a hyperthreaded P4, per atomic
 > operation, last I checked) is only part of the story.  The other
 > problem is that   memory allocators used with this kind of reference
 > counting usually either need synchronization on both allocation and
 > deallocation, or have serious restrictions on memory reuse by other
 > threads.  Modern tracing collectors can more easily avoid per-object
 > synchronization on allocation (and usually do), and automatically
 > avoid it on deallocation.  Even without reference counting overhead,
 > the tracing collector is likely to win FOR SMALL OBJECTS.

Synchronization?  You need memory barriers unless you are doing the
usual C++ "threadsafe as int" in which case the memory synchronization
is provided as part of the global synchronization context.  If you
are talking about atomically thread-safe reference counting, you
can do it without locks, just an extra interlocked instruction or two.
.....
 >
 > It's also worth remembering that if you really want reference
 > counting, there are other ways to implement it which perform better in
 > a multithreaded environment.  The standard technique is to add
 > reference count updates to a per-thread queue instead of performing
 > the increments and decrements immediately.  The queue can then be
 > processed by another thread.  This potentially adds a small delay
 > before destructor invocations on heap objects.  But in general you
 > need that to avoid deadlocks anyway.
 >

Interesting.  Have any papers been written on this?  It kind of looks
like a cross between SMR pointers and reference counting.

Joe Seigh

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote:
> As far as I can imagine Win32 etc will remain supported by the OS but it 
> will not support the latest features of Longhorn but only for backward 
> compatibility. But probably the existing applications will need to be 
> recompiled using /clr (for VC++ compiler) which makes an application to 
> be compiled for .NET (and if it contains native code such as using 
> Win32, the executable is hybrid).

It sounds like an excellent vendor lock-in strategy on the part of
Microsoft.  They have a monopoly on the OS, and if you want to use the
latest features of the OS, you've got to commit to .NET (and, most
likely, Microsoft's development tools).

Non-Microsoft operating systems will be even LESS likely to get ports
of Windows software unless those operating systems ship with .NET
compatible runtimes and libraries.  Windows wins, .NET wins, Microsoft
wins, and consumer and developer choice loses.  That's just great.

With all due respect, .NET sounds like a trojan horse to me.

nospam@nowhere.com wrote:

> It sounds like an excellent vendor lock-in strategy on the part of
> Microsoft.  They have a monopoly on the OS, and if you want to use the
> latest features of the OS, you've got to commit to .NET (and, most
> likely, Microsoft's development tools).
> 
> Non-Microsoft operating systems will be even LESS likely to get ports
> of Windows software unless those operating systems ship with .NET
> compatible runtimes and libraries.  Windows wins, .NET wins, Microsoft
> wins, and consumer and developer choice loses.  That's just great.
> 
> With all due respect, .NET sounds like a trojan horse to me.



However ISO C++ still runs in all CLI machines .NET included, and still 
C++/CLI (and even current managed extensions) feel more natural than COM 
for example (have you seen code using COM?) and less messy than Win32.

If you want to see C++/CLI as a system extension it is OK, we already 
use system extensions in our programs and myself use ISO C++ as much as 
possible. For example when I want to do string operations in .NET I 
convert from String * to std::string and vice versa.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Joe Seigh wrote:
[...]
 > Synchronization?  You need memory barriers unless you are doing the
 > usual C++ "threadsafe as int" in which case the memory synchronization
 > is provided as part of the global synchronization context.

Not quite. "threadsafe as int" refcounting scheme still needs
barriers for decrements/unref() (unless the managed object is
immutable) but doesn't need barriers for increments/addref().

http://www.google.com/groups?selm=3F1F26CC.4125AE8B%40web.de
(Subject: Re: How to multithread intrusive reference counting)

regards,
alexander.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Larry Evans wrote:
 > if the overhead is allocated at the same time

Overhead is not (just) in space, but in time -
reference counts must synchronize to coordinate
access between threads, in order to track shared
structures. GC does not, except at collection time.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1089920102.540148@master.nyc.kbcfp.com>...
[...]
> Well, that's the rub, isn't it. One person's unnecessary is another
> one's vital. As far as I can see, Microsoft is approaching this in
> the time-honored way that Strostrup himself used - add features to
> the language as users request them, gain experience, and formalize.

As far as *I* can see Microsoft may well be adding features as users
request them, but it is certainly formalizing them way before they
gained experience. For how long has a C++/CLI implementation been
publicly available before the ECMA standardization process started
out?

Cheers,
Nicola Musatti

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Joe Seigh wrote:
 > you can do it without locks, just an extra interlocked instruction or two.

I believe that on this newsgroup, "lock" is shorthand for
"system-defined concurrent synchronization primitive".

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 08/04/2004 07:18 AM, Hyman Rosen wrote:
> Larry Evans wrote:
>> if the overhead is allocated at the same time
>
> Overhead is not (just) in space, but in time -
> reference counts must synchronize to coordinate
> access between threads, in order to track shared
> structures. GC does not, except at collection time.
Sure, but my question was "why can't the same

    allocation/deallocation

method used in the BW collector be used in a
refcounted collector?"  The only difference would be
in the amount of overhead tacked onto the beginning
of the allocated object. Since all synchronization on
the refcount is done after allocation and before
deallocation, I can see no reason why not.  Please
let me know if I'm missing something :)

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote:
> However ISO C++ still runs in all CLI machines .NET included, and still 
> C++/CLI (and even current managed extensions) feel more natural than COM 
> for example (have you seen code using COM?) and less messy than Win32.
> 
> If you want to see C++/CLI as a system extension it is OK, we already 
> use system extensions in our programs and myself use ISO C++ as much as 
> possible. For example when I want to do string operations in .NET I 
> convert from String * to std::string and vice versa.

The software company I work for targets half a dozen operating systems
with its products.  In my experience abstracting away OS specific
calls into libraries isn't too horrible.  I believe having to use a
modified language would be.

Time will tell, I guess.  At the moment, .NET sounds like a trojan
horse to me.  Especially since MS keeps things like Windows.Forms to
itself.

nospam@nowhere.com wrote:

> Ioannis Vranos <ivr@guesswh.at.grad.com> wrote:
> 
>>However ISO C++ still runs in all CLI machines .NET included, and still 
>>C++/CLI (and even current managed extensions) feel more natural than COM 
>>for example (have you seen code using COM?) and less messy than Win32.
>>
>>If you want to see C++/CLI as a system extension it is OK, we already 
>>use system extensions in our programs and myself use ISO C++ as much as 
>>possible. For example when I want to do string operations in .NET I 
>>convert from String * to std::string and vice versa.
> 
> 
> The software company I work for targets half a dozen operating systems
> with its products.  In my experience abstracting away OS specific
> calls into libraries isn't too horrible.  I believe having to use a
> modified language would be.
> 
> Time will tell, I guess.  At the moment, .NET sounds like a trojan
> horse to me.  Especially since MS keeps things like Windows.Forms to
> itself.



It isn't a modified language. For example CLI types maps directly to the 
types of the supported languages (where there are ones available)instead 
of intruding them.


For example System::Int32 maps to int and long, System::Boolean to 
bool,System::Byte to unsigned char, System::Char to wchar_t (unicode) etc.

That is it is equivalent to write Int32 x; and int x;


Consider this with the intrusion of exotic alien types like BOOL, 
HPWSTRwhatever such as those used in Win32 API or HINSTANCE nonsense of COM.


In my site I have a freeware password generator program which uses a 
..NET cryptographic random number generator object, and especially its 
member function GetBytes() which fills a System::Byte array on the heap 
with values of 0 to 255. In other words it fills an array if unsigned chars.

System::Byte and unsigned char is *exactly* the same thing. And even in 
the Help file in the C++ signature of the method unsigned char is 
mentioned and not System::Byte.


Or for example assuming a TextBox object in the heap (or in the stack in 
C++/CLI) named textb:


std::string s=whatever;



textb->text=s.c_str();



Even if you consider C++/CLI as a system extension, it is one of the 
best system extensions available, but it is not just a system extension 
since it can be used in other platforms too.


C++/CLI (or even current "managed extensions") is far better than COM, 
Win32 API or anything else I have seen. In fact it has many similarities 
with VCL but it's simpler to use!


I would find a hard way to learn COM or Win32 API, they sound almost 
impossible to me in fact.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Ioannis Vranos wrote:

> Or for example assuming a TextBox object in the heap (or in the stack in 
> C++/CLI) named textb:
> 
> 
> std::string s=whatever;
> 
> 
> 
> textb->text=s.c_str();



Actually the above introduces a possible future crash. The correct (and 
better in the stack as allowed in C++/CLI) is:


std::string s = whatever;


textb.text = gcnew String(s.c_str());


or


if you insist in the heap:


textb->text = gcnew String(s.c_str());



// and textb->text = __gc new String(s.c_str());
// with the current "managed extensions"






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Ioannis Vranos wrote:
> Ioannis Vranos wrote:
> 
>> Or for example assuming a TextBox object in the heap (or in the stack 
>> in C++/CLI) named textb:
>>
>>
>> std::string s=whatever;
>>
>>
>>
>> textb->text=s.c_str();
> 
> 
> 
> 
> Actually the above introduces a possible future crash.



Actually the above would not compile due to different pointer types. Not 
to mention that it would not compile because it should have been


textb->Text


in the first place. What's wrong with me today?






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Nicola Musatti wrote:
> Hyman Rosen <hyrosen@mail.com> wrote in message news:<1089920102.540148@master.nyc.kbcfp.com>...
> [...]
> 
>>Well, that's the rub, isn't it. One person's unnecessary is another
>>one's vital. As far as I can see, Microsoft is approaching this in
>>the time-honored way that Strostrup himself used - add features to
>>the language as users request them, gain experience, and formalize.
> 
> 
> As far as *I* can see Microsoft may well be adding features as users
> request them, but it is certainly formalizing them way before they
> gained experience. For how long has a C++/CLI implementation been
> publicly available before the ECMA standardization process started
> out?


There has been VC++ 2002 and VC++ 2003 with managed extensions. And 
there is also the ECMA and ISO CLI standard and the C#/CLI standard.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Larry Evans <cppljevans@cox-internet.com> wrote in message news:<10h1lpqlkdasq83@corp.supernews.com>...

 > Sure, but my question was "why can't the same
 >
 >     allocation/deallocation
 >
 > method used in the BW collector be used in a
 > refcounted collector?"  The only difference would be
 > in the amount of overhead tacked onto the beginning
 > of the allocated object. Since all synchronization on
 > the refcount is done after allocation and before
 > deallocation, I can see no reason why not.  Please
 > let me know if I'm missing something :)
 >
Allocation and deallocation are separate issues here.

Deallocation:

New/delete or malloc/free deallocates objects one at a time.
Deallocation involves access to a shared data structure (e.g. free
list) and hence requires either locking or a lock-free algorithm based
on something like compare-and-swap.  Hence every deallocation normally
executes a lock acquisition and release (or possible some
compare-and-swap operations instead).

A tracing collector deallocates objects in large quantities, and
typically needs only a single lock acquisition/release for each such
mass deallocation.  (And the mass deallocation is often much cheaper
than one-at-a-time deallocation anyway.)

Hence for a normal tracing GC, the locking overhead is a negligible
cost of deallocation.  For free(), it often dominates.

A reference counting memory manager typically deallocates more than a
single object a time (cf.
http://portal.acm.org/citation.cfm?doid=964001.964019).  But it is
much harder to take advanatge of that, especially if you intersperse
destructor invocations.  Certainly Boost shared_ptr doesn't.

Allocation:

The distinction here is a bit less clear cut.  But it is relatively
easy for a tracing GC to arrange that each thread allocates memory in
large chunks (with synchronization, e.g. by acquiring a lock), and
then keeps track of that large chunk in some thread-local place, so
that individual allocations don't need a lock.  I believe all major
Java implementations do that.  Our collector can (and does in the
standard gcj and probably Mono configurations).  I think so does
Microsoft's .NET implementation.  Thus the vast majority of
allocations don't involve a lock acquisition.

It's not obvious to me that this couldn't be done for malloc/free.
But I know of no implementations that do.  And it seems to be greatly
complicated by the fact that deallocations occur individually and not
in batches.  (I know Emery Berger considered it for the Hoard
malloc/free implementation.  So I'm confident it's not a trivial
problem, perhaps in part because expectations for malloc/free are
different.)

Aside on locking in malloc/free:

There are arguments for and against using a lock-free malloc/free
implementation.  But at least on modern Pentium 4s, the main cost in
either acquiring and releasing a lock or in the lock-free solutions
are the atomic cmpxchg or xchg instructions, which add on the order of
200 cycles each.  Thus it really doesn't matter for present purposes.
(By my measurements a spin lock with exponential back-off probably
gets the best throughput for a simple LIFO free list.  See
http://portal.acm.org/citation.cfm?doid=1011767.1011774 or
http://www.hpl.hp.com/techreports/2004/HPL-2004-105.html .  But much
cleverer malloc implementations are possible.  See for example M.
Michael's 2004 PLDI paper:
http://portal.acm.org/citation.cfm?doid=996841.996848 .)

Hans

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Joe Seigh <jseigh_01@xemaps.com> wrote in message news:<410EDCE5.B2BB58E6@xemaps.com>...
 > "Hans-J. Boehm" wrote:
 >  >
 >  >
 >  > It's also worth remembering that if you really want reference
 >  > counting, there are other ways to implement it which perform better in
 >  > a multithreaded environment.  The standard technique is to add
 >  > reference count updates to a per-thread queue instead of performing
 >  > the increments and decrements immediately.  The queue can then be
 >  > processed by another thread.  This potentially adds a small delay
 >  > before destructor invocations on heap objects.  But in general you
 >  > need that to avoid deadlocks anyway.
 >  >
 >
 > Interesting.  Have any papers been written on this?  It kind of looks
 > like a cross between SMR pointers and reference counting.
 >
Two recent references are

http://portal.acm.org/citation.cfm?doid=378795.378819, or
http://www.research.ibm.com/people/d/dfb/papers/Bacon01Java.pdf

and

http://portal.acm.org/citation.cfm?doid=504282.504309, or
http://www.cs.technion.ac.il/%7Eerez/Papers/refcount-oopsla.ps

There is also more recent work by the same set of people, but it
focusses mostly on cycle detection.

Hans

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<ceqosi$30pl$1@ulysses.noc.ntua.gr>...
> Nicola Musatti wrote:
[...]
> > As far as *I* can see Microsoft may well be adding features as users
> > request them, but it is certainly formalizing them way before they
> > gained experience. For how long has a C++/CLI implementation been
> > publicly available before the ECMA standardization process started
> > out?
> 
> There has been VC++ 2002 and VC++ 2003 with managed extensions. And 
> there is also the ECMA and ISO CLI standard and the C#/CLI standard.

I'm aware that C++/CLI does not exist in isolation, and that it is a
second attempt by Microsoft (and others, this time) to produce a
biding between C++ and the CLI. However this doesn't change the fact
that C++/CLI is being standardized almost while being developed, so
very little experience on its use may have been gained.

Cheers,
Nicola Musatti

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<HQ4Lc.24957$F8.20552@nwrdny02.gnilink.net>...
[...]
> In any case, we have a compnay which is very kindly doing the specification
> and implementation of this new feature set, so we will have experience to
> guide us in whether the results are useful, beautiful, and virtuous. This is
> the same way in which most of C++ was designed, except for the bad parts.

Very true. However, by the time that experience is gained, C++/CLI
will already be an ECMA and very possibly ISO standard. This is what I
object to. If the developers of such a beast called it C## or gave up
on making it an ISO standard by fast tracking it, I'd have no problem
at all.

Cheers,
Nicola Musatti

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Nicola Musatti wrote:

 > Very true. However, by the time that experience is gained, C++/CLI
 > will already be an ECMA and very possibly ISO standard. This is what I
 > object to. If the developers of such a beast called it C## or gave up
 > on making it an ISO standard by fast tracking it, I'd have no problem
 > at all.


Still what kind of "system extensions" would you expect for CLI VMs?






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Nicola Musatti wrote:
 > Very true. However, by the time that experience is gained, C++/CLI
 > will already be an ECMA and very possibly ISO standard. This is what I
 > object to.

This is hardly the first time that something has become a standard
without intensive real-world experience first. Even in C++, export,
two-phase lookup, C functions in std, and probably a bunch of other
stuff were invented by the committee without being tried out first.

For the sake of interoperability, a potentially flawed standard is
better than a moving target.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Niklas Matthies <usenet-nospam@nmhq.net> wrote in message news:<slrncg8iru.l37.usenet-nospam@nmhq.net>...
[...]
 > The standard ensures that competitors of Microsoft can implement it.
 > A past criticism towards Microsoft has always been that they obscure
 > their technologies and make hidden adjustments all the time so that
 > it's impossible for competitors to implement a compatible alternative.

For this a standard is not required, as a public specification, plus
reasonable confidence on its stability, is sufficient.

In the late eighties / early nineties NFS was the de facto standard
shared filesystem among UNIX vendors, long before it became an Open
Group (formerly X/Open) standard. Although Sun retained intellectual
property on it, they published the specification and licensed their
own implementation.

Cheers,
Nicola Musatti

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hans_Boehm@hp.com (Hans-J. Boehm) wrote:
 > Allocation:
 >
 > The distinction here is a bit less clear cut.  But it is relatively
 > easy for a tracing GC to arrange that each thread allocates memory in
 > large chunks (with synchronization, e.g. by acquiring a lock), and
 > then keeps track of that large chunk in some thread-local place, so
 > that individual allocations don't need a lock.  I believe all major
 > Java implementations do that.  Our collector can (and does in the
 > standard gcj and probably Mono configurations).  I think so does
 > Microsoft's .NET implementation.  Thus the vast majority of
 > allocations don't involve a lock acquisition.
 >
 > It's not obvious to me that this couldn't be done for malloc/free.
 > But I know of no implementations that do.

Such an arrangement cannot handle one thread freeing a memory
allocation that was malloc'ed by a different thread, typical
of a producer-consumer pattern. This circumstance is not
especially common, but it prevents the use of unsynchronised
thread-local blocks for a general-purpose malloc/free.

Thread-segregated storage has indeed been implemented for
memory allocators, but I believe that in all cases it is done to
promote locality and avoid cache-line sharing on multiprocessor
machines, and the atomic instructions cannot be omitted.

 > Aside on locking in malloc/free:
 >
 > There are arguments for and against using a lock-free malloc/free
 > implementation.  But at least on modern Pentium 4s, the main cost in
 > either acquiring and releasing a lock or in the lock-free solutions
 > are the atomic cmpxchg or xchg instructions, which add on the order of
 > 200 cycles each.  Thus it really doesn't matter for present purposes.

Yes, but the true cost of acquiring a lock is not the time
spent performing the bus-locked instruction; rather it is
the context switches incurred when other threads run up against
the lock. Should a thread happen to be scheduled out when holding
the lock, every other thread in the program is likely to hit the
lock and be forced to sleep, and this is likely to happen to each
thread before it has consumed a significant fraction of its intended
time-slice.

The context-switching factor is what gives a lock-free heap manager
its compelling performance advantage.

Regards,
Chris

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<ylDKc.15415$F8.9066@nwrdny02.gnilink.net>...
> Peter Dimov wrote:
>  > the simplistic "reference == ownership" model suffices.
> 
> What GC does is entirely remove the need for the concept of
> ownership when it comes to memory.

Not exactly. You still have to explicitly reset the first reference
into each connected graph of dynamically allocated structures. I
believe this is a common source of memory waste in GC based programs.

Cheers,
Nicola Musatti

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<cethme$1e7v$2@ulysses.noc.ntua.gr>...
> Nicola Musatti wrote:
> 
>  > Very true. However, by the time that experience is gained, C++/CLI
>  > will already be an ECMA and very possibly ISO standard. This is what I
>  > object to. If the developers of such a beast called it C## or gave up
>  > on making it an ISO standard by fast tracking it, I'd have no problem
>  > at all.
> 
> Still what kind of "system extensions" would you expect for CLI VMs?

Sorry, I don't understand your question.

Cheers,
Nicola Musatti

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1091717392.806856@master.nyc.kbcfp.com>...
> Nicola Musatti wrote:
>  > Very true. However, by the time that experience is gained, C++/CLI
>  > will already be an ECMA and very possibly ISO standard. This is what I
>  > object to.
> 
> This is hardly the first time that something has become a standard
> without intensive real-world experience first. Even in C++, export,
> two-phase lookup, C functions in std, and probably a bunch of other
> stuff were invented by the committee without being tried out first.

Thank you for these examples supporting my point of view.

> For the sake of interoperability, a potentially flawed standard is
> better than a moving target.

A target is moving only if its creator/mantainer moves it; the NFS
example I made in another post applies also here. Moreover, note that
a standard that is issued too soon and is allowed to change too often
*is* a moving target.

Cheers,
Nicola Musatti

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1091717392.806856@master.nyc.kbcfp.com...
> Nicola Musatti wrote:
>  > Very true. However, by the time that experience is gained, C++/CLI
>  > will already be an ECMA and very possibly ISO standard. This is what I
>  > object to.
>
> This is hardly the first time that something has become a standard
> without intensive real-world experience first. Even in C++, export,
> two-phase lookup
> ...

Yes, and they are not very good poster children for this, are they? ;)

Some of the stuff standardised without much if any implementation- or use-
experience worked quite well, though.

Regards,

Terje



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Chris Noonan" <usenet@leapheap.co.uk> wrote in message
news:ee224908.0408051302.4fb9d457@posting.google.com...
> Hans_Boehm@hp.com (Hans-J. Boehm) wrote:
>  >
>  > There are arguments for and against using a lock-free malloc/free
>  > implementation.  But at least on modern Pentium 4s, the main cost in
>  > either acquiring and releasing a lock or in the lock-free solutions
>  > are the atomic cmpxchg or xchg instructions, which add on the order of
>  > 200 cycles each.  Thus it really doesn't matter for present purposes.
>
> Yes, but the true cost of acquiring a lock is not the time
> spent performing the bus-locked instruction; rather it is
> the context switches incurred when other threads run up against
> the lock. Should a thread happen to be scheduled out when holding
> the lock, every other thread in the program is likely to hit the
> lock and be forced to sleep

The way I understand it, is that at least on x86 (Pentium Pro and later),
the atomic instructions ("lock <instruction>") only lock the local cache, so
it doesn't assert the LOCK# signal on the processor bus, and therefore
doesn't any stop other processors in the system. For the processor
performing the atomic operation, the "lock" prefix should ensure that no
context switch happens during the operation (after all, that's the point of
the prefix).

Regards,

Terje



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Terje Sletteb=F8" wrote:
>
> "Chris Noonan" <usenet@leapheap.co.uk> wrote in message
> news:ee224908.0408051302.4fb9d457@posting.google.com...
>> Hans_Boehm@hp.com (Hans-J. Boehm) wrote:
>> >
>> > There are arguments for and against using a lock-free malloc/free
>> > implementation.  But at least on modern Pentium 4s, the main cost in
>> > either acquiring and releasing a lock or in the lock-free solutions
>> > are the atomic cmpxchg or xchg instructions, which add on the order of
>> > 200 cycles each.  Thus it really doesn't matter for present purposes.
>>
>> Yes, but the true cost of acquiring a lock is not the time
>> spent performing the bus-locked instruction; rather it is
>> the context switches incurred when other threads run up against
>> the lock. Should a thread happen to be scheduled out when holding
>> the lock, every other thread in the program is likely to hit the
>> lock and be forced to sleep
>
> The way I understand it, is that at least on x86 (Pentium Pro and later),
> the atomic instructions ("lock <instruction>") only lock the local cache,=
 so
> it doesn't assert the LOCK# signal on the processor bus, and therefore
> doesn't any stop other processors in the system. For the processor
> performing the atomic operation, the "lock" prefix should ensure that no
> context switch happens during the operation (after all, that's the point =
of
> the prefix).
>

The previous poster is refering the the overhead of suspend and resume of t=
hreads
waiting for a lock.  This tends to dramatically degrade the queue service t=
ime
of a locked resource.  The reason lock-free algorithms tend to do so well i=
n
comparison isn't because they have less "locking" overhead, it's that they
don't incur the suspend/resume overhead since lock-free by definition does =
not
block.

There are lock implementations that allow queue jumping and don't suffer dr=
amatic
performance degradation as long as contention is intermittent and brief, ot=
herwise
they tend to tank as well.

Joe Seigh

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Nicola Musatti wrote:
> Not exactly. You still have to explicitly reset the first reference
> into each connected graph of dynamically allocated structures. I
> believe this is a common source of memory waste in GC based programs.

As someone else has already stated here, losing one particular
reference to an object is a local issue - some piece of code
decides it no longer needs the object. Deleteing an object is
quite something else, because the deleter needs to know that no
one needs the object.

Note that ideal garbage collection collects memory which will
never be used again. It's theoretically possible that analysis
of a program could lead to collecting objects which are still
reachable.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Nicola Musatti wrote:

>>Still what kind of "system extensions" would you expect for CLI VMs?
>
>
> Sorry, I don't understand your question.


I mean in order to make an X Windows application for example, you will
use some system extensions like the QT API.


What kind of system extensions would you expect for a CLI VM? And since
CLI is a standard about virtual machines, there should be a standardised
approach to use them from C++. Would it be better if each CLI VM
provided its own set of system extensions to C++, than having a
standardised one?


For example currently in .NET we use "managed extensions", things like:


__gc class whatever
{
   // ...
};


whatever *p= __gc new whatever;


Myself prefer to have a standardised set of system extensions so as my
code to compile in Mono (when it gets a C++ compiler) for example, than
having to convert my above CLI code to use another system-dependent syntax.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

David Abrahams <dave@boost-consulting.com> wrote in message news:<u4qo2sdsq.fsf@boost-consulting.com>...
 > Gerhard Menzl <gerhard.menzl@spambucket.net> writes:
 >
 > > Hyman Rosen wrote:
 > >
 > > And with GC, you've got to be even more careful to manage lifetime
 > > issues. You can't just entrust class destructors with resource clean-up
 > > for fear they might be called at an inappropriate time. Interfaces
 > > become cluttered with Dispose calls, with everyone developing their own
 > > idea what exactly is destroyed when, if at all.
 >
 > And yet, there is a large category of applications where this sort of
 > thing almost never occurs.  There was no big outcry about GC before
 > Java came along, at least not that I remember.  The presence of GC in
 > Lisp and Python (and...) systems is not normally seen as a problem.

That's because python has deterministic and predictable gc.  Things
get collected when they go out of scope.  As apposed to Java's "it
will be collected sometime, but you we can't promise you exactly when.
  No, really, trust us."

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Joe Seigh" <jseigh_01@xemaps.com> wrote in message
news:4113A9CA.91214D63@xemaps.com...
 >
 > "Terje Sletteb=F8" wrote:
 > >
 > > "Chris Noonan" <usenet@leapheap.co.uk> wrote in message
 > > news:ee224908.0408051302.4fb9d457@posting.google.com...
 > >> Hans_Boehm@hp.com (Hans-J. Boehm) wrote:
 > >> >
 > >> > There are arguments for and against using a lock-free malloc/free
 > >> > implementation.  But at least on modern Pentium 4s, the main cost in
 > >> > either acquiring and releasing a lock or in the lock-free solutions
 > >> > are the atomic cmpxchg or xchg instructions, which add on the order
of
 > >> > 200 cycles each.  Thus it really doesn't matter for present purposes.
 > >>
 > >> Yes, but the true cost of acquiring a lock is not the time
 > >> spent performing the bus-locked instruction; rather it is
 > >> the context switches incurred when other threads run up against
 > >> the lock. Should a thread happen to be scheduled out when holding
 > >> the lock, every other thread in the program is likely to hit the
 > >> lock and be forced to sleep
 > >
 > > The way I understand it, is that at least on x86 (Pentium Pro and
later),
 > > the atomic instructions ("lock <instruction>") only lock the local
cache,=
 >  so
 > > it doesn't assert the LOCK# signal on the processor bus, and therefore
 > > doesn't any stop other processors in the system. For the processor
 > > performing the atomic operation, the "lock" prefix should ensure that no
 > > context switch happens during the operation (after all, that's the point
=
 > of
 > > the prefix).
 >
 > The previous poster is refering the the overhead of suspend and resume of
t=
 > hreads
 > waiting for a lock.  This tends to dramatically degrade the queue service
t=
 > ime
 > of a locked resource.  The reason lock-free algorithms tend to do so well
i=
 > n
 > comparison isn't because they have less "locking" overhead, it's that they
 > don't incur the suspend/resume overhead since lock-free by definition does
=
 > not
 > block.

But is an algorithm using instructions with "lock" prefix a "lock-free
algorithm"? It does lock, but without allowing a context switch before the
lock is released, which could otherwise have resulted in another thread
waiting for the lock, so you don't get the suspend/resume problem you
mention.

Regards,

Terje



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Jeff" <surferjeff@gmail.com> wrote in message
news:781dd16f.0408061455.15630ddb@posting.google.com...
> That's because python has deterministic and predictable gc.  Things
> get collected when they go out of scope.

>From what I gather from

http://python.org/doc/faq/general.html#how-does-python-manage-memory

this is only true if there are no cycles. If there are cycles, collection is
non-deterministic. Moreover, some Python implementations are fully GCed,
i.e. deterministic destruction must always be induced manually, as show in
the file example. Therefore, to make your programs fully portable among all
Python implementations you must program as if there is no refcounting (and
no automatic deterministic destruction).

To me, the decision of some Python implementations to use a mixture of
refcounting and GC looks like a mistake. I doesn't make programming any
easier and needlessly throws away potential performance gains of a pure GC
environment.
Python seems to be pretty much alone with this decision, C++/CLI, C#, Java
are all purely GCed languages.

Regards,

Andreas


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 08/07/2004 04:24 AM, Jeff wrote:
[snip]
> That's because python has deterministic and predictable gc.  Things
> get collected when they go out of scope.  As apposed to Java's "it

How does python do that?  The best way I know is with:

       Martinez; Wachenchauzer; Lins
       "Cyclic Reference Counting with Local Mark-Scan"
       in  _Information Processing Letters_, 34:31-35, 1990

Is that how it's done?

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Jeff wrote:

> That's because python has deterministic and predictable gc.  Things
> get collected when they go out of scope.  As apposed to Java's "it
> will be collected sometime, but you we can't promise you exactly when.
>   No, really, trust us."


However also in C++/CLI, deterministic destruction with managed objects 
in the stack can and should be used as the default.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Terje Sletteb�" wrote:
> 
> 
> But is an algorithm using instructions with "lock" prefix a "lock-free
> algorithm"? It does lock, but without allowing a context switch before the
> lock is released, which could otherwise have resulted in another thread
> waiting for the lock, so you don't get the suspend/resume problem you
> mention.

"lock-free" means the ability for a thread to make forward progress is
not affected by other threads.  The thread does not have to wait for
some other thread to do something like release a lock.  You can wait
by simply spinning but typically is user space you suspend and get
resumed later on.  This adds a huge amount of latency to the service
time if you are using a queueing model.  Enough in some cases to permanently
drive your program into a degraded level of performance.  Lock-free
algorithms offer a way to avoid this problem since they don't need
to use suspend/resume as a wait mechanism

Interlocked instructions typically use some form of locking at the hardware
level to achieve atomicity.  Even simple instructions like loads and stores
may use some form of locking.  But the hardware provides guarantees of forward
progress so basically hardware implementation is not an issue.

With the conditional interlocked instructions such as compare and swap, people
bring up the issue that you use a loop when coding them and a loop means blocking
and therefore not lock-free.  That's not really true.  It depends on what you are
looping on.  If you are using compare and swap to implement a lock and you are
looping waiting for the lock to be freed, that's not lock-free.  If you are looping
trying to push something onto a stack using compare and swap, that is lock-free
since you aren't waiting for the queue head to be set to any particular value.

Joe Seigh

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<cekbc7$2052$1@ulysses.noc.ntua.gr>...
> Tommy McDaniel wrote:
> 
> 
> > Not only likely, but the only conceivable way things can work out,
> > unless Microsoft just never updates their stuff, and guess what the
> > chances of that are. People here are going to cry 'CLI is a standard,
> > CLI is a standard, CLI is a standard,' like that means anything once
> > Microsoft starts extending it and everyone is programming to their
> > implementations, thereby completely screwing over that whole
> > crossplatform thing and leaving C++ with a nonportable mess, but I
> > have lost all hope for making people have some sense. The fact that
> > they have already done it with the bastion of openness that is C#
> > (see, for example, http://developers.slashdot.org/developers/03/10/25/188234.shtml?tid=109&tid=126&tid=156&tid=187)
> > does not seem to matter. C# was a standardized bastion of openness
> > just recently, and now that everyone has told themselves that enough
> > to convince themselves, Microsoft is releasing their own new
> > specifications of the language? What happened to the fricking
> > standard? The same fate awaits all this CLI bullcrap. That people
> > cannot see this gives me thoughts involving forced neutering.
> 
> However if .NET ceases to be CLI compliant 
> for example, or whatever, we will still have ISO C++ (which is a 
> separate standard)

You completely missed my point. My point was about Microsoft's
attitude towards their own fricking .Net 'standards.' People seem to
want to rush to embrace them these days, including, unfortunately,
feeble-minded members of the ISO C++ committee, while, as if
Microsoft's previous behavior were not enough, they are basically
sitting there as we speak showing us exactly how highly they esteem
even their own little 'standards' and just how much those 'standards'
are good for. As I said somewhere, what happens when numbnuttery
carries the day for the C++ committee and CLI is adopted into C++?

> > The problem here is that people here are more or less flat out scared
> > of Microsoft. I have seen posts (from C++ committee members no less)
> > that basically say, and I kid you not, 'we have to do what Microsoft
> > wants or C++ will die.'
> 
> the committee 
> chairman at least in the past (for C++98 creation) was one from SUN! 
> (yes the one that makes Java). MS has been there too.

An example of what I mentioned elsewhere about people unable to grasp
the concept of treating Microsoft like Microsoft and others like
others. Sun != Microsoft. And I do not even like Sun or Java either,
by the way.

> > Well heck, we might as well all just whip out
> > our Visual Basic and C# books. Where you went wrong there was when you
> > mentioned the concept of 'longterm;' I am afraid people here are not
> > paid to think about that.
> > 
> > 
> >>3. Shouldn't Microsoft's pattern of abuses mean we should be skeptical
> >>   of any technologies coming from Microsoft?
> > 
> > 
> > If you were here I would buy you a drink. Not exactly the finest,
> > hardest-to-comprehend point, is it. But good luck getting anyone to
> > see it. Microsoft has pinky sweared that they have seen the light and
> > are now nice and fluffy like a bunny (and are not already giving the
> > brand new C# 'standard' the finger), so it must be true. Just the
> > concept that something from Microsoft should be treated differently
> > than things from most other companies causes massive shock around
> > these parts.
> 
> I think the truth is, that they have seen they cannot afford to ignore 
> C++ programmers.

So instead they will embrace them. Followed by extending and
extinguishing them. It is not some kind of new concept; it even has
its own name (if 'embrace, extend, extinguish' can be considered a
name).

> In any case, C++ programmers do need C++/CLI to make 
> Windows applications since .NET will be the MS future

I cannot claim to give even a little bit of a crap what new hoops they
are making their programmers jump through this week. Is everything
they ever feel like doing on their own one platform going to be
officially given the stamp of standardization? Should everyone else's
glorious new libraries and extensions to languages also be rubber
stamped? Should the GNU C++ extensions also be standardized?

> Win FX will be the .NET of the time. Even Windows Explorer in Longhorn 
> is managed (I suppose "hybrid"/mixed mode) so C++ must be able to use 
> the .NET CLI VM.

C++ can already use whatever you want it to use. You create the
library or compiler extension, and as long as you do not break the C++
Standard, 'C++' on your platform now supports whatever the heck you
want it to support. But the question here is about the standardization
of said crap. Does everyone have to change their programming languages
any time anyone wants to change how things are done on their own
particular platform? Does the C committee (yes, I know we are
discussing C++) change the C Standard every time the Linux kernel
changes, even for major changes (like, say, 2.4 to 2.6)? Should the C
and C++ committees (among others) standardize GCC's extensions too
then? Why should I, someone who uses nothing but Linux, have to give
even a tinge of a crap about what Microsoft is doing, which is in turn
changing (or at least threatening to) my programming languages?

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBFeJZVB8FYP9YqDcRAm2WAJ49qZAU9MS88syg8sJuZVvcGz4IYQCfYWLL
QR2drIcRH4Nws7pc1yXNaKU=
=rJ8Z
-----END PGP SIGNATURE-----

Tommy McDaniel wrote:

> You completely missed my point. My point was about Microsoft's
> attitude towards their own fricking .Net 'standards.' People seem to
> want to rush to embrace them these days, including, unfortunately,
> feeble-minded members of the ISO C++ committee, while, as if
> Microsoft's previous behavior were not enough, they are basically
> sitting there as we speak showing us exactly how highly they esteem
> even their own little 'standards' and just how much those 'standards'
> are good for. As I said somewhere, what happens when numbnuttery
> carries the day for the C++ committee and CLI is adopted into C++?


Yes however what kind of system extensions would you expect for CLI 
environments?


I mean in order to make an X Windows application for example, you will 
use some system extensions like the QT API.


What kind of system extensions would you expect for a CLI VM? And since 
CLI is a standard about virtual machines, there should be a standardised 
approach to use them from C++. Would it be better if each CLI VM 
provided its own set of system extensions to C++, than having a 
standardised one?


For example currently in .NET we use "managed extensions", things like:


// For CLI reference type definition
__gc class whatever
{
  // ...
};


whatever *p= __gc new whatever;


ISO C++ works as usual:

class something
{
  // ...
};


something obj, *p=new something;


Also can be used combined:


__gc class whatever
{
   something *sp;

   public:
   whatever() { sp=new something; // ... }

   ~whatever() { delete sp; // ... }

  // ...
};




Myself prefer to have a standardised set of system extensions so as my 
code to compile in Mono (when it gets a C++ compiler) for example, than 
having to convert my above CLI code to use another system-dependent syntax.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

usenet@leapheap.co.uk (Chris Noonan) wrote in message news:<ee224908.0408051302.4fb9d457@posting.google.com>...
 > ...
 > Such an arrangement cannot handle one thread freeing a memory
 > allocation that was malloc'ed by a different thread, typical
 > of a producer-consumer pattern. This circumstance is not
 > especially common, but it prevents the use of unsynchronised
 > thread-local blocks for a general-purpose malloc/free.
That's not completely clear to me.  You could certainly keep a local
to-be-freed list for each thread, and then perform the real
deallocations in a group, possibly with a single lock acquisition for
the entire batch.  The problem appears to be that this conflicts with
other design goals.

 > ...
 >  > Aside on locking in malloc/free:
 >  >
 >  > There are arguments for and against using a lock-free malloc/free
 >  > implementation.  But at least on modern Pentium 4s, the main cost in
 >  > either acquiring and releasing a lock or in the lock-free solutions
 >  > are the atomic cmpxchg or xchg instructions, which add on the order of
 >  > 200 cycles each.  Thus it really doesn't matter for present purposes.
 >
 > Yes, but the true cost of acquiring a lock is not the time
 > spent performing the bus-locked instruction; rather it is
 > the context switches incurred when other threads run up against
 > the lock. Should a thread happen to be scheduled out when holding
 > the lock, every other thread in the program is likely to hit the
 > lock and be forced to sleep, and this is likely to happen to each
 > thread before it has consumed a significant fraction of its intended
 > time-slice.
 >
 > The context-switching factor is what gives a lock-free heap manager
 > its compelling performance advantage.
 >
That's often a separable issue.  The Hoard memory allocator is quite
good at avoiding lock contention by using multiple locks.  But it
still locks for each allocation.

And some lock implementations seem to handle contention as well as
some lock-free schemes (which are also prone to excessive
cache-coherency traffic with high contention).  See my PODC paper
(cited earlier in this thread) for some sample measurements.

Hans

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Joe Seigh" <jseigh_01@xemaps.com> wrote in message
news:4114F1C2.E1C04C1A@xemaps.com...
>
> "Terje Sletteb�" wrote:
> >
> > But is an algorithm using instructions with "lock" prefix a "lock-free
> > algorithm"? It does lock, but without allowing a context switch before
the
> > lock is released, which could otherwise have resulted in another thread
> > waiting for the lock, so you don't get the suspend/resume problem you
> > mention.
>
> "lock-free" means the ability for a thread to make forward progress is
> not affected by other threads.  The thread does not have to wait for
> some other thread to do something like release a lock.
>
> Interlocked instructions typically use some form of locking at the
hardware
> level to achieve atomicity.  Even simple instructions like loads and
stores
> may use some form of locking.  But the hardware provides guarantees of
forward
> progress so basically hardware implementation is not an issue.

Exactly. And what started this subthread was the discussion about locking
for shared pointer reference counting. As has been shown, you can use atomic
instructions for this ("lock inc" and "lock dec" (the latter sets the
Zero-flag on reaching zero, so you can test that afterwards)), and so can be
implemented as lock-free, as per your definition above.

Regards,

Terje



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Hans-J. Boehm" wrote:
> 
> 
> And some lock implementations seem to handle contention as well as
> some lock-free schemes (which are also prone to excessive
> cache-coherency traffic with high contention).  See my PODC paper
> (cited earlier in this thread) for some sample measurements.
> 

If a somewhat related area, what's your take on the addition of JSR-166
to Java, the interlocked methods to implement lock-free algorithms?  It
wasn't just plain interlocked methods.  There were some with mark bits
and version counts to help solve things like the ABA problem.  You could
use GC to solve the ABA problem, but that would just kill GC with the
volume of object deletions.

I don't think there is any one mechanism that is better over all here.
Each has it's strengths and weaknesses.  Depending on the particular
situation, one solution may work better than another.

Joe Seigh

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Hans-J. Boehm" <Hans_Boehm@hp.com> wrote in message
news:1178a29f.0408071644.3fc6bcd8@posting.google.com...
> And some lock implementations seem to handle contention as well as
> some lock-free schemes (which are also prone to excessive
> cache-coherency traffic with high contention).  See my PODC paper
> (cited earlier in this thread) for some sample measurements.

Now that we got to this point, I've always meant to ask you: what do you
think of Maged Michael's Scalable Lock-Free Dynamic Memory Allocation at
PLDI 2004 (http://www.research.ibm.com/people/m/michael/pldi-2004.pdf)? It
seemed to me that it scales better than any other approaches. (Congrats for
the award by the way :o).)

Andrei



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

usenet@leapheap.co.uk (Chris Noonan) wrote in message news:<ee224908.0408051302.4fb9d457@posting.google.com>...

> Hans_Boehm@hp.com (Hans-J. Boehm) wrote:
>  > Allocation:
>  >
>  > The distinction here is a bit less clear cut.  But it is relatively
>  > easy for a tracing GC to arrange that each thread allocates memory in
>  > large chunks (with synchronization, e.g. by acquiring a lock), and
>  > then keeps track of that large chunk in some thread-local place, so
>  > that individual allocations don't need a lock.  I believe all major
>  > Java implementations do that.  Our collector can (and does in the
>  > standard gcj and probably Mono configurations).  I think so does
>  > Microsoft's .NET implementation.  Thus the vast majority of
>  > allocations don't involve a lock acquisition.
>  >
>  > It's not obvious to me that this couldn't be done for malloc/free.
>  > But I know of no implementations that do.
> 
> Such an arrangement cannot handle one thread freeing a memory
> allocation that was malloc'ed by a different thread, typical
> of a producer-consumer pattern. This circumstance is not
> especially common, but it prevents the use of unsynchronised
> thread-local blocks for a general-purpose malloc/free.
> 
> Thread-segregated storage has indeed been implemented for
> memory allocators, but I believe that in all cases it is done to
> promote locality and avoid cache-line sharing on multiprocessor
> machines, and the atomic instructions cannot be omitted.
> 

May I correct my earlier post in this respect? I believe it
is possible to devise thread-segregated storage which allows
freeing by a thread other than the allocating thread, yet
employs neither locks nor atomic instructions.

Chris

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<cekai1$1tp2$1@ulysses.noc.ntua.gr>...
> Tommy McDaniel wrote:
> 
> >>No CLI is a standard and is no one's patent.
> > 
> > 
> > You might want to read
> > http://yro.slashdot.org/article.pl?sid=03/02/11/0048208&tid=109&tid=155&tid=17
> > before pursuing that line farther.
> 
> Well the above URL says that .NET is patented. That is a different thing 
> than CLI. NET is an ISO CLI compliant implementation, as Visual C++ 
> compiler is (~98% currently) an ISO C++ compliant implementation. They 
> can patent their compiler but not ISO C++.

C++ != .Net. C++ is a preexisting language that they are welcome to
implement, but is not something that they came up with. .Net, however,
is their own thing, that they are having stamped with standardization.
If .Net is patented, you had better bet your butt that you are going
to run afoul of those patents in implementing .Net. Remember, patents
are not copyrights. Once an idea is patented, it cannot be
implemented, regardless of how you implement it. On a side note, I
would say that them gaining a patent on their C++ implementation would
in fact make life very difficult for the rest of the C++ world,
regardless of the fact that the language is itself standardized.

> > So is C#, regarding which you might want to read
> > http://developers.slashdot.org/developers/03/10/25/188234.shtml?tid=109&tid=126&tid=156&tid=187;
> > barely out of the standard oven and already getting the finger from
> > Microsoft. 
> 
> Actually there will be an updated C#/CLI standard. But to tell you the 
> truth I do not care for C# so much. :-)

I do not care for it at all, but that is irrelevant.

> > You might also want to read
> > http://slashdot.org/article.pl?sid=01/07/20/1555256&tid=109, regarding
> > 'universally implementable' standards.
> 
> Again who cares for C#? :-)

That question is irrelevant. The question of interest here is 'who
cares about Microsoft's behavior towards standards, and, more
specifically, their own little "open" .Net standards,' the answer to
which should be 'everyone discussing this and considering adopting
their idiot "standards".'

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBFtZRVB8FYP9YqDcRAgPpAJ4q37hXdRVtcYN8X8RO2ieEJfm2FgCbBZy4
74fDByZbouE6q269ZhEMedw=
=bsZv
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<cf4qdl$1h99$1@ulysses.noc.ntua.gr>...
> Tommy McDaniel wrote:
> 
> > You completely missed my point. My point was about Microsoft's
> > attitude towards their own fricking .Net 'standards.' People seem to
> > want to rush to embrace them these days, including, unfortunately,
> > feeble-minded members of the ISO C++ committee, while, as if
> > Microsoft's previous behavior were not enough, they are basically
> > sitting there as we speak showing us exactly how highly they esteem
> > even their own little 'standards' and just how much those 'standards'
> > are good for. As I said somewhere, what happens when numbnuttery
> > carries the day for the C++ committee and CLI is adopted into C++?
> 
> I mean in order to make an X Windows application for example, you will 
> use some system extensions like the QT API.

Qt is not a standard, let alone one that Trolltech runs around
flaunting. No one said anything about using or not using
system-specific libraries. The only way your statement would apply
would be if Qt were being considered for inclusion into C++ and
Trolltech had a history, continuing to this very day, of flaunting all
standards, even their own, but neither premise is true.

> Would it be better if each CLI VM 
> provided its own set of system extensions to C++, than having a 
> standardised one?

I hope you think so, because that is exactly what will happen when
Microsoft decides to ignore their own CLI standard(s).

> Myself prefer to have a standardised set of system extensions so as my 
> code to compile in Mono (when it gets a C++ compiler) for example, than 
> having to convert my above CLI code to use another system-dependent syntax.

And as I said, that is not going to go quite as you seem to think it
is when Microsoft decides to give the finger to the CLI standards. Is
there something subtle or hard to understand about that concept?

By the way, you ignored that whole part about why I should have to
give a crap about CLI from Linux and that part about standardizing
other stuff too.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBFuktVB8FYP9YqDcRApdmAJ4zxn09iSdv7gc22pV4uFvXJ+8YywCeJJu5
BoLHj4hxjjvooFVkHgvIkSI=
=u65R
-----END PGP SIGNATURE-----

Tommy McDaniel wrote:

> C++ != .Net. C++ is a preexisting language that they are welcome to
> implement, but is not something that they came up with. .Net, however,
> is their own thing, that they are having stamped with standardization.
> If .Net is patented, you had better bet your butt that you are going
> to run afoul of those patents in implementing .Net. Remember, patents
> are not copyrights. Once an idea is patented, it cannot be
> implemented, regardless of how you implement it. On a side note, I
> would say that them gaining a patent on their C++ implementation would
> in fact make life very difficult for the rest of the C++ world,
> regardless of the fact that the language is itself standardized.


In any case, CLI is a standardised *subset* of .NET and as far as I know 
it is not patented.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Tommy McDaniel wrote:

>>I mean in order to make an X Windows application for example, you will 
>>use some system extensions like the QT API.
> 
> 
> Qt is not a standard, let alone one that Trolltech runs around
> flaunting. No one said anything about using or not using
> system-specific libraries. The only way your statement would apply
> would be if Qt were being considered for inclusion into C++ and
> Trolltech had a history, continuing to this very day, of flaunting all
> standards, even their own, but neither premise is true.
> 
> 
>>Would it be better if each CLI VM 
>>provided its own set of system extensions to C++, than having a 
>>standardised one?
> 
> 
> I hope you think so, because that is exactly what will happen when
> Microsoft decides to ignore their own CLI standard(s).
> 
> 
>>Myself prefer to have a standardised set of system extensions so as my 
>>code to compile in Mono (when it gets a C++ compiler) for example, than 
>>having to convert my above CLI code to use another system-dependent syntax.
> 
> 
> And as I said, that is not going to go quite as you seem to think it
> is when Microsoft decides to give the finger to the CLI standards. Is
> there something subtle or hard to understand about that concept?
> 
> By the way, you ignored that whole part about why I should have to
> give a crap about CLI from Linux and that part about standardizing
> other stuff too.



As I said, you can consider C++/CLI as a system extension if you want, 
since it is separated from the ISO C++ standard. I do this myself too at 
least about .net "managed extensions". The only difference is that 
C++/CLI will have a broader scope.


Myself use ISO C++ as much as possible in .NET. But C++/CLI is "cleaner" 
and better than managed extensions, even if it is considered only for 
use in .NET.

So in summary, instead of using VCL in Win32 for example, I prefer 
C++/CLI in .NET. And if I can use C++/CLI in other platforms, the better.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<cf0j13$kqr$1@ulysses.noc.ntua.gr>...
> Nicola Musatti wrote:
[...]
> I mean in order to make an X Windows application for example, you will
> use some system extensions like the QT API.

If by system extensions you mean language extention, not necessarily.
The an interface to the Xt library can be implemented with the current
language plus some platform dependent code for e.g. setting up
sockets, etc.

Trolltech chose to provide extensions through a precompiler, but,
again, that does not require changes to the C++ standard.

> What kind of system extensions would you expect for a CLI VM? And since
> CLI is a standard about virtual machines, there should be a standardised
> approach to use them from C++. Would it be better if each CLI VM
> provided its own set of system extensions to C++, than having a
> standardised one?

One thing is to standardize an API for CLI, another is to require
changes to the standard to make it possible to access functionality
that is currently inaccessible to C++ implementations, yet another is
to implement the API by creating a dialect of the language, "just for
convenience".

I have no objection about the first point; I can understand the second
and consider it worthy of discussion within the standardization
committee, just as I feel about discussing the basic needs to support
multithreading and/or dynamic libraries; I am less content with the
third point.

> For example currently in .NET we use "managed extensions", things like:
> 
> __gc class whatever
> {
>    // ...
> };
> 
> whatever *p= __gc new whatever;
> 
> Myself prefer to have a standardised set of system extensions so as my
> code to compile in Mono (when it gets a C++ compiler) for example, than
> having to convert my above CLI code to use another system-dependent syntax.

But that could be achieved by just standardizing the current approach,
couldn't it? This had the advantage of not hyjacking any keyword, if
at the expense of having to write particularly ugly code.

Do the changes to language envisioned by the C++/CLI cater for similar
needs of other platforms? Should anybody decide to define a binding
to, say, the JVM, will it require a different, non compatible set of
changes?

I suspect that the answer is currently "nobody knows". As such I would
have much prefered a library like interface to the CLI than the
current core language based approach.

Cheers,
Nicola Musatti

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1091811142.888446@master.nyc.kbcfp.com>...
> Nicola Musatti wrote:
> > Not exactly. You still have to explicitly reset the first reference
> > into each connected graph of dynamically allocated structures. I
> > believe this is a common source of memory waste in GC based programs.
> 
> As someone else has already stated here, losing one particular
> reference to an object is a local issue - some piece of code
> decides it no longer needs the object. Deleteing an object is
> quite something else, because the deleter needs to know that no
> one needs the object.

It is still an explicit action in many cases, even though I agree that
it's much more convenient to be able to write

delete this_very_complex_data_structure;

(usually spelt as "p = NULL" or something like that) rather than
having to follow all pointers to the leaf nodes and recursively delete
each node. Even a careful use of destructors doesn't beat the solution
above.

Note that I have nothing against garbage collection, as long as one is
guaranteed of not incurring any overhead when not using it.

Cheers,
Nicola Musatti

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Andreas Huber wrote:
> "Jeff" <surferjeff@gmail.com> wrote in message
> news:781dd16f.0408061455.15630ddb@posting.google.com...
>> That's because python has deterministic and predictable gc.  Things
>> get collected when they go out of scope.
> 
> From what I gather from
> 
> http://python.org/doc/faq/general.html#how-does-python-manage-memory
> 
> this is only true if there are no cycles. If there are cycles, collection is
> non-deterministic. Moreover, some Python implementations are fully GCed,
> i.e. deterministic destruction must always be induced manually, as show in
> the file example. Therefore, to make your programs fully portable among all
> Python implementations you must program as if there is no refcounting (and
> no automatic deterministic destruction).
> 
> To me, the decision of some Python implementations to use a mixture of
> refcounting and GC looks like a mistake.
>
> I doesn't make programming any easier and needlessly throws away
> potential performance gains of a pure GC environment.
<snip>

There wasn't a single decision to do things this way.  The first and
by far the most commonly used implementation, CPython, originally had
only reference-counting.  A cycle-detecting garbage collector was
added in version 2.0.  The decision to continue counting references
and to use mark-and-sweep as a backup preserves source compatibility
with existing extensions and with Python programs that expect
destruction of objects as their last references go out of scope. 
Since CPython only allows one thread in the VM at a time [1], there is
no need for synchronisation of reference-counting and the cost is not
that high.  If and when the BDFL [2] decides there is a need for
better support of multithreading then it might be changed over to a
single non-reference-counting GC.

[1] So multiple threads are only useful when most of the running
    time is consumed within C extensions that release the VM lock.
[2] Python's creator and Benvolent Dictator For Life, Guido Rossum.

Alternate implementations of Python - Jython and IronPython - are
implemented using existing VMs (JVM and .NET CLR respectively) that
provide non-reference-counting GC so the decision to use it was
obvious.  As you say, portable Python code should run on these, but so
long as they are not widely used and so long as Python doesn't include
an easy way to ensure objects are cleaned-up at the end of a scope
(like C#'s "using" or C++'s automatic storage) most Python programmers
won't bother.

To make this relevant to C++: there's a similarity between the
situation in Python, where truly portable programs have to include
explicit clean-up code that's usually redundant, and the potential
situtation in C++-with-optional-GC situation where portable C++
libraries that can make good use of GC would still need to include
determinstic clean-up code for non-GC-using clients.  A program that
uses exceptions or RTTI in any part needs the compiler to generate the
code and metadata that supports them throughout the program.  If a new
standard is to require support for GC, it should similarly require no
more than the use of the appropriate syntax to enable it.  If
implementers can't optimise away GC support in a program that doesn't
use it, let them provide an option to turn it off, as many do with
exceptions and RTTI, but please let's not write that option into the
standard.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Nicola Musatti wrote:

> Trolltech chose to provide extensions through a precompiler, but,
> again, that does not require changes to the C++ standard.
> 
> 
> One thing is to standardize an API for CLI, another is to require
> changes to the standard


What changes to the standard? As it has been mentioned numerous times, 
C++/CLI is a separate standard than ISO C++, and it defines *extensions* 
to ISO C++.


ISO C++ remains unchanged.




> to make it possible to access functionality
> that is currently inaccessible to C++ implementations, yet another is
> to implement the API by creating a dialect of the language, "just for
> convenience".
> 
> I have no objection about the first point; I can understand the second
> and consider it worthy of discussion within the standardization
> committee, just as I feel about discussing the basic needs to support
> multithreading and/or dynamic libraries; I am less content with the
> third point.
> 
> But that could be achieved by just standardizing the current approach,
> couldn't it? This had the advantage of not hyjacking any keyword, if
> at the expense of having to write particularly ugly code.
> 
> Do the changes to language envisioned by the C++/CLI



There are no changes to the language, since ISO C++ remains unchanged 
and ISO C++ code also compiles in a CLI VM.



> cater for similar
> needs of other platforms? Should anybody decide to define a binding
> to, say, the JVM, will it require a different, non compatible set of
> changes?
> 
> I suspect that the answer is currently "nobody knows". As such I would
> have much prefered a library like interface to the CLI than the
> current core language based approach.


Yes however C++/CLI has low level access to CLI that couldn't be 
possible through a library.


Also I do not like exotic libraries myself, but only those that can be 
built using the current "language".






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<cf7tlu$2tvh$1@ulysses.noc.ntua.gr>...
> Tommy McDaniel wrote:
> 
> >>I mean in order to make an X Windows application for example, you will 
> >>use some system extensions like the QT API.
> > 
> > 
> > Qt is not a standard, let alone one that Trolltech runs around
> > flaunting. No one said anything about using or not using
> > system-specific libraries. The only way your statement would apply
> > would be if Qt were being considered for inclusion into C++ and
> > Trolltech had a history, continuing to this very day, of flaunting all
> > standards, even their own, but neither premise is true.
> > 
> > 
> >>Would it be better if each CLI VM 
> >>provided its own set of system extensions to C++, than having a 
> >>standardised one?
> > 
> > 
> > I hope you think so, because that is exactly what will happen when
> > Microsoft decides to ignore their own CLI standard(s).
> > 
> > 
> >>Myself prefer to have a standardised set of system extensions so as my 
> >>code to compile in Mono (when it gets a C++ compiler) for example, than 
> >>having to convert my above CLI code to use another system-dependent syntax.
> > 
> > 
> > And as I said, that is not going to go quite as you seem to think it
> > is when Microsoft decides to give the finger to the CLI standards. Is
> > there something subtle or hard to understand about that concept?
> > 
> > By the way, you ignored that whole part about why I should have to
> > give a crap about CLI from Linux and that part about standardizing
> > other stuff too.
> 
> As I said, you can consider C++/CLI as a system extension if you want, 
> since it is separated from the ISO C++ standard. I do this myself too at 
> least about .net "managed extensions".

I have been talking about when C++ itself is changed to incorporate
Microsoft's crap. I am just about tired of saying that.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBGDV3VB8FYP9YqDcRAo+5AJwNOrRnv0rnMeBMxVc573iiLug5IgCgkQeZ
xlAhTUICcbrsPuxu9bCzKns=
=hdSK
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<cf7t9n$2t5k$1@ulysses.noc.ntua.gr>...
> Tommy McDaniel wrote:
> 
> > C++ != .Net. C++ is a preexisting language that they are welcome to
> > implement, but is not something that they came up with. .Net, however,
> > is their own thing, that they are having stamped with standardization.
> > If .Net is patented, you had better bet your butt that you are going
> > to run afoul of those patents in implementing .Net. Remember, patents
> > are not copyrights. Once an idea is patented, it cannot be
> > implemented, regardless of how you implement it. On a side note, I
> > would say that them gaining a patent on their C++ implementation would
> > in fact make life very difficult for the rest of the C++ world,
> > regardless of the fact that the language is itself standardized.
> 
> In any case, CLI is a standardised *subset* of .NET and as far as I know 
> it is not patented.

The story I linked to about the patents says that the patents were
specifically for the CLR, which it also says is their implementation
of the CLI. So while CLI may only be a subset of .Net, it is the
subset that matters as far as those patents are concerned. If
implementing CLI is patented, then who gives a crap whether CLI itself
is or is not; you cannot do anything with it if you cannot implement
it (without sending a postcard marked "sue me, pretty please" to
Microsoft).

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBGDmGVB8FYP9YqDcRAnl2AJ93e+5B02z++3ncrp3Zt4ijbb1jUQCggPiv
8Luw6m11Q05Lo9oDlXvPu+I=
=zO8C
-----END PGP SIGNATURE-----

Tommy McDaniel wrote:

> The story I linked to about the patents says that the patents were
> specifically for the CLR, which it also says is their implementation
> of the CLI. So while CLI may only be a subset of .Net, it is the
> subset that matters as far as those patents are concerned. If
> implementing CLI is patented, then who gives a crap whether CLI itself
> is or is not; you cannot do anything with it if you cannot implement
> it (without sending a postcard marked "sue me, pretty please" to
> Microsoft).

If CLI was patented, I would be against it. But as I have said about CLI 
(which is a subset of CLR), I haven't seen anywhere that it is patented.

Furthermore it is an ISO standard which makes the possibility of it 
patented, further distant (if not impossible).


I just checked the web to find any CLI relevant patents and the only 
thing I found is mainly about the various .NET APIs which of course can 
be copyrighted and patented.


Only the CLI API is standardised and can be considered portable anyway.

Also I have been checking binary portability of C++/CLI code between 
..NET and Mono lately, and the first results indicate that MS makes the 
produced IL binaries to depend on MS specific managed DLLs, both for VB 
managed code and C++/CLI.

In Mono they provide a virtual DLL for VB to help the produced IL code 
to run on it without recompilation, but as my experience indicates so 
far with VC++ Express 2005 Beta 1, even for C++/CLI code you can't 
expect binary portability in general, at least for executables produced 
by MS compilers. An example from a recent mailing in Mono Devel mailing 
list:



" Thank you for your useful email! I will stick in the C++/CLI code and 
not use managed extensions for consistency and convenience.


The Hello world program, as specified in the current C++/CLI draft 
(version 1.5):


int main()
{
     System::Console::WriteLine("Hello World");
}


C:\c>cl /clr:safe temp.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40607.16
for Microsoft (R) .NET Framework version 2.00.40607.16
Copyright (C) Microsoft Corporation.  All rights reserved.

temp.cpp
Microsoft (R) Incremental Linker Version 8.00.40607.16
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:temp.exe
temp.obj


==> The /clr:safe only produces an executable that passes peverify:



C:\c>peverify temp.exe /verbose

Microsoft (R) .NET Framework PE Verifier.  Version  2.0.40607.16
Copyright (C) Microsoft Corporation. All rights reserved.

All Classes and Methods in temp.exe Verified.

C:\c>


[...]


root@chrome cdrom]# mono temp.exe

** (temp.exe:1416): WARNING **: Could not find assembly 
Microsoft.VisualC, references from /mnt/cdrom/temp.exe (assemblyref_index=1)
      Major/Minor: 8,0
      Build:       1200,0
      Token:       b03f5f7f11d50a3a

cannot open assembly temp.exe
[root@chrome cdrom]#



Any ideas?






Best regards,

Ioannis Vranos"




And the response from a fellow developer in the list:


"Evidently the default compiler flags insert an assembly reference to
Microsoft.VisualC.dll.  If you could run ILDASM.EXE on the assembly and
send us the resulting .il, that would be useful.  (I forget the correct
flags to use to generate the .IL file; just have it spit out as much
information as possible.)

The *real* question would remain after seeing the .il: How do you remove
the reference to Microsoft.VisualC.dll?  I have no idea, though I assume
the compiler documentation would mention it.

Alternatively, and a parallel solution, is to implement the
Microsoft.VisualC.dll assembly and contribute it to Mono.  This would
allow easier use of C++/CLI programs in the future, as developers
wouldn't need to worry about removing the assembly reference.  This is
similar to how Mono provides a Microsoft.VisualBasic.dll assembly for
VB.NET programs.

  - Jon"






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Ioannis Vranos wrote:

> Tommy McDaniel wrote:
> 
>> The story I linked to about the patents says that the patents were
>> specifically for the CLR, which it also says is their implementation
>> of the CLI. So while CLI may only be a subset of .Net, it is the
>> subset that matters as far as those patents are concerned. If
>> implementing CLI is patented, then who gives a crap whether CLI itself
>> is or is not; you cannot do anything with it if you cannot implement
>> it (without sending a postcard marked "sue me, pretty please" to
>> Microsoft).
> 
> 
> If CLI was patented, I would be against it. But as I have said about CLI 
> (which is a subset of CLR), I haven't seen anywhere that it is patented.
> 
> Furthermore it is an ISO standard which makes the possibility of it 
> patented, further distant (if not impossible).
> 
> 
> I just checked the web to find any CLI relevant patents and the only 
> thing I found is mainly about the various .NET APIs which of course can 
> be copyrighted and patented.
> 
> 
> Only the CLI API is standardised and can be considered portable anyway.
> 
> Also I have been checking binary portability of C++/CLI code between 
> .NET and Mono lately, and the first results indicate that MS makes the 
> produced IL binaries to depend on MS specific managed DLLs, both for VB 
> managed code and C++/CLI.
> 
> In Mono they provide a virtual DLL for VB to help the produced IL code 
> to run on it without recompilation, but as my experience indicates so 
> far with VC++ Express 2005 Beta 1, even for C++/CLI code you can't 
> expect binary portability in general, at least for executables produced 
> by MS compilers. An example from a recent mailing in Mono Devel mailing 
> list:
> 
> 
> 
> " Thank you for your useful email! I will stick in the C++/CLI code and 
> not use managed extensions for consistency and convenience.
> 
> 
> The Hello world program, as specified in the current C++/CLI draft 
> (version 1.5):
> 
> 
> int main()
> {
>     System::Console::WriteLine("Hello World");
> }
> 
> 
> C:\c>cl /clr:safe temp.cpp
> Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40607.16
> for Microsoft (R) .NET Framework version 2.00.40607.16
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> temp.cpp
> Microsoft (R) Incremental Linker Version 8.00.40607.16
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> /out:temp.exe
> temp.obj
> 
> 
> ==> The /clr:safe only produces an executable that passes peverify:
> 
> 
> 
> C:\c>peverify temp.exe /verbose
> 
> Microsoft (R) .NET Framework PE Verifier.  Version  2.0.40607.16
> Copyright (C) Microsoft Corporation. All rights reserved.
> 
> All Classes and Methods in temp.exe Verified.
> 
> C:\c>
> 
> 
> [...]
> 
> 
> root@chrome cdrom]# mono temp.exe
> 
> ** (temp.exe:1416): WARNING **: Could not find assembly 
> Microsoft.VisualC, references from /mnt/cdrom/temp.exe 
> (assemblyref_index=1)
>      Major/Minor: 8,0
>      Build:       1200,0
>      Token:       b03f5f7f11d50a3a
> 
> cannot open assembly temp.exe
> [root@chrome cdrom]#
> 
> 
> 
> Any ideas?
> 
> 
> 
> 
> 
> 
> Best regards,
> 
> Ioannis Vranos"
> 
> 
> 
> 
> And the response from a fellow developer in the list:
> 
> 
> "Evidently the default compiler flags insert an assembly reference to
> Microsoft.VisualC.dll.  If you could run ILDASM.EXE on the assembly and
> send us the resulting .il, that would be useful.  (I forget the correct
> flags to use to generate the .IL file; just have it spit out as much
> information as possible.)
> 
> The *real* question would remain after seeing the .il: How do you remove
> the reference to Microsoft.VisualC.dll?  I have no idea, though I assume
> the compiler documentation would mention it.
> 
> Alternatively, and a parallel solution, is to implement the
> Microsoft.VisualC.dll assembly and contribute it to Mono.  This would
> allow easier use of C++/CLI programs in the future, as developers
> wouldn't need to worry about removing the assembly reference.  This is
> similar to how Mono provides a Microsoft.VisualBasic.dll assembly for
> VB.NET programs.
> 
>  - Jon"



And this means you can count on source code portability only for C++/CLI 
code at least if you use MS compilers. ISO C++ source code is portable 
as usual in all CLI C++ compilers.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Tommy McDaniel wrote:

> I have been talking about when C++ itself is changed to incorporate
> Microsoft's crap. I am just about tired of saying that.


Can you provide an example of such a case?






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Ioannis Vranos wrote:

> And this means you can count on source code portability only for C++/CLI 
> code at least if you use MS compilers. ISO C++ source code is portable 
> as usual in all CLI C++ compilers.


Actually I managed to make the .exe to run under Mono:


[root@chrome cdrom]# ls
Microsoft.VisualC.Dll  temp.exe  temp.obj
[root@chrome cdrom]# mono temp.exe
Hello World
[root@chrome cdrom]#


That is, when I placed the Microsoft.VisualC.dll together with the 
executable, it ran successfully in Mono.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Joe Seigh <jseigh_01@xemaps.com> wrote in message news:<411657B1.236DBF2A@xemaps.com>...
 > "Hans-J. Boehm" wrote:
 > >
 > >
 > > And some lock implementations seem to handle contention as well as
 > > some lock-free schemes (which are also prone to excessive
 > > cache-coherency traffic with high contention).  See my PODC paper
 > > (cited earlier in this thread) for some sample measurements.
 > >
 >
 > If a somewhat related area, what's your take on the addition of JSR-166
 > to Java, the interlocked methods to implement lock-free algorithms?  It
 > wasn't just plain interlocked methods.  There were some with mark bits
 > and version counts to help solve things like the ABA problem.  You could
 > use GC to solve the ABA problem, but that would just kill GC with the
 > volume of object deletions.
 >
 > I don't think there is any one mechanism that is better over all here.
 > Each has it's strengths and weaknesses.  Depending on the particular
 > situation, one solution may work better than another.
 >
 > Joe Seigh
 >
I don't have real experience using the JSR 166 additions to Java.  But
I've certainly looked at them.  As far as I can tell, they were very
carefully designed, and certain pieces, notably the synchronizer
framework, seem to be really clever designs.

My impression is that at least marked references don't yet have a full
performance implementation, so it may not be clear for a while how
useful they really are.

Whether or not you can use the GC as an ABA solution really seems to
depend on the context.  If you are trying to move existing nodes
between lists, with each node possibly appearing on multiple lists, it
doesn't seem appropriate.  IIRC Doug Lea claimed that it worked
surprisingly well, at least with a generational GC, in other contexts.

Hans

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Ioannis Vranos" <ivr@guesswh.at.grad.com> wrote in message

 > What changes to the standard? As it has been mentioned numerous times,
 > C++/CLI is a separate standard than ISO C++, and it defines *extensions*
 > to ISO C++.

As has also been mentioned, it restricts what C++ might do in the future.  The
syntactic extensions may not conflict with current C++, but they could limit the
possible directions that C++ might take in the future.  Just look at the typeof
extension that several compilers support versus the decltype proposal.  The
possible use of the name 'typeof' has basically been killed because of existing
"non-interfering" extensions.  Anything that C++ might do will have to consider
its impact on existing code--code which might include extensions such as CLI
syntax.  The CLI effectively commandeers all of the "non-interfering" syntax
(etc.) extensions and limits the breathing room that C++ has for future
extension.

Regards,
Paul Mensonides



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<cfaqcu$1bb7$1@ulysses.noc.ntua.gr>...
> Tommy McDaniel wrote:
> 
> > The story I linked to about the patents says that the patents were
> > specifically for the CLR, which it also says is their implementation
> > of the CLI. So while CLI may only be a subset of .Net, it is the
> > subset that matters as far as those patents are concerned. If
> > implementing CLI is patented, then who gives a crap whether CLI itself
> > is or is not; you cannot do anything with it if you cannot implement
> > it (without sending a postcard marked "sue me, pretty please" to
> > Microsoft).
> 
> If CLI was patented, I would be against it. But as I have said about CLI 
> (which is a subset of CLR), I haven't seen anywhere that it is patented.

If CLR is patented, and CLI is a subset of CLR, then CLI is provably
through logic also patented. Which also makes it a provable statement
that you are against CLI. Do I have to whip out the ASCII logic
symbols?

> Furthermore it is an ISO standard which makes the possibility of it 
> patented, further distant (if not impossible).

How does that make the possibility "further distant?" Did you not get
news about the recent claims that JPEG, an ISO standard, is patented
and we all have to pay up ala GIF?

> Also I have been checking binary portability of C++/CLI code between 
> .NET and Mono lately, and the first results indicate that MS makes the 
> produced IL binaries to depend on MS specific managed DLLs, both for VB 
> managed code and C++/CLI.

But wait, wasn't C++/CLI supposed to be the panacea of binary
portability? What is this dependance on Microsoft libraries that you
speak of? Surely they would not do that, they being such nice people
and all.

> In Mono they provide a virtual DLL for VB to help the produced IL code 
> to run on it without recompilation, but as my experience indicates so 
> far with VC++ Express 2005 Beta 1, even for C++/CLI code you can't 
> expect binary portability in general, at least for executables produced 
> by MS compilers. An example from a recent mailing in Mono Devel mailing 
> list:

Surely you know that you are just proving my point, if your statement
has any relevance at all.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBGdGUVB8FYP9YqDcRAj7YAJ9bozA25aXuyNMTv/6xEWpY5MEU3gCfd/Pe
ofcTXzyEukiHT3M7bTL7INo=
=IEAc
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<cfaqod$1bvd$1@ulysses.noc.ntua.gr>...
> Ioannis Vranos wrote:
> 
> > Tommy McDaniel wrote:
> > 
> >> The story I linked to about the patents says that the patents were
> >> specifically for the CLR, which it also says is their implementation
> >> of the CLI. So while CLI may only be a subset of .Net, it is the
> >> subset that matters as far as those patents are concerned. If
> >> implementing CLI is patented, then who gives a crap whether CLI itself
> >> is or is not; you cannot do anything with it if you cannot implement
> >> it (without sending a postcard marked "sue me, pretty please" to
> >> Microsoft).
> > 
> > 
> > If CLI was patented, I would be against it. But as I have said about CLI 
> > (which is a subset of CLR), I haven't seen anywhere that it is patented.
> > 
> > Furthermore it is an ISO standard which makes the possibility of it 
> > patented, further distant (if not impossible).
> > 
> > 
> > I just checked the web to find any CLI relevant patents and the only 
> > thing I found is mainly about the various .NET APIs which of course can 
> > be copyrighted and patented.
> > 
> > 
> > Only the CLI API is standardised and can be considered portable anyway.
> > 
> > Also I have been checking binary portability of C++/CLI code between 
> > .NET and Mono lately, and the first results indicate that MS makes the 
> > produced IL binaries to depend on MS specific managed DLLs, both for VB 
> > managed code and C++/CLI.
> > 
> > In Mono they provide a virtual DLL for VB to help the produced IL code 
> > to run on it without recompilation, but as my experience indicates so 
> > far with VC++ Express 2005 Beta 1, even for C++/CLI code you can't 
> > expect binary portability in general, at least for executables produced 
> > by MS compilers. An example from a recent mailing in Mono Devel mailing 
> > list:
> >
> > And the response from a fellow developer in the list:
> > 
> > 
> > "Evidently the default compiler flags insert an assembly reference to
> > Microsoft.VisualC.dll.  If you could run ILDASM.EXE on the assembly and
> > send us the resulting .il, that would be useful.  (I forget the correct
> > flags to use to generate the .IL file; just have it spit out as much
> > information as possible.)
> > 
> > The *real* question would remain after seeing the .il: How do you remove
> > the reference to Microsoft.VisualC.dll?  I have no idea, though I assume
> > the compiler documentation would mention it.
> > 
> > Alternatively, and a parallel solution, is to implement the
> > Microsoft.VisualC.dll assembly and contribute it to Mono.  This would
> > allow easier use of C++/CLI programs in the future, as developers
> > wouldn't need to worry about removing the assembly reference.  This is
> > similar to how Mono provides a Microsoft.VisualBasic.dll assembly for
> > VB.NET programs.
> > 
> >  - Jon"
> 
> 
> 
> And this means you can count on source code portability only for C++/CLI 
> code at least if you use MS compilers.

Uh, doesn't that kind of flush all those glorious binary portability
advantages of C++/CLI down the toilet? Source code is already
portable.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBGdMCVB8FYP9YqDcRAjRiAJ4zlWvzCLJcKO/5uN7Q5HUaueOSFQCfUIe1
yTYCOAq64ZikuTpjkPW++tk=
=Np24
-----END PGP SIGNATURE-----

Tommy McDaniel wrote:
>
>>And this means you can count on source code portability only for C++/CLI 
>>code at least if you use MS compilers.
> 
> 
> Uh, doesn't that kind of flush all those glorious binary portability
> advantages of C++/CLI down the toilet? Source code is already
> portable.


Actually after that message I had managed to ran the .exe under Mono and 
in the following days I will be experimenting with both console and GUI 
portability of C++/CLI between .NET and Mono.


About requiring that .dll an MS person told me:


"Ioannis Vranos wrote:

 >> How can I remove that useless assembly reference to "Microsoft.VisualC"?


This is currently a bug in the Visual C++ compiler. We moved a number of
types from Microsoft.VisualC.dll into the frameworks assemblies (like
mscorlib.dll). Those types will need to be introduced on Mono to work, 
which should be trivial.

The simple hello world example shouldn't need any changes to Mono... 
it's just a bug in the VC compiler right now.

-- Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/ 
This posting is provided AS IS with no warranties, and confers no rights. "




Anyway in VS 2005 (and VC++ 2005 Express) there are /clr switch 
specialisations:


/clr[:noAssembly|:pure|:safe|:oldSyntax] compile for the common language 
runtime

     noAssembly - do not produce an assembly
     pure - produce IL-only output file (no native executable code)
     safe - produce IL-only verifiable output file
     oldSyntax - accept the Managed Extensions syntax from Visual C++ 
2002/2003




The /clr:pure and /clr:safe produce IL exes only, which depending on the 
APIs used can be binary portable to other CLI machines.


The "safe" is better than "pure", but I haven't figured out their exact 
difference yet.


Of course, if ISO C++ is used, only /clr can be used, which produces 
mixed binaries which is expected.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Tommy McDaniel wrote:

> If CLR is patented, and CLI is a subset of CLR, then CLI is provably
> through logic also patented. Which also makes it a provable statement
> that you are against CLI. Do I have to whip out the ASCII logic
> symbols?



If CLR is patented, probably then non CLI subset is patented only.



>>Also I have been checking binary portability of C++/CLI code between 
>>.NET and Mono lately, and the first results indicate that MS makes the 
>>produced IL binaries to depend on MS specific managed DLLs, both for VB 
>>managed code and C++/CLI.
> 
> 
> But wait, wasn't C++/CLI supposed to be the panacea of binary
> portability? What is this dependance on Microsoft libraries that you
> speak of? Surely they would not do that, they being such nice people
> and all.



Well, after that I managed to run the binary under Mono, and as I told 
you in another message, an MS person told me that the .dll requirement 
is a bug of the current beta.




> Surely you know that you are just proving my point, if your statement
> has any relevance at all.


The first indications were that MS was making the IL binaries non 
portable by introducing system dependencies, and since I am not biased I 
mentioned it.


However this is not the case after all. But even if it was, C++/CLI code 
would still compile in other C++ compilers of CLI environments (which 
probably would produce portable binaries too).






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Nicola Musatti wrote:
 > It is still an explicit action in many cases, even though I agree that
 > it's much more convenient to be able to write
 >
 > delete this_very_complex_data_structure;
 >
 > (usually spelt as "p = NULL" or something like that) rather than
 > having to follow all pointers to the leaf nodes and recursively delete
 > each node. Even a careful use of destructors doesn't beat the solution
 > above.

No, you appear to have misunderstood. In the case of writing 'p = NULL;'
you are declaring that your 'p' no longer needs access to the thing it
was pointing at. This does not make any claims about any other part of
the program that might still be pointing at the same thing. On the other
hand, writing 'delete p' makes the far stronger claim that no other part
of the program needs the thing that p was pointing at. It is far easier
to get the former and local claim correct than the latter and global one.

Thing about the case of copy-on-write strings which can simply drop their
old buffer and point to a new one.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Terje Sletteb�" <tslettebo@hotmail.com> wrote in message
news:41138344$1@news.broadpark.no...
 > "Hyman Rosen" <hyrosen@mail.com> wrote in message
 > news:1091717392.806856@master.nyc.kbcfp.com...
 > > Nicola Musatti wrote:
 > >  > Very true. However, by the time that experience is gained, C++/CLI
 > >  > will already be an ECMA and very possibly ISO standard. This is what
I
 > >  > object to.
 > >
 > > This is hardly the first time that something has become a standard
 > > without intensive real-world experience first. Even in C++, export,
 > > two-phase lookup
 > > ...
 >
 > Yes, and they are not very good poster children for this, are they? ;)
 >
 > Some of the stuff standardised without much if any implementation- or use-
 > experience worked quite well, though.

[Read this thread til now, my head hurts. Starting yet another tangent...]

Great point, Terje. I guess that I will always reproach this to the C++
standardization committee. Stuff could be standardized even before being
tried out in the masses, provided there is a formal (or at least
semi-formal) proof that it has some properties universally known as useful
(such as modularization or separate complilation). In some cases I think
features have been standardized simply without any proof of any kind, and
we're paying dearly for that.

Andrei



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Paul Mensonides wrote:
 > "Ioannis Vranos" <ivr@guesswh.at.grad.com> wrote in message
 >
 >  > What changes to the standard? As it has been mentioned numerous times,
 >  > C++/CLI is a separate standard than ISO C++, and it defines *extensions*
 >  > to ISO C++.
 >
 > As has also been mentioned, it restricts what C++ might do in the future.  The
 > syntactic extensions may not conflict with current C++, but they could limit the
 > possible directions that C++ might take in the future.


Still many members of ISO C++ committee participate in C++/CLI committee
and there is cooperation between ISO C++ committee and C++/CLI one.



 >  Just look at the typeof
 > extension that several compilers support versus the decltype proposal.


What decltype?



 > The
 > possible use of the name 'typeof' has basically been killed because of existing
 > "non-interfering" extensions.


I can't find any typeof keyword in the current C++/CLI draft.



 >  Anything that C++ might do will have to consider
 > its impact on existing code--code which might include extensions such as CLI
 > syntax.


Well it could have been "managed extensions" MS-specific syntax. And
finally, we need a standardised syntax for interaction with CLI machines.



 >  The CLI effectively commandeers all of the "non-interfering" syntax
 > (etc.) extensions and limits the breathing room that C++ has for future
 > extension.


I do not think so. The pluses of C++/CLI (which *is* needed) outperform
the minuses. Not to mention that C++/CLI is very clean syntax, it does
not get in the way of ISO C++code the way that managed extensions do.


Using VC++ Express Beta 1 I got my first hello world program being
binary (and source when Mono gets a C++ compiler) portable in both Linux
and Windows.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Ioannis Vranos <ivr@guesswh.at.grad.com> wrote in message news:<cf8u6j$1haq$1@ulysses.noc.ntua.gr>...
 > Nicola Musatti wrote:
[...]
 > > One thing is to standardize an API for CLI, another is to require
 > > changes to the standard
 >
 > What changes to the standard? As it has been mentioned numerous times,
 > C++/CLI is a separate standard than ISO C++, and it defines *extensions*
 > to ISO C++.
 >
 > ISO C++ remains unchanged.

You are forgetting the fast track process. It appears very likely that
as soon as the ECMA standard is ratified, it will be submitted to ISO.
Due to the fast track thing, it is also likely that C++/CLI will
become an ISO standard *before* the next ISO C++ standardization round
is over.

Is it likely that, at that point, the C++ committee will not take
C++/CLI into account? The net result is that decision that should have
pertained to the C++ committee will have been taken by others.

[...]
 > > Do the changes to language envisioned by the C++/CLI

 >
 > There are no changes to the language, since ISO C++ remains unchanged
 > and ISO C++ code also compiles in a CLI VM.

See above.

 > > cater for similar
 > > needs of other platforms? Should anybody decide to define a binding
 > > to, say, the JVM, will it require a different, non compatible set of
 > > changes?
 > >
 > > I suspect that the answer is currently "nobody knows". As such I would
 > > have much prefered a library like interface to the CLI than the
 > > current core language based approach.
 >
 > Yes however C++/CLI has low level access to CLI that couldn't be
 > possible through a library.

Can you provide an example? Personally I don't think I have
encountered such a thing.

 > Also I do not like exotic libraries myself, but only those that can be
 > built using the current "language".

If you have to access entities whose semantics are not supported by
the language, there's little choice.

Cheers,
Nicola Musatti

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Andrei Alexandrescu \(See Website for Email\)" <SeeWebsiteForEmail@moderncppdesign.com> wrote in message news:<2nni1iF2mvouU1@uni-berlin.de>...
 > "Hans-J. Boehm" <Hans_Boehm@hp.com> wrote in message
 > news:1178a29f.0408071644.3fc6bcd8@posting.google.com...
 > > And some lock implementations seem to handle contention as well as
 > > some lock-free schemes (which are also prone to excessive
 > > cache-coherency traffic with high contention).  See my PODC paper
 > > (cited earlier in this thread) for some sample measurements.
 >
 > Now that we got to this point, I've always meant to ask you: what do you
 > think of Maged Michael's Scalable Lock-Free Dynamic Memory Allocation at
 > PLDI 2004 (http://www.research.ibm.com/people/m/michael/pldi-2004.pdf)? It
 > seemed to me that it scales better than any other approaches. (Congrats for
 > the award by the way :o).)
 >
Thanks.

I really liked Michael's paper.  I think it's a very nice approach.
Even
aside from the performance and scalability issues, I think there's a
lot
to be said for a lock-free, and hence async-signal-safe malloc.

But I believe his algorithm still requires two atomic operations per
allocation.  Thus I still don't believe it would be faster than a
fairly standard garbage-collecting allocator for sufficiently small
objects.

Hans

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Ioannis Vranos wrote:
> 
> Tommy McDaniel wrote:
> 
> > I have been talking about when C++ itself is changed to incorporate
> > Microsoft's crap. I am just about tired of saying that.
> 
> Can you provide an example of such a case?
> 

I guess Tommy was talking about something that is yet to happen, in
respect to the /standard C++/ (more general examples abound, though
I would replace the word "crap" with "features").

There is C++ and then there is C++/CLI.  The former is to a high degree
platform-neutral and universal, the latter will be heavily affected
by decisions favouring one single platform (namely CLI).  Yes, CLI
is a platform to me, because I could never reasonably expect it
to be implemented on /all/ of 5 or 6 non-MS operating systems on which
I've used C++; much less would I have a /need/ for that to happen.

C++/CLI is very likely to have a reciprocal effect on C++, one way or
the other (e.g. by direct inclusion of its parts into standard C++,
by inhibiting the development of certain aspects C++, by creating
a parallel culture and market, etc.)

Is it really that hard to see that some of the above is very
undesirable to those amongst us who do not want CLI?

Denis

Nicola Musatti wrote:
> Is it likely that, at that point, the C++ committee will not take
> C++/CLI into account?

Well, that's up to them, isn't it? You yourself could join and
act to prevent this, if you like.

> The net result is that decision that should have pertained to the
 > C++ committee will have been taken by others.

"Should have"? The C++ committee has no power to prevent others from
extending the language, or assuming control over attempts to do so.
Not only that, it's apparent from your two statements I quoted that
you believe that had it been in the power of the committee to act on
these decisions, you would favor that the extensions be denied. In no
case would there have been a C++/CLI standard established in a timely
manner. Microsoft has walked a fine line between unilaterally deciding
what they need, and acting as a good public citizen in making the
specifications available as a standard so that interoperability and
stability are assured.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Denis Remezov wrote:

> I guess Tommy was talking about something that is yet to happen, in
> respect to the /standard C++/ (more general examples abound, though
> I would replace the word "crap" with "features").
> 
> There is C++ and then there is C++/CLI.  The former is to a high degree
> platform-neutral and universal, the latter will be heavily affected
> by decisions favouring one single platform (namely CLI).  Yes, CLI
> is a platform to me, because I could never reasonably expect it
> to be implemented on /all/ of 5 or 6 non-MS operating systems on which
> I've used C++; much less would I have a /need/ for that to happen.


Yes CLI is a platform. However how can C++/CLI affect ISO C++ more than 
if it was not standardised? My point is that the effect would be the 
same standardised or not.


And I prefer open standards to proprietary. And if something 
standardised is proved to become popular,  then of course it will affect 
ISO C++ anyway (proprietary or not).




> C++/CLI is very likely to have a reciprocal effect on C++, one way or
> the other (e.g. by direct inclusion of its parts into standard C++,
> by inhibiting the development of certain aspects C++, by creating
> a parallel culture and market, etc.)


How will this happen if C++/CLI remains unpopular? How would this 
avoided if it was proprietary and became popular?






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Le Chaud Lapin wrote in message news:<fc2e0ade.0407131134.c322501@posting.google.com>...
> I am reading a thread running concurrently about CLI, and I have very
> much trouble figuring out why anyone would want to perturb a language
> like C++ with things like gcnew, etc.
> 
> Is garbage collection necessary?  Is it a problem we should even
> solving by extending the entire language?
> 


First of all, I used to programm in GC environments, but I do not like
the idea of GC in C++. C++ destructors are very natural to me. And
smart ptrs solve most of the problems. Moreover, different tools exist
to check for unallocated memory. But GC can be useful too, sometimes
it even better as alredy mentioned in this thread, and many people
will appreciate it. If somebody wants to have GC in C++ Standard then
only compiler writers will get a headache! But usually they write
compilers not for free, don't they? Why does somebody have to use
feature, if he don't want to?

For instance, there is very useful feature in C++. Exceptions. Everone
should use them, right? But one of our target compilers does not
support them. And we do not use them. The same about partial
specialization.

But. There is another point why I agree with any changes in C++ to
make it compatible with MS .Net: I just like C++.

And I see that a lot of coding is beeing done in C++ for Windows.
Still.

I used to programm in Object Pascal a lot, but I see that C# lacks a
lot of features C++ has, and I do not want to lose ability to code in
C++ as many other developers already did!
And either C++ will be natural .Net language or I will have to write
in another language (what I already do for ASP.NET coding).


Regards,
Vyacheslav Lanovets
Topcon Positioning Systems

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Paul Mensonides wrote:
> As has also been mentioned, it restricts what C++ might do in the future.

So? If the extensions prove so popular that future C++ needs to at least
stay out of their way, then that is a success that should be cheered.

Avoiding change because of potential conflict with a possible future version
is a loser's game. *Every* extension will conflict with some possible future
version, so abiding by such a restriction would result in no extensions ever.
I understand that this is exactly what some people want, but that's not going
to stop the others.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<gd_Rc.4265$K82.3083@trndny01>...
> Nicola Musatti wrote:
>  > It is still an explicit action in many cases, even though I agree that
>  > it's much more convenient to be able to write
>  >
>  > delete this_very_complex_data_structure;
>  >
>  > (usually spelt as "p = NULL" or something like that) rather than
>  > having to follow all pointers to the leaf nodes and recursively delete
>  > each node. Even a careful use of destructors doesn't beat the solution
>  > above.
> 
> No, you appear to have misunderstood. In the case of writing 'p = NULL;'
> you are declaring that your 'p' no longer needs access to the thing it
> was pointing at. This does not make any claims about any other part of
> the program that might still be pointing at the same thing. On the other
> hand, writing 'delete p' makes the far stronger claim that no other part
> of the program needs the thing that p was pointing at. It is far easier
> to get the former and local claim correct than the latter and global one.

I'm aware of this. I just assumed (without mentioning it, I admit)
that I was referring to the last live pointer pointing to a data
structure.

Note that the increased safety of GC has a downside too: in order to
insure that a structure may be claimed by the GC you have to make sure
that all pointers to it either went out of scope or were explicitly
set to NULL (or, recursively, belonged to a structure for which either
of the two condition holds).

I'm convinced that in practice this does not result in very complex
bookkeeping, but it only takes missing one pointer to waste memory.

Cheers,
Nicola Musatti

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Ioannis Vranos <ivr@guesswh.at.grad.com> writes:

>  > As has also been mentioned, it restricts what C++ might do in the future.  The
>  > syntactic extensions may not conflict with current C++, but they could limit the
>  > possible directions that C++ might take in the future.
>
>
> Still many members of ISO C++ committee participate in C++/CLI committee
> and there is cooperation between ISO C++ committee and C++/CLI one.

Not much so far.  C++/CLI is being standardized at such a ferocious
pace that it's very hard for most of the C++ committee members to keep
up.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Nicola Musatti wrote:

> You are forgetting the fast track process. It appears very likely that
> as soon as the ECMA standard is ratified, it will be submitted to ISO.
> Due to the fast track thing, it is also likely that C++/CLI will
> become an ISO standard *before* the next ISO C++ standardization round
> is over.
> 
> Is it likely that, at that point, the C++ committee will not take
> C++/CLI into account? The net result is that decision that should have
> pertained to the C++ committee will have been taken by others.



Ok, they may take C++/CLI into account. And what is wrong with that? 
There are many other standards they also take into account.


>  > Yes however C++/CLI has low level access to CLI that couldn't be
>  > possible through a library.
> 
> Can you provide an example? Personally I don't think I have
> encountered such a thing.


I do not know much C++/CLI, have just started checking it in my free 
time, but in "managed extensions" for example you can create a pin 
pointer to make a managed object to not be moved by the garbage 
collector in the heap and pass it to regular ISO C++ functions which 
take pointers. An example:


#using <mscorlib.dll>


template<class T>

inline void somefun(T *p)
{
  p->x++;
}



__gc struct whatever
{
  int x;

  whatever():x(1) {}
};


int main()
{
  whatever *p=__gc new whatever;

  whatever __pin *r=p;

  somefun(r);
}




In the above, as long as the whatever object is pointed by the pin 
pointer, it cannot be moved by the GC and will not be garbage collected. 
And this pointer can be used in regular ISO C++ functions.


Another example is:


#using <mscorlib.dll>



__value struct whatever
{
  int x;

  whatever():x(1) {}
};


int main()
{
  whatever wobj;

  __box whatever *p=__box(wobj);

}




Deterministic finalisation:


#using <mscorlib.dll>


__gc class whatever
{
  public:
  ~whatever() { }

};


int main()
{
  whatever *p= __gc new whatever;


  delete p;
}



And these in "managed extensions". C++/CLI is far better than managed 
extensions. It provides more simple and clean syntax, separate things 
are kept separate: for example handles and pointers are different 
things, it provides new stuff, mscorlib.dll is not needed for C++/CLI 
code, more powerful control, deterministic destruction with managed 
objects in the *stack*, no need for Dispose definition etc. These things 
are not possible currently with other languages like C#, and some  will 
probably never will like C++/CLI pin_ptr.


ISO C++ and C++/CLI can interoperate more elegantly, cleanly and 
efficiently.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Vyacheslav Lanovets wrote:

 > First of all, I used to programm in GC environments, but I do not like
 > the idea of GC in C++. C++ destructors are very natural to me.



In C++/CLI destructors and finalizers are different things.




 > And
 > smart ptrs solve most of the problems. Moreover, different tools exist
 > to check for unallocated memory. But GC can be useful too, sometimes
 > it even better as alredy mentioned in this thread, and many people
 > will appreciate it. If somebody wants to have GC in C++ Standard then
 > only compiler writers will get a headache! But usually they write
 > compilers not for free, don't they? Why does somebody have to use
 > feature, if he don't want to?



Well C++/CLI is very wise. Managed objects GC pointers are called
handles and are symbolised with ^.


So consider this:


// Usual template function
template<class T>
void somefunc(T *p);



class whatever
{
   // ...
};



ref class managed1
{
   whatever x;
   // ...
};


ref class managed2
{
    whatever *p;
   //...
    public:
    managed2() { p=new whatever; }

//Destructor for deterministic destruction
    ~managed2() { delete p; }

// Finaliser, called at the time of garbage collection
// if destructor is not called.
    !managed2() { delete p; }
};




// ...


// On the GC heap
managed1 ^h=gcnew managed1;


// Deterministic destruction
// *Optional* but possible.
delete h;


// GC object in the stack
// Destroyed at the end of its scope.
// Deterministic destruction.
managed2 m;



h=gcnew managed1;

// Pins the object in the GC heap so as it cannot be moved or garbage
// collected by the garbage collector and thus its address remains the
// same so as it can be used in ISO C++ code, and converts it to a
// regular pointer.
pin_ptr<managed1 *>p=h;

// Possible
managed1 *w=p;


// See the function declaration in the beginning
somefunc(p);



When the pin_ptr object goes out of scope or stops pointing to the
managed object, then the GC can move the object or garbage collect it.



So ISO C++ and C++/CLI can be used combined without interfering with
each other, and interoperating with each other!






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Ben Hutchings wrote:
 > Andreas Huber wrote:
 >> To me, the decision of some Python implementations to use a mixture
 >> of refcounting and GC looks like a mistake.
 >>
 >&