C++ standard
best...@gmail.com
Java is same on every platform. If I write a java compiler or JVM, I
HAVE to confirm to java standard. IMHO it has helped JAVA to grow.
That's not the case with C++. Code which works perfect on SUN OS sun
CC may not even compile on Linux G++.
I can write my own compiler which does not stick to C++ standard and
still sell it as C++ compiler. (Correct me if I am wrong)
Question 1
Why don't we enforce C++ standard on compilers?
Question 2
C++ is not exactly controlled by one company or person.
Who is expected to control C++?
Is it C++ standard committee? If not why does it not control?
Question 3
Java world has come up with solid concept / specifications like J2EE
(or servlet JSP).
Why C++ committee does not try to setup groups for such technologies
that can help C++ grow?
Question 4
Java C# give solid ready to use standard class framework C++ is far
behind. Why standard for such class framework is missing?
I may have asked many stupid questions. (blame it on lack of C++
skills)
I hope I am not impolite in asking these questions.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jaunty
blessing in disguise. Some compiler really provide very useful
deviation from the standard. Though It all depends on the programmer to
confrom to the standard if you want you code to be portable across
compilers and there are tools which will tell you if your code is not
confirming to standard). There is a C++ standard commitee and most of
the top notch compilers are trying to do there best with every new
release.
> Question 1
> Why don't we enforce C++ standard on compilers?
Since many compilers were out much before the C++ standards was formed
there are lots of disparities between compilers from different vendors.
And lots of code has already been written using compiler and they can
not just change all at once in there version to break all the legacy
code.
> Question 2
> C++ is not exactly controlled by one company or person.
> Who is expected to control C++?
> Is it C++ standard committee? If not why does it not control?
As far as I know the standards commitee is not a single person and it
is represented by lots of C++ gurus from different companies as well as
individuals.
> Question 3
> Java world has come up with solid concept / specifications like J2EE
> (or servlet JSP).
> Why C++ committee does not try to setup groups for such technologies
> that can help C++ grow?
I can say that C++ is a platform and lot of frameworks can be built
upon it. Though some compilers gives there own framework over C++,
standard committe try to keep the standards minimal so that most of the
compilers can support it.
> Question 4
> Java C# give solid ready to use standard class framework C++ is far
> behind. Why standard for such class framework is missing?
There are many ready made framework e.g. boost for C++. Again the same
question that many platform do not require those heavy frameworks so
not a part of standards.
Thanks,
Sanjay
Francis Glassborow
best...@gmail.com writes
>
>
>Java is same on every platform. If I write a java compiler or JVM, I
>HAVE to confirm to java standard. IMHO it has helped JAVA to grow.
Well the name Java belongs to Sun Microsystems so they can control its
use in the context of computers (just as Microsoft can control the use
of 'Windows'). And the consistency isn't quite as good as you seem to
think.
>
>That's not the case with C++. Code which works perfect on SUN OS sun
>CC may not even compile on Linux G++.
Yes, but only if you choose to use extensions. Conforming C++ compiles
everywhere though it might not always have the same results when the
program is run.
>I can write my own compiler which does not stick to C++ standard and
>still sell it as C++ compiler. (Correct me if I am wrong)
Yes, but at least in the UK, if you market it as a compiler for ISO C++
(or BSI C++) you can be dealt with for a breech of the Trade
Descriptions Act.
>
>Question 1
>Why don't we enforce C++ standard on compilers?
Because no one has the authority to do so.
>
>
>Question 2
>C++ is not exactly controlled by one company or person.
>Who is expected to control C++?
>Is it C++ standard committee? If not why does it not control?
No one 'controls' it (and that is true of many other computer languages
such as Fortran) however WG21 is responsible for stating what
constitutes conforming C++ after that it is up to the laws of individual
countries to decide what ot do if a compiler does not conform.
>
>Question 3
>Java world has come up with solid concept / specifications like J2EE
>(or servlet JSP).
>Why C++ committee does not try to setup groups for such technologies
>that can help C++ grow?
Because we do not have the resources to do so even if we thought it
desirable. Have you noticed the problems caused by Java's continual
changes?
>
>Question 4
>Java C# give solid ready to use standard class framework C++ is far
>behind. Why standard for such class framework is missing?
That is a matter of opinion and one that not all of us buy into.
>
>I may have asked many stupid questions. (blame it on lack of C++
>skills)
>I hope I am not impolite in asking these questions.
They were honest questions but as is often the case they reveal quite a
bit about the level of knowledge and understanding (nad not only of C++)
of the questioner.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Alan Griffiths
> Java is same on every platform.
This is not so, but I'll pass over it as not relevant to the main
thrust of your post.
> If I write a java compiler or JVM, I
> HAVE to confirm to java standard. IMHO it has helped JAVA to grow.
>
> That's not the case with C++. Code which works perfect on SUN OS sun
> CC may not even compile on Linux G++.
> I can write my own compiler which does not stick to C++ standard and
> still sell it as C++ compiler. (Correct me if I am wrong)
If you can find paying customers, then yes.
> Question 1
> Why don't we enforce C++ standard on compilers?
Because there is no-one prepared to pay for enforcement. There was a
time that govenments required compilers to be validated against a
standard before being used for their contracts. They decided that the
costs outweighed the benefits.
> Question 2
> C++ is not exactly controlled by one company or person.
> Who is expected to control C++?
> Is it C++ standard committee? If not why does it not control?
The C++ standard is controlled by ISO. The ISO standards committee is
made up of national bodies (e.g. ANSI) representing individual
counties. The national bodies are represented by people that can spare
their time to work on the standard.
ISO is in the business of publishing and maintaining standards not of
enforcing adherence to its standards.
Note that the C++ standards activity is funded largely by individuals
donating their own time and expertise because they think it worthwhile.
A few lucky individuals are actually paid by their employer for their
efforts. In these cases the employer is a vendor of a C++ compiler or
library implementation.
Between family, paying work and other commitments I generally only
manage to passively follow discussions and contribute a couple of days
in a year. I'd love to do more, but unless some benefactor with a
large wallet comes along...
> Question 3
> Java world has come up with solid concept / specifications like J2EE
> (or servlet JSP).
> Why C++ committee does not try to setup groups for such technologies
> that can help C++ grow?
One answer is that this is not the role of ISO.
Another is that creating a standard is an expensive way to develop a
library.
A third is that many of the same people that donate to the standards
effort also contribute to boost.
> Question 4
> Java C# give solid ready to use standard class framework C++ is far
> behind. Why standard for such class framework is missing?
In both cases a single vendor was prepared to fund the development work
- they expected to make money as a result.
The ISO model is very different and, in practice at least, requires
that multiple vendors with very different priorities co-operate.
--
Alan Griffiths
http://www.octopull.demon.co.uk/
http://www.theoverloadset.co.uk/
http://www.accu.org/
Frederick Gotham
> Java is same on every platform. If I write a java compiler or JVM, I
> HAVE to confirm to java standard. IMHO it has helped JAVA to grow.
"have to" or "are encouraged to"?
> That's not the case with C++. Code which works perfect on SUN OS sun
> CC may not even compile on Linux G++.
Hence the terms, "portable code" and "non-portable code".
> I can write my own compiler which does not stick to C++ standard and
> still sell it as C++ compiler. (Correct me if I am wrong)
I could write a Java compiler and sell it as a coffee maker.
> Question 1
> Why don't we enforce C++ standard on compilers?
We don't have a big enough gun.
> Question 2
> C++ is not exactly controlled by one company or person.
> Who is expected to control C++?
> Is it C++ standard committee? If not why does it not control?
C++ is controlled by the C++ programming Standard, and thus by the
keepers of the Standard, the Standard Committee.
> Question 3
> Java world has come up with solid concept / specifications like J2EE
> (or servlet JSP).
> Why C++ committee does not try to setup groups for such technologies
> that can help C++ grow?
There are plenty -- wxWidgets for GUI for example.
> Question 4
> Java C# give solid ready to use standard class framework C++ is far
> behind. Why standard for such class framework is missing?
Elaborate on that. I'm not incredibly familiar with Java, but from what I
know, its "classes" are a watered-down version of C++ classes.
--
Frederick Gotham
Goalie_Ca
best...@gmail.com wrote:
> Java is same on every platform. If I write a java compiler or JVM, I
> HAVE to confirm to java standard. IMHO it has helped JAVA to grow.
>
> That's not the case with C++. Code which works perfect on SUN OS sun
> CC may not even compile on Linux G++.
> I can write my own compiler which does not stick to C++ standard and
> still sell it as C++ compiler. (Correct me if I am wrong)
>
> Question 1
> Why don't we enforce C++ standard on compilers?
VC++ has issues with templates, MS also had issues with their java
implementation but eventually went to court over it IIRC. As far as
embedded systems go i've actually had better luck with c++ than java.
>From what i understand sun is a little too easy to release java certs
to vendors for phones because they want to establish the market.
> Question 2
> C++ is not exactly controlled by one company or person.
> Who is expected to control C++?
> Is it C++ standard committee? If not why does it not control?
Yes, C++ is controlled by a committee. While this slows down its
evolution it eliminates "corporate interest". It is really up to the
vendors to play nicely though.
> Question 3
> Java world has come up with solid concept / specifications like J2EE
> (or servlet JSP).
> Why C++ committee does not try to setup groups for such technologies
> that can help C++ grow?
Well that would be outside of the scope of the committee. While TR1 and
TR2 will have new functionality to make this stuff easier it is really
up to the 3rd party to come up and libraries and applications on their
own. Remember, C++ is a general purpose language.
> Question 4
> Java C# give solid ready to use standard class framework C++ is far
> behind. Why standard for such class framework is missing?
Well... to be honest I don't think it was too high of a priority in
past releases. In fact the next version of C++ will be geared towards
library improvements. Read about TR1 and TR2. For the time being check
out boost as a lot of the functionality is being based on the boost
libraries.
> I may have asked many stupid questions. (blame it on lack of C++
> skills)
> I hope I am not impolite in asking these questions.
Asking questions is good. It gets people to think about things they
have forgotten or assumed. I always like to stir up the pot myself ;)
Walter Bright
> Java is same on every platform. If I write a java compiler or JVM, I
> HAVE to confirm to java standard. IMHO it has helped JAVA to grow.
>
> That's not the case with C++. Code which works perfect on SUN OS sun
> CC may not even compile on Linux G++.
> I can write my own compiler which does not stick to C++ standard and
> still sell it as C++ compiler. (Correct me if I am wrong)
You are correct. C++ is not a trademarked term, but Java is (by Sun).
> Question 1
> Why don't we enforce C++ standard on compilers?
Enforcement of a standard requires:
1) C++ being trademarked
2) A C++ compiler validation procedure endorsed by whoever controls the
C++ trademark
C++ and C++ compilers existed for more than a decade before any C++
standard appeared. It would be unreasonable (and probably impossible) to
legally force existing C++ implementations off the market.
There are several C++ validation suites, but none of them are accepted
or endorsed by the C++ standard committee as official.
That said, C++ compilers steadily get more conformant because of market
pressures.
> Question 2
> C++ is not exactly controlled by one company or person.
> Who is expected to control C++?
> Is it C++ standard committee? If not why does it not control?
The C++ standard committee can only control their C++ standard document.
They can't control anything else because they do not have any trademark
control over the term "C++". Anyone can produce a document claiming to
be a "C++ standard". The only authority the C++ standards committee has
is simple acceptance by the C++ programming community. The day the C++
standards committee stops doing what the C++ programming community wants
is the day the committee ceases to have any relevance or authority.
> Question 3
> Java world has come up with solid concept / specifications like J2EE
> (or servlet JSP).
> Why C++ committee does not try to setup groups for such technologies
> that can help C++ grow?
The C++ committee is composed of unpaid volunteers. The idea is that if
someone feels strongly that something should be done, they should step
up, volunteer, and provide the resources to get it done.
> Question 4
> Java C# give solid ready to use standard class framework C++ is far
> behind. Why standard for such class framework is missing?
> I may have asked many stupid questions. (blame it on lack of C++
> skills)
> I hope I am not impolite in asking these questions.
Not at all. They are good questions. Java and C++ have followed very,
very different language development models and paths to success. It's
interesting and instructive to compare them.
-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
Lally
best...@gmail.com wrote:
> [snip]
> Question 4
> Java C# give solid ready to use standard class framework C++ is far
> behind. Why standard for such class framework is missing?
Actually, you'll notice that C++ apps tend to be 'natural' on the
platform they're implemented in, while Java apps always feel out of
place. That's because the standard class frameworks in Java (swing,
awt) make simplifying assumptions to implement the same APIs across all
the Java platforms.
As someone who's had to make portable Java code work on several
platforms (swt, swing, awt), I assure you that the basic assumption
that every window system works the same is absolutely false. Event
propagation, message handling, widget layering, layout, etc. very quite
a bit between platforms. Everry major platform vendor puts out a C++
API for their system, specifically because it's set up for their
platform. The Java toolkits attempt to approximate their model (e.g.
policies for event propagation, message handling, widget layer, layout,
etc) using the C/C++ API the vendor provides. The gap in between is
usually quite large.
This is why you'll notice that major Java desktop apps have a
compatability list for platforms. As a mac & linux user, I know to
look at those lists before downloading a large Java app.
Usually, that's what people are asking for in a standard class
framework -- something to do a graphical desktop app with. It's been
20+ years of commercial desktop development, so it's a fair question.
Yet you'll notice that there's still plenty of suck in libraries for
desktop app development -- most of them are still happy they figured
out model/view/controller! I don't mean to directly attack java here,
but Java's libraries are well known for their mediocrity. Yes, they've
got quantity, but the quality's never something you talk too much
about.
As for C++, you choose the libraries you want for your task. The truth
is that this works out better 99% of the time, as there are usually
important differences between them that can make or break your project.
Thanks to multiple inhertiance, you can use more than one library in
your application without having some utterly disgusting glue code to
put things together.
On the topic of the language itself -- outside of Visual C++ 6, the
compilers are going to comply with the language for most anything any
non-expert's going to do with it. There are smaller differences that
get in the way here and there, but it usually takes some advanced code
to bring those out. If you don't want to deal with that, just use g++.
kanze
[Just a couple of nits...]
> best...@gmail.com wrote:
[...]
> > Question 1
> > Why don't we enforce C++ standard on compilers?
> Enforcement of a standard requires:
> 1) C++ being trademarked
> 2) A C++ compiler validation procedure endorsed by whoever controls the
> C++ trademark
I suspect that there are legal means other than trademarks which
could also be used. (Which doesn't change your basic point, of
course. C++ doesn't have any of these legal means---Sun ensured
that it had them for Java.)
> > Question 2
> > C++ is not exactly controlled by one company or person.
> > Who is expected to control C++?
> > Is it C++ standard committee? If not why does it not control?
> The C++ standard committee can only control their C++ standard document.
> They can't control anything else because they do not have any trademark
> control over the term "C++". Anyone can produce a document claiming to
> be a "C++ standard".
I think that ISO is trademarked; it is at least protected in
some way, and not just anyone can publish something called an
ISO standard.
But it stops there. If I repackage a K&R C compiler, and claim
that it complies with the ISO C++ standard, ISO isn't going to
take any action. With something that blatant, of course, I may
get into trouble because of various truth in advertising laws.
And some countries may also have specific laws---a DIN standard
has a particular legal status in Germany, for example, and I
believe (although I'm far from sure) that it is illegal for you
to label a product X if there is a DIN standard for X, and you
are not conform. (If this is true, however, the law certainly
isn't enforced. The ISO C++ standard is also a DIN standard, so
technically, it would be illegal to label something a C++
compiler if it didn't support export.)
[...]
> > Question 4
> > Java C# give solid ready to use standard class framework C++ is far
> > behind. Why standard for such class framework is missing?
> > I may have asked many stupid questions. (blame it on lack of C++
> > skills)
> > I hope I am not impolite in asking these questions.
> Not at all. They are good questions. Java and C++ have
> followed very, very different language development models and
> paths to success. It's interesting and instructive to compare
> them.
Since no one else has mentionned it, I will point out one
particular difference, and the consequences. Java rigorously
defines the size and formats of its basic types; C++ doesn't.
The result is that you do have to pay more attention in C++ if
you want to avoid implementation dependencies. Another result
is that an efficient implementation of Java is impossible on
some platforms. C++ tries to permit efficient implementations
on all reasonable hardware. If you have to target that 36 bit
1's complement machine that is still being sold, C++ has a
definite advantage:-).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
jbannon
> Java is same on every platform. If I write a java compiler or JVM, I
> HAVE to confirm to java standard. IMHO it has helped JAVA to grow.
>
> That's not the case with C++. Code which works perfect on SUN OS sun
> CC may not even compile on Linux G++.
> I can write my own compiler which does not stick to C++ standard and
> still sell it as C++ compiler. (Correct me if I am wrong)
Well, you could try! It wouldn't survive very long however. If you
advertise that your compiler is standard-conforming and it isn't then
you can bet you would have very angry customers on your hands as well
as possibly ending up in court on criminal charges depending on the
country you're selling in. Bottom line - it had better do what it says
on the tin.
Aside: I'm not a huge fan of commercial vendors anyway. I use the GCC
which, although not completely conformant for a variety of reasons, is
close enough for my purposes. One of these days I might get myself a
copy of Comeau but that's about as far as I would go.
>
> Question 1
> Why don't we enforce C++ standard on compilers?
>
This has already been covered well enough by Francis and others.
Basically, it's not the job to the Standard comittee to enforce the
standard but to define the language and its basic facilities in
addition to codifying existing practice. What vendors do with that
definition is up to them, but see answers to the first part.
<rest snipped>
There is one really fundamental point of difference between Java and
C++ (besides design philosophy). Like C, C++ is designed to be run on a
variety of hardware platforms whereas Java is designed to be run on a
single "hardware" platform (the JVM). Indeed without the JVM, executing
a Java program would not be possible at all because the language is
intimately tied to the design of the machine. Similar remarks apply to
both J# and C#, escept that here it is the CLI that underpins the
language definition.
Best regards,
Jim Bannon
Walter Bright
> Walter Bright wrote:
>> The C++ standard committee can only control their C++ standard document.
>> They can't control anything else because they do not have any trademark
>> control over the term "C++". Anyone can produce a document claiming to
>> be a "C++ standard".
>
> I think that ISO is trademarked; it is at least protected in
> some way, and not just anyone can publish something called an
> ISO standard.
>
> But it stops there. If I repackage a K&R C compiler, and claim
> that it complies with the ISO C++ standard, ISO isn't going to
> take any action. With something that blatant, of course, I may
> get into trouble because of various truth in advertising laws.
I think ISO could take legal action against someone claiming to have an
"ISO IEC 14882-1998 C++ compiler" that didn't support export. But not a
"C++ compiler".
> And some countries may also have specific laws---a DIN standard
> has a particular legal status in Germany, for example, and I
> believe (although I'm far from sure) that it is illegal for you
> to label a product X if there is a DIN standard for X, and you
> are not conform. (If this is true, however, the law certainly
> isn't enforced. The ISO C++ standard is also a DIN standard, so
> technically, it would be illegal to label something a C++
> compiler if it didn't support export.)
There is the possibility that if one sells a "C++ compiler" that is
actually a vacuum cleaner, one could be prosecuted for fraud. On the
other hand, the absence of any official C++ test suite means that nobody
can prove any C++ compiler to be standards compliant, and I suspect any
legal case against a non-conformant compiler would fall apart on that basis.
Doesn't Sun have some official validation suite for Java?
> Since no one else has mentionned it, I will point out one
> particular difference, and the consequences. Java rigorously
> defines the size and formats of its basic types; C++ doesn't.
> The result is that you do have to pay more attention in C++ if
> you want to avoid implementation dependencies. Another result
> is that an efficient implementation of Java is impossible on
> some platforms. C++ tries to permit efficient implementations
> on all reasonable hardware. If you have to target that 36 bit
> 1's complement machine that is still being sold, C++ has a
> definite advantage:-).
PDP-10's became obsolete years before C++ appeared on the scene. I think
the C++ community would be well served by statements in the Standard
along the lines of "if it's a 32 bit CPU, then int shall be 32 bits,
etc." That would bless current existing practice into something that
could be relied upon.
That said, I believe the single biggest obstacle to C++ library
production is the lack of garbage collection. Every C++ shop seems to
evolve towards its own peculiar methodology to managing memory, meaning
that getting one 3rd party library to play well with another is a big
problem. And then, of course, there's simply the vast amount of effort
expended in any C++ library trying to manage memory. The Boehm
collector, while effective, cannot be relied upon by library vendors
because it isn't part of the standard, making it only useful for
"island" projects.
-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Goalie_Ca
toolkit feels quite "native" on macs . QT is a C++ framework :D
Stephen M. Webb
> [...]
>
> Question 3
> Java world has come up with solid concept / specifications like J2EE
> (or servlet JSP).
> Why C++ committee does not try to setup groups for such technologies
> that can help C++ grow?
C++ is used for far more software than is Java. Perhaps one should
examine what it was about C++ that made it grow and could be applied to
benefit Java?
> Question 4
> Java C# give solid ready to use standard class framework C++ is far
> behind. Why standard for such class framework is missing?
See, C++ is a technology, a tool. Java is a solution. Comparing the
two is much like comparing apples and fruitbaskets.
--smw
abdullah...@lmco.com
> Question 3
> Java world has come up with solid concept / specifications like J2EE
> (or servlet JSP).
> Why C++ committee does not try to setup groups for such technologies
> that can help C++ grow?
There are standard technologies defined by the OMG (Object Managment
Group) that are widely used and have C++ bindings. An example is the
CORBA Component Model (CCM) and CORBA.
For more informaiton on CORBA, please look at:
http://www.cs.wustl.edu/~schmidt/corba-overview.html
> Question 4
> Java C# give solid ready to use standard class framework C++ is far
> behind. Why standard for such class framework is missing?
There are many solid frameworks for C++, however they are not part of
the C++ standard. In particular, one of the most portable C++
frameworks is the ADAPTIVE Communication Environment (ACE). For more
information on ACE please look at:
http://www.cs.wustl.edu/~schmidt/ACE-overview.html
ACE/TAO are widely used in the commercial industry. For a list of some
Companies that are using it, please look at:
http://www.cs.wustl.edu/~schmidt/ACE-users.html
I hope this helps,
Abdul
Lally
Goalie_Ca wrote:
> QT Programs generally turn out pretty well. Of course no generic gui
> toolkit feels quite "native" on macs . QT is a C++ framework :D
The cross-platform toolkits are best left when you know your app:
1. will have little UI work
2. will _certainly_ not require any custom widgets
Custom widget development & debugging on multiple platforms is a real
pain. If it's just a little amount, then it's tolerable. But there's
a low threshold before you're better off writing custom UIs for each
platform.
Qt's ok in most regards, and would be one of my top 3 choices for a
cross-platform UI app.
Walter Bright wrote:
> That said, I believe the single biggest obstacle to C++ library
> production is the lack of garbage collection. Every C++ shop seems to
> evolve towards its own peculiar methodology to managing memory, meaning
> that getting one 3rd party library to play well with another is a big
> problem. And then, of course, there's simply the vast amount of effort
> expended in any C++ library trying to manage memory. The Boehm
> collector, while effective, cannot be relied upon by library vendors
> because it isn't part of the standard, making it only useful for
> "island" projects.
C++ can certainly use more memory management options. But I've been
bitten enough by Java's GC to know it's certainly not a copy-paste
answer. Perhaps a few options that decide which operator new() runs?
GC for some things, Obj-C's autorelease pools for others, STL custom
allocators for others, and normal manual memory mgmt for everything
else.
Bo Persson
"Walter Bright" <wal...@digitalmars-nospamm.com> skrev i meddelandet
news:n6qdneY06LtfOzPZ...@comcast.com...
> kanze wrote:
>
>> Since no one else has mentionned it, I will point out one
>> particular difference, and the consequences. Java rigorously
>> defines the size and formats of its basic types; C++ doesn't.
>> The result is that you do have to pay more attention in C++ if
>> you want to avoid implementation dependencies. Another result
>> is that an efficient implementation of Java is impossible on
>> some platforms. C++ tries to permit efficient implementations
>> on all reasonable hardware. If you have to target that 36 bit
>> 1's complement machine that is still being sold, C++ has a
>> definite advantage:-).
>
> PDP-10's became obsolete years before C++ appeared on the scene.
There are others that are still around, you can buy one if you want
(probably not :-)
http://www.unisys.com/products/mainframes/os__2200__mainframes/index.htm
Don't know about any C++ compiler though.
> I think
> the C++ community would be well served by statements in the Standard
> along the lines of "if it's a 32 bit CPU, then int shall be 32 bits,
> etc." That would bless current existing practice into something that
> could be relied upon.
That's what the int32_t typedef does for C99. Good if available, but
non-portable if the machine happens to be 36-bit.
Bo Persson
Gene Bushuyev
news:n6qdneY06LtfOzPZ...@comcast.com...
> kanze wrote:
>> Walter Bright wrote:
>
> That said, I believe the single biggest obstacle to C++ library
> production is the lack of garbage collection.
And just how exactly would the C++ standard library implementation benefit from
garbage collection?
--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George Orwell
Raoul
Bo Persson wrote :
> "Walter Bright" <wal...@digitalmars-nospamm.com> skrev i meddelandet
> news:n6qdneY06LtfOzPZ...@comcast.com...
> > kanze wrote:
> >
> >> Since no one else has mentionned it, I will point out one
> >> particular difference, and the consequences. Java rigorously
> >> defines the size and formats of its basic types; C++ doesn't.
> >> The result is that [...] an efficient implementation of Java is impossible
> >> on some platforms. C++ tries to permit efficient implementations
> >> on all reasonable hardware. If you have to target that 36 bit
> >> 1's complement machine that is still being sold, C++ has a
> >> definite advantage:-).
> >
> > PDP-10's became obsolete years before C++ appeared on the scene.
>
> There are others that are still around, you can buy one if you want
> (probably not :-)
>
> http://www.unisys.com/products/mainframes/os__2200__mainframes/index.htm
>
Interestingly - in the context of Jame's claim - , Unisys prominently
advertizes Java in the URL above.
James Kanze
> Bo Persson wrote :
>> "Walter Bright" <wal...@digitalmars-nospamm.com> skrev i meddelandet
>> news:n6qdneY06LtfOzPZ...@comcast.com...
>>> kanze wrote:
>>>> Since no one else has mentionned it, I will point out one
>>>> particular difference, and the consequences. Java rigorously
>>>> defines the size and formats of its basic types; C++ doesn't.
>>>> The result is that [...] an efficient implementation of Java is
impossible
>>>> on some platforms. C++ tries to permit efficient implementations
>>>> on all reasonable hardware. If you have to target that 36 bit
>>>> 1's complement machine that is still being sold, C++ has a
>>>> definite advantage:-).
>>> PDP-10's became obsolete years before C++ appeared on the scene.
>> There are others that are still around, you can buy one if you want
>> (probably not :-)
>> http://www.unisys.com/products/mainframes/os__2200__mainframes/index.htm
> Interestingly - in the context of Jame's claim - , Unisys
> prominently advertizes Java in the URL above.
The Unisys mainframes are extremely complex, very high
throughput data processing machines. I can't think of anything
you'd do on the mainframe itself that you'd want to do in Java.
Unisys sells complete systems, however, not just isolated CPU's.
The complete system will include a frontal processor to talk to
terminals, the Internet, and such. This frontal processor is, I
believe, a standard 32 bit Intel chip; at any rate, it certainly
has 8 bit bytes. Doubtlessly, it is this processor where the
Java VM runs. Most likely, of course, they will have extended
it in order to optimize communication and integration with the
mainframe. But the simple Java bean will run on the frontal,
off-loading the more compicated data processing to dedicated
functions (written in C or assembler?) on the mainframe.
--
James Kanze kanze...@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
> kanze wrote:
>> Walter Bright wrote:
>>> The C++ standard committee can only control their C++ standard
document.
>>> They can't control anything else because they do not have any trademark
>>> control over the term "C++". Anyone can produce a document claiming to
>>> be a "C++ standard".
>> I think that ISO is trademarked; it is at least protected in
>> some way, and not just anyone can publish something called an
>> ISO standard.
>> But it stops there. If I repackage a K&R C compiler, and claim
>> that it complies with the ISO C++ standard, ISO isn't going to
>> take any action. With something that blatant, of course, I may
>> get into trouble because of various truth in advertising laws.
> I think ISO could take legal action against someone claiming
> to have an "ISO IEC 14882-1998 C++ compiler" that didn't
> support export. But not a "C++ compiler".
I'm not sure what they could do. I know that they don't take
action in such cases. The ISO trademark/copyright or whatever
legal term is applicable applies to the standard itself. If you
publish a document, and claim it is an ISO standard, when ISO
has nothing to do with it, then I think that they would act. I
don't think they would if you simply Claim conformance with a
real ISO document, no matter how far you stray.
>> And some countries may also have specific laws---a DIN standard
>> has a particular legal status in Germany, for example, and I
>> believe (although I'm far from sure) that it is illegal for you
>> to label a product X if there is a DIN standard for X, and you
>> are not conform. (If this is true, however, the law certainly
>> isn't enforced. The ISO C++ standard is also a DIN standard, so
>> technically, it would be illegal to label something a C++
>> compiler if it didn't support export.)
> There is the possibility that if one sells a "C++ compiler"
> that is actually a vacuum cleaner, one could be prosecuted for
> fraud. On the other hand, the absence of any official C++ test
> suite means that nobody can prove any C++ compiler to be
> standards compliant, and I suspect any legal case against a
> non-conformant compiler would fall apart on that basis.
In the end, it all depends on local laws, and what the jury and
the judge think. Obviously, the more blatant the
misrepresentation, the better case you have. In practice, too,
I think that prevailing practice will generally be taken into
account. If you're the only compiler claiming to be C++, and
not supporting export, I suspect that you would run a risk in
some countries. As we both know, however, that is far from
being the case.
> Doesn't Sun have some official validation suite for Java?
Not that I know of. But since they define the language, and
they hold all rights to it, they can pretty much do what they
want.
>> Since no one else has mentionned it, I will point out one
>> particular difference, and the consequences. Java rigorously
>> defines the size and formats of its basic types; C++ doesn't.
>> The result is that you do have to pay more attention in C++ if
>> you want to avoid implementation dependencies. Another result
>> is that an efficient implementation of Java is impossible on
>> some platforms. C++ tries to permit efficient implementations
>> on all reasonable hardware. If you have to target that 36 bit
>> 1's complement machine that is still being sold, C++ has a
>> definite advantage:-).
> PDP-10's became obsolete years before C++ appeared on the
> scene. I think the C++ community would be well served by
> statements in the Standard along the lines of "if it's a 32
> bit CPU, then int shall be 32 bits, etc." That would bless
> current existing practice into something that could be relied
> upon.
C has gone somewhat in that direction, with its extended
integral types. If a machine supports a 32 bit 2's complement
integer, it is supposed to define "int32_t" in <stdint.h>. And
you can test whether it does or not using something like:
#ifdef INT32_MAX
It sounds like a reasonable compromize to me.
With regards to "if it's a 32 bit CPU, then int shall be 32
bits", would you extend this to 64 bits: "if it's a 64 bit CPU,
then int shall be 64 bits"? Because if so, I know a lot of
implementations which wouldn't be conform: Sun, Microsoft,
g++... In most cases, I'd say that they don't have a choice,
since they want their int to be compatible with the platform's
system API, which usually specifies int to be a 32 bit value.
> That said, I believe the single biggest obstacle to C++
> library production is the lack of garbage collection.
Biggest, I don't know, but the absence of standard solutions for
some very basic problems (like memory management, but also,
historically, strings and such) is definitly a very big
obstacle.
> Every C++ shop seems to evolve towards its own peculiar
> methodology to managing memory, meaning that getting one 3rd
> party library to play well with another is a big problem.
Presumably, the presence of boost::shared_ptr in the next
version of the standard would solve this. Too little, too late,
IMHO (and there is a very good possibility of C++ getting
garbage collection as well).
> And then, of course, there's simply the vast amount of effort
> expended in any C++ library trying to manage memory. The Boehm
> collector, while effective, cannot be relied upon by library
> vendors because it isn't part of the standard, making it only
> useful for "island" projects.
Or by delivering two versions of the library. But then you've
had to solve the problem the hard way anyway.
--
James Kanze kanze...@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Bo Persson
"Raoul" <raould...@hotmail.com> skrev i meddelandet
news:1152433758.4...@p79g2000cwp.googlegroups.com...
>
> Bo Persson wrote :
>
>> "Walter Bright" <wal...@digitalmars-nospamm.com> skrev i
>> meddelandet
>> news:n6qdneY06LtfOzPZ...@comcast.com...
>> > kanze wrote:
>> >
>> >> Since no one else has mentionned it, I will point out one
>> >> particular difference, and the consequences. Java rigorously
>> >> defines the size and formats of its basic types; C++ doesn't.
>> >> The result is that [...] an efficient implementation of Java is
>> >> impossible
>> >> on some platforms. C++ tries to permit efficient
>> >> implementations
>> >> on all reasonable hardware. If you have to target that 36 bit
>> >> 1's complement machine that is still being sold, C++ has a
>> >> definite advantage:-).
>> >
>> > PDP-10's became obsolete years before C++ appeared on the scene.
>>
>> There are others that are still around, you can buy one if you want
>> (probably not :-)
>>
>> http://www.unisys.com/products/mainframes/os__2200__mainframes/index.htm
>>
>
> Interestingly - in the context of Jame's claim - , Unisys
> prominently
> advertizes Java in the URL above.
>
Yes, and no.
These machines will run just about everything, including Windows,
using their (optional) Intel Xeon add-on processors. I bet there is
where the Java code is run as well.
Bo Persson
James Kanze
> "Walter Bright" <wal...@digitalmars-nospamm.com> skrev i meddelandet
> news:n6qdneY06LtfOzPZ...@comcast.com...
>> I think the C++ community would be well served by statements
>> in the Standard along the lines of "if it's a 32 bit CPU,
>> then int shall be 32 bits, etc." That would bless current
>> existing practice into something that could be relied upon.
> That's what the int32_t typedef does for C99. Good if
> available, but non-portable if the machine happens to be
> 36-bit.
I think part of Walter's point was that a lot of C++
applications don't have to be that portable. For a lot of
applications, once you support Windows, Mac, Linux on a PC and
the five mainstream Unix, you've covered well over 99% of your
potential market anyway. And all of these are either 32 bit 2's
complement, or 64 bit 2's complement, but with int a 32 bit
type.
In practice, I don't think any standardization is necessary for
his requirements. The fact is that if it is a 32 bit 2's
complement machine, that's what int will be. The standard may
allow exotic architectures, but it certainly doesn't require an
implementation to go out of its way just to be exotic.
Add to that the possiblity of compile time testing by means of:
#include <stdint.h>
#ifndef INT32_MAX
#error Not supported
#endif
which is present in C99, and will almost certainly be present in
the next version of C++, and I think you've got the best of both
worlds.
--
James Kanze kanze...@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
> best...@gmail.com wrote:
>> Java is same on every platform. If I write a java compiler or JVM, I
>> HAVE to confirm to java standard. IMHO it has helped JAVA to grow.
>> That's not the case with C++. Code which works perfect on SUN OS sun
>> CC may not even compile on Linux G++.
>> I can write my own compiler which does not stick to C++ standard and
>> still sell it as C++ compiler. (Correct me if I am wrong)
> Well, you could try! It wouldn't survive very long however.
A number of companies have tried it: Microsoft, with Visual C++,
Sun, with Sun CC, g++, etc. And they do seem to be surviving.
--
James Kanze kanze...@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Walter Bright
> There are others that are still around, you can buy one if you want
> (probably not :-)
I still have -10 code I wrote in the 70's, and the -10 instruction set
is an engineering marvel. But no, I probably don't want one <g>.
>> I think
>> the C++ community would be well served by statements in the Standard
>> along the lines of "if it's a 32 bit CPU, then int shall be 32 bits,
>> etc." That would bless current existing practice into something that
>> could be relied upon.
>
> That's what the int32_t typedef does for C99. Good if available, but
> non-portable if the machine happens to be 36-bit.
I haven't run across anyone who uses the stdint typedefs, but I do
endlessly see each person/group creating their own workarounds for the
int portability issue. Maybe the problem is inertia.
-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Raoul
> it certainly has 8 bit bytes. Doubtlessly, it is this processor where the
> Java VM runs. Most likely, of course, they will have extended
> it in order to optimize communication and integration with the
> mainframe. But the simple Java bean will run on the frontal,
> off-loading the more compicated data processing to dedicated
> functions (written in C or assembler?) on the mainframe.
Well, as I get it - perhaps wrongly - , Unisys has a native Java VM...
http://www.oetrends.com/news.php?action=view_record&idnum=468
Not that it matters so much where the Java VM runs... The ability of
C++ to support esoteric machine architectures is often pointed out in
this kind of discussions. I was surprised to find out that even on
these machines Java has higher visibility.
Walter Bright
> "Walter Bright" <wal...@digitalmars-nospamm.com> wrote in message
> news:n6qdneY06LtfOzPZ...@comcast.com...
>> kanze wrote:
>>> Walter Bright wrote:
> [...]
>> That said, I believe the single biggest obstacle to C++ library
>> production is the lack of garbage collection.
>
> And just how exactly would the C++ standard library implementation benefit from
> garbage collection?
Managing memory greatly complicates library design. Just look at all the
effort going into <shared_ptr>, for example.
Bo Persson
>> This frontal processor is, Ibelieve, a standard 32 bit Intel chip;
>> at any rate,
>> it certainly has 8 bit bytes. Doubtlessly, it is this processor
>> where the
>> Java VM runs. Most likely, of course, they will have extended
>> it in order to optimize communication and integration with the
>> mainframe. But the simple Java bean will run on the frontal,
>> off-loading the more compicated data processing to dedicated
>> functions (written in C or assembler?) on the mainframe.
>
> Well, as I get it - perhaps wrongly - , Unisys has a native Java
> VM...
>
> http://www.oetrends.com/news.php?action=view_record&idnum=468
>
> Not that it matters so much where the Java VM runs... The ability of
> C++ to support esoteric machine architectures is often pointed out
> in
> this kind of discussions. I was surprised to find out that even on
> these machines Java has higher visibility.
>
It does matter! :-)
When comparing the "silly" restrictions in C++, to enable it to run in
more environments, to Java's "run everywhere", it *is* important to
notice the restrictions Java actually has.
If you go further into the JBoss documentation, you will see that it
runs on top of Red Hat Linux, which in turn supports Intel, AMD, and
IBM processors. This seems to me like it runs on the Xeon part of the
Unisys mainframes, not the 36-bit processors.
On our IBM zSeries mainframes, IBM had to add special Java hardware to
get decent performance in its WebSphere environment. Before they did,
the webserver took more than 50% of the mainframe capacity.
So Java runs everywhere, but might need special hardware support to
get acceptable performance. C++ runs native even on odd hardware, at
the cost of not requiring an int to be 32 bit, two's complement. What
do we prefer?
Bo Persson
Gene Bushuyev
> Gene Bushuyev wrote:
>> "Walter Bright" <wal...@digitalmars-nospamm.com> wrote in message
>> news:n6qdneY06LtfOzPZ...@comcast.com...
>>> kanze wrote:
>>>> Walter Bright wrote:
>> [...]
>>> That said, I believe the single biggest obstacle to C++ library
>>> production is the lack of garbage collection.
>>
>> And just how exactly would the C++ standard library implementation benefit
>> from
>> garbage collection?
>
> Managing memory greatly complicates library design. Just look at all the
> effort going into <shared_ptr>, for example.
So you believe shared_ptr, which wasn't even part of the std library, is the
only example of what you mentioned as "the single biggest obstacle?" Even though
it comprises a very small percentage of standard library + TR1 code and not used
in implementation of any other library facility? And if implementation of
shared_ptr "greatly complicates library design," what would we say about
implementation of garbage collection? And finally, since shared_ptr is there in
the library, is GC still "the single biggest obstacle?"
Let me also note, the idea of shared ownership that shared_ptr implements is not
that commonly used or needed. Shared ownership comes with costs, such as heavy
and slow pointers. In some cases it doesn't matter, in other cases it makes
shared_ptr unusable. And just like GC, it can be easily abused by novices adding
to a world wide heap of poor designs.
--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George Orwell
kanze
> Gene Bushuyev wrote:
> > "Walter Bright" <wal...@digitalmars-nospamm.com> wrote in message
> > news:n6qdneY06LtfOzPZ...@comcast.com...
> >> kanze wrote:
> >>> Walter Bright wrote:
> > [...]
> >> That said, I believe the single biggest obstacle to C++ library
> >> production is the lack of garbage collection.
> > And just how exactly would the C++ standard library
> > implementation benefit from garbage collection?
> Managing memory greatly complicates library design. Just look
> at all the effort going into <shared_ptr>, for example.
Even worse is the lack of a standard memory management idiom.
What do you do as a library implementor, just return a raw
pointer, document who is responsible for what, and hope for the
best? Implement your own, in house smart pointers, and impose
these on the user? (Lots of fun for the user if he has three or
four libraries that take this path.) Impose the Boehm garbage
collector?
Technically, the last is about the only reasonable solution.
Commercially, however, it probably poses a few problems.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
[...]
> I haven't run across anyone who uses the stdint typedefs, but
> I do endlessly see each person/group creating their own
> workarounds for the int portability issue. Maybe the problem
> is inertia.
Definitly. Not all C compilers are conform to C99 yet, so
portability is also a problem. (I do use the stdint typedef's,
but I also maintain my own copy of stdint.h, in case I run into
a compiler which doesn't have it. Which is the case for both
Sun cc and gcc under Solaris, and VC++ 2005 under Windows.)
Generally speaking, there seems to be absolutely no demand from
the C community to move to C99. The C++ community is more
progressive, and hopefully, once <cstdint> is part of the C++
standard, there will be pressure on compiler vendors to provide
it.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
marius lazer
> And just like GC, it can be easily abused by novices adding
> to a world wide heap of poor designs.
So do you really mean that COMPETENCY counts?
Kidding aside, quality of designs/implementations does not come from
the language. I personally prefer C++ over Java because of obvious
power and flexibility advantage. None offer 100% portability (when Sun
says "write once - run anywhere", to pros it really means "write once -
test everywhere").
My 2 Cents,
Marius Lazer (mar...@lazertech-inc.com)
marius lazer
> Doesn't Sun have some official validation suite for Java?
Not as far as I know (Sun owns it so they do whatever they want). On
the other hand there are unofficial test suites for C++ that few
compilers pass (BTW, no Sun C++ compiler passes): boost (www.boost.org)
and the much stricter Loki (sourceforge.net/projects/loki-lib).
Marius Lazer (mar...@lazertech-ic.com)
Goalie_Ca
> Beratung in objektorientierter Datenverarbeitung
> 9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
Returning a std::auto_ptr is a nice way of saying <<you take over the
resource!>>. Sharedpointers are nice for sharing. Weak pointers are
like being a passenger and have someone else drive. I don't see any
advantage of using Boehm GC over making use of smart pointers. The only
problem i have is that a standard is useless if no one follows it.
loufoque
> Even worse is the lack of a standard memory management idiom.
> What do you do as a library implementor, just return a raw
> pointer, document who is responsible for what, and hope for the
> best? Implement your own, in house smart pointers, and impose
> these on the user? (Lots of fun for the user if he has three or
> four libraries that take this path.) Impose the Boehm garbage
> collector?
The standard way is probably to return the object by value to let it be
automatically managed on the 'automatic memory' (the stack).
Earl Purple
Walter Bright wrote:
>
> Managing memory greatly complicates library design. Just look at all the
> effort going into <shared_ptr>, for example.
That it is a library and not part of the standard can obviously make it
less portable. Can I always guarantee that my implementation of
shared_ptr will be identical to yours if, say, I write a library that
produces objects and returns them as shared_ptr, with their custom
deleter neatly thrown in.
And while your shared_ptr may be the same as mine now, what happens
when new-improved shared_ptr comes along? That might break existing
code in that situation. (Probably would). It's not limited to
shared_ptr, of course. I can't even get my libraries to return a
std::string. But then I guess C++ has no concept of a library.
So yes, the only safe option is to give you my own shared_ptr which I
can say for certain will not change as long as you are using this
particular library.
Now the solution here is for shared_ptr to come with a "detach"
function - of course it would have to detach the deleter too, but it
would mean you could transfer the pointer (and its deleter) from one
shared_ptr to a different implementation of a shared_ptr.
In fact I can have my own shared_ptr library do that. So you have my
shared_ptr with my libraries but then when you get the objects you can
detach the pointers and deleters and transfer them across to your own
shared_ptrs (most likely the latest version of the boost or tr1) for
all your own code.
Of course, you have to call detach() with caution as my shared-pointer
would no longer have any responsibility for it.
Now if boost's (or tr1's) shared_ptr also came with a detach() function
it would be useful. Because then I could also work with whatever
version of boost/tr1 shared_ptr I have on my own side, then simply
convert them to the custom shared_ptr for portability, then you convert
back.
kanze
> Returning a std::auto_ptr is a nice way of saying <<you take
> over the resource!>>. Sharedpointers are nice for sharing.
> Weak pointers are like being a passenger and have someone else
> drive. I don't see any advantage of using Boehm GC over making
> use of smart pointers.
Except that you just explained it. Each time you use a pointer,
you have to think about which type of pointer. It's added work.
Most of the time, it's not really difficult, but it is still one
additional thing you have to think about. And every once in
awhile, a case occurs where it really isn't obvious, and it
requires considerable thought.
> The only problem i have is that a standard is useless if no
> one follows it.
Which, I agree, is the biggest problem here. When I write all
of the code myself, I use the Boehm collector; why make things
harder than necessary. But as soon as third party libraries are
involved, you have to start being careful.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
> kanze wrote :
> > Even worse is the lack of a standard memory management
> > idiom. What do you do as a library implementor, just return
> > a raw pointer, document who is responsible for what, and
> > hope for the best? Implement your own, in house smart
> > pointers, and impose these on the user? (Lots of fun for
> > the user if he has three or four libraries that take this
> > path.) Impose the Boehm garbage collector?
> The standard way is probably to return the object by value to
> let it be automatically managed on the 'automatic memory' (the
> stack).
When you can. It doesn't work for entity objects, which can't
be copied, and it doesn't work for anything polymorphic. It
can also cause performance problems for large collections---the
copy constructor for an std::list<std::string> with over 50000
elements is not going to be instantanious.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Walter Bright
> With regards to "if it's a 32 bit CPU, then int shall be 32
> bits", would you extend this to 64 bits: "if it's a 64 bit CPU,
> then int shall be 64 bits"? Because if so, I know a lot of
> implementations which wouldn't be conform: Sun, Microsoft,
> g++... In most cases, I'd say that they don't have a choice,
> since they want their int to be compatible with the platform's
> system API, which usually specifies int to be a 32 bit value.
Interesting that you bring that up. Existing practice for 64 bit C++
compilers is to still make the int 32 bits - for portability reasons.
My suggestion was for standardizing common existing practice, not
breaking it.
>> That said, I believe the single biggest obstacle to C++
>> library production is the lack of garbage collection.
>
> Biggest, I don't know, but the absence of standard solutions for
> some very basic problems (like memory management, but also,
> historically, strings and such) is definitly a very big
> obstacle.
The historical string class problem (everyone inventing their own string
class) had its roots in lack of GC. Note that none of the GC languages
have a problem with string classes.
>> Every C++ shop seems to evolve towards its own peculiar
>> methodology to managing memory, meaning that getting one 3rd
>> party library to play well with another is a big problem.
> Presumably, the presence of boost::shared_ptr in the next
> version of the standard would solve this.
> Too little, too late,
I tend to agree, it's hard to imagine all that legacy C++ code being
redesigned. Or even a small percentage of it.
> IMHO (and there is a very good possibility of C++ getting
> garbage collection as well).
C++ should have acquired GC about 15 years ago. I think your comment
about too little, too late applies to that as well. Even if GC were
adopted, how many years would it be before it diffuses through to all
the C++ platforms out there? 10 years?
>> And then, of course, there's simply the vast amount of effort
>> expended in any C++ library trying to manage memory. The Boehm
>> collector, while effective, cannot be relied upon by library
>> vendors because it isn't part of the standard, making it only
>> useful for "island" projects.
>
> Or by delivering two versions of the library. But then you've
> had to solve the problem the hard way anyway.
That's right. And even if the Standard adopts GC, there are a lot of C++
programmers who use C++ because it doesn't have GC, and so will not use
GC. A library vendor would have to accommodate that.
-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Walter Bright
> "Walter Bright" <wal...@digitalmars-nospamm.com> wrote in message
> news:kqOdnSTKWYjl8SzZ...@comcast.com...
>> Gene Bushuyev wrote:
>>> "Walter Bright" <wal...@digitalmars-nospamm.com> wrote in message
>>> news:n6qdneY06LtfOzPZ...@comcast.com...
>>>> kanze wrote:
>>>>> Walter Bright wrote:
>>> [...]
>>>> That said, I believe the single biggest obstacle to C++ library
>>>> production is the lack of garbage collection.
>>> And just how exactly would the C++ standard library implementation benefit
>>> from
>>> garbage collection?
>> Managing memory greatly complicates library design. Just look at all the
>> effort going into <shared_ptr>, for example.
>
>
> So you believe shared_ptr, which wasn't even part of the std library, is the
> only example of what you mentioned as "the single biggest obstacle?"
No, I meant it as illustrative of the difficulty and effort required to
design memory management into C++ library components. GC doesn't
eliminate memory management issues, but it does substantially simplify
code and greatly increases the interoperability of disparate libraries.
-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Walter Bright
> Generally speaking, there seems to be absolutely no demand from
> the C community to move to C99.
That shouldn't be surprising. The C programmers who want new features
moved to C++ or D.
-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Chris Hills
<wal...@digitalmars-nospamm.com> writes
>kanze wrote:
>> Generally speaking, there seems to be absolutely no demand from
>> the C community to move to C99.
>
>That shouldn't be surprising. The C programmers who want new features
>moved to C++ or D.
If there is a C++ compiler for the platform in question it would be
better to move to C++ than add things to C.
However in the embedded world where for many platforms there is no C++
compiler there has been an equal lack of enthusiasm to rush to C99.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
James Kanze
> James Kanze wrote:
>> With regards to "if it's a 32 bit CPU, then int shall be 32
>> bits", would you extend this to 64 bits: "if it's a 64 bit
>> CPU, then int shall be 64 bits"? Because if so, I know a lot
>> of implementations which wouldn't be conform: Sun, Microsoft,
>> g++... In most cases, I'd say that they don't have a choice,
>> since they want their int to be compatible with the
>> platform's system API, which usually specifies int to be a 32
>> bit value.
> Interesting that you bring that up. Existing practice for 64
> bit C++ compilers is to still make the int 32 bits - for
> portability reasons.
I'm not sure that portability is the only, or even the major
reason. Vendors want to support what the hardware allows;
modern 64 bit hardware has no trouble with integer values of 8,
16, 32 and 64 bits. If you make int 64 bits, and char 8, how do
you support both 16 and 32 bit ints; you've only got one type
available between char and int.
Also, 32 bits is more than enough for a lot of uses. (16
isn't.) Why should people use more memory when they don't need
it?
> My suggestion was for standardizing common existing practice,
> not breaking it.
In practice, if it's existing practice, it is standardized. Do
you know of any 32 bit machine where int isn't 32 bits?
>>> That said, I believe the single biggest obstacle to C++
>>> library production is the lack of garbage collection.
>> Biggest, I don't know, but the absence of standard solutions
>> for some very basic problems (like memory management, but
>> also, historically, strings and such) is definitly a very big
>> obstacle.
> The historical string class problem (everyone inventing their
> own string class) had its roots in lack of GC. Note that none
> of the GC languages have a problem with string classes.
GC would certainly have given a "standard" option: char*.
>>> Every C++ shop seems to evolve towards its own peculiar
>>> methodology to managing memory, meaning that getting one 3rd
>>> party library to play well with another is a big problem.
>> Presumably, the presence of boost::shared_ptr in the next
>> version of the standard would solve this.
>> Too little, too late,
> I tend to agree, it's hard to imagine all that legacy C++ code
> being redesigned. Or even a small percentage of it.
Agreed. For new code, boost::shared_ptr is better than nothing,
but it's not enough improvement to warrent redesigning your
application to take advantage of it. GC is. (Just MHO, of
course.)
>> IMHO (and there is a very good possibility of C++ getting
>> garbage collection as well).
> C++ should have acquired GC about 15 years ago.
I don't know about "15 years ago". Garbage collection
technology back then wasn't nearly as mature as it is now. But
the C++ standard isn't 15 years old. And somewhere about 10
years ago (give or take a year or two), the technology did
become mature enough.
> I think your comment about too little, too late applies to
> that as well. Even if GC were adopted, how many years would
> it be before it diffuses through to all the C++ platforms out
> there? 10 years?
There, you've hit a sensitive point with me. If garbage
collection takes as long as export, I won't see it before I'm
retired.
Hopefully, in the case of GC, there will be significant market
pressure. And the presence of a freely available implementation
will doubtlessly help too---I would be surprised if g++ didn't
have it within a couple of years after its being adopted, for
example. (MS seems to favor it as well. And once both MS and
g++ have it...)
>>> And then, of course, there's simply the vast amount of effort
>>> expended in any C++ library trying to manage memory. The Boehm
>>> collector, while effective, cannot be relied upon by library
>>> vendors because it isn't part of the standard, making it only
>>> useful for "island" projects.
>> Or by delivering two versions of the library. But then you've
>> had to solve the problem the hard way anyway.
> That's right. And even if the Standard adopts GC, there are a
> lot of C++ programmers who use C++ because it doesn't have GC,
> and so will not use GC. A library vendor would have to
> accommodate that.
I'm not sure. There are already a lot of things that library
vendors don't accommodate. But you're right that it is a risk.
--
James Kanze kanze...@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Walter Bright
> Also, 32 bits is more than enough for a lot of uses. (16
> isn't.) Why should people use more memory when they don't need
> it?
Why, indeed. I can't see making int 64 bits even if the CPU is 64 bits.
> > My suggestion was for standardizing common existing practice,
> > not breaking it.
> In practice, if it's existing practice, it is standardized. Do
> you know of any 32 bit machine where int isn't 32 bits?
Nope. But I *do* see a lot of worrying about it, and effort expended
attempting to immunize one's source code against the possibility that
int may be 35 bits. By standardizing existing practice, all that worry
would be eliminated.
> GC would certainly have given a "standard" option: char*.
And std::string goes out the window <g>, bringing us full circle on what
to do with strings. I find it ironic you say that. In D, strings are
char[] (arrays of chars). Lots of people coming to D from other
languages say "where's the string class?" Turns out that the existence
of GC makes a string class largely irrelevant.
> >> IMHO (and there is a very good possibility of C++ getting
> >> garbage collection as well).
>
> > C++ should have acquired GC about 15 years ago.
>
> I don't know about "15 years ago". Garbage collection
> technology back then wasn't nearly as mature as it is now. But
> the C++ standard isn't 15 years old.
The first standard (the ARM) is 15 years old, + or -.
Gene Bushuyev
[...]
> The historical string class problem (everyone inventing their own string
> class) had its roots in lack of GC. Note that none of the GC languages
> have a problem with string classes.
This historical problem is an old history. It was the case before the standard
library was adopted. I haven't seen anybody writing their own string class for
years. I have seen people creating their own string classes for specific
purposes. For example, I have a static_string in my collection for fast strings
located on stack, which also works seemlessly with std::string and algorithms.
I also don't see how string class is related to GC. Do you need GC to implement
std::string? No. How can GC possibly be used in something like static_string? It
can't. On the other hand, if you look at Visual C++, which has GC, there are at
least 3 string classes available. The best of all of them is still std::string.
The "modern" VC++ extensions all look like a saddle on a cow. All those other
modern languages with GC are actually way behind C++ in their language designs,
and they need a GC crutch to deal with their data model.
[...]
> C++ should have acquired GC about 15 years ago. I think your comment
> about too little, too late applies to that as well. Even if GC were
> adopted, how many years would it be before it diffuses through to all
> the C++ platforms out there? 10 years?
Probably never. And the reason that there is no GC neither in the C++ Standard
nor as a typical extension is the lack of demand. Good C++ practices tend to
produce the objects with automatic storage duration. Resourse management is done
in ctor/dtor, which is robust, flexible and deterministic.
--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George Orwell
James Kanze
> James Kanze wrote:
>> Also, 32 bits is more than enough for a lot of uses. (16
>> isn't.) Why should people use more memory when they don't need
>> it?
> Why, indeed. I can't see making int 64 bits even if the CPU is
> 64 bits.
Supposing, of course, that there isn't a significant time
penalty in doing otherwise.
>>> My suggestion was for standardizing common existing practice,
>>> not breaking it.
>> In practice, if it's existing practice, it is standardized. Do
>> you know of any 32 bit machine where int isn't 32 bits?
> Nope. But I *do* see a lot of worrying about it, and effort
> expended attempting to immunize one's source code against the
> possibility that int may be 35 bits. By standardizing existing
> practice, all that worry would be eliminated.
Yes and no. I worry about it in code which has to be 100%
portable. But since there are CPU's with 36 bits, I think it's
justified. I don't worry about it most of the time. I do try
to use int32_t when I think it would make a difference. But
since all of the platforms I have ready access to have 32 bit
ints, if I've missed a case or two, I won't notice it.
>> GC would certainly have given a "standard" option: char*.
> And std::string goes out the window <g>, bringing us full
> circle on what to do with strings.
I disagree. There is functionality in std::string (or some
other string class) which isn't in char*. A string of text has
a specific semantic that is different from that of an array of
char.
> I find it ironic you say that. In D, strings are char[]
> (arrays of chars). Lots of people coming to D from other
> languages say "where's the string class?" Turns out that the
> existence of GC makes a string class largely irrelevant.
It depends on what char[] supports. Java has java.lang.String,
for example. Whether it is a "user defined class", as in C++,
special semantics assigned to char[], or something in between,
as in Java (where java.lang.String has a lot of features which
you simply cannot emulate in a normal class) doesn't matter too
much---when all is said and done, I think I prefer the "build in
type" solution.
>>>> IMHO (and there is a very good possibility of C++ getting
>>>> garbage collection as well).
>>> C++ should have acquired GC about 15 years ago.
>> I don't know about "15 years ago". Garbage collection
>> technology back then wasn't nearly as mature as it is now. But
>> the C++ standard isn't 15 years old.
> The first standard (the ARM) is 15 years old, + or -.
OK. But as I said, I think that when the ARM was published,
there were still legitimate arguments against garbage
collection. It may or may not have been the "right" decision,
but it was certainly a defendable decision then.
But that was then:-).
--
James Kanze kanze...@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
James Kanze
> "Walter Bright" <wal...@digitalmars-nospamm.com> wrote in message
> news:m9GdnQiIO9kwHSrZ...@comcast.com...
> [...]
>> The historical string class problem (everyone inventing their
>> own string class) had its roots in lack of GC. Note that none
>> of the GC languages have a problem with string classes.
> This historical problem is an old history. It was the case
> before the standard library was adopted. I haven't seen
> anybody writing their own string class for years.
For how many years? As little as five years ago, it was still a
real problem. And in practice, software, and especially
software interfaces, has a very long lifetime. You defined the
interface 15 years ago; it obviously didn't use std::string.
But you're still stuck with it.
> I have seen people creating their own string classes for
> specific purposes. For example, I have a static_string in my
> collection for fast strings located on stack, which also works
> seemlessly with std::string and algorithms.
> I also don't see how string class is related to GC.
It's not, directly. The problem is one of having a standard
solution to a general problem. Both representing strings and
managing memory are general problems. Both lacked a standard
solution until recently; managing memory still lacks one. So
every library reinvented the wheel, in an incompatible way.
> Do you need GC to implement std::string?
It would allow implementations with better performance. But
it's true that std::string's interface (e.g. requiring [] to
return a reference) is somewhat limiting with regards to
possible gains anyway.
> No. How can GC possibly be used in something like
> static_string?
Actually, it could simplify making static_string compatible with
standard strings, since it would mean you could use exactly the
same memory management code in both.
> It can't. On the other hand, if you look at Visual C++, which
> has GC, there are at least 3 string classes available. The
> best of all of them is still std::string. The "modern" VC++
> extensions all look like a saddle on a cow. All those other
> modern languages with GC are actually way behind C++ in their
> language designs,
For some things. C++ is behind them for others.
> and they need a GC crutch to deal with their data model.
Hardly a crutch. Just a tool to make programmers more
efficient. Obviously, you can write working code without it;
you can also write working code without classes, templates or
inheritance. They're all tools which make the programmer's life
easier.
> [...]
>> C++ should have acquired GC about 15 years ago. I think your
>> comment about too little, too late applies to that as well.
>> Even if GC were adopted, how many years would it be before it
>> diffuses through to all the C++ platforms out there? 10
>> years?
> Probably never. And the reason that there is no GC neither in
> the C++ Standard nor as a typical extension is the lack of
> demand.
That argument is like the argument against classes in C.
There's no demand for classes in C, because all of the people
who want classes have moved on to C++.
But in fact, it' hardly true. I know that all of the new
projects I work on use the Boehm collector, and I'm not alone,
so as an extension, one can hardly speak of lack of demand.
People want garbage collection in C++ because the other
languages, which offer it, have other problems. In the end, one
tries to chose the easier battles, and I find it more likely to
get garbage collection in C++ than to get value semantics and
all the other things that are missing in Java.
(My impression, but it is just a subjective impression, is that
the chances are very good that the next version of C++ will have
garbage collection. There seems to be more or less a concensus
in the standardization committee that it should be studied, and
given that we have existing practice, and know it works, and is
useful, I'd say that the odds are in favor of it.)
> Good C++ practices tend to produce the objects with automatic
> storage duration.
Certainly the presence of value semantics makes garbage
collection less essential. That doesn't mean that it isn't an
important asset, however.
> Resourse management is done in ctor/dtor, which is robust,
> flexible and deterministic.
And doesn't always have the desired semantics for the special
resource memory.
--
James Kanze kanze...@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Walter Bright
> "Walter Bright" <wal...@digitalmars-nospamm.com> wrote in message
> news:m9GdnQiIO9kwHSrZ...@comcast.com...
> [...]
>> The historical string class problem (everyone inventing their own
>> string
>> class) had its roots in lack of GC. Note that none of the GC
>> languages
>> have a problem with string classes.
>
> This historical problem is an old history. It was the case before
> the standard
> library was adopted. I haven't seen anybody writing their own
> string class for
> years. I have seen people creating their own string classes for
> specific
> purposes. For example, I have a static_string in my collection for
> fast strings
> located on stack, which also works seemlessly with std::string and
> algorithms.
I've written my own, too (to handle UTF), and for other various reasons.
> I also don't see how string class is related to GC. Do you need GC
> to implement
> std::string? No.
Obviously you're right, you don't. But with GC, you don't even need to
write a string class.
> How can GC possibly be used in something like static_string? It
> can't.
> On the other hand, if you look at Visual C++, which has GC, there
> are at
> least 3 string classes available. The best of all of them is still
> std::string.
> The "modern" VC++ extensions all look like a saddle on a cow.
You may be right in that GC just may never fit comfortably with C++.
> All those other
> modern languages with GC are actually way behind C++ in their
> language designs,
> and they need a GC crutch to deal with their data model.
That's one perspective. Looking at it from the opposite perspective, one
might conclude that C++ needs all those features to make up for lack of
GC <g> .
>
> [...]
>> C++ should have acquired GC about 15 years ago. I think your comment
>> about too little, too late applies to that as well. Even if GC were
>> adopted, how many years would it be before it diffuses through to all
>> the C++ platforms out there? 10 years?
>
> Probably never. And the reason that there is no GC neither in the C+
> + Standard
> nor as a typical extension is the lack of demand.
A lot of C++ people frequently turn to GC languages - because they need
the productivity improvements that come from GC. They'll even put up
with a language that executes 100 times slower just because it's faster
to develop their application in it. They'll use C++ only when they need
the performance.
> Good C++ practices tend to
> produce the objects with automatic storage duration. Resourse
> management is done
> in ctor/dtor, which is robust, flexible and deterministic.
Sure. Adding GC will not take any of that away. Many GC languages do
make the mistake of deciding that GC is the hammer and everything else
is a nail, but it doesn't have to be that way.
-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Bo Persson
> James Kanze wrote:
>> Also, 32 bits is more than enough for a lot of uses. (16
>> isn't.) Why should people use more memory when they don't need
>> it?
>
> Why, indeed. I can't see making int 64 bits even if the CPU is 64
> bits.
>
>> > My suggestion was for standardizing common existing practice,
>> > not breaking it.
>> In practice, if it's existing practice, it is standardized. Do
>> you know of any 32 bit machine where int isn't 32 bits?
>
> Nope. But I *do* see a lot of worrying about it, and effort expended
> attempting to immunize one's source code against the possibility
> that
> int may be 35 bits. By standardizing existing practice, all that
> worry
> would be eliminated.
It wouldn't help on 35 bit hardware anyway.
Standardizing a 32 bit int on 32 bit hardware is like, I don't know...
Isn't the int type already supposed to be the "natural" size on any
hardware?
Bo Persson
loufoque
> Now if boost's (or tr1's) shared_ptr also came with a detach() function
> it would be useful. Because then I could also work with whatever
> version of boost/tr1 shared_ptr I have on my own side, then simply
> convert them to the custom shared_ptr for portability, then you convert
> back.
See the boost FAQ to know why shared_ptr doesn't have a release() function.
http://boost.org/libs/smart_ptr/shared_ptr.htm
But anyway, I think shared_ptr is mostly useless.
It was made for shared ownership, which basically never occurs and is
quite contradictory with RAII.
However I have seen a lot of people use it simply because they found it
simpler to manage memory that way, but they don't really need it most of
the time.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
loufoque
> When you can. It doesn't work for entity objects, which can't
> be copied, and it doesn't work for anything polymorphic.
They can be wrapped in stuff like clone_ptr<Base>, which will make an
object that can behave polymorphically (it can actually contain a
Derived object, copying will perform deep copy and the object is freed
upon destruction)
The C++ standard only provides auto_ptr which moves instead of copying,
which is semantically wrong, but it can also be used to wrap polymorphic
objects and to return non-copyable elements.
> It
> can also cause performance problems for large collections---the
> copy constructor for an std::list<std::string> with over 50000
> elements is not going to be instantanious.
That is why the new standard will introduce move semantics.
And anything I can think of can be moved for a pretty cheap price.
As of today, though, you can rely on NRVO to know that returning local
variables by value won't copy.
charl...@gmail.com
> [...]
> > C++ should have acquired GC about 15 years ago. I think your comment
> > about too little, too late applies to that as well. Even if GC were
> > adopted, how many years would it be before it diffuses through to all
> > the C++ platforms out there? 10 years?
Gene Bushuyev replied:
> Probably never. And the reason that there is no GC neither in the C++ Standard
> nor as a typical extension is the lack of demand. Good C++ practices tend to
> produce the objects with automatic storage duration. Resourse management is done
> in ctor/dtor, which is robust, flexible and deterministic.
THANK YOU, Gene.
I bite my tongue every time GC comes up. I understand its utility,
as I understand the value of high-level scripting in langauges like
Perl/Python/Ruby. Further, I understand the value of "higher-level"
OO languages with GC and dynamic typing, like Smalltalk and Lisp.
But, that's not C++ with its compile-time static typing. I would
*never* use GC. IMHO, for most OO, it's simply a bad way
to view the problem. For the *vast* majority of our designs, object
ownership is defined through well-understood containment within
well-defined (logical) abstractions. If it's not, IMHO, you are
missing
key abstractions.
If you create an object and you don't know who should "own" it,
you have a primitive design.
I admit exceptions to this principle in "strange" domains, like
implementation of an object-database library, but those tend to
be rare. Still, that simply means the "owner" will be some kind
of artifact (not a logical entity, as is most common in most domains).
All GC does is say, "I create objects but don't feel like defining
an owner, so I just leave my mess for the janitor, whom I assume
will clean up for me in a proper way."
I'd be *so sad* if the C++ standard got screwed up with GC, and
I had to figure out how to work around it and shut it off.
Walter Bright
> > It wouldn't help on 35 bit hardware anyway.
> >
> > Standardizing a 32 bit int on 32 bit hardware is like, I don't know...
> >
> > Isn't the int type already supposed to be the "natural" size on any
> > hardware?
I've seen people go to great pains to say the Standard doesn't specify
the size of an int, so some implementation is free to make them 35 bits.
And that's true.
But any CPU maker or compiler vendor would be out of their minds to make
such a perverse machine/implementation.
There have been machines with 10 bit bytes, and 36 bit words. But
they're dead, dead, dead. The concern about a resurgence of such
machines is unjustified, and despite all the effort spent typedef'ing
int, I bet that most code will break anyway <g>.
P.S. I remember back in the bad old 16 bit days, people used typedefs
everywhere for "portability". Then, along came 32 bit windows. That code
all broke anyway.
-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
loufoque
> > Isn't the int type already supposed to be the "natural" size on any
> > hardware?
No.
And it isn't with most compilers for AMD64.
Le Chaud Lapin
> > All GC does is say, "I create objects but don't feel like defining
> > an owner, so I just leave my mess for the janitor, whom I assume
> > will clean up for me in a proper way."
Well said.
Ironically, after the mess is created, the creator of the mess often
spends days (sometimes weeks) trying to recover the determinism that
was lost by GC. I have already seen in recent months several occasions
where a GC evangelist got himself into a nasty situation with
garbage-collected code, fiddled around with his nasty code for a few
days, then finally resorted to consutling a non-GC person to help him
figure out how to force his GC stuff to be more deterministic. It's
comical to watch.
The "Nettting C++" article of this month touches on the same issue:
http://msdn.microsoft.com/msdnmag/issues/06/08/NettingC/default.aspx
> > I'd be *so sad* if the C++ standard got screwed up with GC, and
> > I had to figure out how to work around it and shut it off.
It might be 5 years from now, but eventually, the pro-GC people will
realize that there is no susbtitute for good form.
-Le Chaud Lapin-
Gene Bushuyev
news:44bbba06$0$27037$626a...@news.free.fr...
> Earl Purple wrote :
>
>> Now if boost's (or tr1's) shared_ptr also came with a detach() function
>> it would be useful. Because then I could also work with whatever
>> version of boost/tr1 shared_ptr I have on my own side, then simply
>> convert them to the custom shared_ptr for portability, then you convert
>> back.
>
> See the boost FAQ to know why shared_ptr doesn't have a release() function.
> http://boost.org/libs/smart_ptr/shared_ptr.htm
They basically give two reasons:
1) other shared_ptr's will destroy the object. Which can be solved by resetting
the shared pointer to NULL and/or count to 0. I'm not talking about actual
shared_ptr implementattion, rather about a legacy shared_ptr from my library.
2) "the pointer returned by release() would be difficult to deallocate reliably"
due to custom deleter. This is a spurious reason, because the caller of
release() takes all responsibility for this action. It's none of shared_ptr
business how the caller is going to delete the resource.
Why the release() is desirable? Because we live in imperfect world. Not long ago
I had to interface with a library which could only accept a naked pointer.
>
> But anyway, I think shared_ptr is mostly useless.
> It was made for shared ownership, which basically never occurs and is
> quite contradictory with RAII.
There is a truth to that; shared_ptr is mostly used not because of the need to
share resources, for which shared_ptr is inadequate anyway, but because auto_ptr
doesn't work, something like unique_ptr is not available, and making deep copy
is too expensive.
--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George Orwell
Francis Glassborow
Chaud Lapin <jaibu...@gmail.com> writes
>It might be 5 years from now, but eventually, the pro-GC people will
>realize that there is no susbtitute for good form.
>
extremes are, IMHO, misguided. GC is not the answer to all problems and
in some domains it is pretty nigh useless. OTOH it is in answer to some
problems in some problem domains and for those people its lack results
in them having to make considerable efforts to simulate it.
If C++ abandoned deterministic object lifetimes there would a a
legitimate reason to complain but I see no reason for objecting to GC as
an option. It is just one more tool in a programmer's kit, and if he
does not want to use it, C++ will not force him to. But this is not a
reason to object to its availability.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
kanze
> Bo Persson wrote:
> > > It wouldn't help on 35 bit hardware anyway.
> > > Standardizing a 32 bit int on 32 bit hardware is like, I
> > > don't know...
> > > Isn't the int type already supposed to be the "natural"
> > > size on any hardware?
> I've seen people go to great pains to say the Standard doesn't
> specify the size of an int, so some implementation is free to
> make them 35 bits. And that's true.
> But any CPU maker or compiler vendor would be out of their
> minds to make such a perverse machine/implementation.
They exist, and are still being sold (and presumably bought).
> There have been machines with 10 bit bytes, and 36 bit words.
> But they're dead, dead, dead.
You can still buy a machine with 36 bit words (and 1's
complement) today. Such things may be dead in the desktop
market, but the mainframe world moves a lot slower.
> The concern about a resurgence of such machines is
> unjustified, and despite all the effort spent typedef'ing int,
> I bet that most code will break anyway <g>.
If the code isn't meant to be portable, it's not surprising.
Most of the code I write is designed to run on exactly one
machine, and contains a lot of system dependencies. (Actually,
I do try to write it so that we can port easily between Posix
compatible systems, and not just Solaris. And some parts have
recently been ported to Linux, without too much difficulty.)
Realistically, if you're writing software designed to run on a
desktop, you don't have to take 36 bit machines into account.
Realistically, if you're writing software which is designed
aroung Posix facilities, you don't either (although both 32 bit
and 64 bit hardware is quite likely).
> P.S. I remember back in the bad old 16 bit days, people used
> typedefs everywhere for "portability". Then, along came 32 bit
> windows. That code all broke anyway.
Mine didn't:-) (and it didn't make that much use of typedef's).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
> charl...@gmail.com wrote:
> > > All GC does is say, "I create objects but don't feel like
> > > defining an owner, so I just leave my mess for the
> > > janitor, whom I assume will clean up for me in a proper
> > > way."
> Well said.
So why do companies like those I work for hire janitors, rather
than requiring the engineers to sweep the floors?
> Ironically, after the mess is created, the creator of the mess
> often spends days (sometimes weeks) trying to recover the
> determinism that was lost by GC. I have already seen in recent
> months several occasions where a GC evangelist got himself
> into a nasty situation with garbage-collected code, fiddled
> around with his nasty code for a few days, then finally
> resorted to consutling a non-GC person to help him figure out
> how to force his GC stuff to be more deterministic. It's
> comical to watch.
How does garbage collection have any effect on determinism? I
fail to see the relationship. (But then, maybe that's because
I'm used to using garbage collection in C++ code.)
[...]
> > > I'd be *so sad* if the C++ standard got screwed up with
> > > GC, and I had to figure out how to work around it and shut
> > > it off.
> It might be 5 years from now, but eventually, the pro-GC
> people will realize that there is no susbtitute for good form.
Maybe some day, all programmers will be in my position, where
they are paid to produce solutions, as efficiently as possible,
and won't oppose tools that increase their efficiency.
Actually, I think that is already the case in a lot of cases.
There definitly seems to be a lot of support for garbage
collection amongst the C++ programmers I've talked to.
(Including a number of committee members---a vote in the last
committee meeting indicated a definite consensus for at least
persuing the issue.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
> > Walter Bright spaketh:
> > [...]
> > > C++ should have acquired GC about 15 years ago. I think
> > > your comment about too little, too late applies to that as
> > > well. Even if GC were adopted, how many years would it be
> > > before it diffuses through to all the C++ platforms out
> > > there? 10 years?
> Gene Bushuyev replied:
> > Probably never. And the reason that there is no GC neither
> > in the C++ Standard nor as a typical extension is the lack
> > of demand. Good C++ practices tend to produce the objects
> > with automatic storage duration. Resourse management is done
> > in ctor/dtor, which is robust, flexible and deterministic.
> THANK YOU, Gene.
For the false illusion? There IS a large demand for garbage
collection in C++. The standards committee is seriously
considering it for the next version of the standard. Third
party companies are successfully selling garbage collection as
an add in, and an open source implementation is widely used.
None of which, of course, says that we should abandon value
semantics for value oriented types, nor drop constructors and
destructors.
> I bite my tongue every time GC comes up. I understand its
> utility, as I understand the value of high-level scripting in
> langauges like Perl/Python/Ruby. Further, I understand the
> value of "higher-level" OO languages with GC and dynamic
> typing, like Smalltalk and Lisp.
> But, that's not C++ with its compile-time static typing. I
> would *never* use GC.
That's an interesting statement, because compile-time static
typing for dynamically allocated objects requires garbage
collection. It can't be done otherwise, or at least, I don't
think so. C++ implementations don't do it; they use the
"undefined behavior" to let them off the hook.
> IMHO, for most OO, it's simply a bad way to view the problem.
> For the *vast* majority of our designs, object ownership is
> defined through well-understood containment within
> well-defined (logical) abstractions.
A large majority, yes. And there are certainly objects for
which garbage collection is not really the right solution
(although even with such objects, it permits some form of type
safety, which isn't possible otherwise). I have, in fact, often
wished for a sort of reverse garbage collection as well: rather
than deleting an object when there are no more pointers to it,
it would get rid of all pointers to an object when it the object
is deleted.
The fact that it isn't necessary all of the time doesn't mean
that it isn't useful in enough cases to be worthwhile.
> If it's not, IMHO, you are missing key abstractions.
It depends on the object. Many objects DO have explicit
lifetimes. All garbage collection brings to them is an ability
to detect the errors: an explicit and understandable error
message, instead of undefined behavior. Many others however,
don't really need an explicit lifetime, as long as they are
there when needed (i.e. someone holds a pointer to them). For
those, garbage collection is THE solution. (And of course, a
lot of objects have value semantics, and should probably never
be allocated dynamically anyway. For those, of course, garbage
collection is irrelevant.)
> If you create an object and you don't know who should "own"
> it, you have a primitive design.
I find a lot of cases where the design says that it doesn't
matter.
> I admit exceptions to this principle in "strange" domains,
> like implementation of an object-database library, but those
> tend to be rare. Still, that simply means the "owner" will be
> some kind of artifact (not a logical entity, as is most common
> in most domains).
> All GC does is say, "I create objects but don't feel like
> defining an owner, so I just leave my mess for the janitor,
> whom I assume will clean up for me in a proper way."
It's not a question of feeling, but of design. There are
objects for which artificially designating an owner is just
extra work, and is, in fact, an artifact of a weakness in the
language.
> I'd be *so sad* if the C++ standard got screwed up with GC,
> and I had to figure out how to work around it and shut it off.
If you don't like being more productive, that's understandable.
If you're paid by the line, garbage collection will certainly
reduce your income.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
> Gene Bushuyev wrote:
[...]
> > All those other modern languages with GC are actually way
> > behind C++ in their language designs, and they need a GC
> > crutch to deal with their data model.
> That's one perspective. Looking at it from the opposite
> perspective, one might conclude that C++ needs all those
> features to make up for lack of GC <g> .
My perspective is that no language is perfect. And that very
few are totally bad, either. Globally, for the type of software
I write, C++ seems more appropriate than, say, Java; I need a
higher degree of robustness and maintainability than Java can
offer. But C++ with garbage collection turns out to be even
more appropriate than C++ without.
> > [...]
> >> C++ should have acquired GC about 15 years ago. I think
> >> your comment about too little, too late applies to that as
> >> well. Even if GC were adopted, how many years would it be
> >> before it diffuses through to all the C++ platforms out
> >> there? 10 years?
> > Probably never. And the reason that there is no GC neither
> > in the C++ Standard nor as a typical extension is the lack
> > of demand.
> A lot of C++ people frequently turn to GC languages - because
> they need the productivity improvements that come from GC.
> They'll even put up with a language that executes 100 times
> slower just because it's faster to develop their application
> in it. They'll use C++ only when they need the performance.
Alternatively, we put up with the lack of garbage collection
because we need other features that the other languages don't
offer. That doesn't mean that we wouldn't prefer having it. Or
that we don't use it when possible---I use the Boehm collector
in most new projects.
> > Good C++ practices tend to produce the objects with
> > automatic storage duration. Resourse management is done in
> > ctor/dtor, which is robust, flexible and deterministic.
> Sure. Adding GC will not take any of that away. Many GC
> languages do make the mistake of deciding that GC is the
> hammer and everything else is a nail, but it doesn't have to
> be that way.
Which is what I've been saying for quite a while now. GC is a
valuable tool. It makes me more productive. But it isn't a
silver bullet.
Personally, 35 years of experience has made me rather sceptical
about silver bullets. I'll settle for something that just makes
my code cleaner and easier to write.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
david...@gmail.com
Gene Bushuyev wrote:
<snip>
> All those other modern languages with GC are actually way behind C++ in their language designs,
<snip>
You're making a category error. C++ and "all those other modern
languages" (by which I assume you mean Java, C# etc.) have different
design goals. So simply asserting that one is behind the other is akin
to saying that Sundays are better than Diet Coke.
Cheers,
Dave Boyle
Allan W
Le Chaud Lapin wrote:
> charl...@gmail.com wrote:
>>> All GC does is say, "I create objects but don't feel like defining
>>> an owner, so I just leave my mess for the janitor, whom I assume
>>> will clean up for me in a proper way."
>
> Well said.
>
> Ironically, after the mess is created, the creator of the mess often
> spends days (sometimes weeks) trying to recover the determinism that
> was lost by GC. I have already seen in recent months several occasions
> where a GC evangelist got himself into a nasty situation with
> garbage-collected code, fiddled around with his nasty code for a few
> days, then finally resorted to consutling a non-GC person to help him
> figure out how to force his GC stuff to be more deterministic. It's
> comical to watch.
>
> The "Nettting C++" article of this month touches on the same issue:
>
> http://msdn.microsoft.com/msdnmag/issues/06/08/NettingC/default.aspx
That article presents code which is written in C++/CLI.
C++/CLI is a .NET language... complete with GC.
It is a different language than Standard C++.
But anyway, the very first line of the very first code sample in that
article
is:
public ref class TQL {
The keyword "ref" does not exist in standard C++, nor is it needed.
The keyword "public" is not used that way in standard C++.
There was a HUGE discussion about the name "C++/CLI", not long ago
(and very heated, for a moderated group)... As I recall, the only real
agreement was that C++/CLI is a different language than Standard C++,
despite having such a similar name. Disagreement about whether this
was evil or not. But note that the Microsoft Visual Studio compiler
(which
supports C++/CLI) also supports Standard C++. But you have to
understand the difference.
david...@gmail.com
THEORY:
"Good C++ practices tend to produce the objects with automatic storage
duration. Resourse management is done in ctor/dtor, which is robust,
flexible and deterministic."
PRACTICE:
"Why the release() is desirable? Because we live in imperfect world.
Not long ago I had to interface with a library which could only accept
a naked pointer."
"There is a truth to that; shared_ptr is mostly used not because of the
need to share resources, for which shared_ptr is inadequate anyway, but
because auto_ptr doesn't work, something like unique_ptr is not
available, and making deep copy is too expensive."
So, when implementing a system using C++ we have the choice of:
- references
- value types
- raw pointers,
- a whole set of smart pointers (some in the standard library, some
not),
- smart pointers that are "inadequate",
- smart pointers that "don't work"
- a new sort of smart pointer, such as "unique pointer", suggested
about once a week,
- legacy code that means even in situations where smart pointers could
work, they aren't used.
GC is far from perfect but the above is a shambles.
Cheers,
Dave Boyle
Carl Barron
Bushuyev <sp...@spamguard.com> wrote:
> There is a truth to that; shared_ptr is mostly used not because of
> the need to
> share resources, for which shared_ptr is inadequate anyway, but
> because
> auto_ptr
> doesn't work, something like unique_ptr is not available, and
> making deep copy
> is too expensive.
I don't find shared_ptr inadequate, but I often find it to be
overkill, but if the profiler does not indicate that is a problem, I
don't solve it:)
I recommend it here, since most of the time it solve alot of problems
that a poster is creating in his post, and shared_ptr nicely solves
these problems simply. [not necessarily optimally]
Le Chaud Lapin
> How does garbage collection have any effect on determinism? I
> fail to see the relationship. (But then, maybe that's because
> I'm used to using garbage collection in C++ code.)
>
Honestly, I don't know. When my pro-GC friend comes to be with a, "I
can't get this thing to destruct when I want it to", my ears turn off a
bit. But the last problem had something to do with a distributed
communication. He had an object that represented one-side of a
communication session, and apparent the object was not going away when
he thought it was.
So I imagine that one waits for the GC environment to destroy dangling
objects. So perhaps the problem is the mindset...saying that one is
willing to trust the GC to take care of everything, so long as it takes
care of everything *right now* (in special cases).
-Le Chaud Lapin-
charl...@gmail.com
> charl...@gmail.com wrote:
>>> Walter Bright spaketh:
>>> [...]
>>>> C++ should have acquired GC about 15 years ago.
>
>>> <snip, > And the reason that there is no GC neither
>>> in the C++ Standard nor as a typical extension is the lack
>>> of demand. Good C++ practices tend to produce the objects
>>> with automatic storage duration. Resourse management is done
>>> in ctor/dtor, which is robust, flexible and deterministic.
>
>> THANK YOU, Gene.
>
> For the false illusion? There IS a large demand for garbage
> collection in C++. The standards committee is seriously
> considering it for the next version of the standard. Third
> party companies are successfully selling garbage collection as
> an add in, and an open source implementation is widely used.
They can consider it all they want. ;-) I was just happy to
hear a dissenting view (GC isn't universally desired in C++).
>> I bite my tongue every time GC comes up. <snip, has
>> utility in other languages but not C++>,
>>
>> I would *never* use GC [...in C++]
> That's an interesting statement, because compile-time static
> typing for dynamically allocated objects requires garbage
> collection. It can't be done otherwise, or at least, I don't
> think so. C++ implementations don't do it; they use the
> "undefined behavior" to let them off the hook.
My assertion is that the stronger the type, and the more
mature the design, the more deliberate you want to be in
controlling your object lifecycle (and not leave anything to
an external system, which GC is, because GC doesn't have
your model dependencies and business logic).
>> IMHO, for most OO, it's simply a bad way to view the problem.
>> For the *vast* majority of our designs, object ownership is
>> defined through well-understood containment within
>> well-defined (logical) abstractions.
>
> A large majority, yes. And there are certainly objects for
> which garbage collection is not really the right solution
> (although even with such objects, it permits some form of type
> safety, which isn't possible otherwise). I have, in fact, often
> wished for a sort of reverse garbage collection as well: rather
> than deleting an object when there are no more pointers to it,
> it would get rid of all pointers to an object when it the object
> is deleted.
What you're calling GC and "reverse" GC, I'm suggesting
is better handled with business logic as defined through your
model (since it actually knows what all your types mean
anyway).
> The fact that it isn't necessary all of the time doesn't mean
> that it isn't useful in enough cases to be worthwhile.
I use GC all the type in Perl. I go decades without it in C++.
I concede the point that if that's how you view design, GC
is a valid computer science artifact to legitimately address
some problems in some domains. (I'd just prefer it to
be in a library external to the C++ standard itself.)
>> If it's not, IMHO, you are missing key abstractions.
>
> It depends on the object. Many objects DO have explicit
> lifetimes. All garbage collection brings to them is an ability
> to detect the errors: an explicit and understandable error
> message, instead of undefined behavior. Many others however,
> don't really need an explicit lifetime, as long as they are
> there when needed (i.e. someone holds a pointer to them). For
> those, garbage collection is THE solution. (And of course, a
> lot of objects have value semantics, and should probably never
> be allocated dynamically anyway. For those, of course, garbage
> collection is irrelevant.)
You're describing a case where I agree in some GC utility:
When many "trivial" non-connected objects are popping in and
out, all over the system. That's how Perl/Python work too,
and GC is quite handy there.
I don't commonly find that design in most C++ systems (the
types are stronger, and they have better "knowledge" of whom
they reference since that's the business logic).
>> <snip>,
>> All GC does is say, "I create objects but don't feel like
>> defining an owner, so I just leave my mess for the janitor,
>> whom I assume will clean up for me in a proper way."
>
> It's not a question of feeling, but of design. There are
> objects for which artificially designating an owner is just
> extra work, and is, in fact, an artifact of a weakness in the
> language.
The original statement suggests the janitor doesn't have
sufficient context to make decisions about what should be
cleaned up, when, how, and in what order.
Yes, I concede the point that GC can work well for the "trivial"
case where the object isn't coupled to anything and no other
specifal considerations exist.
Unfortunately, I find that small (normal) changes to a design
results in your system now having "non-trivial" cleanup
considerations that GC can't handle. In that case, I find
that rather than getting GC to "behave properly", it would have
been faster/easier/more robust/more correct to simply address
object lifecycles in my design.
>> I'd be *so sad* if the C++ standard got screwed up with GC,
>> and I had to figure out how to work around it and shut it off.
>
> If you don't like being more productive, that's understandable.
> If you're paid by the line, garbage collection will certainly
> reduce your income.
Now, now, be nice. ;-) You're a smart guy that raises valid
points, so I'm merely attempting to respond honestly.
But, my original comment was true: I'd be sad if GC were added
to C++, and I'd try to find a way to shut it off, because I don't
have use for it (even considering my honest goal for productivity ;-).
Gene Bushuyev
news:1153221030.2...@75g2000cwc.googlegroups.com...
> charl...@gmail.com wrote:
>>> Walter Bright spaketh:
>>> [...]
>>>> C++ should have acquired GC about 15 years ago. I think
>>>> your comment about too little, too late applies to that as
>>>> well. Even if GC were adopted, how many years would it be
>>>> before it diffuses through to all the C++ platforms out
>>>> there? 10 years?
>
>> Gene Bushuyev replied:
>>> Probably never. And the reason that there is no GC neither
>>> in the C++ Standard nor as a typical extension is the lack
>>> of demand. Good C++ practices tend to produce the objects
>>> with automatic storage duration. Resourse management is done
>>> in ctor/dtor, which is robust, flexible and deterministic.
>
>> THANK YOU, Gene.
>
> For the false illusion? There IS a large demand for garbage
> collection in C++. The standards committee is seriously
> considering it for the next version of the standard. Third
> party companies are successfully selling garbage collection as
> an add in, and an open source implementation is widely used.
Since my name was dragged back into this discussion :-) I feel
responsibility to
answer. I suggest you provide some real cases where C++ is hampered
by the
absense of GC. If you provide a convincing example, nobody will argue
about it
anymore. So far nothing in this long thread demonstrated there are
such cases. I
haven't seen the arguments indicating that RAII design principle is
lacking.
Discussions of the string class or shared_ptr didn't add anything to
the claims
that GC is useful and necessary.
On the other hand, my experience tells me that nobody wants to use
the Visual
C++ GC extensions unless forced to do so. I don't use them, though
they are
readily available and despite the fact that this feature was touted
by MS for
several years. I also downloaded Boehm collector out of curiosity a
couple of
years ago and I'm still waiting for the problem that would make it a
solution.
There were also some claims elsewhere in this thread that GC can
happily coexist
with C++ deterministic destruction. But if the destruction (GC
finalization) is
deterministic then I don't care whether there is GC or not, I manage
the life
time of objects as without GC. GC becomes a detail of memory allocator
implementation. Compiler is free to implement any of many memory
allocation
schemes, C++ doesn't prevent memory allocators to delay reuse of the
storage for
deleted objects untill collection time, and the program doesn't need
to know
that. On the other hand, in the presence of GC, why would anybody try
to make GC
based objects behave deterministically? - It only adds a pain to the
programmer
to jump over the hoops and fight GC. If you want deterministic
destruction, you
definitely don't want GC; if you want GC, you definitely don't want
deterministic destruction, in fact you don't want any non-trivial
destruction; -
the two don't blend together, one fighting the other.
Finally, below are some popular myths about C++ that I mined on the web:
1) "C++ programmers spend large chunks of their time designing for
explicit
storage management and tracking down storage bugs." In another place
a 30-40%
reduction in development time is promissed.
Not true. Designing RAII into classes or choosing the proper smart
pointers is
the simplest task during project design and takes little time and
efforts.
Relying on GC will probably create more bugs and slow the development
down
because managing objects life-times and proper ownership were not
seriously
considered, thus producing more logical bugs and increasing
development time.
2) "Dangling pointers, storage leaks, memory smashes, and out-of-
bounds array
indices are the bane of the C++ programmer and his customers."
Not true as long as good software design principles are followed.
There are bad
programmers of course who program sloppily. The problem is not the
deficiency of
the tool (C++), but incompetence of some practitioners. As somebody
said, if the
language allows you to jump off the cliff, it doesn't mean you have
to do it.
The solution to sloppy programmers is not GC, but education. Just
like the
solution to a messy dog is training and not an intelligent vacuum
cleaner.
Otherwise with or without GC the programm will be a mess anyway.
3) "Some of the most complicated aspects of C++ arise from using
constructors
and destructors to make up for the lack of garbage collection."
Well, if understanding ctor/dtor mechanism is so complicated for
somebody, maybe
(s)he needs to find a simpler language - Basic, Java? Those language
are pretty
simple as long as you don't need to do anything for which there isn't
a ready
solution in the library.
There is a misconception that GC would free a programmer from
properly designing
constructors and destructors. Not true. For example, a class that has
a pointer
has to decide the proper copy construction and assignment, whether it
needs a
shallow or a deep copy of the object that the pointer reffers to, or
whether to
transfer ownership or share it. If anything, GC is only capable of
concealing
the real design issues, not helping solving them.
4) garbage collection will make C++ "safe"
No. There is more than one way to screwing things up. Programmers
that can't
manage memory well, can't manage the other things either. If somebody
expects
his "unsafe" C++ programs to become "safe" after adding GC he is
setting himself
up for a big disappointment.
--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
C++ is my favorite garbage collected language because it produces so
little
garbage. ~ Stroustrup
charl...@gmail.com
> Le Chaud Lapin wrote:
>> charl...@gmail.com wrote:
>>>> All GC does is say, "I create objects but don't feel like
>>>> defining an owner, so I just leave my mess for the
>>>> janitor, whom I assume will clean up for me in a proper
>>>> way."
>
>> Well said.
>
> So why do companies like those I work for hire janitors, rather
> than requiring the engineers to sweep the floors?
Admitedly, sweeping the floors and emptying the wastebasket
isn't necessarily an engineer function (and I concede those to
be distractions). The complaint against GC in C++ is that it's
not that simple: I make a mess leaving papers all over my
office (on the walls, floor, and my desk), and the janitor is
just supposed to "know" which things he should throw away
because I won't put them in the wastebasket myself.
It's so annoying when the janitor erases my whiteboard and
I lose important concepts, but he's just doing the best he
can with the context he has.
>> Ironically, after the mess is created, the creator of the mess
>> often spends days (sometimes weeks) trying to recover the
>> determinism that was lost by GC. I have already seen in recent
>> months several occasions where a GC evangelist got himself
>> into a nasty situation with garbage-collected code, fiddled
>> around with his nasty code for a few days, then finally
>> resorted to consutling a non-GC person to help him figure out
>> how to force his GC stuff to be more deterministic. It's
>> comical to watch.
>
> How does garbage collection have any effect on determinism? I
> fail to see the relationship. (But then, maybe that's because
> I'm used to using garbage collection in C++ code.)
There are many:
- rules for order of destruction
- rules for reclaiming/updating dependant objects
- circular "sets" of cross-referencing objects (where the whole
set should be collected)
- timeliness to reclaim large amounts of resources held
by a single (or few) objects
- etc. (everybody bitten by Java GC knows many more)
If *logic* (i.e., "rules") are needed to "help" specify how to
delete objects, then that should be managed by your model
through your business logic and not in the GC (because
indeed, the GC doesn't have sufficient context except for
the simple case).
> [...]
>>>> I'd be *so sad* if the C++ standard got screwed up with
>>>> GC, and I had to figure out how to work around it and shut
>>>> it off.
>
>> It might be 5 years from now, but eventually, the pro-GC
>> people will realize that there is no susbtitute for good form.
>
> Maybe some day, all programmers will be in my position, where
> they are paid to produce solutions, as efficiently as possible,
> and won't oppose tools that increase their efficiency.
If you spend days chasing "order of delete" problems and attempting
to force re-claiming of resources in a time-sensitive manner, that's
not an increase in efficiency.
I don't expect pro/anti GC agreement *ever*. Different languages
cause you to think differently, and I don't dispute the value of GC
in all cases -- it's great in Perl and Python (which I also use).
My assertion is that for most OO designs, it's usually not a
good way to view the problem since it allows you to *not* make
fundamental decisions, like what objects should exist and who
should own them.
I don't care that "scalars" and "hashes/dictionaries" come-and-go
all the time in other languages (cleaned up by GC), but in C++
I want my strongly typed object lifecycles to be decided
deliberately, because they exist for a specific purpose, because
they are strongly typed.
> Actually, I think that is already the case in a lot of cases.
> There definitly seems to be a lot of support for garbage
> collection amongst the C++ programmers I've talked to.
> (Including a number of committee members---a vote in the last
> committee meeting indicated a definite consensus for at least
> persuing the issue.)
Understood. IMHO, though, I'd rather something like that be
external (like through BOOST) and not part of the language,
since it attempts to solve a problem I don't have.
Lally
kanze wrote:
> For the false illusion? There IS a large demand for garbage
> collection in C++. The standards committee is seriously
> considering it for the next version of the standard. Third
> party companies are successfully selling garbage collection as
> an add in, and an open source implementation is widely used.
>
> None of which, of course, says that we should abandon value
> semantics for value oriented types, nor drop constructors and
> destructors.
Exactly. Plenty of people want GC (as an option), but don't want to
see Java's GC, or anything but a natural C++ GC, that doesn't break the
rest of the language. Still, there are more options than just GC and
manual new/delete. If GC's added, it's gotta be defined well enough
that people can still get as much control over the process as they
need, and it has to be friendly to _all_ the other features of the
language.
> > I bite my tongue every time GC comes up. I understand its
> > utility, as I understand the value of high-level scripting in
> > langauges like Perl/Python/Ruby. Further, I understand the
> > value of "higher-level" OO languages with GC and dynamic
> > typing, like Smalltalk and Lisp.
>
> > But, that's not C++ with its compile-time static typing. I
> > would *never* use GC.
>
> That's an interesting statement, because compile-time static
> typing for dynamically allocated objects requires garbage
> collection. It can't be done otherwise, or at least, I don't
> think so. C++ implementations don't do it; they use the
> "undefined behavior" to let them off the hook.
I really haven't the faintest clue what you mean here. Mind explaining
a bit?
> > IMHO, for most OO, it's simply a bad way to view the problem.
> > For the *vast* majority of our designs, object ownership is
> > defined through well-understood containment within
> > well-defined (logical) abstractions.
>
> A large majority, yes. And there are certainly objects for
> which garbage collection is not really the right solution
> (although even with such objects, it permits some form of type
> safety, which isn't possible otherwise). I have, in fact, often
> wished for a sort of reverse garbage collection as well: rather
> than deleting an object when there are no more pointers to it,
> it would get rid of all pointers to an object when it the object
> is deleted.
How does that compare to boost::weak_ptr<>?
Chris Hills
kanze <ka...@gabi-soft.fr> writes
>Walter Bright wrote:
>> Bo Persson wrote:
>> > > It wouldn't help on 35 bit hardware anyway.
>
>> > > Standardizing a 32 bit int on 32 bit hardware is like, I
>> > > don't know...
>
>> > > Isn't the int type already supposed to be the "natural"
>> > > size on any hardware?
>
>> I've seen people go to great pains to say the Standard doesn't
>> specify the size of an int, so some implementation is free to
>> make them 35 bits. And that's true.
>
>> But any CPU maker or compiler vendor would be out of their
>> minds to make such a perverse machine/implementation.
>
>They exist, and are still being sold (and presumably bought).
>
>> There have been machines with 10 bit bytes, and 36 bit words.
>> But they're dead, dead, dead.
>
>You can still buy a machine with 36 bit words (and 1's
>complement) today. Such things may be dead in the desktop
>market, but the mainframe world moves a lot slower.
The embedded world is also different. the PC programmers seem to forget
they are in fact in a minority. All a PC is really is a set of embedded
systems in close proximity. I have clients whose products are hard
drives, CD drives, graphics cards, keyboards etc etc all have MCU in
them.
>> The concern about a resurgence of such machines is
>> unjustified, and despite all the effort spent typedef'ing int,
>> I bet that most code will break anyway <g>.
>
>If the code isn't meant to be portable, it's not surprising.
>Most of the code I write is designed to run on exactly one
>machine, and contains a lot of system dependencies. (Actually,
>I do try to write it so that we can port easily between Posix
>compatible systems, and not just Solaris. And some parts have
>recently been ported to Linux, without too much difficulty.)
I have the same problem in CLC where people seem to thin code should be
portable. Most embedded code is usually, at best portable between MCU in
the same family but that is it.
>> P.S. I remember back in the bad old 16 bit days, people used
>> typedefs everywhere for "portability". Then, along came 32 bit
>> windows. That code all broke anyway.
As it happens the most common MCU on the planet is still the 8 bit 8051
and it is only recently that 32 bit MCU have started to become a major
trend. That is ARM. I think the x86 family are still in a minority.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Gene Bushuyev
news:1153239447....@p79g2000cwp.googlegroups.com...
[...]
> > So, when implementing a system using C++ we have the choice of:
> >
> > - references
> > - value types
and what was the problem with the above?
> > - raw pointers,
those should be managed. And GC isn't the best solution at all.
> > - a whole set of smart pointers (some in the standard library, some
> > not),
so what's wrong with that? The reason there are several smart pointer
classes is
because the problems they solve are different. GC is kind of one size
fits all
approach, which usually means: fit none.
> > - smart pointers that are "inadequate",
Did somebody say that *all* smart pointers are inadequate for *all*
uses? I only
mentioned that shared_ptr may not be adequate to manage shared resources
because
the latter may require a different level of granularity than shared_ptr
offer.
> > - smart pointers that "don't work"
auto_ptr "doesn't work" as a substitute for unique_ptr, but work for the
other
cases.
> > - a new sort of smart pointer, such as "unique pointer", suggested
> > about once a week,
because that's the correct type of pointer for the problem. The solution
should
be appropriate for the problem. And I'm still waiting to hear what
problem GC
solves.
> > - legacy code that means even in situations where smart pointers could
> > work, they aren't used.
And how would GC solve the legacy code problem? The situation I
described cannot
be solved completely with shared_ptr, it cannot be solved with GC either.
> >
> > GC is far from perfect but the above is a shambles.
> >
I didn't say GC is far from perfect. I said it was useless.
--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George
Orwell
kanze
> kanze wrote:
> > Le Chaud Lapin wrote:
> >> charl...@gmail.com wrote:
> >>>> All GC does is say, "I create objects but don't feel like
> >>>> defining an owner, so I just leave my mess for the
> >>>> janitor, whom I assume will clean up for me in a proper
> >>>> way."
> >> Well said.
> > So why do companies like those I work for hire janitors,
> > rather than requiring the engineers to sweep the floors?
> Admitedly, sweeping the floors and emptying the wastebasket
> isn't necessarily an engineer function (and I concede those to
> be distractions). The complaint against GC in C++ is that
> it's not that simple: I make a mess leaving papers all over
> my office (on the walls, floor, and my desk), and the janitor
> is just supposed to "know" which things he should throw away
> because I won't put them in the wastebasket myself.
> It's so annoying when the janitor erases my whiteboard and
> I lose important concepts, but he's just doing the best he
> can with the context he has.
I don't see the problem. Garbage collection (in C++ or
elsewhere) doesn't clean up anything you could possibly reuse.
There are cases where it fails to clean up things that you don't
intend to use, but in such cases, you can just tell it that you
don't want to use them, e.g. by setting the pointer to the
object to NULL.
> >> Ironically, after the mess is created, the creator of the
> >> mess often spends days (sometimes weeks) trying to recover
> >> the determinism that was lost by GC. I have already seen in
> >> recent months several occasions where a GC evangelist got
> >> himself into a nasty situation with garbage-collected code,
> >> fiddled around with his nasty code for a few days, then
> >> finally resorted to consutling a non-GC person to help him
> >> figure out how to force his GC stuff to be more
> >> deterministic. It's comical to watch.
> > How does garbage collection have any effect on determinism?
> > I fail to see the relationship. (But then, maybe that's
> > because I'm used to using garbage collection in C++ code.)
> There are many:
> - rules for order of destruction
Unchanged by garbage collection.
> - rules for reclaiming/updating dependant objects
There aren't any in C++. Garbage collection has no effect on
the ones you write.
> - circular "sets" of cross-referencing objects (where the whole
> set should be collected)
No problem with any of the garbage collectors I've used. (It is
a problem with some of the replacements, like shared_ptr.)
> - timeliness to reclaim large amounts of resources held
> by a single (or few) objects
I'm not sure what you're talking about here. If the resource is
memory, garbage collection will kick in if the memory is needed,
at the latest. If the resource isn't memory, garbage collection
has nothing to do with it, and while nothing is improved by
using garbage collection, nothing is made worse, either.
> - etc. (everybody bitten by Java GC knows many more)
I've never met anyone bitten by Java GC (and I've done major
projects in Java), so I wouldn't know. Are you sure you aren't
confusing this with other issues, like the absence of
destructors and on stack objects in Java, or the use of
exceptions even in cases where you really need to abort.
> If *logic* (i.e., "rules") are needed to "help" specify how to
> delete objects, then that should be managed by your model
> through your business logic and not in the GC (because indeed,
> the GC doesn't have sufficient context except for the simple
> case).
If an object needs explicit destruction, because the destructor
is concerned with more than just freeing memory, then you still
have to do whatever you're doing now. Garbage collection
doesn't help with anything but memory management. But it
doesn't make things worse, either; it's just neutral.
In practice, about 90% of the non-trivial destructors in my code
are concerned only with memory management, so that's 90% of the
classes where it could potentially help.
> > [...]
> >>>> I'd be *so sad* if the C++ standard got screwed up with
> >>>> GC, and I had to figure out how to work around it and shut
> >>>> it off.
> >> It might be 5 years from now, but eventually, the pro-GC
> >> people will realize that there is no susbtitute for good
> >> form.
> > Maybe some day, all programmers will be in my position,
> > where they are paid to produce solutions, as efficiently as
> > possible, and won't oppose tools that increase their
> > efficiency.
> If you spend days chasing "order of delete" problems and
> attempting to force re-claiming of resources in a
> time-sensitive manner, that's not an increase in efficiency.
But I don't. I use garbage collection in C++ today, and I've
never once seen any of these problems.
> I don't expect pro/anti GC agreement *ever*.
It's sort of like one scientists comments concerning relativity,
in the 1940's, I think. When asked whether there would ever be
agreement between the pro-relativity and the anti-, given that
the anti-'s weren't being convinced by the pro's, he said there
would be, as soon as all of the anti's retired. Some older
physicists, who grew up before relativity, simply refused to
accept it, but all newer physicists were adopting it.
Similarly, nobody who has actually used garbage collection in
C++ seems to oppose it, so presumably, once it becomes standard,
all new programmers will grow up not understanding what all the
fuss is about.
> Different languages cause you to think differently, and I
> don't dispute the value of GC in all cases -- it's great in
> Perl and Python (which I also use). My assertion is that for
> most OO designs, it's usually not a good way to view the
> problem since it allows you to *not* make fundamental
> decisions, like what objects should exist and who should own
> them.
Careful. Garbage collection has very little effect on your high
level design. It concerns memory (a very low level resource),
and NOT lifetime of object. It only enters into play when
you're far enough along in your design to know which objects
really do have a concrete and deterministic lifetime, and which
are just there, and which don't have any particular lifetime
issues. Having gotten that far, garbage collection frees you
from the bother of having to develop code to ensure the proper
freeing of these latter; it can also be used to ensure that
accidentally using an object whose deterministic lifetime has
ended provokes an immediate and recognizable error, rather than
some random behavior.
> I don't care that "scalars" and "hashes/dictionaries"
> come-and-go all the time in other languages (cleaned up by
> GC), but in C++ I want my strongly typed object lifecycles to
> be decided deliberately, because they exist for a specific
> purpose, because they are strongly typed.
And true strong typing requires garbage collection, so we agree.
> > Actually, I think that is already the case in a lot of
> > cases. There definitly seems to be a lot of support for
> > garbage collection amongst the C++ programmers I've talked
> > to. (Including a number of committee members---a vote in
> > the last committee meeting indicated a definite consensus
> > for at least persuing the issue.)
> Understood. IMHO, though, I'd rather something like that be
> external (like through BOOST) and not part of the language,
> since it attempts to solve a problem I don't have.
If you've got infinite memory, then of course, memory management
is a problem you don't have. Otherwise, it is a problem you
have. The fact that you have good solutions for it doesn't
change the fact that it implies writing additional code, which
in turn means more work. The difference is far from as great as
some people might think, but it is still significant.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
> kanze wrote:
> > charl...@gmail.com wrote:
> >>> Walter Bright spaketh:
> >>> [...]
> >>>> C++ should have acquired GC about 15 years ago.
> >> Gene Bushuyev replied:
> >>> <snip, > And the reason that there is no GC neither in the
> >>> C++ Standard nor as a typical extension is the lack of
> >>> demand. Good C++ practices tend to produce the objects
> >>> with automatic storage duration. Resourse management is
> >>> done in ctor/dtor, which is robust, flexible and
> >>> deterministic.
> >> THANK YOU, Gene.
> > For the false illusion? There IS a large demand for garbage
> > collection in C++. The standards committee is seriously
> > considering it for the next version of the standard. Third
> > party companies are successfully selling garbage collection
> > as an add in, and an open source implementation is widely
> > used. <,snip>
> They can consider it all they want. ;-) I was just happy to
> hear a dissenting view (GC isn't universally desired in C++).
The problem is that the dissenting view comes uniquely from
people who don't know garbage collection, and consists either of
vacuous statements that don't really mean anything, or of
complaints about things that aren't problems, and that shows
their lack of knowledge on the subject. If you take Gene's
statements:
-- There is a demand, a very strong demand. The people working
on the issue in the C++ standards committee are doing so
because there is a demand. The people in the committee who
voted in favor of it also did so because there is a demand.
-- Good C++ practices does include using automatic objects as
much as possible. I don't think anyone would dispute that.
But what does that have to do with garbage collection?
-- Resource management, in general is done in the destructor.
Memory happens to be a very special resource, however, for
which a good alternative exists. Why write code when you
don't need to?
> >> I bite my tongue every time GC comes up. <snip, has
> >> utility in other languages but not C++>,
> >> I would *never* use GC [...in C++]
> > That's an interesting statement, because compile-time static
> > typing for dynamically allocated objects requires garbage
> > collection. It can't be done otherwise, or at least, I
> > don't think so. C++ implementations don't do it; they use
> > the "undefined behavior" to let them off the hook.
> My assertion is that the stronger the type, and the more
> mature the design, the more deliberate you want to be in
> controlling your object lifecycle (and not leave anything to
> an external system, which GC is, because GC doesn't have your
> model dependencies and business logic).
Your assertion doesn't hold water. Strong typechecking of
dynamically allocated objects requires garbage collecction.
Strong typechecking means that if I have a T*, it is either
null, or points to an object of type T (or derived from type
T---but polymorphism is actually a contradiction with strong
static typechecking). If the object to which a pointer points
can cease to exist while the pointer still exists, than you
don't have strong typechecking.
Perfectly strong typechecking probably isn't desirable. Or
rather, the cost---forbidding pointers to local objects---is
probably higher than the gains you'd get for it. There's also
the fact that garbage collection can't prevent objects from
logically ceasing to exist, even though pointers to them exist.
The best you can do is dynamic checking; garbage collection does
ensure that the memory underlying the object doesn't get
recycled as long as a pointer to it exists, so you can add flags
and runtime checks to detect the error.
> >> IMHO, for most OO, it's simply a bad way to view the problem.
> >> For the *vast* majority of our designs, object ownership is
> >> defined through well-understood containment within
> >> well-defined (logical) abstractions.
> > A large majority, yes. And there are certainly objects for
> > which garbage collection is not really the right solution
> > (although even with such objects, it permits some form of
> > type safety, which isn't possible otherwise). I have, in
> > fact, often wished for a sort of reverse garbage collection
> > as well: rather than deleting an object when there are no
> > more pointers to it, it would get rid of all pointers to an
> > object when it the object is deleted.
> What you're calling GC and "reverse" GC, I'm suggesting is
> better handled with business logic as defined through your
> model (since it actually knows what all your types mean
> anyway).
Reverse GC must be handled through business logic, because there
is no alternative. It usually involves not a few lines of code,
which have to be written and maintained. GC can be successfully
handled through business logic. It also involves additional
lines of code, which have to be written and maintained. When
there exists a perfectly working alternative, it would be
foolish not to use it. (And unprofessional: my customers don't
pay me to write unnecessary lines of code; they pay me to
produce solutions, as efficiently as possible.)
> > The fact that it isn't necessary all of the time doesn't
> > mean that it isn't useful in enough cases to be worthwhile.
> I use GC all the type in Perl. I go decades without it in C++.
> I concede the point that if that's how you view design, GC is
> a valid computer science artifact to legitimately address some
> problems in some domains. (I'd just prefer it to be in a
> library external to the C++ standard itself.)
I can understand that. The problem is that it can be done much
more efficient if the compiler collaborates. The other argument
in favor of a language solution is that it will also be possible
to declare, at the language level, that some code is
incompatible with garbage collection. Which is an important
point as well: while there is close to a consensus that adding
garbage collection would improve C++, there is also a very
strong consensus that it must remain possible to write C++
programs without it.
> >> If it's not, IMHO, you are missing key abstractions.
> > It depends on the object. Many objects DO have explicit
> > lifetimes. All garbage collection brings to them is an
> > ability to detect the errors: an explicit and understandable
> > error message, instead of undefined behavior. Many others
> > however, don't really need an explicit lifetime, as long as
> > they are there when needed (i.e. someone holds a pointer to
> > them). For those, garbage collection is THE solution. (And
> > of course, a lot of objects have value semantics, and should
> > probably never be allocated dynamically anyway. For those,
> > of course, garbage collection is irrelevant.)
> You're describing a case where I agree in some GC utility:
> When many "trivial" non-connected objects are popping in and
> out, all over the system. That's how Perl/Python work too,
> and GC is quite handy there.
> I don't commonly find that design in most C++ systems (the
> types are stronger, and they have better "knowledge" of whom
> they reference since that's the business logic).
I certainly agree that not everything should be garbage
collected. My value objects are still pretty much always on the
stack, as are my RAII objects. My business entity objects also
continue to have explicit lifetimes, although I count on garbage
collection to recover the memory. (It saves a few lines of
code, but nothing dramatic.) But there remain enough other
objects (maybe 10 or 20%) for which garbage collection is a
significant gain. And one or two places where the alternatives
are really awkward.
> >> <snip>,
> >> All GC does is say, "I create objects but don't feel like
> >> defining an owner, so I just leave my mess for the janitor,
> >> whom I assume will clean up for me in a proper way."
> > It's not a question of feeling, but of design. There are
> > objects for which artificially designating an owner is just
> > extra work, and is, in fact, an artifact of a weakness in the
> > language.
> The original statement suggests the janitor doesn't have
> sufficient context to make decisions about what should be
> cleaned up, when, how, and in what order.
Actual experience shows that he does.
> Yes, I concede the point that GC can work well for the
> "trivial" case where the object isn't coupled to anything and
> no other specifal considerations exist.
> Unfortunately, I find that small (normal) changes to a design
> results in your system now having "non-trivial" cleanup
> considerations that GC can't handle. In that case, I find
> that rather than getting GC to "behave properly", it would
> have been faster/easier/more robust/more correct to simply
> address object lifecycles in my design.
> >> I'd be *so sad* if the C++ standard got screwed up with GC,
> >> and I had to figure out how to work around it and shut it
> >> off.
> > If you don't like being more productive, that's
> > understandable. If you're paid by the line, garbage
> > collection will certainly reduce your income.
> Now, now, be nice. ;-) You're a smart guy that raises valid
> points, so I'm merely attempting to respond honestly.
I appreciate technical arguments. But in the past, we've heard
garbage collection opponents bringing up arguments that it was
only laziness, etc. And it's very hard to respond to arguments
which are completely irrelevant (and often honestly made, simply
because the person in question doesn't really know what garbage
collection is, or how it is used). A statement like "the
standard got screwed up with GC" is loaded. It isn't a
technical argument, but rather presupposes the premise. The C++
standard will not be "screwed up" by garbage collection, and
believe it or not, the people working hardest to add it to the
standard do take into account that there are also times that it
isn't appropriate.
> But, my original comment was true: I'd be sad if GC were
> added to C++, and I'd try to find a way to shut it off,
> because I don't have use for it (even considering my honest
> goal for productivity ;-).
Well, prepare to be sad. And although it shouldn't be difficult
to turn off, I'd suggest that you leave it on. Anywhere objects
have a determistic lifetime, they continue to have one. But
there are (and will continue to be) objects which are just gobs
of data, or just agents, whose lifetime is irrelevant to the
application. If such an object is owned and used by just one
client, you'll save maybe one line in the destructor; you might
save a little in the class definition as well, because you won't
have to think about what type of pointer to use to ensure
exception safety. If the object is effectively used by several
clients, on the other hand, you'll save a significant amount of
work by letting garbage collection take care of it.
This obviously doesn't apply to all objects. You still have to
analyse what the lifetime should be. The only difference is
that with garbage collection, when the anaysis shows that no
particular lifetime management is necessary, you're work is
done; without garbage collection, you still have to be concerned
with the memory management issue down to the lowest coding
levels. And that's extra work. It's more lines of code to
write and to maintain.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
> >> THANK YOU, Gene.
Hampered in what way? My productivity has certainly been
increased since I've started using garbage collection; not being
able to use it in some contexts (e.g. because of a risk of
incompatibility with a third party library) certainly hampers my
productivity.
> If you provide a convincing example, nobody will argue about
> it anymore.
What's more convincing than actual experience.
>So far nothing in this long thread demonstrated there are such
>cases. I haven't seen the arguments indicating that RAII
>design principle is lacking. Discussions of the string class
>or shared_ptr didn't add anything to the claims that GC is
>useful and necessary.
Garbage collection is pretty irrelevant with regards to RAII.
Perhaps nobody bothered mentionning with regards to a string
class, simply because it seemed trivially obvious that a string
class would be easier to write if garbage collection were
present (and generally faster as well). And in the shared_ptr
discussions, it's often been pointed out that shared_ptr is a
poor replacement for real garbage collection: error prone,
awkward, and with a significant negative effect on performance.
It's obviously not "necessary"---we've written correct C++
applications without it. In the same way, templates aren't
necessary (I made extensive use of <generic.h> in the past),
nor classes (I've written large applications in C).
It's just as obvious that it is an effective tool when used
where appropriate. At the very least, you write every thing as
you always have, and you loose nothing. In almost all
applications, however, there will be cases where it will mean a
few less lignes of code, so the total effect is a gain.
> On the other hand, my experience tells me that nobody wants to
> use the Visual C++ GC extensions unless forced to do so.
That's not the impression I get here, but it varies. I've no
particular desire to use managed C++, but that's beside the
point. I do actively use the Boehm collector in my C++ on Unix
based platforms, and I can speak from experience on that one
point: it definitly improves my productivity, by reducing the
number of lines I have to write.
> I don't use them, though they are readily available and
> despite the fact that this feature was touted by MS for
> several years. I also downloaded Boehm collector out of
> curiosity a couple of years ago and I'm still waiting for the
> problem that would make it a solution.
It's *a* solution anytime you have to manage memory. I think
you know that. Whether it is the best solution depends on the
application, but I've found it to be a cost efficient solution
in many cases. Obviously, I didn't wait until I had a problem I
didn't know how to solve otherwise before trying it, however.
> There were also some claims elsewhere in this thread that GC
> can happily coexist with C++ deterministic destruction. But
> if the destruction (GC finalization) is deterministic then I
> don't care whether there is GC or not, I manage the life time
> of objects as without GC.
Destruction and GC finalization are two totally unrelated
concepts. In the rare cases where you need deterministic
destruction, GC doesn't help. (At least the way I use it,
destructors are never called for garbage collected objects.)
> GC becomes a detail of memory allocator implementation.
> Compiler is free to implement any of many memory allocation
> schemes, C++ doesn't prevent memory allocators to delay reuse
> of the storage for deleted objects until collection time, and
> the program doesn't need to know that.
It doesn't need to. On the other hand, knowing that the
compiler will do this, and being able to count on it, means that
there is some code which doesn't need writing. It's as simple
as that.
> On the other hand, in the presence of GC, why would anybody
> try to make GC based objects behave deterministically? - It
> only adds a pain to the programmer to jump over the hoops and
> fight GC. If you want deterministic destruction, you
> definitely don't want GC; if you want GC, you definitely don't
> want deterministic destruction, in fact you don't want any
> non-trivial destruction; - the two don't blend together, one
> fighting the other.
You are assuming that all objects must conform to the same
approach. In practice, this is far from the case already in
real programs---I once tried to implement an application where
the only pointers were boost::shared_ptr, and it doesn't work.
Regardless of the application, different types of objects have
different requirements. The fact that some object types can't
use garbage collection effectively, or shouldn't be used with
garbage collection, doesn't mean that you don't gain with the
other objects. And you have to do the analysis anyway---with or
without garbage collection, object lifetime must be considered
at the design level. It's only when you start coding that
garbage collection comes into play---for certain objects, it
means that you need zero lines of code to ensure the termination
of the object lifetime.
> Finally, below are some popular myths about C++ that I mined
> on the web:
Don't believe everything you read on the web:-). (Or elsewhere,
for that matter---I've found errors in the Encyclopaedia
Brittanica.)
> 1) "C++ programmers spend large chunks of their time designing
> for explicit storage management and tracking down storage
> bugs." In another place a 30-40% reduction in development
> time is promissed. Not true.
Large chucks is probably true, for a sufficiently small enough
value of large:-). 30%-40% sounds large, even for just the gain
in coding time. (And if we consider that over 50% of the total
development time is spent in design, and that garbage collection
has little effect there...) But even 10% is not to be sneezed
at.
(Note too that if you do make an error in storage management, it
can take an awfully long time to track down. Garbage
collection, by reducing the number of lines of code, does reduce
the probability of such an error. On the other hand, good code
review reduces it even more.)
> Designing RAII into classes or choosing the proper smart
> pointers is the simplest task during project design and takes
> little time and efforts.
Designing RAII for use when appropriate is certainly a good
idea. Chosing the correct smart pointer, however, is far from
trivial, since no one pointer handles all of the cases
correctly.
> Relying on GC will probably create more bugs and slow the
> development down
Why? That doesn't correspond to my actual experience.
> because managing objects life-times and proper ownership were
> not seriously considered,
This is an argument that I cannot understand. How is it that
using garbage collection will turn normally competent
programmers into babbling idiots? Since when does garbage
collection prevent me from managing object lifetimes, when
appropriate. And I've posted more than once here that even
with garbage collection, I use auto_ptr is specific cases where
the previous owner should not be allowed access to the object
after handing off ownership.
In fact, I'd argue that this latter case is really a strong
argument in favor of garbage collection. Smart pointers mix two
different concepts of ownership: who has a right to access, and
who is responsible for freeing the memory. Eliminate the
latter, and you're free to use smart pointers much more
effectively.
> thus producing more logical bugs and increasing development
> time.
Your claims are, again, in contradiction with actual experience.
> 2) "Dangling pointers, storage leaks, memory smashes, and
> out-of- bounds array indices are the bane of the C++
> programmer and his customers."
That's true as far as it goes. Regretfully, they're also the
bane of Java programmers and their customers. Because...
> Not true as long as good software design principles are
> followed.
Perfectly correct. Irrelevant with regards to garbage
collection, however; nobody in his right mind would claim that
garbage collection changes anything here. If you don't follow
good software design principles, your code won't work. If you
do, it will. Garbage collection or no, in both cases. (And of
course, you could replace "garbage collection" with any other
feature you choose, and still have just as true a statement.)
In the end, your argument against garbage collection is
basically that you believe that it will turn normally
intelligent, profession people into babbling irresponsible
idiots. Do you have any evidence to support such a claim; it
sounds pretty preposterous to me.
I'm very convinced that if an organization is unable to produce
quality software without feature X (for all possible X), then it
will also be unable to produce it with feature X. The
difference is in the cost of doing so. If your organization
doesn't know how to produce quality code without garbage
collection, garbage collection won't change that. If your
organization does know how to produce quality code without
garbage collection, however, garbage collection will usually
reduce the cost of doing so.
> There are bad programmers of course who program sloppily. The
> problem is not the deficiency of the tool (C++), but
> incompetence of some practitioners.
Or the organizations in which they work. Nobody is claiming
that garbage collection will turn incompetent idiots into
careful, competent programmers. There's no silver bullet.
Garbage collection will reduce the time careful, competent
programmers need to produce correct code for a given
application.
> As somebody said, if the language allows you to jump off the
> cliff, it doesn't mean you have to do it.
So the fact that it is possible to misuse garbage collection
isn't an argument against it.
> The solution to sloppy programmers is not GC, but education.
> Just like the solution to a messy dog is training and not an
> intelligent vacuum cleaner. Otherwise with or without GC the
> programm will be a mess anyway.
Totally agreed. But who's arguing anything along those lines.
> 3) "Some of the most complicated aspects of C++ arise from
> using constructors and destructors to make up for the lack of
> garbage collection."
I've never heard this one myself, even from the most wide eyed
fanatics.
Let's get one thing clear: constructors and destructors are one
of the most important security aspects C++ has to offer. And I
certainly wouldn't give them up to get garbage collection. But
I don't have to. The C++ I currently use supports both. I use
both.
> Well, if understanding ctor/dtor mechanism is so complicated
> for somebody, maybe (s)he needs to find a simpler language -
> Basic, Java? Those language are pretty simple as long as you
> don't need to do anything for which there isn't a ready
> solution in the library.
Don't exagerate. Java's actually pretty usable for small to
medium sized applications, as long as you don't have to be too
robust. But it's clear that once you've grown used to the
robustness that constructors and destructors allow, it's hard to
go back. (Provided you value robustness, of course.)
But where's the argument vis-à-vis garbage collection here?
Guilt by association? My reading of your argument is: lack of
destructors is bad (we agree), thus, Java is bad (an
overstatement, since one one feature can be considered make or
break, but I'll let it go), Java has garbage collection, so
garbage collection is bad. That last jump doesn't correspond to
any principle of logic I'm familiar with---it's along the lines
of "I once met an X who was dishonest, thus, all X are stupid."
> There is a misconception that GC would free a programmer from
> properly designing constructors and destructors.
Not in my mind. I imagine that this misconception isn't shared
by many of the committee members who voted in favor of garbage
collection, either.
> Not true. For example, a class that has a pointer has to
> decide the proper copy construction and assignment, whether it
> needs a shallow or a deep copy of the object that the pointer
> reffers to, or whether to transfer ownership or share it. If
> anything, GC is only capable of concealing the real design
> issues, not helping solving them.
I don't see where it conceals anything, unless you want it to.
It only means that in certain cases, I will have less lines of
code to write.
> 4) garbage collection will make C++ "safe"
> No. There is more than one way to screwing things up.
> Programmers that can't manage memory well, can't manage the
> other things either. If somebody expects his "unsafe" C++
> programs to become "safe" after adding GC he is setting
> himself up for a big disappointment.
Come on. Garbage collection isn't a silver bullet. There is no
silver bullet. We all know that. You're just setting up
strawmen to knock down.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
> kanze wrote:
> > charl...@gmail.com wrote:
> >>> Walter Bright spaketh:
> >>> [...]
> >>>> C++ should have acquired GC about 15 years ago.
> >> Gene Bushuyev replied:
> >>> <snip, > And the reason that there is no GC neither in the
> >>> C++ Standard nor as a typical extension is the lack of
> >>> demand. Good C++ practices tend to produce the objects
> >>> with automatic storage duration. Resourse management is
> >>> done in ctor/dtor, which is robust, flexible and
> >>> deterministic.
> >> THANK YOU, Gene.
> > For the false illusion? There IS a large demand for garbage
> > collection in C++. The standards committee is seriously
> > considering it for the next version of the standard. Third
> > party companies are successfully selling garbage collection
> > as an add in, and an open source implementation is widely
> > used. <,snip>
> They can consider it all they want. ;-) I was just happy to
> hear a dissenting view (GC isn't universally desired in C++).
The problem is that the dissenting view comes uniquely from
people who don't know garbage collection, and consists either of
vacuous statements that don't really mean anything, or of
complaints about things that aren't problems, and that shows
their lack of knowledge on the subject. If you take Gene's
statements:
-- There is a demand, a very strong demand. The people working
on the issue in the C++ standards committee are doing so
because there is a demand. The people in the committee who
voted in favor of it also did so because there is a demand.
-- Good C++ practices does include using automatic objects as
much as possible. I don't think anyone would dispute that.
But what does that have to do with garbage collection?
-- Resource management, in general is done in the destructor.
Memory happens to be a very special resource, however, for
which a good alternative exists. Why write code when you
don't need to?
> >> I bite my tongue every time GC comes up. <snip, has
> >> utility in other languages but not C++>,
> >> I would *never* use GC [...in C++]
> > That's an interesting statement, because compile-time static
> > typing for dynamically allocated objects requires garbage
> > collection. It can't be done otherwise, or at least, I
> > don't think so. C++ implementations don't do it; they use
> > the "undefined behavior" to let them off the hook.
> My assertion is that the stronger the type, and the more
> mature the design, the more deliberate you want to be in
> controlling your object lifecycle (and not leave anything to
> an external system, which GC is, because GC doesn't have your
> model dependencies and business logic).
Your assertion doesn't hold water. Strong typechecking of
dynamically allocated objects requires garbage collecction.
Strong typechecking means that if I have a T*, it is either
null, or points to an object of type T (or derived from type
T---but polymorphism is actually a contradiction with strong
static typechecking). If the object to which a pointer points
can cease to exist while the pointer still exists, than you
don't have strong typechecking.
Perfectly strong typechecking probably isn't desirable. Or
rather, the cost---forbidding pointers to local objects---is
probably higher than the gains you'd get for it. There's also
the fact that garbage collection can't prevent objects from
logically ceasing to exist, even though pointers to them exist.
The best you can do is dynamic checking; garbage collection does
ensure that the memory underlying the object doesn't get
recycled as long as a pointer to it exists, so you can add flags
and runtime checks to detect the error.
> >> IMHO, for most OO, it's simply a bad way to view the problem.
> >> For the *vast* majority of our designs, object ownership is
> >> defined through well-understood containment within
> >> well-defined (logical) abstractions.
> > A large majority, yes. And there are certainly objects for
> > which garbage collection is not really the right solution
> > (although even with such objects, it permits some form of
> > type safety, which isn't possible otherwise). I have, in
> > fact, often wished for a sort of reverse garbage collection
> > as well: rather than deleting an object when there are no
> > more pointers to it, it would get rid of all pointers to an
> > object when it the object is deleted.
> What you're calling GC and "reverse" GC, I'm suggesting is
> better handled with business logic as defined through your
> model (since it actually knows what all your types mean
> anyway).
Reverse GC must be handled through business logic, because there
is no alternative. It usually involves not a few lines of code,
which have to be written and maintained. GC can be successfully
handled through business logic. It also involves additional
lines of code, which have to be written and maintained. When
there exists a perfectly working alternative, it would be
foolish not to use it. (And unprofessional: my customers don't
pay me to write unnecessary lines of code; they pay me to
produce solutions, as efficiently as possible.)
> > The fact that it isn't necessary all of the time doesn't
> > mean that it isn't useful in enough cases to be worthwhile.
> I use GC all the type in Perl. I go decades without it in C++.
> I concede the point that if that's how you view design, GC is
> a valid computer science artifact to legitimately address some
> problems in some domains. (I'd just prefer it to be in a
> library external to the C++ standard itself.)
I can understand that. The problem is that it can be done much
more efficient if the compiler collaborates. The other argument
in favor of a language solution is that it will also be possible
to declare, at the language level, that some code is
incompatible with garbage collection. Which is an important
point as well: while there is close to a consensus that adding
garbage collection would improve C++, there is also a very
strong consensus that it must remain possible to write C++
programs without it.
> >> If it's not, IMHO, you are missing key abstractions.
> > It depends on the object. Many objects DO have explicit
> > lifetimes. All garbage collection brings to them is an
> > ability to detect the errors: an explicit and understandable
> > error message, instead of undefined behavior. Many others
> > however, don't really need an explicit lifetime, as long as
> > they are there when needed (i.e. someone holds a pointer to
> > them). For those, garbage collection is THE solution. (And
> > of course, a lot of objects have value semantics, and should
> > probably never be allocated dynamically anyway. For those,
> > of course, garbage collection is irrelevant.)
> You're describing a case where I agree in some GC utility:
> When many "trivial" non-connected objects are popping in and
> out, all over the system. That's how Perl/Python work too,
> and GC is quite handy there.
> I don't commonly find that design in most C++ systems (the
> types are stronger, and they have better "knowledge" of whom
> they reference since that's the business logic).
I certainly agree that not everything should be garbage
collected. My value objects are still pretty much always on the
stack, as are my RAII objects. My business entity objects also
continue to have explicit lifetimes, although I count on garbage
collection to recover the memory. (It saves a few lines of
code, but nothing dramatic.) But there remain enough other
objects (maybe 10 or 20%) for which garbage collection is a
significant gain. And one or two places where the alternatives
are really awkward.
> >> <snip>,
> >> All GC does is say, "I create objects but don't feel like
> >> defining an owner, so I just leave my mess for the janitor,
> >> whom I assume will clean up for me in a proper way."
> > It's not a question of feeling, but of design. There are
> > objects for which artificially designating an owner is just
> > extra work, and is, in fact, an artifact of a weakness in the
> > language.
> The original statement suggests the janitor doesn't have
> sufficient context to make decisions about what should be
> cleaned up, when, how, and in what order.
Actual experience shows that he does.
> Yes, I concede the point that GC can work well for the
> "trivial" case where the object isn't coupled to anything and
> no other specifal considerations exist.
> Unfortunately, I find that small (normal) changes to a design
> results in your system now having "non-trivial" cleanup
> considerations that GC can't handle. In that case, I find
> that rather than getting GC to "behave properly", it would
> have been faster/easier/more robust/more correct to simply
> address object lifecycles in my design.
> >> I'd be *so sad* if the C++ standard got screwed up with GC,
> >> and I had to figure out how to work around it and shut it
> >> off.
> > If you don't like being more productive, that's
> > understandable. If you're paid by the line, garbage
> > collection will certainly reduce your income.
> Now, now, be nice. ;-) You're a smart guy that raises valid
> points, so I'm merely attempting to respond honestly.
I appreciate technical arguments. But in the past, we've heard
garbage collection opponents bringing up arguments that it was
only laziness, etc. And it's very hard to respond to arguments
which are completely irrelevant (and often honestly made, simply
because the person in question doesn't really know what garbage
collection is, or how it is used). A statement like "the
standard got screwed up with GC" is loaded. It isn't a
technical argument, but rather presupposes the premise. The C++
standard will not be "screwed up" by garbage collection, and
believe it or not, the people working hardest to add it to the
standard do take into account that there are also times that it
isn't appropriate.
> But, my original comment was true: I'd be sad if GC were
> added to C++, and I'd try to find a way to shut it off,
> because I don't have use for it (even considering my honest
> goal for productivity ;-).
Well, prepare to be sad. And although it shouldn't be difficult
to turn off, I'd suggest that you leave it on. Anywhere objects
have a determistic lifetime, they continue to have one. But
there are (and will continue to be) objects which are just gobs
of data, or just agents, whose lifetime is irrelevant to the
application. If such an object is owned and used by just one
client, you'll save maybe one line in the destructor; you might
save a little in the class definition as well, because you won't
have to think about what type of pointer to use to ensure
exception safety. If the object is effectively used by several
clients, on the other hand, you'll save a significant amount of
work by letting garbage collection take care of it.
This obviously doesn't apply to all objects. You still have to
analyse what the lifetime should be. The only difference is
that with garbage collection, when the anaysis shows that no
particular lifetime management is necessary, you're work is
done; without garbage collection, you still have to be concerned
with the memory management issue down to the lowest coding
levels. And that's extra work. It's more lines of code to
write and to maintain.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
> kanze wrote:
> > For the false illusion? There IS a large demand for garbage
> > collection in C++. The standards committee is seriously
> > considering it for the next version of the standard. Third
> > party companies are successfully selling garbage collection
> > as an add in, and an open source implementation is widely
> > used.
> > None of which, of course, says that we should abandon value
> > semantics for value oriented types, nor drop constructors
> > and destructors.
> Exactly. Plenty of people want GC (as an option), but don't
> want to see Java's GC, or anything but a natural C++ GC, that
> doesn't break the rest of the language.
What is Java's garbage collection? The problem(s) with Java
have nothing to do with garbage collection.
> Still, there are more options than just GC and manual
> new/delete.
Certainly, and the more options, the better. (Provided, of
course, that you don't pay for what you don't use.)
> If GC's added, it's gotta be defined well enough that people
> can still get as much control over the process as they need,
> and it has to be friendly to _all_ the other features of the
> language.
I think that's a foregone conclusion, shared by every (or almost
every) member of the committee.
> > > I bite my tongue every time GC comes up. I understand its
> > > utility, as I understand the value of high-level scripting in
> > > langauges like Perl/Python/Ruby. Further, I understand the
> > > value of "higher-level" OO languages with GC and dynamic
> > > typing, like Smalltalk and Lisp.
> > > But, that's not C++ with its compile-time static typing. I
> > > would *never* use GC.
> > That's an interesting statement, because compile-time static
> > typing for dynamically allocated objects requires garbage
> > collection. It can't be done otherwise, or at least, I don't
> > think so. C++ implementations don't do it; they use the
> > "undefined behavior" to let them off the hook.
> I really haven't the faintest clue what you mean here. Mind
> explaining a bit?
The basic principle is fairly simple, I think. If I have a T*,
it must either be null, or point to an object of type
T---otherwise, the language isn't typesafe. If someone can
delete the object, then my pointer points to raw memory, which
is neither a T nor a null pointer. And if by chance, the raw
memory is then reallocated, my pointer may even point to an
object of an entirely different type.
To obtain this total degree of type safety in C++ isn't
practical, since it requires three things:
-- mandatory garbage collection, so that the memory can't be
recycled,
-- no destructors (or any equivalent) on dynamic objects, so
that the object can't cease to exist even if the memory
isn't freed, and
-- a prohibition against pointers to local objects, since local
objects cease to exist when they go out of scope.
Since no one is suggesting that garbage collection by mandatory,
and the cure for the latter two introduces far more problems
than it solves, we're not about to see true 100% static type
safety in C++. (The addition of garbage collection does mean
that you get type safety for dynamically allocated objects which
aren't deleted. Which is something, anyway.)
> > > IMHO, for most OO, it's simply a bad way to view the problem.
> > > For the *vast* majority of our designs, object ownership is
> > > defined through well-understood containment within
> > > well-defined (logical) abstractions.
> > A large majority, yes. And there are certainly objects for
> > which garbage collection is not really the right solution
> > (although even with such objects, it permits some form of type
> > safety, which isn't possible otherwise). I have, in fact, often
> > wished for a sort of reverse garbage collection as well: rather
> > than deleting an object when there are no more pointers to it,
> > it would get rid of all pointers to an object when it the object
> > is deleted.
> How does that compare to boost::weak_ptr<>?
It goes further. It doesn't just put the pointer into a
testable, invalid state, it actually removes it. (In practice,
I've found boost::weak_ptr pretty useless in such cases. All
too often, the object is in a map or a set, or something like
that, and you don't want to just change the value---if it's in a
set, you can't, anyway---but to remove it from the container.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Seungbeom Kim
> >
> > Careful. Garbage collection has very little effect on your high
> > level design. It concerns memory (a very low level resource),
> > and NOT lifetime of object.
I have to make sure what GC actually means in practice...
Isn't it about not having to explicitly write 'delete' expressions
when you don't need the objects, and GC's automatically taking care of
it? And we all know that 'delete' expressions do two things: destroying
the object by calling the destructor, and releasing the memory. Then how
is it possible that GC does not concern lifetime of objects?
--
Seungbeom Kim
Bo Persson
"Seungbeom Kim" <musi...@bawi.org> skrev i meddelandet
news:e9p380$7a2$1...@news.Stanford.EDU...
> kanze wrote:
>> >
>> > Careful. Garbage collection has very little effect on your high
>> > level design. It concerns memory (a very low level resource),
>> > and NOT lifetime of object.
>
> I have to make sure what GC actually means in practice...
>
> Isn't it about not having to explicitly write 'delete' expressions
> when you don't need the objects, and GC's automatically taking care
> of
> it? And we all know that 'delete' expressions do two things:
> destroying
> the object by calling the destructor, and releasing the memory. Then
> how
> is it possible that GC does not concern lifetime of objects?
Because it doesn't bother with the objects, it just recycles the
memory.
Technically, the object is still there if the destructor never runs,
but we cannot tell the difference as we cannot reach the object
anyway.
Objects that have a non-trivial destructor will have to be deleted as
before, others can just be dropped.
char* p = new char[1000];
p = 0;
will not leak the memory with GC. That the destructor for the chars
doesn't run is not a big problem.
Bo Persson
Hyman Rosen
> I have to make sure what GC actually means in practice...
>
> Isn't it about not having to explicitly write 'delete' expressions
> when you don't need the objects, and GC's automatically taking care of
> it? And we all know that 'delete' expressions do two things: destroying
> the object by calling the destructor, and releasing the memory. Then how
> is it possible that GC does not concern lifetime of objects?
GC does not (or should not) call destructors on objects,
just make their memory available for reuse. The lifetime
of those objects is (logically) endless.
Joel Eidsath
> > set should be collected)
>
> No problem with any of the garbage collectors I've used. (It is
> a problem with some of the replacements, like shared_ptr.)
_Shared pointers instead of Garbage Collection_
Would a shared_ptr that did take care of circular dependencies be an
acceptable alternative to garbage collection? Performance would not be
as good as a garbage collector, but it would be an approach without the
serious technical difficulties brought on by trying to wed garbage
collection to C++. The main benefits of garbage collection that you've
claimed in your posts (increased programmer productivity through not
having to worry about object cleanup) would seem to be solved by this.
_Garbage Collection and Design_
In this thread I've seen only one good non-technical objection to
adding garbage collection to C++: garbage collection leads to sloppy
design.
Another programmer ease-of-use technique is automatic typing and that
definitely leads to sloppy design. I don't see garbage collection as
leading to anything as bad as this, but it seems important to me to
weigh this concern. That garbage collection seems to alter the basic
design of programs seems undeniable.
Andrei Alexandrescu (See Website For Email)
> Gene Bushuyev wrote:
>>2) "Dangling pointers, storage leaks, memory smashes, and
>>out-of- bounds array indices are the bane of the C++
>>programmer and his customers."
>
>
> bane of Java programmers and their customers. Because...
I'll bite. Because... what?
Andrei
James Dennett
> kanze wrote:
>>> Careful. Garbage collection has very little effect on your high
>>> level design. It concerns memory (a very low level resource),
>>> and NOT lifetime of object.
>
> I have to make sure what GC actually means in practice...
>
> Isn't it about not having to explicitly write 'delete' expressions
> when you don't need the objects, and GC's automatically taking care of
> it?
No.
GC, as usually discussed in the context of C++, is about
reclamation of unreferenced memory to simulate a better
approximation to unlimited memory. It just lets you
forget about cleaning up *memory*. Other resources
still need to be handled the same way as in current C++.
> And we all know that 'delete' expressions do two things: destroying
> the object by calling the destructor, and releasing the memory. Then how
> is it possible that GC does not concern lifetime of objects?
Because GC is only really suitable for release of memory.
-- James
Andrei Alexandrescu (See Website For Email)
> Designing RAII into classes or choosing the proper smart
> pointers is
> the simplest task during project design and takes little time and
> efforts.
I won't even contend that, although one might, but allow me to just make
a little point around here.
So I understand you agree that smart pointers are (at least)
occasionally useful.
Then you might imagine a category of people working on projects for
which smart pointers would be particularly useful. Then smart pointers
would pervade such projects.
Then I'm sure you agree a point could be reached where some subset of
the following factors leads to too much of an annoyance:
a) Passing smart pointers around becomes too much of an efficiency
problem. With MT smart pointers the tipping point is particularly quick
to reach, but even ST smart pointers can significantly erode the code's
performance. This creates strong pressure to either use
pointers/references to smart pointers, or selectively use raw pointers
instead of smart pointers, both of which are a round trip back to the
problem we were solving with smart pointers. Besides, making the
decision on what cases ask for such bypassing of smart pointer semantics
has an ongoing development cost.
b) There are ownership cycles. Hopefully you also agree that this is not
always (and perhaps not even usually) a sign of bad design. I also think
you'd agree that ownership cycles may not be trivial to address robustly.
c) The structure of a project's team makes it hard to educate
programmers to properly and consistently use smart pointers. Hard does
not mean impossible, but it just translates in time spent on meetings,
code reviews etc.
d) The code uses lock-free programming that make it hard to devise and
implement algorithms for deterministic storage reclamation.
If you agree with the arguments before, you just agreed that there is a
non-null set of people and projects that could benefit from garbage
collection.
Andrei
Francis Glassborow
<musi...@bawi.org> writes
>I have to make sure what GC actually means in practice...
>
>Isn't it about not having to explicitly write 'delete' expressions
>when you don't need the objects, and GC's automatically taking care of
>it? And we all know that 'delete' expressions do two things: destroying
>the object by calling the destructor, and releasing the memory. Then how
>is it possible that GC does not concern lifetime of objects?
No, you have missed the point. For example a dynamic object with a
trivial destructor (i.e. there is no resource to release) need not be
'deleted', GC will look after the recovery of memory when the last
pointer goes out of scope.
That is just one very simple example. In fact as soon as a dtor is
called an objects lifetime has ended though at that point the resources
will remain allocated until the dtor is exited,
I think the trouble is that you have taken a simplistic statement about
GC (meaning delete does not need to be used) as being what it is or
means.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
James Kanze
> kanze wrote:
>>> Careful. Garbage collection has very little effect on your high
>>> level design. It concerns memory (a very low level resource),
>>> and NOT lifetime of object.
> I have to make sure what GC actually means in practice...
> Isn't it about not having to explicitly write 'delete' expressions
> when you don't need the objects, and GC's automatically taking care of
> it? And we all know that 'delete' expressions do two things:
> destroying the object by calling the destructor, and releasing the
> memory. Then how is it possible that GC does not concern lifetime of
> objects?
Garbage collection is about managing memory. If the only reason you are
calling delete is to free the memory (the most frequent case in my
code), then you don't need it. If you are calling it for other reasons
(i.e. the destructor of the object does more than just free memory),
then you need it.
Obviously, this means distinguishing between categories of objects. But
we already have do that anyway, so there's no real additional constraint
here. About the only difference is that with garbage collection, there
is less code to write, and less code to debug.
--
James Kanze kanze...@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Gene Bushuyev
>> If you provide a convincing example, nobody will argue about
>> it anymore.
>
> What's more convincing than actual experience.
Ok, since the experience is the best criteria here, I did an experiment. I
counted all "delete" expressions in the last medium-size project. They represent
less than 0.1% of the number of lines of code. Practically all of them are due
to the third party library that didn't do the proper cleanup of its own objects.
You may ask, would the design be changed if GC were available, so the percentage
of its use would go up? I don't think so. When the choice is between a heap and
stack based object, I take the latter any day.
--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George Orwell
James Kanze
>>> - circular "sets" of cross-referencing objects (where the whole
>>> set should be collected)
>> No problem with any of the garbage collectors I've used. (It is
>> a problem with some of the replacements, like shared_ptr.)
> _Shared pointers instead of Garbage Collection_
> Would a shared_ptr that did take care of circular dependencies
> be an acceptable alternative to garbage collection?
> Performance would not be as good as a garbage collector, but
> it would be an approach without the serious technical
> difficulties brought on by trying to wed garbage collection to
> C++. The main benefits of garbage collection that you've
> claimed in your posts (increased programmer productivity
> through not having to worry about object cleanup) would seem
> to be solved by this.
I'm not too concerned about how garbage collection is
implemented, but I also don't see any reason to do it the hard
way, since better solutions exist. And of course, you don't
want to explicitly have to choose yet another pointer type.
> _Garbage Collection and Design_
> In this thread I've seen only one good non-technical objection
> to adding garbage collection to C++: garbage collection leads
> to sloppy design.
I'm not sure if you can consider it "good". Anything, misused,
can leat to sloppy design. Even without garbage collection, we
all know programmers coming from a Java background who allocate
everything on the stack---I don't see anyone suggesting that we
should deprecate new, however.
> Another programmer ease-of-use technique is automatic typing
> and that definitely leads to sloppy design. I don't see
> garbage collection as leading to anything as bad as this, but
> it seems important to me to weigh this concern. That garbage
> collection seems to alter the basic design of programs seems
> undeniable.
I don't think it does. I think that what alters the basic
design of programs is NOT having value semantics---there are
things that you can do in C++ that you cannot do in e.g. Java to
ensure the safety of your program.
The whole advantage C++ has over other languages is its support
for different paradigms. Anytime you only use one paradigm,
there's usually a better language for it, which specializes in
that paradigm. Java is, for example, an excellent language for
a small application where all of the problems lend themselves to
an OO solution. My experience to date has been that large
programmes, there are a number of different problems, and that
the best solutions for each problem often use different
paradigms. Garbage collection adds another paradigm, or rather,
makes one of the existing paradigms easier to use. And that's
about it; it has no effect on any of the other paradigms.
--
James Kanze kanze...@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Steven E. Harris
> Another programmer ease-of-use technique is automatic typing and
> that definitely leads to sloppy design.
Says you, with "definitely" being shorthand for "I'm pretty sure".
Hyperbole aside, do you have a bad experience you'd like to share?
--
Steven E. Harris
James Kanze
> kanze wrote:
>> Gene Bushuyev wrote:
>>> 2) "Dangling pointers, storage leaks, memory smashes, and
>>> out-of- bounds array indices are the bane of the C++
>>> programmer and his customers."
>> That's true as far as it goes. Regretfully, they're also the
>> bane of Java programmers and their customers. Because...
> I'll bite. Because... what?
Because of what I wrote later, I think. I can't find the post
you're responding to, but generally, when I terminate with the
three points, it's because, exceptionally, I've read the next
paragraph I'm responding to, and it seems more natural to go
into details there.
Anyway, the reason is simple: object lifetime doesn't
necessarily depend on whether there are pointers to the object
or not. If you call dispose(), or whatever the function is
called, on an object in Java, what do you call pointers which
still point to it, if not dangling? They may not point to raw
memory, or some random data from another object (because the
memory has been reallocated), but they still don't point to a
usable object.
--
James Kanze kanze...@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Graham Menhennitt
Email)" <SeeWebsit...@erdani.org> wrote:
>a) Passing smart pointers around becomes too much of an efficiency
>problem. With MT smart pointers the tipping point is particularly quick
I find that I rarely "pass smart pointers around". I generally have
objects that hold smart pointers to the objects that they own. For
passing to methods without sharing ownership, it is much more common
to dereference the smart pointer and pass a reference to the object.
In the rare cases where it is necessary to allow for passing a null
pointer, I would rather pass a raw pointer. This is a signal to me
that the object is NOT being shared.
>b) There are ownership cycles. Hopefully you also agree that this is not
>always (and perhaps not even usually) a sign of bad design. I also think
>you'd agree that ownership cycles may not be trivial to address robustly.
I'd also say that they are rare. Again references or raw pointers for
non-owned objects is preferable.
>c) The structure of a project's team makes it hard to educate
>programmers to properly and consistently use smart pointers. Hard does
>not mean impossible, but it just translates in time spent on meetings,
>code reviews etc.
This I have to agree with. But I'd rather not cater to the lowest
level member of the team. Instead I'd try to raise their level to that
of the other members.
--
Graham
Graham Menhennitt
wrote:
>Obviously, this means distinguishing between categories of objects. But
>we already have do that anyway, so there's no real additional constraint
I disagree. It means distiguishing between categories of _classes_.
That's (one reason) why I don't like GC. The owner of a pointer does
not necessarily know whether the pointer can safely be left for GC.
Consider:
class B { virtual ~B() {} };
class D : public B { ~D() { resource.release(); } };
void f(B* b)
{
// can b safely be left for GC?
}
--
Graham
Peter C. Chapin
> Garbage collection is about managing memory. If the only reason you are
> calling delete is to free the memory (the most frequent case in my
> code), then you don't need it. If you are calling it for other reasons
> (i.e. the destructor of the object does more than just free memory),
> then you need it.
>
> Obviously, this means distinguishing between categories of objects. But
> we already have do that anyway, so there's no real additional constraint
> here. About the only difference is that with garbage collection, there
> is less code to write, and less code to debug.
What if the category of an object changed during program maintenance?
For example at first a class might only use its destructor to release
memory but then later it is revised to do other necessary (non-memory)
resource management tasks. If the program was relying on GC to clean up
objects from this class, such a change would require a very error prone
process of adding deletes everywhere they were previously left out.
Peter
Joe Seigh
> Gene Bushuyev wrote (among many other things):
>
>>Designing RAII into classes or choosing the proper smart
>>pointers is
>>the simplest task during project design and takes little time and
>>efforts.
>
>
> I won't even contend that, although one might, but allow me to just make
> a little point around here.
>
> So I understand you agree that smart pointers are (at least)
> occasionally useful.
>
> Then you might imagine a category of people working on projects for
> which smart pointers would be particularly useful. Then smart pointers
> would pervade such projects.
>
> Then I'm sure you agree a point could be reached where some subset of
> the following factors leads to too much of an annoyance:
>
> a) Passing smart pointers around becomes too much of an efficiency
> problem. With MT smart pointers the tipping point is particularly quick
> to reach, but even ST smart pointers can significantly erode the code's
> performance. This creates strong pressure to either use
> pointers/references to smart pointers, or selectively use raw pointers
> instead of smart pointers, both of which are a round trip back to the
> problem we were solving with smart pointers. Besides, making the
> decision on what cases ask for such bypassing of smart pointer semantics
> has an ongoing development cost.
In multi-threaded programming, shared data has to be synchronized
properly and this will likely incur some amount of overhead no matter
what, whether the data is a pointer or some shared data the pointer
refers to. That said, there are some smart pointers that have little
overhead, not anywhere near what you are thinking of.
>
....
>
> d) The code uses lock-free programming that make it hard to devise and
> implement algorithms for deterministic storage reclamation.
I wouldn't know about it being hard to implement them but you can reuse
implementations once you or someone else has done them.
The big problem with smart pointers is that C++ doesn't properly support
pointer abstraction. Unfortunately, it's not broken enough that anyone
will ever fix it.
--
Joe Seigh
When you get lemons, you make lemonade.
When you get hardware, you make software.
marius lazer
kanze wrote:
>
> In practice, about 90% of the non-trivial destructors in my code
> are concerned only with memory management, so that's 90% of the
> classes where it could potentially help.
>
In my practice over 90% of destructors deal with resource management
other than memory (connections, transactions, etc.) and lifetime
management. There isn't one explicit call to delete in the over 2
million lines of code I'm working with (we're using loki::SmartPointer
which is a policy-based class that can define over 350 variations of
smart pointer behavior). That being said, memory management isn't an
issue for us; it was part of the design and now nobody even thinks
about it. It's just being taken care of, PERIOD.
However, it seems that for many posting to this topic memory management
is an after-thought and thus a BIG problem. No GC will fix broken
designs.
I would never rely on any GC to close the connections for me or tell me
when some object came into existence and exactly when it "died". That's
part of the deterministic behavior of C++ that GC would steal away.
Marius Lazer
Joel Eidsath
> Ok, since the experience is the best criteria here, I did an experiment. I
> counted all "delete" expressions in the last medium-size project. They represent
> less than 0.1% of the number of lines of code. Practically all of them are due
> to the third party library that didn't do the proper cleanup of its own objects.
When I think of the utility of garbage collection to me personally,
that's the one instance that springs to mind. It's happened to me more
than once: There's some third party library that I need to use, and the
documentation is obtuse as to whether I'm in charge of memory or it is.
I'd love to be able to pass this off to garbage collection. Of course
that would mean a C++ garbage collector that could snap-in and work
with legacy code (presumably with compiler errors if that code is doing
something that might break collection).
Roland Pibinger
[repost - first post did not come through]
>"Seungbeom Kim" <musi...@bawi.org> skrev i meddelandet
>> I have to make sure what GC actually means in practice...
>> Isn't it about not having to explicitly write 'delete' expressions
>> when you don't need the objects, and GC's automatically taking care
>> of it? And we all know that 'delete' expressions do two things:
>> destroying the object by calling the destructor, and releasing the
>> memory. Then how
>> is it possible that GC does not concern lifetime of objects?
>
>Because it doesn't bother with the objects, it just recycles the
>memory.
>Technically, the object is still there if the destructor never runs,
>but we cannot tell the difference as we cannot reach the object
>anyway.
>Objects that have a non-trivial destructor will have to be deleted as
>before, others can just be dropped.
Nope. Also all destructors of base class objects and member objects
(and member of member objects and ...) would have to be 'trivial'. In
order to distinguish deletable from non-deletable objects a new
keyword ('gcnew') would have to be introduced. Since the user cannot
be burdened with the task of looking up inplementation details the
compiler would have to check for the triviality of all destructors in
case genew is used. Moreover the code would become dependent on the GC
runtime and would not work without it.
>
>char* p = new char[1000];
>p = 0;
>
>will not leak the memory with GC. That the destructor for the chars
>doesn't run is not a big problem.
Sure, GC would much more compatible with C than with C++. But C++, as
mentioned before, has better means to control memory (resources in
general) than GC.
Best regards,
Roland Pibinger
Joel Eidsath
> > that definitely leads to sloppy design.
>
> Says you, with "definitely" being shorthand for "I'm pretty sure".
>
> Hyperbole aside, do you have a bad experience you'd like to share?
Maintaining other people's Perl and trying to figure out what is going
on just from the variable name and what's being done to it.
marius lazer
Andrei Alexandrescu (See Website For Email) wrote:
> > Designing RAII into classes or choosing the proper smart
> > pointers is
> > the simplest task during project design and takes little time and
> > efforts.
>
> I won't even contend that, although one might, but allow me to just make
> a little point around here.
>
> So I understand you agree that smart pointers are (at least)
> occasionally useful.
>
> Then you might imagine a category of people working on projects for
> which smart pointers would be particularly useful. Then smart pointers
> would pervade such projects.
With all due respect (and I have plenty), smart pointers do pervade our
over 2 million lines of code but not directly; every instance of a
class that can be dynamically allocated has an associated typedef of
the "right" loki::SmartPtr specialization or raw pointer (class ABC has
a ABC_Ptr too). We don't even need code reviews to catch offenders
since a simple grep does the job.
>
> Then I'm sure you agree a point could be reached where some subset of
> the following factors leads to too much of an annoyance:
>
> a) Passing smart pointers around becomes too much of an efficiency
> problem. With MT smart pointers the tipping point is particularly quick
> to reach, but even ST smart pointers can significantly erode the code's
> performance. This creates strong pressure to either use
> pointers/references to smart pointers, or selectively use raw pointers
> instead of smart pointers, both of which are a round trip back to the
> problem we were solving with smart pointers. Besides, making the
> decision on what cases ask for such bypassing of smart pointer semantics
> has an ongoing development cost.
I haven't seen the performance problem introduced by smart pointers
properly used. It is an overhead, it's true, but it's noise in the
global picture. When the use of smart pointers become my performance
problem I'll be in really-really good shape... And yes, signatures are
defined in the design process and whenever appropriate we take
references to ClassPtr to avoid the extra copy.
>
> c) The structure of a project's team makes it hard to educate
> programmers to properly and consistently use smart pointers. Hard does
> not mean impossible, but it just translates in time spent on meetings,
> code reviews etc.
Not necessarily. As long as the design enforces the use of smart
pointers (memory management is built in and not an implementation issue
as a design after-thought) the "offending code" wouldn't even compile.
>
> d) The code uses lock-free programming that make it hard to devise and
> implement algorithms for deterministic storage reclamation.
Agree, but yet again, design must deal with this, not implementation.
By then it's too late anyway and no GC will solve the concurrency
problems missed by design.
>
> If you agree with the arguments before, you just agreed that there is a
> non-null set of people and projects that could benefit from garbage
> collection.
I do agree that *some* might benefit from GC and personally I don't
object to it as long as it's not required.
Marius
Andrei Alexandrescu (See Website For Email)
>
>>>If you provide a convincing example, nobody will argue about
>>>it anymore.
>>
>>What's more convincing than actual experience.
>
>
>
> counted all "delete" expressions in the last medium-size project. They represent
That experiment should be properly conducted, and counting the delete
expressions is not informative. For example, someone might define
Dispose to call delete and then use Dispose throughout. So a more
elaborate counting technique must be used.
Andrei
James Kanze
> kanze wrote:
>> In practice, about 90% of the non-trivial destructors in my
>> code are concerned only with memory management, so that's 90%
>> of the classes where it could potentially help.
> In my practice over 90% of destructors deal with resource
> management other than memory (connections, transactions, etc.)
> and lifetime management.
And what kind of an application is that? No value objects? No
entity objects? No business logic?
> There isn't one explicit call to delete in the over 2 million
> lines of code I'm working with (we're using loki::SmartPointer
> which is a policy-based class that can define over 350
> variations of smart pointer behavior).
So what. You've still had to think about the issues, decide
which smart pointer to use where, etc. Or you're dealing with a
very trivial application, which doesn't do much.
> That being said, memory management isn't an issue for us; it
> was part of the design and now nobody even thinks about it.
> It's just being taken care of, PERIOD.
Because someone wrote the code to do it.
> However, it seems that for many posting to this topic memory
> management is an after-thought and thus a BIG problem.
It seems that for many arguing against garbage collection, it is
necessary to invent such arguements, yes. None of the
proponents of garbage collection are claiming such things.
> No GC will fix broken designs.
And nobody claims it will.
> I would never rely on any GC to close the connections for me
> or tell me when some object came into existence and exactly
> when it "died".
I wouldn't either. That's not the role of garbage collection.
Where has anyone claimed that garbage collection would manage
connections?
> That's part of the deterministic behavior of C++ that GC would
> steal away.
Here we go again. Garbage collection changes absolutely nothing
with regards to the deterministic nature of C++. I don't know
where this myth got started, but given the number of times it's
been debunked, I'm beginning to wonder if there isn't a little
bit of bad faith on the part of the people who keep bringing it
up.
--
James Kanze kanze...@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]