C++ standard

0 views
Skip to first unread message

best...@gmail.com

unread,
Jul 6, 2006, 6:24:05 AM7/6/06
to

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

unread,
Jul 6, 2006, 6:08:52 PM7/6/06
to
Firstly I would say that giving freedom to compilers a bit is a
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

unread,
Jul 6, 2006, 6:07:44 PM7/6/06
to
In article <1152154738....@b68g2000cwa.googlegroups.com>,
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

unread,
Jul 6, 2006, 6:06:14 PM7/6/06
to
best...@gmail.com wrote:
> 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

unread,
Jul 6, 2006, 6:04:21 PM7/6/06
to
Bestbrain posted:


> 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

unread,
Jul 6, 2006, 6:18:09 PM7/6/06
to
Here we go!!

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

unread,
Jul 6, 2006, 6:17:22 PM7/6/06
to
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)

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

unread,
Jul 7, 2006, 10:13:19 AM7/7/06
to

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

unread,
Jul 7, 2006, 10:18:01 AM7/7/06
to
Walter Bright wrote:

[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

unread,
Jul 7, 2006, 10:09:57 AM7/7/06
to
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. 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

unread,
Jul 7, 2006, 7:55:30 PM7/7/06
to
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".


> 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

unread,
Jul 7, 2006, 7:55:53 PM7/7/06
to
QT Programs generally turn out pretty well. Of course no generic gui
toolkit feels quite "native" on macs . QT is a C++ framework :D

Stephen M. Webb

unread,
Jul 7, 2006, 7:51:25 PM7/7/06
to
best...@gmail.com wrote:
> [...]

>
> 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

unread,
Jul 7, 2006, 7:56:14 PM7/7/06
to
Hi,

> 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

unread,
Jul 8, 2006, 7:28:50 PM7/8/06
to

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

unread,
Jul 8, 2006, 7:31:38 PM7/8/06
to

"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

unread,
Jul 9, 2006, 10:27:43 AM7/9/06
to
"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?

--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George Orwell

Raoul

unread,
Jul 9, 2006, 10:29:00 AM7/9/06
to

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

unread,
Jul 9, 2006, 5:04:17 PM7/9/06
to
Raoul wrote:
> 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

unread,
Jul 9, 2006, 5:02:39 PM7/9/06
to
Walter Bright wrote:
> 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

unread,
Jul 9, 2006, 5:06:52 PM7/9/06
to

"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

unread,
Jul 9, 2006, 5:03:33 PM7/9/06
to
Bo Persson wrote:
> "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

unread,
Jul 9, 2006, 5:05:17 PM7/9/06
to
jbannon wrote:
> 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

unread,
Jul 10, 2006, 5:27:31 PM7/10/06
to
Bo Persson wrote:
> "Walter Bright" <wal...@digitalmars-nospamm.com> skrev i meddelandet
>> 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 :-)

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

unread,
Jul 10, 2006, 5:31:06 PM7/10/06
to
> 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.

Walter Bright

unread,
Jul 10, 2006, 5:43:13 PM7/10/06
to
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.

Bo Persson

unread,
Jul 11, 2006, 4:45:25 PM7/11/06
to

"Raoul" <raould...@hotmail.com> skrev i meddelandet
news:1152513779....@b28g2000cwb.googlegroups.com...

>> 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

unread,
Jul 11, 2006, 4:47:39 PM7/11/06
to
"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?" 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

unread,
Jul 11, 2006, 5:11:29 PM7/11/06
to
Walter Bright wrote:
> 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

unread,
Jul 11, 2006, 5:10:46 PM7/11/06
to
Walter Bright wrote:

[...]


> 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

unread,
Jul 12, 2006, 6:17:40 PM7/12/06
to
Gene Bushuyev wrote:
> 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

unread,
Jul 12, 2006, 6:16:55 PM7/12/06
to
Walter Bright wrote:
> 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

unread,
Jul 12, 2006, 6:25:52 PM7/12/06
to
> Conseils en informatique orient=E9e objet/
> 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

unread,
Jul 12, 2006, 6:47:34 PM7/12/06
to
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).

Earl Purple

unread,
Jul 12, 2006, 6:46:01 PM7/12/06
to

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

unread,
Jul 13, 2006, 5:09:44 PM7/13/06
to

> 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

unread,
Jul 13, 2006, 5:10:26 PM7/13/06
to
loufoque wrote:
> 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

unread,
Jul 15, 2006, 6:33:32 AM7/15/06
to
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.

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

unread,
Jul 15, 2006, 6:47:17 AM7/15/06
to
Gene Bushuyev wrote:
> "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

unread,
Jul 15, 2006, 6:46:35 AM7/15/06
to
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.

-Walter Bright
www.digitalmars.com C, C++, D programming language compilers

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Chris Hills

unread,
Jul 15, 2006, 10:34:44 AM7/15/06
to
In article <Dt-dnax9_7RU6yrZ...@comcast.com>, Walter Bright
<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

unread,
Jul 15, 2006, 5:36:27 PM7/15/06
to
Walter Bright wrote:
> 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

unread,
Jul 16, 2006, 8:42:54 AM7/16/06
to
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.


> 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

unread,
Jul 16, 2006, 8:41:37 AM7/16/06
to
"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 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

unread,
Jul 17, 2006, 3:22:44 PM7/17/06
to
Walter Bright wrote:
> 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

unread,
Jul 17, 2006, 3:31:20 PM7/17/06
to
Gene Bushuyev wrote:
> "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

unread,
Jul 17, 2006, 3:38:03 PM7/17/06
to
Gene Bushuyev wrote:
> "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

unread,
Jul 17, 2006, 3:57:04 PM7/17/06
to

"Walter Bright" <wal...@digitalmars-nospamm.com> skrev i meddelandet
news:97-dnW5I97gKmCfZ...@comcast.com...

> 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

unread,
Jul 17, 2006, 4:13:43 PM7/17/06
to
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

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

unread,
Jul 17, 2006, 4:13:00 PM7/17/06
to
kanze wrote :

> 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

unread,
Jul 17, 2006, 4:13:22 PM7/17/06
to
> 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.

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

unread,
Jul 17, 2006, 10:42:52 PM7/17/06