Re: Array optimizing problem in C++?

[James Kanze]

On Apr 10, 4:06 pm, Jerry Coffin <jcof...@taeus. comwrote:

In article <zvidnaVzlq9JOm HanZ2dnUVZ_tOtn [e-mail] >,
l...@lewscanon. com says...

[...]

You seem to be equating use of GC with Java -- at least for
me, most use of GC has been in ML, Smalltalk and Scheme
(though I've probably used a couple of other Lisp variants at
least as much as Java as well).

Just a note, but in all of these languages, *all* objects are
dynamically allocated. I wonder if this isn't more what caused
you problems, rather than garbage collection.

In a language in which all objects are dynamically allocated,
garbage collection is almost a necessity. Can you imagine what
it would be like if you had to do a delete for each
java.lang.Strin g you new'ed? And of course, a language in which
all objects are dynamically allocated can't really support RAII,
at least not in any meaningful way. And that's a route I don't
particularly want to go, at least not in C++. (Note that done
correctly, such a route is not necessarily wrong, and even has
certain immediate advantages---in a very real sense, dangling
ponters are impossible. But personally, I still prefer a
language where values behave like values.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jerry Coffin]

In article <9df07a3a-64dc-4534-9e80-e9085b611c29
@u69g2000hse.go oglegroups.com> , ja*********@gma il.com says...

[ ... ]

Just a note, but in all of these languages, *all* objects are
dynamically allocated. I wonder if this isn't more what caused
you problems, rather than garbage collection.

True -- the languages are enough different from C++ that a meaningful
comparison is difficult.

In a language in which all objects are dynamically allocated,
garbage collection is almost a necessity. Can you imagine what
it would be like if you had to do a delete for each
java.lang.Strin g you new'ed? And of course, a language in which
all objects are dynamically allocated can't really support RAII,
at least not in any meaningful way. And that's a route I don't
particularly want to go, at least not in C++. (Note that done
correctly, such a route is not necessarily wrong, and even has
certain immediate advantages---in a very real sense, dangling
ponters are impossible. But personally, I still prefer a
language where values behave like values.)

Dangling pointers are impossible as long as everything is working
correctly, that's true. OTOH, makes some other things easy to manage
that most of the other languages make more difficult. The questions are
1) which problems arise more often, and 2) which are more difficult to
fix.

In fairness, the other point I should probably raise is that quite a bit
of what I write is _fairly_ low-level kinds of code. In particular, I've
written a fair number of debugger-like things (mostly for automating
various code tracing, rather than really debugger-like things such as
manual single-stepping, but fairly similar nonetheless). In any case,
their relatively low-level nature may mean that I just don't encounter
as many of the situations where GC would do a lot of good, but do
encounter more were RAII is useful. In particular, creating or
destroying an object in my program is typically tied directly to some
specific event in the code being tested, leaving little room for the
garbage collector to really contribute a whole lot.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On 13 avr, 07:08, Jerry Coffin <jcof...@taeus. comwrote:

In article <9df07a3a-64dc-4534-9e80-e9085b611c29
@u69g2000hse.go oglegroups.com> , james.ka...@gma il.com says...

[ ... ]
Dangling pointers are impossible as long as everything is working
correctly, that's true. OTOH, makes some other things easy to manage
that most of the other languages make more difficult. The questions are
1) which problems arise more often, and 2) which are more difficult to
fix.

I think that this will largely depend on the application and the
programming style. Given that, I'd argue that GC is applicable
for certain applications and certain styles, and that one of the
goals of C++ is to give the programmer the choice. In this
regard, using garbage collection shouldn't be manditory (and
really can't be, if you want C++ to be usable in critical,
embedded applications, where all use of dynamic allocation is
banned), but it should be a requirement that an implementation
provide it.

As I said, it's a useful tool in some cases, and as such, should
be available.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jerry Coffin]

In article <ff6354f2-655b-4f6a-9e67-
db**********@l4 2g2000hsc.googl egroups.com>, ja*********@gma il.com
says...

[ ... ]

I think that this will largely depend on the application and the
programming style. Given that, I'd argue that GC is applicable
for certain applications and certain styles, and that one of the
goals of C++ is to give the programmer the choice. In this
regard, using garbage collection shouldn't be manditory (and
really can't be, if you want C++ to be usable in critical,
embedded applications, where all use of dynamic allocation is
banned), but it should be a requirement that an implementation
provide it.

I don't see how it makes sense to mandate it. Some implementations are
targeted specifically and entirely at systems for which GC just doesn't
make sense at all. If you restricted the mandate to hosted systems, I'd
consider that a lot closer to reasonable, but even there I don't think
it really makes sense for it to be mandatory. Along with it just not
making sense, truly mandating GC is almost impossible anyway. The
current paper that talks about it has pages and pages of description,
but when you get down to it (and I know I've mentioned this before) the
garbage collection itself isn't really mandatory at all -- it all comes
down to one non-normative note saying that high quality implementations
are expected to make as much memory available as possible.

In the end, it's all about return on investment. In this case we're
mandating a large investment with no certainty of a return and (by your
estimate) only about a 10% return at best. I can think of a number of
things I think would benefit C++, but I've never formally suggested most
of them, because I don't think the payoff is worth the investment -- but
in these terms, GC scores considerably _worse_ than almost anything else
I can think of.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Apr 13, 6:21 pm, Jerry Coffin <jcof...@taeus. comwrote:

In article <ff6354f2-655b-4f6a-9e67-
db57d3f5d...@l4 2g2000hsc.googl egroups.com>, james.ka...@gma il.com
says...

[ ... ]

I think that this will largely depend on the application and the
programming style. Given that, I'd argue that GC is applicable
for certain applications and certain styles, and that one of the
goals of C++ is to give the programmer the choice. In this
regard, using garbage collection shouldn't be manditory (and
really can't be, if you want C++ to be usable in critical,
embedded applications, where all use of dynamic allocation is
banned), but it should be a requirement that an implementation
provide it.

I don't see how it makes sense to mandate it. Some
implementations are targeted specifically and entirely at
systems for which GC just doesn't make sense at all. If you
restricted the mandate to hosted systems, I'd consider that a
lot closer to reasonable, but even there I don't think it
really makes sense for it to be mandatory. Along with it just
not making sense, truly mandating GC is almost impossible
anyway. The current paper that talks about it has pages and
pages of description, but when you get down to it (and I know
I've mentioned this before) the garbage collection itself
isn't really mandatory at all -- it all comes down to one
non-normative note saying that high quality implementations
are expected to make as much memory available as possible.

When you get right down to it, that's all the standard
"mandates" for delete, too. There's certainly nothing in the
standard which would guarantee that you'll eventually be able to
reuse the memory which is freed. For various reasons, such a
guarantee isn't possible, or at least, no one has found a
reasonable way to word it so that it still takes into account
all of the aleas of actual implementations (fragmentation,
different strategies with regards to coalescence, etc.). On the
other hand, the intent is clear.

The wording in the case of garbage collection is even more
wishy-washy, for political reasons. There's no real reason not
to mandate that the implementation support it whenever dynamic
allocation is supported (which is formally, always). In
practice, of course, in implementations will do whatever they
have to to be usable on the system in question; I've used
implementations of C which didn't support float and double, or
at least had compile time switches to turn it off. In the case
of garbage collection, of course, if you do delete everything
you've allocated, you don't see it. An implementation could
certainly make a version of malloc/free available which would
only work in this case, just as quality implementations
generally make several versions of malloc/free available today.

In the end, it's all about return on investment. In this case
we're mandating a large investment

What large investment? On the part of whom? Integrating the
Boehm collector is certainly not a lot of work on the part of
the implementors.

with no certainty of a return and (by your estimate) only
about a 10% return at best. I can think of a number of things
I think would benefit C++, but I've never formally suggested
most of them, because I don't think the payoff is worth the
investment -- but in these terms, GC scores considerably
_worse_ than almost anything else I can think of.

All I can say is that there are a number of users (myself
included) who find the investment worthwhile enough to do it
ourselves. It took me less than a day to get the Boehm
collector up and running with g++ under Linux, and I don't have
access to all of the inside knowledge of the implementors. And
10%, over the life of a project, is a lot more than one man-day,
even for a single project. 10% gain for 90% of the C++ projects
almost certainly adds up to man-years.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Razii]

On Mon, 14 Apr 2008 00:43:31 -0700 (PDT), James Kanze
<ja*********@gm ail.comwrote:

>All I can say is that there are a number of users (myself
included) who find the investment worthwhile enough to do it
ourselves. It took me less than a day to get the Boehm
collector up and running with g++ under Linux, and I don't have
access to all of the inside knowledge of the implementors. And
10%, over the life of a project, is a lot more than one man-day,
even for a single project. 10% gain for 90% of the C++ projects
almost certainly adds up to man-years.

Doesn't look that simple to me. I downloaded gc version 6.7 and 6.8.

nmake nodebug=1 gc.mak

makefile(389) : fatal error U1001: syntax error : illegal character
'{' in macro

I then downloaded 7.0 and by using the exact same command as posted
above, it built fine. Huh?

Then I added the header file

#include "gc_cpp.h"

Changed the "new" to

Tree *t = new (GCNew) Tree;

cl /O2 -I"\gc-7.0\include" new.cpp "\gc-7.0\Release\gc. lib"

Compiled fine but when I run the new.exe,

"This application has failed to start because MSVCR90.dll was not
found"

I found the file and put it in the same directory. Next error: An
application has made an error to load the C runtime library
incorrectly."

What the heck.

[Jerry Coffin]

In article <71257c78-fa71-48f8-802e-84e1a5f5c748
@x41g2000hsb.go oglegroups.com> , ja*********@gma il.com says...

[ ... ]

When you get right down to it, that's all the standard
"mandates" for delete, too. There's certainly nothing in the
standard which would guarantee that you'll eventually be able to
reuse the memory which is freed. For various reasons, such a
guarantee isn't possible, or at least, no one has found a
reasonable way to word it so that it still takes into account
all of the aleas of actual implementations (fragmentation,
different strategies with regards to coalescence, etc.). On the
other hand, the intent is clear.

It's true that very little is mandated about delete. The fundamental
difference is that it stops there -- i.e. we don't have pages and pages
throughout the rest of the standard devoted to enabling it to do
nothing. N2287 is 23 pages long, and it looks like about 15 pages of
that is proposed to be added to the standard. Along with that, they
propose changing the language to make some things that are currently
defined parts of the language become undefined behavior.

[ ... ]

In the end, it's all about return on investment. In this case
we're mandating a large investment

What large investment? On the part of whom? Integrating the
Boehm collector is certainly not a lot of work on the part of
the implementors.

A couple of points. First of all, it looks to me like some work will
need to be done on the Boehm collector to make it conform with the
proposal in N2287.

Second, you seem to be looking at it entirely in terms of use with the
half dozen (or so) implementations to which it has already been ported.
As you know perfectly well, however, that's a long ways short of every
C++ compiler around. Porting it to a compiler that's not already
supported isn't nearly so trivial.

Finally, it looks like although the collector proper is covered by quite
a liberal license, parts of integrating it uses code that falls under
more restrictive licenses -- which might be a bit of a problem for some
commercial compilers and such.

[ ... ]

All I can say is that there are a number of users (myself
included) who find the investment worthwhile enough to do it
ourselves. It took me less than a day to get the Boehm
collector up and running with g++ under Linux, and I don't have
access to all of the inside knowledge of the implementors. And
10%, over the life of a project, is a lot more than one man-day,
even for a single project. 10% gain for 90% of the C++ projects
almost certainly adds up to man-years.

Adding it yourself, on a compiler for which it's already supported, for
the right kind of project may well be a win. Mandating that it be added
for every implementation of C++, regardless of the target is a whole
different story -- you know as well as I do that for quite a few high-
reliability and/or real-time situations, almost all dynamic allocation
is verboten. When/if that's the primary (or only) target of a particular
implementation, requiring it to include a garbage collector simply makes
no sense.

Likewise, there are a fair number of smaller systems for which GC would
be possible, but rarely if ever of any real help. Just for example, a
few years ago I was dealing with some code for some security cameras.
The system had a joy-stick, a half dozen (or so) buttons, and four
motors (X, Y, Z and focus). C++ was a reasonable fit for the system, but
garbage collection wouldn't have been at all. More importantly, I can
hardly imagine a system that would be built around that processor that
WOULD benefit from GC -- so trying to get that compiler to include it
wouldn't make any sense.

I think one of the biggest real problems with C++ today is that almost
nobody follows the standard, or really even makes an attempt at doing
so. Changing it in a way that makes it even less applicable to a large
number of systems would not, IMO, be a good move at all.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Lew]

Jerry Coffin wrote:

[many very interesting things about C++]

Good C++ conversation.

--
Lew