Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
The Ramifications Of A Garbage Collected C++

By Carnage4Life in Technology
Tue Oct 10, 2000 at 03:19:49 AM EST
Tags: Software (all tags)
Software

Ever since I read C++ Answers From Bjarne Stroustrop on Slashdot a few months ago I have been struck by this quote "When (not if) automatic garbage collection becomes part of C++, it will be optional". I am drawn by the fact that C++ may become a garbage collected language and have decided to investigate what exists in C++ garbage collection at the current time and also whether this means that maybe more new server applications will start being written in C++ and not Java. My conclusions and speculations are below.


What Exists Now

After clicking around Bjarne Stroustrop's site, I came across links to Hans Boehm's site on garbage collection. There he has a well written page that dissects the advantages and disadvantages of garbage collection in C++. From my readings it is clear that there are several third-party garbage collectors for C++, but currently the C++ standard makes no mention of garbage collection (although I heard that a proposal from Bjarne Stroustrop was voted down sometime ago).

Basically the advantages of Garbage Collection are:
  • 30 to 40 percent faster development time.
  • Less restrictive interfaces and more reusable code.
  • Easier implementation of sophisticated data structures.
  • Eliminates some premature deallocation errors.
  • Uses equivalent or less CPU-time than a program that uses explicit memory deallocation.

While the disadvantages are
  • More interaction with the hard disk (virtual memory/paging) due to examining all pointers in the application.
  • May not work if programmers use various tricks and hacks while coding (e.g. casting pointers to ints and back)
  • May utilize more space than a program that uses explicit memory deallocation.
  • Unpredictable nature of collector runs may create unexpected latency and time lags in the system.
In my opinion, the advantages of using garbage collection in C++ greatly outweigh any disadvantages and i may begin to user Boehm's toolkit.

What Will Exist In The Future

From Bjarne Stroustrop's comments it is clear that the C++ standard will eventually have garbage collection and even better that it won't violate the "pay for it only if you use it" doctrine of C++. Also from this article on the MSDN site, Visual C++ will have automatic garbage collection provided by the .NET environment.

Java vs. C++

Currently a lot of server side applications are being built with Java due to factors like garbage collection, a large number of libraries and buzzword compliance. In my opinion, the one thing that is slowing development of C++ is the fact that every large C++ application leaks memory (that's why we need Purify and BoundsChecker). I believe that once C++ garbage collection becomes widespread (as it shall with both the C++ standard and MSFT's .NET pushing for it soon) we will see a larger number of reusable libraries spring up as well as better applications. Frankly Java™ is cool but lack of asynchronous I/O, templates, global variables or enumerated types will always make it second to C++ for me.

What does the kuro5hin readership think?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
C++ Garbage Collection Would...
o Make the language too slow. 15%
o Make it a viable contender to Java. 3%
o Be A Welcome Addition To The Language Standard 49%
o Not Matter Because I do not use C++ 31%

Votes: 191
Results | Other Polls

Related Links
o Slashdot
o Kuro5hin
o C++ Answers From Bjarne Stroustrop
o Hans Boehm's
o advantages and disadvantages of garbage collection in C++
o article on the MSDN site
o Purify
o BoundsChec ker
o Also by Carnage4Life


Display: Sort:
The Ramifications Of A Garbage Collected C++ | 163 comments (161 topical, 2 editorial, 0 hidden)
VC++ Garbage Collection? (3.00 / 15) (#1)
by Dacta on Tue Oct 10, 2000 at 01:24:43 AM EST

Where did you get that Visual C++ will have automatic garbage collection provided by the .NET environment? As I read it, C# will have garbage collection, but C++ will continue as is (at least until Garbage Collection makes it into the C++ spec).

I think the quote:

Memory management has also been enhanced. Managed Extensions provide access to a garbage-collected memory heap and automatically manage objects allocated from this heap. Garbage collection means an automatic performance boost for most applications and allows the developer to focus on more important aspects of the application instead of the management of objects and pointers. Watch for more information about new C++ features in upcoming issues of MSDN Magazine.
is refering more to the use of .NET (COM) objects than tradtional C++ objects. Maybe not, though... who can read the mind of Microsoft?



Re: VC++ Garbage Collection? Yes (3.57 / 7) (#2)
by Carnage4Life on Tue Oct 10, 2000 at 01:34:21 AM EST

Where did you get that Visual C++ will have automatic garbage collection provided by the .NET environment?

1.) I have a friend who's worked on the MSFT .NET team.

2.)The paragraph you are quoting from is entitled New Features in C++ not new features in .NET or new features in C#. Also the first paragraph reads
    Starting with Visual Studio .NET, the basic C++ language has been extended to provide support for programming to the new Microsoft .NET Framework.
That seems conclusive to me, what do you think?



[ Parent ]
Re: VC++ Garbage Collection? (1.20 / 5) (#3)
by pope nihil on Tue Oct 10, 2000 at 02:01:27 AM EST

since when has microsoft followed standards? last time i checked, i couldn't get anything to compile in VC++ that used the STL.

I voted.

[ Parent ]
Re: VC++ Garbage Collection? (1.16 / 6) (#5)
by mafried on Tue Oct 10, 2000 at 02:06:29 AM EST

'm voting for Harry Browne, the Libertarian candidate. Who are you voting for?

I'd vote independant, but they can't seem to decide on who their candidate is.

[ Parent ]
Re: VC++ Garbage Collection? (2.75 / 4) (#15)
by Dacta on Tue Oct 10, 2000 at 03:42:27 AM EST

since when has microsoft followed standards? last time i checked, i couldn't get anything to compile in VC++ that used the STL.

Well, the MS STL implementation is pretty good. I've been using it all day today, and it has compiled everything I've found on the net. MS uses the Dinkumware STL library, which is claimed to be the mose compliant in existance.

I'm not a C++ expert by any means, but I understood that it is actually the g++ STL implementation that has issues with standards compliance. Something about streams not using the STL? I think that is partly why Redhat went to GCC 2.96. I'm sure someone will correct me...



[ Parent ]
Implementation (3.00 / 4) (#24)
by inpHilltr8r on Tue Oct 10, 2000 at 07:23:22 AM EST

For anyone interested in how the STL works it's magic, I'd reccomend the SGI implementation , which actually uses whole words, rather than the osbufacted mess MS bundled.

Good documentation too.

[ Parent ]

Or (3.00 / 3) (#44)
by Dacta on Tue Oct 10, 2000 at 09:31:51 AM EST

Or even STLPort - a port of the SGI STL to various compilers/architectures.



[ Parent ]
Re: VC++ Garbage Collection? (none / 0) (#73)
by your_desired_username on Tue Oct 10, 2000 at 01:31:34 PM EST

The gcc 2.96 that came with rh7.0 has *exactly the same* STL that comes with 2.95.2. There are no improvements in that area.

gcc 2.95.2's STL implementation is as good as what comes with most other compilers - including MSVC++ 6.0. gcc's defeciencies are its ancient <iostream>, its total lack of <sstream>, etc (which is are important parts of the standard C++ library, but *not* part of the STL)

There is a vastly improved standard C++ library in the works for gcc - it will be availible with gcc 3.0 .

[ Parent ]
Re: VC++ Garbage Collection? (2.60 / 5) (#12)
by Spinoza on Tue Oct 10, 2000 at 03:20:26 AM EST

That quote is in a section entitled "New Features in C++" I would take this, and the paragraph's use of the past tense to imply that these features have been implemented in Microsoft's C++. Either that, or the vaporware generator is out of control.

[ Parent ]

Re: VC++ Garbage Collection? (2.16 / 6) (#14)
by Dacta on Tue Oct 10, 2000 at 03:36:20 AM EST

I'm using VC++6.0 (the latest version) at the moment, and it's not there.



[ Parent ]
Re: VC++ Garbage Collection? (2.60 / 5) (#16)
by Spinoza on Tue Oct 10, 2000 at 03:52:10 AM EST

I believe the paragraph refers to the upcoming version, coinciding with .NET

In other words the developers have implemented this feature, but the version is not yet released. On the other hand, they might be lying, confused, semi-illiterate drunks, who are just making things up. Considering the article is about something called "Visual Studio .NET", I suspect thst Visual C++ 6.0 is probably only of peripheral relevance regarding new features.

[ Parent ]

Re: VC++ Garbage Collection? (3.50 / 6) (#63)
by Keith Russell on Tue Oct 10, 2000 at 12:22:12 PM EST

Yes and no. Microsoft is adding a __gc keyword. When it's added to a class declaration, all instances of that class are managed, which includes, among other things, being gc'ed. Here's an example from the NGWS SDK:
#using <mscorlib.dll>
#using namespace System;

__gc class X {
    public:
        int i;
        int ReturnInt() {return 5;}
};

void main() {
    X* px;
    px = new X;
    px->i = 4;
    int n = px->ReturnInt();
}
The GC will pick px up when it goes out-of-scope at the end of main(). You can still explicitly destroy px using delete px; or px->~px();

Everyday we're standing in a wind tunnel/Facing down the future coming fast - Rush
Implements IStdDisclaimer
[ Parent ]
Garbage Collection Performance Hit (2.13 / 23) (#4)
by mafried on Tue Oct 10, 2000 at 02:03:06 AM EST

(warning ahead of time: this is a bit of a rant. mark hates people who never take the time to consider exactly how all these new "buzzword" technologies work, and what kind of performance hit can be expected when they are adopted into production level code. mark also hates people who talk about themselves in the third person)

Garbage collection (as seen in languages such as Java and UnrealScript) involves a complex reference counting scheme that introduces a major performance hit to the code compiled with support for it (regardless of whether it utalizes it or not). At what benifit to the developer? They can now be more lazy.

Referance counted garbage collection involves incrementing or decrementing a "counter" variable (an INC or DEC instruction plus a few MOVs) every time a pointer changes values (which, as any programmer knows, is quite often). It then tests the value of the "counter" variable against zero (one CMP instruction), before potentially branching to deallocation code (introducing the possibility of branch misprediction [and thus a halt in the CPU pipeline]). And this occurs EVERY SINGLE TIME a pointer takes on a new value.

All this for what? To allow the programmer to be a even more lazy than he already is? Gawd, it's amazing programmers are allowed to get away with what they do already, let alone add "features" that will undoubtably shlow down production level code if left unchecked. Using multiply inherited virtual abstract base class hierachies (anyone here actually examines the assembly/machine code outputed by your compiler? ugh.) in production level code is bad enough without intorducing performance hogs such as this.

Re: Garbage Collection Performance Hit (4.50 / 10) (#10)
by Nat Lanza on Tue Oct 10, 2000 at 02:51:17 AM EST

Garbage collection is a "new buzzword technology"? Er, what?

You appear to have hit upon the fact that refcounting garbage collection can be slow. Well, sure. However, it isn't even close to being the only kind of garbage collection. What about mark-and-sweep, for example?

Also, the "to allow the programmer to be even more lazy than he already is" bit is just absurd. Memory allocation errors cause a lot of programming errors. There's no reason anybody should have to do memory management by hand. Programmers used to have to do register allocation by hand, but now we've accepted that the compiler can do a better job. Why not accept that the compiler can manage memory better?

Really, it's not a fancy new buzzword technology. Garbage collection has been around for a long time, and there's a lot of academic literature on the subject. Please read some of it before ranting about how horrible garbage collection is.

[ Parent ]
compiler doing mem management (3.57 / 7) (#29)
by boxed on Tue Oct 10, 2000 at 08:23:26 AM EST

Why not accept that the compiler can manage memory better?

Because it can't? The compiler can't do register allocation better than a human as you claim either, it's just that the overhead of doing it just isn't worth it anymore. There will come a time when memory management won't be worth it for the same reasons but we aren't there yet. Wait a few years at least... And as we all know, the old tedious way of doings things will always need to remain because we need to do stuff that pushes the limits of the hardware...

[ Parent ]

Re: compiler doing mem management (3.60 / 5) (#34)
by vinay on Tue Oct 10, 2000 at 08:34:59 AM EST

I have a friend who took a class with Sedgewick (the Algorithms in C guy). He was told, while taking that class, that current compiler algorithms are efficient enough that human optimization rarely provides any improvements.

Note, I said "rarely." You're right in that instances will always exist in which hand-optimization will be necessary. On the other hand, I think you underestimate the current state of technology.

-\/

-\/


[ Parent ]
Re: compiler doing mem management (1.50 / 6) (#36)
by boxed on Tue Oct 10, 2000 at 08:59:06 AM EST

Well I think you're underestimating the human mind :P

[ Parent ]
Re: Garbage Collection Performance Hit (2.00 / 4) (#32)
by vinay on Tue Oct 10, 2000 at 08:30:36 AM EST

I agree. While I won't deny that programmers are lazy, I will deny that GC allows such laziness. GC, if implemented correctly make code more error free.

The other thing I'm seeing is the rips on java and its runtime efficiency. There is JIT compiled java that approaches, and even matches the speed of C++. I don't have any examples right now, but I'm sure I can find some if anybody is interested.

-\/

-\/


[ Parent ]
Re: Garbage Collection Performance Hit (3.25 / 4) (#48)
by drewcifer on Tue Oct 10, 2000 at 10:19:41 AM EST

I'd like to see those bechmarks. I noticed one 'home-grown' comparison that was posted to the comp.lang.java newsgroup recently was severly biased towards the java implementation.

I'm not saying it's not possible, just keeping a healthy sceptical stance.

As a side note, you can find several research papers that show automatic memory management equaling or exceeding the speeds of explicite memory management (sometimes by up to %30). Go search on CORA and see for yourself.

GC doesn't have to be slow.

[ Parent ]

Re: Garbage Collection Performance Hit (3.00 / 3) (#51)
by vinay on Tue Oct 10, 2000 at 10:51:40 AM EST

try this link over at stanford.

here's another that's a little more thorough, but it's also at "javaworld," so it's possibly a tad biased.

-\/

-\/


[ Parent ]
Re: Garbage Collection Performance Hit (4.10 / 10) (#11)
by Spinoza on Tue Oct 10, 2000 at 02:55:22 AM EST

Pure snobbery. I agree that garbage collectors are a crutch for lazy programmers. What I think you overlook is that there is no cure for lazy programmers, so we have to look to alternatives, such as garbage collectors.

If I were working in an environment where I was required to modify code rapidly, I would probably begin to feel fairly irritable whenever I had to check that my program was freeing memory properly. It's fairly tedious, and can require more effort than most programmers are willing to contribute to code that isn't particularly interesting to them. (ie. few people get excited about making the seventh set of modifications to their database middleware server code. It might have been fun the first time around, but the thrill just doesn't last.)

I dare say that a certain level of annoyance would be justified if a major application in a role that requires high performance, such as apache were rewritten using a garbage collector. I don't think the same level of indignation should arise if garbage collection becomes a part of the C++ standard. It should exist as an option for people who are working in environments that require software to made and modified quickly, yet maintain a certain stability level.

Yes, you can expect a slowdown from garbage collection. So what? Speed is not always the number one priority in a project. Sometimes maintainability is more important. Sometimes people are just lazy.

[ Parent ]

Re: Garbage Collection Performance Hit (none / 0) (#115)
by Michael Leuchtenburg on Wed Oct 11, 2000 at 12:41:36 AM EST

Annoyance is, of course, only justified if said rewrite actually slows down the code and provides no other benefits (like being able to have Apache processes serve more requests before dying to work around memory leaks, mainly in system libraries).

[ #k5: dyfrgi ]
[ TINK5C ]
[ Parent ]
Lazy programmers aren't bad! (none / 0) (#163)
by Jim Dabell on Sun Oct 29, 2000 at 11:03:33 AM EST

Pure snobbery. I agree that garbage collectors are a crutch for lazy programmers. What I think you overlook is that there is no cure for lazy programmers, so we have to look to alternatives, such as garbage collectors.

Why are there so many posts here talking about lazy programmers as if they are bad? Lazy programmers are better. A lazy programmer will get the computer to do all the work - by using already existing libraries, by keeping the features to a minimum, and by keeping the code simple. These are all good things (in moderation, of course).



[ Parent ]
Uninformed Rant (5.00 / 8) (#39)
by Carnage4Life on Tue Oct 10, 2000 at 09:11:38 AM EST

<*snip* incoherrent rumblings>
Garbage collection (as seen in languages such as Java and UnrealScript) involves a complex reference counting scheme that introduces a major performance hit to the code compiled with support for it (regardless of whether it utalizes it or not). At what benifit to the developer? They can now be more lazy.
<*snip* more incoherrent rumblings>

Your post is very uninformed.
    Reference counting is not the only garbage collection algorithm and in fact is considered by language purists as unsatisfactory since it can't handle circular links. There are many more algorithms including Mark-Sweep Garbage Collection, Mark-Compact Garbage Collection, Copying Garbage Collection, Generational Garbage Collection,and Incremental and Concurrent Garbage Collection. In fact if you had bothered to click the link to Han's Boehm's site that was in my article you would have realized that I was talking about mark-sweep garbage collection and not reference counting. This doesn't mean that Mark-Sweep doesn't have its problems (making two passes across memory and the space taken up by the marks is expensive) but these may be remedied by using Generational garbage collection.
    The Java™ standard does not require that reference counting be the GC algorithm of choice merely that there should be garbage collection. In fact most JVMs use Mark-Sweep garbage collection.
    Garbage collection does not make developers more lazy but instead frees them up to actually worry about the design and logic of their program instead of worrying about tangential book keeping issues, in today's world of machines with 1 GB of RAM and 1 GHz CPUs the performance hit by garbage collection is permissible when balanced against the time saved. Explicit memory management may make sense when writing C++ code with a few thousand lines of code but once the code reaches a few million lines of code, it leaks, this isn't supposition it is fact.
    To call garbage collection a new buzzword technology is nothing short of amazing. Garbage collection has existed for over a decade (or two) in Lisp and Smalltalk, hardly buzzword languages.
    Finally as for GC being slower thean explicit memory management, this is only true in specific situations which have been researched to death (links to papers can be found on Hans Boehm's site). Frankly, the extra code required to make manual memory management work properly (for example, explicit reference counting, smart pointers, etc) is often more expensive than a garbage collector would be.


[ Parent ]
asynchronous I/O in java? (2.46 / 13) (#6)
by dieman on Tue Oct 10, 2000 at 02:14:53 AM EST

lack of asynchronous I/O

Theres this neat class called BufferedReader that does what you need I think.

BufferedReader blah = new BufferedReader( new Reader( file ) );
.
.
while(0!=blah.read(buf, offset, length)) {
	// copy out of buf here ...
}
.
.

Did you see any blocking?
---
blah

Re: asynchronous I/O in java? (3.25 / 4) (#55)
by alder on Tue Oct 10, 2000 at 11:43:58 AM EST

BufferedReader is just that - a buffered reader. Which is important in Java, because all other readers/streams are unbufferred. But there will be a point in time when it will have to read by itself next block of data from the underlying Reader, and that operation is synchronous! So you code will have to stop and wait while that Reader, through library, through driver, and so on, fetches the next block.

Asynchrounous operations do not require your code to wait, and because of this provide you with methods that initiate read/write operation and allow you to query I/O completion status. Or, as an alternative, you will have select/poll helpers at your disposal to predict when read/write operation will not block, and so emulate asynchronous I/O.

[ Parent ]

Re: asynchronous I/O in java? (2.50 / 4) (#56)
by beergut on Tue Oct 10, 2000 at 11:49:11 AM EST

Yes. There is blocking there, if the obj.read() method is mapped to the system level read() function, but does not invoke it with O_NBLOCK, or use some other method to ensure asynchronicity.

--BeerGut

i don't see any nanorobots or jet engines or laser holography or orbiting death satellites.
i just see some orangutan throwing code-feces at a computer screen.

-- indubitable
[ Parent ]

Re: asynchronous I/O in java? (none / 0) (#133)
by jovlinger on Wed Oct 11, 2000 at 05:11:37 PM EST

It shouldn't be too hard to implement select behavior with threads, should it? You pass it a whole bunch of read and write request objects and ask it to return the object which completed first. You then query the object to determine what the status was, bytes read... that sort of thing.

Internally, there'd be a thread for each request, which could be a bit on the heavy weight side, but hey, it'd work, and the only alternative is to use threads on a program-wide level.

Tho I will grant you that my request creation architecture is a bit on the clunky side. But hey. It's a 5 minute solution.

[ Parent ]

globals (2.59 / 22) (#7)
by dieman on Tue Oct 10, 2000 at 02:19:05 AM EST

Are evil, you shouldn't have to use globals in 99.95% of all instances when writing in Object Oriented languages. Keep globals away. Even in perl I know how to get around most instances where globals are Not Worth It.
---
blah
Re: globals (1.25 / 8) (#8)
by bottgeek on Tue Oct 10, 2000 at 02:27:28 AM EST

this is such common knowledge i cannot believe it had a 3.5 when i modded it down. seriously mod things up if it is interesting and actually informative.
I like food! Food tastes good!
[ Parent ]
Several. Read it or do not. (4.18 / 32) (#13)
by your_desired_username on Tue Oct 10, 2000 at 03:25:43 AM EST


(This is a rant, and it responds to several posts here - I am not
  going make 5 seperate replies with my 400 bytes per second modem
  connection. )

(0) Reference counting is only one of many gc techniques - most of
    which can implemented with reasonable performance for most
    applications.

(1) Most pointers to non-arrays do *not* change values often - in
    fact, they almost always keep the same value throughout their
    lifetimes. This is true in both C and C++. As for those pointers
    used for accessing arrays - well, C++ pointers are an assembly
    level construct, and arrays are a high level concept and using one
    as the other is a dangerous mix. Competent C++ programmers use
    std::vector.  

(2) Having used reference counting - and several other types of gc -
    in C++, and having benchmarked C++ programs with and without gc, I
    can say that for many applications, the performance difference is
    not measurable - but for some applications it is very
    important. It hard to tell in advance which category a program
    will fall into, though for most UI-heavy programs the performance
    overhead does not matter. 

(3) There are some gc purists who assert that reference counting is
    not 'real gc'. I disagree with them, because I know how to use
    destructors. 

(4) Competent C++ programmers (a) do not often need gc, and (b) know
    where to get it when they do need it. (see www.boost.org) Desire
    for gc is the symptom. The real problem is that those who teach
    C++ do not teach their students how use the features C++ already
    has. new and delete are low-level, are for implementing
    containers, are not intended for use in high level code, or by
    novices. If you use new and delete frequently, you are doing
    something wrong, or the designer of the gui library you are using
    did something horribly wrong.

(5) The improvements in development time cited for gc are highly
    dependent on coding style - gc never made me develop 30 percent
    faster (I measured it to less than 10%), but it is a big help to
    some people.

(6) The only reason - and it is a *good* reason - to put gc in the C++ 
    standard, is so that perhaps all the fools in the various
    universities and colleges around the world will wake the fuck up
    and start teaching their C++ students to use features that are
    already available to C++ programmers. Maybe that will not
    work; it does not (yet) seem to be working for the standard C++
    library. 

(7) Hopefully I am wrong, but I am afraid this the majority of people
    in this forum (a) do not care about gc in C++, and (c) do not have
    the technical knowledge necessary to understand the implications
    of adding gc to C++, or the historical knowledge to understand why
    it is not there in the first place. (If you know why destructors
    make reference counting trivial and natural, but most other gc
    algorithms very difficult, then I am wrong. If you know how many
    little-used-but-well-designed-garbage-collected languages were
    invented (prior to the cpu boom of the 90s), and then hardly used
    at all, I am wrong again. If you understand the reasons why and
    the situations in which destructors can be superior to gc, I am
    wrong a third time.)

(And now, having spewed much counterproductive fire and darkness about
  this topic, will vote it -1, not fit for a non C++-specific forum.)



Re: Several. Read it or do not. (3.20 / 10) (#22)
by rongen on Tue Oct 10, 2000 at 06:35:57 AM EST

Wow! Concise, informative, and largely I agree with you! :)

(6) The only reason - and it is a *good* reason - to put gc in the C++ standard, is so that perhaps all the fools in the various universities and colleges around the world will wake the fuck up and start teaching their C++ students to use features that are already available to C++ programmers. Maybe that will not work; it does not (yet) seem to be working for the standard C++ library.

It may hearten you to know that a Dr. where I am getting my CS undergrad "degree" really hammers on the STL. It's there from day one. His course is supposed to be "Object Oriented Programming" (and is, it goes into all the intricacies) but he also deals with many C++ language issues and encourages use of the STL. "Don't reinvent the wheel" is his motto.
read/write http://www.prosebush.com
[ Parent ]

Re: Several. Read it or do not. (2.55 / 9) (#26)
by Matrix on Tue Oct 10, 2000 at 07:51:26 AM EST

Any decent books you'd recommend for learning the STL? I've found some documentation online, but almost all of it seems to be reference material.


Matrix
"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

Re: Several. Read it or do not. (2.57 / 7) (#33)
by codemonkey_uk on Tue Oct 10, 2000 at 08:34:50 AM EST

Visit the ACCU website and check out the book reviews section.

If your serious about C/C++ then I'd strongly recomend joining.

Thad
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Books (3.42 / 7) (#40)
by Dacta on Tue Oct 10, 2000 at 09:17:36 AM EST

I just got (today) Accelerated C++ by Andre Koenig & Barbara E. Moo (ISBN 0-201-70353-X). I found it a little basic in that it is fairly short, but outstanding in that it (a) ignores C and (b) uses the STL from the first chapter. If you don't know C++ at all, it would be the best book you can get, I think.

http://www.acceleratedcpp.com/

I suspect Thinking in C++ (2nd Edition) might be good, too, but I've only had a quick look at the online version.



[ Parent ]
Books for the STL (3.85 / 7) (#60)
by your_desired_username on Tue Oct 10, 2000 at 12:11:22 PM EST

_Generic Programming and the STL_ by Matt Austern (who worked with stepanov on sgi's implementation of the stl). ISBN 0-201-30956-4

This is the best STL reference I know of. Unlike most reference texts, it is very readable, and has plenty of good examples.

[ Parent ]
Re: Several. Read it or do not. (3.50 / 2) (#93)
by XScott on Tue Oct 10, 2000 at 06:52:36 PM EST

new and delete are low-level, are for implementing containers, are not intended for use in high level code, or by novices. If you use new and delete frequently, you are doing something wrong, or the designer of the gui library you are using did something horribly wrong.


I hadn't thought about it like this before, but I agree strongly with your statement. You don't need garbage collection if you don't directly use dynamic memory allocation. If your libraries and collection classes are good (and the STL is mediocre in my mind), you should never have to call new or delete for much of anything.


-- Of course I think I'm right. If I thought I was wrong, I'd change my mind.
[ Parent ]
Re: Several. Read it or do not. (none / 0) (#148)
by Dougan on Thu Oct 12, 2000 at 10:47:08 AM EST

Most pointers to non-arrays do *not* change values often -in fact, they almost always keep the same value throughout their lifetimes. This is true in both C and C++. As for those pointers used for accessing arrays - well, C++ pointers are an assembly level construct, and arrays are a high level concept and using one as the other is a dangerous mix. Competent C++ programmers use std::vector.
Which, in most STL implementations, inlines to a bunch of array operations and accesses through pointers to array elements (std::vector<T>::iterator is usually defined as T*).. Arrays are not a high-level concept, they are extremely primitive constructs. The only way to get around this problem is to treat a vector iterator as a reference to the array + an array offset (which incidentally, is how many languages, including my current project Aldor, handle this).

The disadvantage, of course, is that vector iterators now are twice as space inefficient. Also, most C++ programmers (especially those with a C background) are not willing, given the shortcomings of C/C++, to forego the flexibility of pointer arithmetic in exchange for good garbage collection performance. This is one reason why alternatives to C++ (such as Java, ML, C#) are gaining prevalence -- a garbage collecting environment has been shown to enhance programmer productivity.

Cheers,
Greg

[ Parent ]

GC and destructors. (4.13 / 23) (#17)
by i on Tue Oct 10, 2000 at 04:26:49 AM EST

GC and destructors don't mix well.

Suppose we have to GC a circular structure. Say A points to B and B points to A. In what order the destructors are to be called? The GC code has no way of knowing what we want, so it must chose some arbitrary order. Let's say GC choses to destroy A first, B second. What if B's destructor wants to use A? It will get an object for which a destructor was already called, IOW raw memory -- no good. This is why Boehm's collector doesn't call destructors for circular structures.

If a destructor causes an exception, all hell breaks lose. Currently this is only true for stack-allocated C++ objects. Moreover, this situation can be corrected by changing the language (or sticking to some well-defined rules in the current language) in such a way that multiple independent exceptions are allowed to coexist. With GC, the problem is much more acute. It is unknown when and where the destructor will be called, so all code must be prepared to handle all exceptions -- no good again. Granted, the current wisdom is not to throw an exception from within destructors. But other methods of handling errors that occur in destructors are also problematic with GC. For instance, one cannot use scoped set_..._handler-style method, again because it is unknown when and where destructors are get called. So one has to settle for global handlers.

Finally, in a multithreaded application it is unclear in which thread destructors should run.

All these problems exist in Java too, but in Java destructors (finalizers in Java-speak) are rarely used. It is possible to write very Java-esque C++, but this style is alien to most competent C++ programmers. I dare to say that C++-with-GC is an entirely new language which is much more similar to Java than to C++-sans-GC. Which brings us to a question: why not use Java in the first place? (I know, I know. Templates, overloading, blah blah. All valid reasons.)

I'm not opposed to GC in general, or even to GC in the context of C++. I think that GC in C++ can make sense in some circumstances. The issue however must be approached with great care.



and we have a contradicton according to our assumptions and the factor theorem

Destructors are redundant in a GC language. (3.60 / 10) (#41)
by Carnage4Life on Tue Oct 10, 2000 at 09:21:32 AM EST

GC and destructors don't mix well.

Just out of curiosity doesn't garbage collection make a destructor redundant? A destructor is a language hack to get around the factthat there is no GC in C++, once garbage collection is added, exactly what purpose would destructors serve?

From Appendix C of The C++ Programming Language by Bjarne Stroustrop
    When an object is about to be recycled by a garbage collector, two alternatives exist.
    1.] Call the destructor of the Object.
    2.] Treat the object as raw memory. (don't call the destructor).

    By default, a garbage collector should use option (2) because objects created by new and never deleted are never destroyed. Thus, one can see a garbage collector as a mechanism for simulating infinite memory.


[ Parent ]
Re: Destructors are redundant in a GC language. (3.40 / 10) (#45)
by Jonathan White on Tue Oct 10, 2000 at 09:47:07 AM EST

What if the object has a resource such as a database or network connection that should be released? What if that object needs to notify other objects or release locks? There are many other things that may need to be done at destruction time other than freeing memory.

[ Parent ]
Re: Destructors are redundant in a GC language. (3.28 / 7) (#62)
by alder on Tue Oct 10, 2000 at 12:13:27 PM EST

Destructor is a very convenient semantical "hack". Consider for a moment a case when you created a number of objects, begin using them, and some exception has occured. Your objects must dispose of resources they might have allocated. Here you have two choices: either write appropriate finally construct, or let destructors do the job as part of stack unwinding. It's almost OK, if the finally has to be written once or twice, but the more finally you have to write the more places, where you can forget something, you have. So destructors is a feature that is very nicely automate proper deallocation of recources and therefore a feature that is nice to have, but, as the original poster mentioned, GC and destructors don't mix well... unfortunately.

[ Parent ]
Re: Destructors are redundant in a GC language. (3.42 / 7) (#70)
by your_desired_username on Tue Oct 10, 2000 at 01:23:53 PM EST

Your Stroustrup quote is from 2nd edition, (copyright 1989?), and it
  is out of date - he has changed his opinion. (Good C++ programmers
  use 3rd edition.)

In D&E (sorry, no section or page number; my copy of D&E is packed),
  Stroustrup brings up the same quote, and explains some of the
  problems with this notion.

One issue is that destructors are general resource management tool -
  they are used for everything from thread mutexes to database handles
  to sockets. For most existing C++ programs, a garbage collector
  will need to call destructors.

Reference counting is a gc algorithm that can be easily used with
  destructors, and has no bad interactions with destructors. The
  disadvantage of reference counting is that does not collect circular
  data structures. This is easily solved by writing destructors that
  break circular links before the objects become unreachable. (I have
  not yet seen a circular data structure that was not the result of a
  deliberate decision to create a circular data structore.)


[ Parent ]
Incorrect hypothesis (2.00 / 1) (#116)
by Carnage4Life on Wed Oct 11, 2000 at 12:59:32 AM EST

Your Stroustrup quote is from 2nd edition, (copyright 1989?), and it is out of date - he has changed his opinion. (Good C++ programmers use 3rd edition.)

bzzzt... wrong. The quote is from the 3rd Edition ©1997.

One issue is that destructors are general resource management tool - they are used for everything from thread mutexes to database handles to sockets. For most existing C++ programs, a garbage collector will need to call destructors.

The post I responded to claimed that garbage collectors and destructors are incompatible and I was merely showing that he was extremely mistaken. As the poster pointed out, Java™ has the same problem and gets around them with finalizers and thus there is no problem with interactions. Most people forget that unlike memory references, system resources are usually only used by one object at a time. File handles, sockets, etc are either kept global or are eliminated in the finalize() method call. If C++ implements garbage collection then destructors will simply be replaced by functions that clean up non-memory system resources and these can be managed a whole lot better than memory.



[ Parent ]
Re: Incorrect hypothesis (2.00 / 2) (#119)
by your_desired_username on Wed Oct 11, 2000 at 05:59:37 AM EST

  
I unpacked my copy of D&E (and my other Stroustrup books), and
  the section I was refering to is section 10.7.2, page 222.

It turns out that while your quote is in fact from 3rd edition (sorry
  about that), 2nd edition contains a very similar paragraph
  describing the same policy, with the same justification, which is
  why I thought you were quoting from 2nd, and D&E does in fact
  contain several objections to the strategy you quoted. I do not
  know why Stroustrup changed back to his earlier policy (3rd is more
  recent than D&E).

Personally, I still think the policy of the garabage collector not
  calling destructors would make it difficult to adapt existing
  programs to use a garbage collector, though it would not be a
  significant problem for new programs written after such a garbage
  collector was introduced.


[ Parent ]
Re: Destructors are redundant in a GC language. (none / 0) (#149)
by Dougan on Thu Oct 12, 2000 at 10:53:48 AM EST

Just out of curiosity doesn't garbage collection make a destructor redundant? A destructor is a language hack to get around the factthat there is no GC in C++, once garbage collection is added, exactly what purpose would destructors serve?
For instance, releasing a network handle, or cleanly closing a network connection (if there is some nice application-level way to terminate the connection, for instance "QUIT" in FTP); closing files; etc..

Cheers,
Greg

[ Parent ]

... (none / 0) (#161)
by ksandstr on Sun Oct 15, 2000 at 11:59:48 AM EST

You can have a "close" method for all of these things. That's the way I've seen things handled in Python, although in Python you can still def a __del__(self) method for a class if you really really need to.



Fin.
[ Parent ]
Re: GC and destructors. (none / 0) (#146)
by jacob on Thu Oct 12, 2000 at 09:43:30 AM EST

The problem with destructors and GC is just that they have a very strict time rule- the destructor gets executed when the object dies, not 10 seconds later. If you relax that rule- that is, make the semantics of a destructor that it gets called at some unknown time after the destruction of the object but before the program finishes- the problems go away. (I know PLT's Scheme does it this way, and I believe that's the semantics for finalizers in Java, though I could be mistaken.)

--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]
from a user's perspective (3.52 / 21) (#18)
by semis on Tue Oct 10, 2000 at 04:49:15 AM EST

Most of the posts around here seem to be getting into the technical aspects of garbage collection.

I would like to comment on my experiences with C++ and memory management. I hate it. Some people have what seems to be a natural ability to visualise what the memory in their programs is doing - whats being referenced, when they don't need it, etc..

Now, I'm *ok* with memory management in C. Mainly because it's not OO and tracking memory is alot easier for me.

But OO? No way. My C++ leaks all over the place. Not because I am not a competent programmer - I can visualise logical and OO structure easily - just not memory :(

Thus, I would love to see garbage collection in C++. "Old schoolers" might be vehemently against it.. they say it makes their software slower - but then again thats what ASM programmers said about C! I think it's only inevitable.

Anyways, thats my perspective. When C++ has garbage collection I will certainly be "turning it on" !

Re: from a user's perspective (3.57 / 7) (#21)
by rongen on Tue Oct 10, 2000 at 06:27:16 AM EST

Have you ever tried using auto-pointers instead of "regular" pointers? They kind of pass the responsibility for deleting an object around so the programmer doesn't have to track this explicitly. My experience with these (and C++) is rather limited though, so you should take what I say with a grain of salt... But look into them, it might prove worth your time.

Check pp. 409-15 in "C++ Primer" (Lippman and Lajolie) or your favorite C++ book for how and why to use these...
read/write http://www.prosebush.com
[ Parent ]

Re: from a user's perspective (3.75 / 4) (#61)
by Samrobb on Tue Oct 10, 2000 at 12:12:38 PM EST

Some anecdotal evidence about smart pointers...

While developing our 1.x product, we had fairly regular problems with identifying and tracking down memory and refcount leaks (lots of COM objects - the product is written for Windows, obviously.) We managed to get them ironed out, but there was at least one siginificant leak that took three people about a week to identify and patch.

Four months into 2.x development, we've got (approximately) the same amount of code as we ended up with in 1.x, with only the occaisional memory leak. One of the major differences between the two code bases was switching from manual memory/refcount management and methods returning error codes to extensive use of smart pointers and exception handling.

While I'm sure that GC would have solved our problem as well, I think that using a non-GC language that supports smart pointers and the like can come very close to providing the same sort of "it just works" memory management.


"Great men are not always wise: neither do the aged understand judgment." Job 32:9
[ Parent ]
Re: from a user's perspective (none / 0) (#101)
by nickread on Tue Oct 10, 2000 at 07:26:37 PM EST

Thus, I would love to see garbage collection in C++. "Old schoolers" might be vehemently against it..

"Old Schoolers"?? I'm 19, still doing my degree (only to get on paper what I already know), not an "Old Schooler", and even I know that GC can really suck when it's not wanted.

On a lighter note, how can you find OO memory management much different from procedural languages? Objects are good in that you write them to do their own memory (de)allocation. Once you have you object working correct (with out leaks, incorrect logic, etc), it will work all the time, every time. Also, the GC will not be working on what each object needs because you've already thoroughly tested the object before hand (hopefully).

[ Parent ]

What a biased poll (2.00 / 10) (#19)
by PresJPolk on Tue Oct 10, 2000 at 04:58:18 AM EST

It assumes that anyone who develops with C++ will jump at the chance to slap on garbage collection.

Automatic garbage collection will never be able to replace competent design, because a garbage collector can't understand what the program is trying to do.

It seems to me that GC is most useful when the developers can't or won't take the time to design, which isn't a process that ever leads to good software anyway. So, here's one C++ developer who really doesn't care. :-)

Re: What a biased poll (3.57 / 7) (#20)
by i on Tue Oct 10, 2000 at 06:24:34 AM EST

Automatic garbage collection will never be able to replace competent design, because a garbage collector can't understand what the program is trying to do.
By the same logic, compilers will never be able to replace hand-crafted assembly, because a compiler can't understand what the program is trying to do.
It seems to me that GC is most useful when the developers can't or won't take the time to design, which isn't a process that ever leads to good software anyway.
What about functional programming? Are FPers incompetent? Do they produce bad software?

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]
Re: What a biased poll (1.00 / 4) (#59)
by PresJPolk on Tue Oct 10, 2000 at 12:09:18 PM EST

What about functional programming? Are FPers incompetent? Do they produce bad software

Don't reverse my logic. Just because I'm saying that GC would be of most use to the incompetent, doesn't mean I'm saying only the incompetent want GC.



[ Parent ]
Re: What a biased poll (none / 0) (#141)
by mafried on Wed Oct 11, 2000 at 11:36:23 PM EST

By the same logic, compilers will never be able to replace hand-crafted assembly, because a compiler can't understand what the program is trying to do.

That's right, they are. Nice to see that you've finally woken up to the fact.

[ Parent ]
Re: What a biased poll (3.66 / 6) (#23)
by tagish on Tue Oct 10, 2000 at 06:53:50 AM EST

What an ignorant post ;-)

It assumes that anyone who relies on garbage collection is incompetent. In fact the ramifications of GC are far more wide reaching and more important than freeing programmers from the inconvenience of remembering when to discard allocated objects.

By making the issue of which part of an application owns the object (and must therefore undertake to free it) effectively moot GC greatly simplifies a number of designs.

Hands up anyone who remembers when "compiled languages would never replace assembler because the compiler can't understand what the program is trying to do".


-- Hexten
[ Parent ]

Re: What a biased poll (1.00 / 3) (#58)
by PresJPolk on Tue Oct 10, 2000 at 12:08:01 PM EST

It assumes that anyone who relies on garbage collection is incompetent. In fact the ramifications of GC are far more wide reaching and more important than freeing programmers from the inconvenience of remembering when to discard allocated objects.

No, what I mean is that GC is of most benefit to the lazy and incompetent.



[ Parent ]
Re: What a biased poll (4.50 / 2) (#75)
by tagish on Tue Oct 10, 2000 at 01:54:54 PM EST

I agree completely. I feel the same about operating systems -- competent, diligent users can just toggle the switches on the front of the box.

There may be legitimate objections to garbage collection, but yours are not among them I'm afraid.
-- Hexten
[ Parent ]

(3.64 / 17) (#25)
by daani on Tue Oct 10, 2000 at 07:50:33 AM EST

I bet the majority are reading this and thinking "I know where all the memory is. For every new I can see the delete. What's the problem?". At least that's what I thought anyway. But where I work (we develop a SCADA product, all C++, 3 platforms diff platforms running in a deployed system) the biggest hassle is memory leaks in various modules. It is really limiting the scale of the system. If C++ had of done garbage collection when it was first developed.....

Anyway my point is that I wouldn't think it was all that great to develop with a GC C++, but I might prefer to [buy|deploy|use|modify] software that I knew didn't leak memory.

Less CPU use with GC (2.94 / 18) (#27)
by boxed on Tue Oct 10, 2000 at 08:07:41 AM EST

Uses equivalent or less CPU-time than a program that uses explicit memory deallocation.

Eh, you must be joking. GC is _always_ slower than good solid manual memory handling. This is pretty obvious since the GC has to check through the memory at regular intervals to check if memory needs to be destroyed, even if there is no memory that actually does needs to be freed

Re: Less CPU use with GC (3.14 / 7) (#31)
by codemonkey_uk on Tue Oct 10, 2000 at 08:27:22 AM EST

GC is _always_ slower than good solid manual memory handling.
Yes. But the point GC advocates are trying to get across is that most people can't write good solid manual memory handling. In fact most people have problems writing applications that don't leak.

The point for these people is not beating the best case, but beating the average case. Its a question of education or garbage collection...

Thad
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Re: Less CPU use with GC (4.00 / 7) (#35)
by i on Tue Oct 10, 2000 at 08:46:30 AM EST

GC is _always_ slower than good solid manual memory handling.
Yes.
Not necessarily. A quick Google search reveals several interesting documents.

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]
Re: Less CPU use with GC (2.83 / 6) (#37)
by boxed on Tue Oct 10, 2000 at 09:01:44 AM EST

Yea, this is why I'm generally pro-GC, but claiming it is faster than conventional memory management is just plain wrong...

[ Parent ]
Re: Less CPU use with GC (3.85 / 7) (#38)
by tagish on Tue Oct 10, 2000 at 09:10:13 AM EST

GC based allocators may have the potential to be faster than non-GC allocators because their allocation strategies can be very much simplified.

Bear in mind also that garbage collection can run when the system is idle which, even if GC consumes more processor time overall, can improve throughput and responsiveness.


-- Hexten
[ Parent ]

Re: Less CPU use with GC (none / 0) (#86)
by pli on Tue Oct 10, 2000 at 04:40:04 PM EST

... claiming it is faster than conventional memory management is just plain wrong...
Claiming the opposite is just as wrong. A garbage collected application can run faster than it's non-garbage collected counterpart, but not neccessarly. It completely depends on the the GC strategy and the memory allocation pattern of the application. However, in most cases a non-garbage collected application will run faster.

[ Parent ]
Re: Less CPU use with GC (4.00 / 6) (#68)
by your_desired_username on Tue Oct 10, 2000 at 12:57:19 PM EST

I am actually replying to this whole thread.

(0) Modern computers have enormous amounts of processing power. For
    many applications, factor of 2 slower will not be noticeable to
    the user - let alone 10% or 20%. 

(1) The performance impact of gc varies greatly depending on the gc
    algorithm chosen, the behavior the application, and how they
    interact.

(2) The performance impact of programmer-managed memory varies
    greatly, depending on the application and the skill of the
    programmers involved.

Arguing about the performance of gc is akin to arguing about the
  performance of slicks vs all-weather tires, but not paying any
  attention to the kinds of roads people drive on, the cars they
  drive, and how fast they really need to go.

(There are some applications where performance is quite important -
  and there are applications where most (or all) gc algorithms not an
  option for reasons (like unpredictability) other than performance.)  


[ Parent ]
Re: Less CPU use with GC (4.00 / 2) (#104)
by tdanner on Tue Oct 10, 2000 at 07:59:23 PM EST

To implement GC on top of C++ in a backwards-compatible way, you pretty much have to use a conservative collector. That's what Boehm did. It does what you say: scan through the heap at regular intervals (well, actually it checks when you ask for more memory and there isn't any). There are some strange hacks based on overriding the pointer-related operators to get around this, but as far as I know none of them work especially well, especially in the face of third-party libraries.

But I want to take issue with your assertion that GC is always slower than manual deallocation. In safe languages (these days, that's pretty much all languages except C, C++, and assembly), the runtime gets complete mediation of pointers, so it can do much, much better.

Consider the mark-and-sweep collection algorithm. It goes like this:

  1. Start with the root set of pointers. That typically includes any pointers in the current stack frame and the globals.
  2. Mark those objects as "used" in some central heap map.
  3. Recursively follow any pointers in those objects marking stuff used and following more pointers.
  4. When you finish that, you have a new memory usage map for use in allocation.

What's the complexity of that algorithm? The number of currently active objects. Sounds pretty bad! But consider that, in most modern OO systems (which is what high-level language features are targetted at, so please don't carp about the real-time system that controls your airbags), there are usually more dead objects than live ones! What's the complexity of manual deallocation? It's proportional to the number of dead objects. Now we have a framework for choosing a memory management system based on performance concerns. Are there usually going to be more dead objects or lives ones?

Now for another twist: the copy collection algorithm. This time, instead of keeping a map as you mark stuff, copy it to a second heap. Maintain a table of the moves you make so that you can update the pointers in other objects as you copy them. When you're done, just "free" the whole first heap.

Now, this takes twice as much memory, which hurts. But look at what you get for it: easy heap defragmentation! In some cases (primarily small objects), that can be great for VM performance. There's a variation on this one called generational garbage collection where you track the age of each object. In most OO systems, the older an object is, the less likely it is to be dead. So you keep old objects separate from young ones to keep the time required for a pass nice and short.

So while most of this doesn't really help C++, it does help safe languages. Unfortunately, Perl and Python are both still reference-counted, which has pretty crappy performance, but hey - who expects great performance form Perl and Python?

Tim



[ Parent ]
Re: Less CPU use with GC (none / 0) (#111)
by Pseudonym on Tue Oct 10, 2000 at 10:18:09 PM EST

Eh, you must be joking. GC is _always_ slower than good solid manual memory handling. This is pretty obvious since the GC has to check through the memory at regular intervals to check if memory needs to be destroyed, even if there is no memory that actually does needs to be freed

No it's not. It's often the case that the cost of the overhead of keeping track of object lifetimes is greater than the cost of garbage collection.

The overhead cost can also sometimes be super-linear! That is, being obliged to keep track of object lifetimes can sometimes require use of a less efficient algorithm. This can happen when you're using very complex data structures with all sorts of internal references (e.g. in a compiler).

This is pretty obvious since the GC has to check through the memory at regular intervals to check if memory needs to be destroyed [...]

A generational collector only needs to check through the most recently allocated objects, and after a certain time promote those objects which are still live to "less recently allocated" status. Even then, only live objects are scanned, which is usually a very small fraction of the recently allocated objects. Lots of objects have very short lifetimes in a modern OO program.


sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
[ Parent ]
Nobody's mentioned that... (1.80 / 15) (#28)
by Luke Scharf on Tue Oct 10, 2000 at 08:12:12 AM EST

<rant>

Nobody's mentioned that Java isn't used very much. Sure it's a handy and useful language (and it can be used for serious computation if you stretch the JVM to it's limits), but almost everything that I see is writtin in C/C++.

Not to mention that all of the "real" application that I've used or that people I work with have used that were written Java has been nearly unusable due to performance problems on our PIIs. (With one exception, but it's an environment for simulating hardware designs and we expect it to take hours to run on our Athlon 950 + 1gb or RAM.) I'm trying to remember the names of the applications -- I'll check and see if people are interested.

Grabbing the most performance-reducing feature from Java scares me. Of course, I don't like cstrings and fail to see the point of namespaces right now too. Oh, yeah -- taking the .h off of the header files caused me some problems when I had a header files that happened to be the same name as my executable. :-)

</rant>



Re: Nobody's mentioned that... (3.75 / 4) (#43)
by Dacta on Tue Oct 10, 2000 at 09:27:18 AM EST

What do you work on?

I've just, (for the first time) come across a business app that uses C++, and that is only because it is a MTS/COM layer for other COM enabled languages to use.

I have reasonably extensive experience working on business apps, and I've seen VB, Delphi, Java, COBOL and assorted other weird languages. C/C++ is conspicous by its absence.

OTOH, I see heaps and heaps of Java. I don't know what kind of app you are working on, but we're running server-side Java on PII 600s under Windows, with IIS on the same machine for our development environment. It works fine - days without rebooting, which is pretty good for NT4. It is fairly intensive in memory usage, but not really as bad as everyone claims. I hear that Apache Coocoon needs 256Meg RAM just to run, though - so obviously some people have issues.



[ Parent ]
Re: Nobody's mentioned that... (1.25 / 4) (#57)
by mx on Tue Oct 10, 2000 at 12:03:45 PM EST

days without rebooting? wow, i am impressed. only on a microsoft platfor could that be a good thing. i have a few server apps that have gone *years* between reboots. "neener, neener, neener, good code is for loosers"
- mx
[ Parent ]
Re: Nobody's mentioned that... (2.00 / 1) (#95)
by Dacta on Tue Oct 10, 2000 at 06:58:10 PM EST

:-)
What can I say?

[ Parent ]
Re: Nobody's mentioned that... (2.00 / 1) (#96)
by boxed on Tue Oct 10, 2000 at 07:00:07 PM EST

May I remind you that Windows, IIS, Office and practically everything else MS makes were written in C/C++. Now try to name a "business app" that is used more often than Office. I dare ya!

[ Parent ]
Re: Nobody's mentioned that... (2.00 / 2) (#107)
by Luke Scharf on Tue Oct 10, 2000 at 08:55:57 PM EST

OTOH, I see heaps and heaps of Java. I don't know what kind of app you are working on, but we're running server-side Java on PII 600s under Windows

Most of the code I see are educational programming projects and Linux kernel code so I'm a little biased. I like to play with device drivers, but I can't say that I've written anything impressive.

Another poster stated that Microsoft Office and IIS are written in C/C++. I very conservatively estimate that 95% of the binaries on a typical Windows NT system are written in C/C++. Now, on a Windows NT workstation that's easy for me to reach, there are about 2050 EXEs, DLLs, and VXDs on the local drive. This sums to to around 350mb of binaries. Big applications like Microsoft Office, Workview Office, and the like are remote-mounted from the server and weren't counted here.

My experience on Linux machines is that the C/C++ source code is ALWAYS bigger than the binary. YMMV on Windows as I don't remember the dark mountain-dew enhanced nights coding-nights of my freshman year very well. Either way, that's a LOT of C/C++ code.

Ok, so supposing that someone has 100k lines worth of code written and working nicely in Java. I consider that "not used very much". Depengind on what you're doing, the Java code may be the crown jewel of the system, but it still ain't much by weight.

Also, I'm pretty sure that a lot of the Java class library (right term?) is implimented through the JNI. (Although not absoultely certain). At least the system calls have to get out of the JVM somehow, and the GUI libraries have to be fast AND call non-kernel level APIs like the win32 api and xlib (or motif or gtk?). Guess what that means - C/C++ code!

Of course, this analysis is highly biased towards system programming. If, for instance, you select all code that generates web pages, the picture will probably change substantially -- to something like 50% Java code, depending on how you think of your webserver and your OS.



[ Parent ]
Clarification (4.00 / 1) (#117)
by Dacta on Wed Oct 11, 2000 at 02:39:17 AM EST

When I'm talking about business programs I'm not talking about MS Office or things like that. I'm talking about vertical applications - things like bill processors, stock management and other similar things.

While they may not take up as much space as Office on computers, they are typically used more. These are the systems that people talk about when they say they require 24/7 availability. I've never really worked on something that was in heavy use 24/7, but I have done critical systems that were in use 18/7 for 3 months straight. That wasn't in C++ (it was Delphi), and believe me, it was used more than any office installation I've seen.

I do understand the point about Office being C++, but that's not the point. That is written by lots of progammers, who have time and talent to burn. The apps I'm talking about are typically written & supported by overworked & underpaid IT department, who have management telling them to get things fixed or the business will go bust.



[ Parent ]
Re: Nobody's mentioned that... (2.66 / 3) (#54)
by beergut on Tue Oct 10, 2000 at 11:34:06 AM EST

The best use I've devised for namespaces is for grouping together functions and data into a logical "package".

Consider:

In C, I have a library of containers, with much of the code in common - say, a binary tree (used to represent linked lists (with O(lg(n)) goto-index search complexity), ordered lists, searchable trees, balanced trees, and which can be ganged into arrays for hashing and fast collision resolution.

It only makes the most logical sense to share as much of this code as possible between the various child "classes". In order for a function in, say, bstree.c to be available to code in lnklst.c, however, is to make its scope public.

This is solved by the "namespace" abstraction. A couple of private header files for prototypes, and a "namespace __my__private__crap__", and the functions and any static data (allocator page free lists, etc.) are bundled out of sight.

C's use of a "flat" symbol space is convenient for pounding out low-level code (though I think something like device drivers in a kernel could use a better system of linkage - then you'd easily resolve problems with namespace collision, and "oh, I have two of these cards in my system - but I can only use the first one detected because the driver's exported symbols clash with itself" problems). C++'s authors, IMNSHO, made a mistake when they elected to follow C down that path, and introduced name mangling to flatten their heirarchies of classes. In the end, it has caused more grief than it's worth.

Granted, C++'s use of namespaces is a bit ... obtuse. For instance, you can't use namespaces as template parameters, so you have to construct classes with static methods and data to net the same effect - in which case, why have namespaces at all?

My $.02

--BeerGut

i don't see any nanorobots or jet engines or laser holography or orbiting death satellites.
i just see some orangutan throwing code-feces at a computer screen.

-- indubitable
[ Parent ]

GC necessary == (lazy && inattentive programmer) (2.50 / 22) (#30)
by sbeitzel on Tue Oct 10, 2000 at 08:25:37 AM EST

"Every large C++ application leaks memory." Bah. That's not a language limitation, that's a programming limitation. That's entirely the result of all these guys who've been ranting about how you don't learn vital programming skills in school and you can just pick up a language on your own.

Sure, you can pick up C++ on your own. But unless the "Teach Yourself C++..." books have gotten significantly better, you're not going to understand destructors and you're probably going to write code that leaks memory. If you just pay attention and think about what's going on, there's no problem.

For two and a half years I wrote C++ ISAPI DLLs that were run hundreds of times per minute. Once, early on, I made a mistake and leaked one word per request. Under normal load it crashed the server in a couple of minutes. That only happened once. I reiterate: all you've got to do is pay attention to what you're doing. And use the class destructor!

If the apocryphal large C++ application were developed using MFC, then of course it would leak memory; MFC is buggy as a backyard tomato and breaks when you try to scale it up beyond single-user load. But if I can't trust MS to manage the memory in their own framework (CString, CHttpServer, CRecordset, CStringList) then you'll understand my reluctance to letting them manage memory in my code.

Re: GC necessary == (lazy && inattentive programme (3.80 / 5) (#50)
by maketo on Tue Oct 10, 2000 at 10:35:17 AM EST

So, just because you are given a better tool means that you are going to be lazy and inattentive? That is like saying that more comfortable cars mean bad drivers. Or something to the effect. As a reader mentioned - GC should be in any high(er) level language - if it is not, all that manual memory manipulation defeats the purpose of the abstraction that we are supposed to have gained with the high level language.
agents, bugs, nanites....see the connection?
[ Parent ]
Re: GC necessary == (lazy && inattentive programme (none / 0) (#94)
by boxed on Tue Oct 10, 2000 at 06:56:18 PM EST

Heh, good analogy, especially since it's true! More comfortable cars is a danger when driving short distances. (Comfortable cars are of course neccessary when driving long distances.) This follows by the same logic that dictates that churches have hard benches and roads never ever be straight for long distances. If your car is too comfortable and the road too straight you'll fall asleap and crash.

[ Parent ]
GC necessary == (lazy && inattentive) programmers (none / 0) (#158)
by kjeldar on Fri Oct 13, 2000 at 06:25:07 PM EST

...Comfortable cars are of course neccessary when driving long distances...

I hate to be a logic nitpicker, but you just blew a hole in your own argument. Think about it.

[ Parent ]
Re: GC necessary == (lazy && inattentive programme (3.00 / 1) (#89)
by trhurler on Tue Oct 10, 2000 at 05:55:22 PM EST

Sure, you can pick up C++ on your own. But unless the "Teach Yourself C++..." books have gotten significantly better, you're not going to understand destructors and you're probably going to write code that leaks memory. If you just pay attention and think about what's going on, there's no problem.
I learned C++ outside of a classroom, and I know the language as well as or better than anyone I know who gained his knowledge in a classroom. I didn't use some crappy self-help book, to be sure. Yeah, I have a degree - but that's not what made me competent. Of all the people I know who learned their programming in a classroom(which is to say, probably a couple hundred,) there are three who are competent. Frankly, I find apologists for the modern "higher education" system to be somewhat annoying, but then to insinuate that those of us who actually learn because we enjoy it are idiots - that's really crude, man.


--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Re: GC necessary == (lazy && inattentive programme (none / 0) (#98)
by nickread on Tue Oct 10, 2000 at 07:17:07 PM EST

I fully agree with your statement about 3 out of a couple of hundred students not being able to program properly, if at all.

I'm going to do a Software Project course next year as part of my 3rd year. We have to be in a small team (4-5) of students to undertake the project, but I don't know if there exist 3 other people doing the same Comp. Sci. degree that could write a "hello world" program in C, or even make a "hello world" web page!

What am I to do?!?!

[ Parent ]

Re: GC necessary == (lazy && inattentive programme (none / 0) (#120)
by ghoti on Wed Oct 11, 2000 at 07:40:33 AM EST

What am I to do?!?!
Easy: You do all the work, and the others get the degree (and you too, of course). At least that's the way it worked in my projects. I don't think teamwork works very well when the people aren't good at programming. You need to learn that first, and thoroughly, too.
°<><
[ Parent ]
Another argument for GC (4.42 / 28) (#46)
by jacob on Tue Oct 10, 2000 at 09:56:58 AM EST

I'm surprised no one has mentioned this yet: one of my professors in college was one of the leading developers of Scheme, a high-level language that, among many other features, has built-in garbage collection. He argued that manual memory allocation and deallocation was bad in high-level programming languages because it would violate their abstraction level: why, in solving a problem about geographical mapping or analyzing sonar data or playing solitaire or whatever, does the problem of where contiguous blocks of unused memory exist matter?

What bits are allocated to what is an extremely low-level concern. High-level languages ought to abstract over low-level concerns because that is the point of high-level languages. You get faster development time out of C++ than assembly because C++ allows you to think about your problem in terms of the problem domain, not in terms of what exactly to tell your CPU to do.

You sometimes lose some efficiency (over the most efficient possible assembly program) for that benefit, but that's okay: first, you're not losing more than a constant factor if you understand computer science, and second, CPU cycles are cheap and programmer cycles are expensive. Third, high-level abstractions (yes, including garbage collection) can lead you to an overall more elegant, efficient solution than you would have thought of had you been more concerned with where the bits go.

Furthermore, in the critical places where high-level abstractions impose too much overhead, you always have the option of rewriting just those sections in assembly and tweaking the hell out of them. The best of both worlds.



--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

Re: Another argument for GC (3.20 / 5) (#74)
by your_desired_username on Tue Oct 10, 2000 at 01:41:48 PM EST

From the very begining, C++ was intended to be good language for low-level programming. This was one of the reasons - although not the primary reason - why gc was originally left out of C++.

[ Parent ]
Re: Another argument for GC (2.57 / 7) (#76)
by SIGFPE on Tue Oct 10, 2000 at 03:01:08 PM EST

One of the things I've found about college professors, whether or not they were devlopers of fine languages like scheme, is that they have a tendency to make statements that don't bear much relation to reality and are better suited to ideal worlds in which we don't live!
SIGFPE
[ Parent ]
Re: Another argument for GC (4.66 / 3) (#134)
by shaum on Wed Oct 11, 2000 at 06:23:11 PM EST

Optimizing to value programmer time over machine time is very much a real-world concern. It's the reason why the real world has gravitated towards time-saving tools like VB, Access, and Perl, none of which are exactly the darlings of academia.

There are some domains in which machine time is the sine qua non -- "infrastructure" like OS, network, and DBMS software; real-time; and embedded systems with tight hardware constraints -- but the rest of the time, i.e. for 90%-plus of the software in the world, shaving a day off the development time is far more important that shaving a second off the execution time.

As I've transitioned from C/C++ to Java and Perl, I've been amazed at how much faster the work goes when you don't have to sweat memory management.

:wq!
[ Parent ]

What's really needed... (3.63 / 19) (#47)
by Millennium on Tue Oct 10, 2000 at 09:57:45 AM EST

Garbage collection is all well and good, particularly for beginning programmers. But people here are right in that it doesn't replace manual memory management.

That doesn't, however, mean it can't still be useful.

What I'd like to see is a GC-like debugging device. Such a tool, when it destroys garbage, warns the programmer that it had to do so, thus blocking a potential memory leak. Along with information on the destroyed onject, this could become a very useful tool for finding and plugging memory leaks (Stroustrop was right in his assertion that all large programs leak memory; this is a way to help fix it).

For final builds, the "training wheels" could be removed, thus reclaiming the performance lost to the GC while debugging.

C++, as it currently has memory-management features which traditionaly garbage-collected languages lack, is uniquely suited to this sort of tool. What do others here think about something like this?


What's the fun in being "cool" if you can't wear a sombrero? -Hobbes


Performance and GC (4.71 / 7) (#53)
by jfpoole on Tue Oct 10, 2000 at 11:10:46 AM EST

For final builds, the "training wheels" could be removed, thus reclaiming the performance lost to the GC while debugging.

Running a garbage collector does not necessarily mean that performance suffers. In fact, there have been occurences where replacing malloc/free with a garbage collector has increased the performance of a program by 10%.

Also, if you design your program from scratch to use a garbage collector, you can get rid of all the memory management code in your program. In smaller programs this is probably a trivial amount of code, but in larger programs the amount of code saved can be fairly dramatic. Thus, not only is there less code to run, there's also less code to write, which is a Big Win. Developers can then focus on other aspects of the program that the user will find useful (such as functionality, interface, or squashing more bugs) rather than manually wrangling memory.

-j

[ Parent ]

Re: Performance and GC (none / 0) (#109)
by Luke Scharf on Tue Oct 10, 2000 at 09:46:59 PM EST

Running a garbage collector does not necessarily mean that performance suffers. In fact, there have been occurences where replacing malloc/free with a garbage collector has increased the performance of a program by 10%.

No offense, but the person using malloc/free in the origional program must have been an idiot.

Anyone who writes pointer code should know better than to do the following:

#include <malloc.h>
int main()
{
  for(int i=0; i<100; i++)
    {
	char* mybuf;
	mybuf = (char*)malloc(1000*sizeof(char));
	
	//Do something interesting

	free(mybuf);
    }
}

The call to malloc() is expensive -- especially if the program has to wait around for the OS to actually give it more memory.

Elegant? Maybe, depending on how you think about your data. Slow? Defeintly.

Here's what I would usually consider the Right Way:

#include <malloc.h>
int main()
{
  char* mybuf;
  mybuf = (char*)malloc(1000*sizeof(char));

  for(int i=0; i<100; i++)
    {
	
	//Do something interesting

    }

  free(mybuf);
}


[ Parent ]
Contrived Examples And More Shenanigans (none / 0) (#112)
by Carnage4Life on Tue Oct 10, 2000 at 10:37:32 PM EST

Using malloc/free (maybe the original poster meant new/delete) becomes hairy when managing complex objects that contain dynamically allocated data that contains dynamically allocated data, ad infinitum and will be shared by multiple objects.

class RoundRobin{

private:
//ready queue of PCBs
deque<PCB*> readyQueue;

//initializes the readyQueue
void initReadyQueue(PList processList);

//free memory pool
vector<int> freePool;

//used memory list
map<int, pair<PCB*,int>* > usedMemList;

//paging daemon log file
ofstream pagefile;

//scheduler log file
ofstream schedulefile;
};


Above is a sample class that holds contains a data structure that holds dynamic data which also contain a data structure that contains dynamic data. In production code that is several hundred thousand or millions of lines long with complex interactions between objects like the one above or even more complex, managing memory deallocations needs sophisticated techniques such as smart pointers or manual reference counting to make sure the memory state is consistent and even then leaks are usually unavoidable.

For example the company I worked for this summer had a product with over 400 boolean flags meaning that there were 2^400 permutations of states that the product could be in at a given time. In this situation, the amount of effort being spent in designing leak prevention and tracking mechanisms would have been equivalent or less than the amount of effort involved in garbage collection if the GC thread ran at the right time.



[ Parent ]
Re: Performance and GC (none / 0) (#118)
by bowb on Wed Oct 11, 2000 at 04:08:05 AM EST

Also, there's automatic optimizations that can be done in Garbage Collected languages that can't be done in languages with Manual Memory Management. For instance

Trishul M. Chilimbi, " Cache-Conscious Data Structures--Design and Implementation", Computer Sciences Dept., University of Wisconsin-Madison , July 1999.
http://www.cs.wisc.edu/~chilimbi/Pubs.html

That paper deals with the placement of data structures in memory to take advantage of cache. This can't be done in C++ because structures can't be move transparently to the programmer.

The author of the paper contends that, since CPU speed is outpacing memory IO speed, memory IO becomes the bottleneck, and optimizations like this will become increasingly important.

[ Parent ]

Re: What's really needed... (2.66 / 3) (#67)
by Surly on Tue Oct 10, 2000 at 12:56:42 PM EST

Isn't this what memory tools are used for? When I develop, I do run the tools after each major change that I make and occasionally after small changes. There is a bit of a learning curve to understanding the output of these tools but they are very usefull.

[ Parent ]
Why not just not have leaks? (1.87 / 16) (#49)
by pyromage on Tue Oct 10, 2000 at 10:34:47 AM EST

I know I'm going to get flamed for this, but hell, why not? Why not just write code without leaks? It sounds hard, but run your program through a utility like MemProf or such and you can easily identify and fix all leaks! So why worry about GC?

The fix-it-later mentality only works as well as.. (2.33 / 3) (#64)
by marlowe on Tue Oct 10, 2000 at 12:23:01 PM EST

the tools you have. And when you've been programming long enough, you learn to instinctively distrust most tools.
-- The Americans are the Jews of the 21st century. Only we won't go as quietly to the gas chambers. --
[ Parent ]
Re: Why not just not have leaks? (3.25 / 4) (#65)
by your_desired_username on Tue Oct 10, 2000 at 12:30:59 PM EST

Funny you should mention that. I write C++ code without leaks all the time.

C++'s constructors and destructors make it easy for one to manage one's own memory (and other resources - good C++ programmers know destructors can be used to manage every thing from thread mutexes to database handles to sockets)

But all of this requires (a) knowing how to use destructors (b) discipline and (c) attention to detail.

My experience is that many programmers fail on 2 of the 3. The fact that you and I can manage our own memory is often not enough; if you have a 5 person team, and only 4 of the 5 know how to manage memory, the 5th will cause many problems.

[ Parent ]
Re: Why not just not have leaks? (none / 0) (#132)
by jovlinger on Wed Oct 11, 2000 at 05:00:34 PM EST

Possibly, the biggest win of GC isn't plugging memory leaks, but rather simplifing interface design. When you pass objects into and outof a third party library, it is a clear win not to have to worry about whose reponsibility it is to free them. In a manually managed language, you are stuck either passing by copy (boo!) or with complicated reference counting schemes (thus complicating the interface).

Johan

[ Parent ]

Rather biased article (3.41 / 17) (#52)
by jwb on Tue Oct 10, 2000 at 11:00:56 AM EST

When you write a persuasive article such as this one, you of course are required to cast your viewpoint positively. But you must at least remember that if you go too far, you will lose credibility and the reader will not be persuaded.

This article lists the supposed advantages of the Boehm GC as absolute, and lists the disadvantages as conditional. The GC certainly reduces development time by 30 to 40 percent, and it may not work in some cases.

The author could as easily written it to be much more biased in the other direction:

  • May decrease development time for unskilled programmers.
  • Some people may perceive the interfaces to be less restrictive.
  • Swaps all the time.
  • Doesn't work with all source code.
  • Creates more bloated object code.
  • Unpredictable algorithm leads to randomly poor performance.

The right thing to do would be to present each of the disadvantages and advantages in their true nature and degree.

(1.42 / 7) (#66)
by mx on Tue Oct 10, 2000 at 12:36:19 PM EST

"days without rebooting?" wow, i am impressed. only on a microsoft platform could that be a good thing.

in my time i've developed a few portable server apps in c++ that have gone *years* between reboots.

"neener, neener, neener, good code is for loosers


- mx
Java has more advantages than just GC (3.22 / 9) (#69)
by yosemite on Tue Oct 10, 2000 at 01:01:04 PM EST

I am a Professional Developer™, and have written a fair amount of code in C, C++, and Java. In my experience, Java has several advantages over C/C++ besides GC:

  • Exceptions -- all error conditions in Java are handled through exceptions. C/C++ on the other hand... Win32 (where I am most familiar) is a nightmare of incompatabilities. Sometimes the error code is returned directly. Sometimes you get a special value (FALSE, or NULL, or INVALID_HANDLE_VALUE) and you have to call GetLastError to get the error code. And depending on the context, the error code is a WinError, or a HRESULT, or something else entirely. Having the error handling unified by a single paradigm built in to the language is an incredible advantage!

  • Unit testing -- in Java, you can have a main function on every class, so your unit test programs can be a part of the standard code base, even part of the release build!

  • Packages -- I know C++ has namespaces, which is almost the same thing, but namespaces (at least in my experience) have just not caught on the way packages have in Java.

In some sense, Java's real advantage is in its community and culture -- Java is very self-consously object oriented in design and attitude. C++, OTOH, has roots back to the days when the idea that "writing high-level code is better than spaghetti code" was controversial. This legacy is still in the language, and still followed by many of those who write it (present company excepted, of course).

-y

--
[Signature redacted]

Re: Java has more advantages than just GC (3.66 / 3) (#82)
by drivers on Tue Oct 10, 2000 at 04:03:29 PM EST

Exceptions:

C++ also has exceptions. It is not the fault of C++ that Microsoft returns errors in result codes. That is because Win32 is written in C. Checking result codes of every system call is normal practice in regular C coding. MFC is a very thin wrapper for Win32.

At the same time I could write code for Java that when it had an error, would return a result code that the calling objects would have to check for explictly, instead of catching as an exception.

C++ has exceptions, Java has exceptions. It's just that Java has been using them consistently from the beginning, because Java is a much newer language, they added a lot of stuff that was later added to C++ standard version 3.

Main: Not sure what to say about that. :)

Packages: Namespaces "just haven't caught on" Namespaces are also a C++ version 3 addition.

Let's not turn this into a Languages Holy War. :) Languages should be judged based on what they make possible (and/or simple), not for the sins of their users.

[ Parent ]

Re: Java has more advantages than just GC (none / 0) (#97)
by Zagadka on Tue Oct 10, 2000 at 07:13:23 PM EST

Another little bit about exceptions in Java: for most types of exception, Java forces you to deal with them, either by catching them or mentioning them in your throws clause. The fact that C++ doesn't do this, coupled with the fact that templates and operator overloading can lead to exceptions being thrown from some pretty weird spots, can cause memory leaks and other nasty problems.

[ Parent ]
Re: Java has more advantages than just GC (4.50 / 2) (#100)
by your_desired_username on Tue Oct 10, 2000 at 07:26:07 PM EST

What do you mean by 'C++ standard version 3'? There is only one C++ standard, and that is ISO 14882, and it was ratified on july 27th, 1998. There was (a long time ago, circa 1990) an ATT C++ 3.0 - but that was never a standard - it was a partial implementation of the C++ ARM, which became the working paper for the standard, and, eventually, after the addition of a very large library and a few changes to the core language, the 1998 standard I mentioned earlier.

[ Parent ]
Exceptions (3.50 / 2) (#91)
by boxed on Tue Oct 10, 2000 at 06:39:47 PM EST

It may be noted also that you are forced to catch exceptions in Java, which is stupid. If an exception isn't caught the thread will die, that's normal behaviour in C++ and it makes a lot of sense. Of course, Java has never been about giving the programmer choices :P

[ Parent ]
Re: Exceptions (none / 0) (#105)
by Inferno on Tue Oct 10, 2000 at 08:29:38 PM EST

You can extend RuntimeException to implement unchecked exceptions - but that eliminates the point of exceptions: the programmer should expect things to go wrong, and should deal with them. Runtime exceptions halt the thread, displaying a message telling you that some subclass of RuntimeException wasn't caught.

[ Parent ]
Re: Exceptions (none / 0) (#139)
by /ASCII on Wed Oct 11, 2000 at 09:11:26 PM EST

Are you saying that EVERY array lookup shoud be enclosed by a try/catch? That would increase code size by a factor 2. Or do you mean that Array bounds checking is a bad thing and should be deleted? No thanks, I like things the way they are, thank you very much.
"The time has come", the Walrus said, "To talk of many things: Of shoes and ships and sealing wax, of cabbages and kings."
[ Parent ]
Re: Exceptions (5.00 / 1) (#106)
by /ASCII on Tue Oct 10, 2000 at 08:42:31 PM EST

I usually avoid saying that people are wrong... but you're wrong.

In Java, when throwing an exception, you can make it a subclass of any Throwable class, Like Error, Exception or RuntimeException. If an object subclassing RuntimeException is thrown, it doesn't have to be caught.

Never noticed that an array access can throw ArrayIndexOutOfBoundsException, but you needn't catch those to use an array? Never noticed that doing ANY operation on a null object throws a NullPointerException?

Shame on you, now go to you room and write a ten-page essay on way Java will take over the known universe and why Scott McNeally is the most glorious man ever to wear a necktie.


"The time has come", the Walrus said, "To talk of many things: Of shoes and ships and sealing wax, of cabbages and kings."
[ Parent ]

Re: Exceptions (5.00 / 1) (#136)
by boxed on Wed Oct 11, 2000 at 08:01:41 PM EST

/me hangs head in shame

[ Parent ]
Re: Exceptions (none / 0) (#145)
by nictamer on Thu Oct 12, 2000 at 09:22:10 AM EST

I might be wrong (I haven't done any Java in over a year now), but I thought that NullPointerException was an .. exception among regular exceptions, as well as probably a few others, in that you did'nt have to catch them?
--
Religion is for sheep.
[ Parent ]
Re: Exceptions (none / 0) (#129)
by ramses0 on Wed Oct 11, 2000 at 04:03:24 PM EST

In addition to the alternatives already presented, when I was programming in Java, and didn't want to deal with any errors that might crop up, I'd simply make that function blah() throws ThisException, ThatException, etc...

My syntax is probably all wrong, but the requirement in Java is that Something(tm) does Something(tm) with Exceptions(tm), even if it's as simple as passing responsibility up to the calling function.

Builtin exceptions handling is probably what I miss most in my current language of choice (PHP). But then again, during web development, it's just a lot easier to say "pshaw" :^)=

--Robert
[ rate all comments , for great justice | sell.com ]
[ Parent ]

C++ is not Java... (3.72 / 11) (#71)
by trhurler on Tue Oct 10, 2000 at 01:28:21 PM EST

After a long, long time spent thinking about it, I still have things I like and things I don't in languages. GC is one of them, but it depends on the language. GC belongs in languages like Java. It does not belong in systems programming languages. Period. End of statement. No more consideration, we're done. If you want GC, then C++ is the wrong language for your project, for a lot more reasons than whether it has GC or not; you should be using Python, or Java, or something else made for writing applications. C++ has no advantage whatsoever in that field, and many disadvantages. On the other hand, if you really must write yet another OO operating system, or if you want to model weather or simulate a car crash or a nuclear explosion or something like that, C++ is probably your beast. However, in those applications, you are NOT going to want GC(or any other "feature" with only semideterministic runtime overhead, for that matter. Can you say "exceptions?")

Really, if you are going to use the wrong language for a project, I'd rather see code written in C than C++. It is true that C gives you enough rope to hang yourself, but C++ does too, and it comes with a pre-made gallows and a book on knot-tying.


--
'God dammit, your posts make me hard.' --LilDebbie

Re: C++ is not Java... (2.00 / 1) (#113)
by Michael Leuchtenburg on Wed Oct 11, 2000 at 12:13:07 AM EST

Fortunately for you, then, GC will be optional. If you don't want it, don't use it.

[ #k5: dyfrgi ]
[ TINK5C ]
[ Parent ]
Re: C++ is not Java... (none / 0) (#142)
by djzoot on Thu Oct 12, 2000 at 02:14:04 AM EST

My favorite quote about C++ comes from Bjarne Stroustrup:

C makes it easy to shoot yourself in the foot; C++ makes it harder,
but when you do it blows your whole leg off.
--
There is no K5.
[ Parent ]
Flame-bait language advocacy, please ignore (none / 0) (#159)
by Xenophon Fenderson, the Carbon(d)ated on Fri Oct 13, 2000 at 06:40:13 PM EST

To be honest, I'd much rather write those simulations in Common Lisp, where I have (i.e. "can buy or download") a mature GC, a standardized exceptions mechanism, a powerful object system, and real macros, unlike a certain other language. Not to mention true incremental compilation (with optimizers that generate machine code as good as your C++ compiler does) and a dynamic run-time system that allows me to patch b0rken functions from within the error handler itself (and then restart the computation from a few stack frames back). ;)

But hey, if writing a large and complicated system in what is operationally indistinguishable from banging rocks together to get ones and zeros floats your boat, by all means go right ahead. :-P



--
Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, mhm21x16, and the Patron Saint of All Things Plastic fnord
I'm proud of my Northern Tibetian heritage!
[ Parent ]
GC is bad in Java--how will it be better in C++? (3.86 / 15) (#72)
by kostya on Tue Oct 10, 2000 at 01:30:13 PM EST

I am more a Java programmer than a C++ programmer--so I use GC all the time.

Yes, GC allows faster program development. You can crank out the programs. You can write and deploy much, much faster. This is ALL true. But it is only a part of the truth.

The fact is that GC always comes back to haunt you. You are designing a fast algorithm that needs to get rid of things--in Java, you just set the reference to null. Do you realize how scary that is in practice? I used to do product support for a major Java Middleware Server. I ran the app on a Sun e450 with 2G of RAM, and I gave the Java Server (JVM actually) a 512M heap. It cycled through the entire heap once every 3 seconds. EVERY 3 seconds, the Java Server would allocate so many objects (and then throw them away) that it ate through and GC'd 512M of RAM!!

Now someone who wants to defend GC might say that is an isolated exampe. Come do Java work with me. You will find it is the exact opposite. This is the NORM. This app server I supported--it isn't some rinkie-dink operation. That app server is put out by one of the leaders in the Java App Server market--it is considered a defacto standard! The fact is that GC leads to this kind of programming. What is worse is that when you want to be a good programmer and manage your memory, you can't.

Yes, GCed languages are easy for RAD strategies and prototypes. But they lead to basic problems that just shouldn't happen. It is amazing the number of people who think that creating new strings has no cost whatsoever. You optimize their code and their jaws drop.

I agree with the previous post: GC would be nice as a debugging tool that is removed before production. However, in today's market, we all know that very few companies would ever remove it before going to production--how much software today is really beta software shoved out the door to soon?



----
Veritas otium parit. --Terence
WebSphere? (4.00 / 4) (#77)
by chaz on Tue Oct 10, 2000 at 03:14:03 PM EST

I have developed significant (50,000 line +) applications with IBM's WebSphere and IBM HTTP Server (which is Apache, really). During development, we did occasionally get situations where the heap is exhausted quickly. In every case, it was due to a lack of thought on the part of the programmer. When we thought about the problem, we invariably ended up with clearer faster code.

WWTBR (without wishing to be rude), I suggest you have a look at the usage of temporary objects, particularly Strings. Use StringBuffers instead, or you will end up with huge numbers of temporarys that have to be collected.

[ Parent ]

Re: WebSphere? (4.00 / 3) (#79)
by kostya on Tue Oct 10, 2000 at 03:45:24 PM EST

I agree with you. But to a certain extent, when a client tells you "It isn't my damn code--fix your app server," you have to basically put up and shut up. The glories of consulting. I actually had the problem pegged on arrival, but it took the customer three months to listen to me. Politics.

As it was, the problem was basically programmers generating code according to how the tutorials said and forgetting common sense. You might say this isn't the app server's fault, and that would be partially true. But the problem is more basic--GC leads to sloppy programming. Even the app server did some stupid stuff.

I'm not saying it is a definite, "must happen" scenario. But GC tends to allow programmers to be sloppy. And while we would all love to think that everyone wants to be efficient, most of the time programmers are to pressed for time to bother cleaning up their code. This is especially true of Java programmers since they are usually at web dev shops. Web products have obscene time schedules that force people to put out stuff at phenomonal rates.

Or at least, all the ones I have worked at :-)



----
Veritas otium parit. --Terence
[ Parent ]
Re: WebSphere? (4.33 / 3) (#81)
by chaz on Tue Oct 10, 2000 at 03:59:39 PM EST

Agreed. I think that one of the problems is the way Java (in particular) is taught - "Hey, it has an automatic garbage collector - you don't have to think about object lifetimes!"

This attitude is positively harmful. If you don't understand the scoping/lifetime of the objects you are managing, you will get into terrible trouble very quickly. On the other hand, nobody gets paid for writing good code. If it works, it gets deployed. If I'm not careful I'll start my "Software as an engineering discipline" rant ;)

Incidentally, what I hate about K5 is all these rational, informed people having sensible discussions. Time to go back to /. again....

[ Parent ]

Re: WebSphere? (3.00 / 3) (#108)
by carb0n on Tue Oct 10, 2000 at 09:33:07 PM EST

Agreed... I'm currently working on an Applet/Application which everyone though was a beautiful work of art. Turns out when a window was closed, it wasnt really closed - cause there was a reference to the window from the caller. Thus every new window was adding additional overhead (snmp polling). Didnt take long till the CPU was at 100 percent just outputting all the messages to the console from all the (hidden) windows! This was one of the better adventures I have had with this code. I swear the average VB program shines in comparison! :) I'm still a hardcore C++ bigot, but I'm _very_ impressed with what Borland did with JBuilder 4.0.

[ Parent ]
Re: WebSphere? (3.20 / 5) (#114)
by Delirium on Wed Oct 11, 2000 at 12:33:04 AM EST

Incidentally, what I hate about K5 is all these rational, informed people having sensible discussions. Time to go back to /. again....

DOOD I WORK AS A GARBAGE COLLECTOR ON THAT BIG SMELLY TRUCK, SOMETIMES I STEAL PEOPLE'S GARBAGE HEHEHE! C++ sux tho. Garbage collector breaks cuz whole damn language is garbage!

...Oh, I don't know, perhaps with some effort we can fix this minor problem with the k5 discussions you noted =P

[ Parent ]

Excuse me, but... (none / 0) (#162)
by ksandstr on Sun Oct 15, 2000 at 12:10:14 PM EST

Doesn't this give you a massive headache with the automatic memory management? I mean, you'll have to live with the fact that the underlying GC implementation can be as arbitrary as it likes - at least when you do explicit memory management you get to choose that "HERE is where the foo_ptr chunk will die! die, foo_ptr!".

I guess my ANSI C background is showing again.



Fin.
[ Parent ]
Re: GC is bad in Java--how will it be better in C+ (4.00 / 5) (#78)
by ZephyrAlfredo on Tue Oct 10, 2000 at 03:38:59 PM EST

"The fact is that GC leads to this kind of
programming. What is worse is that when you want to be a good programmer and manage your memory, you can't."

Untrue. In my Java optimizations, I reused everything. 'Neglecting' the principles of "garbage collection" and "memory management," I reused most of my objects. It worked. Minimizing deallocation helped break my 30 fps goal. Really, I can duplicate your problems in C++ as well; it seems to me that your 'algorithim' is the equivalent of

do {
   burden = new CString("xyz");
   ...
   delete burden;
} while (!done);

I like garbage collection, but I do not rely on it, since reusing your memory is so much faster than realloc()ing it.


[ Parent ]
Re: GC is bad in Java--how will it be better in C+ (4.25 / 4) (#80)
by kostya on Tue Oct 10, 2000 at 03:55:32 PM EST

    "Untrue. In my Java optimizations, I reused everything ..."

I think you missed my point. You can program like a slob in any language. I can write shell scripts which out perform C++ programs if the C++ is bad enough :-)

My point is that GC can give many developers a false sense of security. They will tend to bad technique unless they are formally trained or experienced in some of the pitfalls. I agree with you about reuse--it is what my code does all the time. But the reality of most of the projects I work on is that I work in teams. With the labor shortage here on the East Coast, most of these people are not CS grads with experience in non-GC languages. They learn Java in their off-hours. They do a great job.

But GC tends to lead them to bad conclusions or allows them to make simple mistakes. And with the timelines I usually work under, the mistakes can get to the very end releases without being discovered (web development is hectic and often mismanaged). Perhaps it is not GC's fault. But it seems that GC allows programmers lee-way that starts them down these roads.

Of course, programmers with experience learn and try to stop making these errors. Perhaps it will just take a few years before GC principles make it into the basic training of most programmers. Right now, it is pretty messy out there.

Don't get me wrong--I like Java. I just think all this hype about Java being "easy" is misplaced. It is easier in many regards, but it still requires classical training in programming principles. Many of the companies I have worked for see Java as some silver bullet that will make all their developers more productive. And this is both true and false. Adding GC to C++ will not be a panacea to productivity problems. My point is to the author of the article: GC can be a benefit and a detriment.



----
Veritas otium parit. --Terence
[ Parent ]
Re: GC is bad in Java--how will it be better in C+ (5.00 / 3) (#131)
by jovlinger on Wed Oct 11, 2000 at 04:54:33 PM EST

Not that I've had much in the way of experience writing large software, but I feel the following is a true statement. Do you agree?

It requires less effort to transform a naive over-allocating GCed program to be efficient and memory-reusing than the effort required to debug memory leaks in a manually collected program.

johan

[ Parent ]

Re: GC is bad in Java--how will it be better in C+ (4.33 / 3) (#84)
by Bert Peers on Tue Oct 10, 2000 at 04:09:37 PM EST

True; His point, however, is that in C++ it is very explicit that you're commiting suicide with a new and delete upon every iteration. GC'd languages however, as someone has literally said, suggest infinite memory. I'm not too experienced in Java, but from the listings I've seen I also believe that Java programmers too quickly forget about what happens behind the scenes. Sortof like C++ programmers who lose touch with their C roots and start to ignore the runtime cost of virtual functions, cache friendly class layouts, etc : out of sight, out of mind. If you point out to those people that they should at least be aware of how a compiler implements vtables etc, their response is sometimes that, if they have to take all this into account, what is the benefit of "abstracting" it "away" ? So to bounce back : if you have to remember what memory you have allocated and design your algorithms so that you can efficiently reuse it, aren't you defeating the main reason of GCing, which is to forget about all that ?...

[ Parent ]
GC + lazy programmers (3.77 / 9) (#83)
by oleandrin on Tue Oct 10, 2000 at 04:05:55 PM EST

GC isn't for lazy programmers. People start complaining when they've been taught to write code in a way that isn't very compatible with the nature of GC, and they see a performance hit or whatever. It's actually possible to write very fast and efficient code in a GC'ed language, provided you have some understanding of how GC is working there. The real "lazy" programmer here is one who assumes he shouldn't concern himself at all with GC while writing in a GC'ed language.

When writing in Java or Lisp or Python or Scheme or Ruby etc., it's important to keep in mind the existence of the GC, just as when writing in C or C++ you need to keep in mind how memory is allocated.

I have an easier time writing GC-efficient algorithms than plugging leaks, so GC is the way for me :)

A surprising counter-example: GCC (1.50 / 2) (#85)
by gtt on Tue Oct 10, 2000 at 04:23:16 PM EST

Everyone knows that GCC uses the Boehm garbage collector, right? In fact, it's written in C. If you've been following the GCC list, they dropped support for the CHILL language front end because it doesn't use GC the way everything else does. -GTT

Re: A surprising counter-example: GCC (5.00 / 2) (#135)
by sdr on Wed Oct 11, 2000 at 07:42:45 PM EST

Just to clarify the point - the various gcc frontends use garbage collection during the compilation. Also, as far as I can see, the gcc frontends do not use the Boehm collector - the garbage collectors used by gcc are in the files ggc*.c in the gcc/gcc/ directory of the gcc source. The default collector is a mark sweep collector using a different allocation lists for different sixes. See ggc-page.c for details.

The Boehm collector is used by gcj - the gnu java compiler - for runtime garbage collection.



[ Parent ]
GC for me? (3.50 / 2) (#87)
by skim123 on Tue Oct 10, 2000 at 04:51:16 PM EST

I dunno, I guess I view GC as a tool, not a way of life... so, use a GC language if you need it, don't if you don't. I wouldn't be opposed to C++ adding optional GC that would not degrade performance if you decided not to use it.

I have been writing some programs in C# (Microsoft's new .NET Java) lately, and have never done Java programming before. It's weird, having GC, just not worrying about destroying allocated objects. In looking through some example code I'll see things like:

SomeObject x = new SomeObject(blah);

and they'll prance along, use x every now and then and then just leave the function without freeing x's memory! Hehe, it takes a while before scenarios like that stop raising red flags in your head...

Money is in some respects like fire; it is a very excellent servant but a terrible master.
PT Barnum


Re: GC for me? (none / 0) (#90)
by caine on Tue Oct 10, 2000 at 06:05:09 PM EST

Since Microsofts sites aren't exactly a miracle of readability, I thought I'd asked you what you develop C# in? Visual Studio? I'd really want a free (as in beer) compiler, but I guess that doesn't exist yet? =)

--

[ Parent ]

Re: GC for me? (none / 0) (#102)
by skim123 on Tue Oct 10, 2000 at 07:44:26 PM EST

I thought I'd asked you what you develop C# in? Visual Studio? I'd really want a free (as in beer) compiler, but I guess that doesn't exist yet?

Quite incorrect. You can get a free compiler for C#, JScript.NET, and VB at http://msdn.microsoft.com/net/. I use Notepad to write my C# code (not enough HD space to install the VS7 beta... sigh...)

Anywho, the neat thing about .NET, IMHO, is the ASP+ (seeing as I'm one who uses ASP a lot). Anyhow, the ASP+ pages are actually compiled (well, Intermediate Language), so for ASP+ to work (which is free), MS has to give away the compilers (for free).

Money is in some respects like fire; it is a very excellent servant but a terrible master.
PT Barnum


[ Parent ]
Re: GC for me? (none / 0) (#125)
by caine on Wed Oct 11, 2000 at 01:41:58 PM EST

Ah, thanks a lot. =) Found what I wanted! =)Now all we need is a C# compiler for Linux =).

--

[ Parent ]

Didn't Like GC... (4.25 / 4) (#88)
by Maniac on Tue Oct 10, 2000 at 05:09:53 PM EST

For the most part I'm involved in real time system development so garbage collection is the LAST thing I want in a system. The system must operate in a predictable manner so all of the storage is preallocated before we start the real time application. No allocations or deallocations allowed in run time [no leaks either].

There were a couple cases where I used GC in the deep, dark past. It was a mixed bag. They included:

  • Using SNOBOL in the late 70's, early 80's for manipulating text. I use perl today for the same kind of features. For the most part, the SNOBOL applications had good performance though they tended to be larger than other applications (a real concern when you have only 1M of memory...).
  • Using Symbolics Lisp Machines in the early 80's for developing tools. We found there were good ways & bad ways to build applications. Use the bad way & you ended up with an unusable system. Literally, it took longer to do the GC than a reboot! Use a good way & the system stayed up for weeks w/o any problems.
  • More recently using Java for some toy applications. Couldn't really tell the difference in performance with similar C or C++ applications.
With this background and from reading the other notes, I would say it is still important to minimize the amount of garbage you create. Your program will just run better if you do so.

If you need to allocate & free memory a lot, consider a wrapper around malloc/free that has a look aside list to reuse already allocated but unused storage. For Java & C++, you already have the hooks to do this in the constructor & destructor methods. Use them.

Your experience is out of date (3.50 / 4) (#103)
by ToddBlanchard on Tue Oct 10, 2000 at 07:46:06 PM EST

GC has progressed light years beyond what the old SNOBOL or Lisp machines implemented. There are real time GC algorithms with hard upper bounds on collection times. Whether you can afford them depends on your application and hardware resources, but they're not nearly as costly as the older algos.

The Java GC implementations have been rather lame so far, and they are somewhat dependent on the VM you're using. In fact, modern Smalltalk VMs are generally higher performance than the current crop of JVMs including GC implementation.

Anyhow, I'd take a look at GC again - your experience is way out of date.

[ Parent ]
Lots of people think they don't use dynamic memory (none / 0) (#143)
by Paul Johnson on Thu Oct 12, 2000 at 04:31:44 AM EST

When in fact they do.

What do you do in your preallocated system when it has to deal with several things in the environment which come and go at various times? (E.g. aircraft tracked by a radar)?

Well, its obvious isn't it. You preallocate an array and store the aircraft records in that. Of course you run out of slots pretty soon, so you have to keep track of which aircraft have left the airspace and tag those slots as deallocated. Better put in a free list of slots so you can find a free one in constant time.

Errr... you've just re-invented dynamic allocation with all its problems. Need to have some other data which refers to an aircraft record (like a record for its flight plan)? Better make sure you don't wind up with stale poin^H^H^H^H slot numbers there. And what happens if you don't record an aircraft leaving the airspace for some reason? Why, you get a slot leak.

Paul.
You are lost in a twisty maze of little standards, all different.
[ Parent ]

Dynamic allocation very limited if any (none / 0) (#152)
by Maniac on Fri Oct 13, 2000 at 11:49:02 AM EST

In several of the older systems I worked on there was NO dynamic allocation of any kind. It was just not done. More modern systems do have some but its use IS extremely limited.

The only place where it MAY still continue to take place are with services provided by the OS. For example - a hardware driver will buffer data in some cases. The smart ones take the buffer we give them (statically allocated at start up). For our code, if we run out of buffers (or slots as you say), the application fails. Don't do that.

What I have seen implemented for situations like the one you describe [in aircraft flight software] is a fixed list with a priority mechanism. For example, the "high value" and "high threat" aircraft are kept in the list & the rest are ignored. An aircraft may get added and dropped several times if it is near the limit of surveillance. The ones closest to you are kept in the list until they hit the ground or go away. This is also intended to help the pilot prioritize the work.

The other place I should mention is the stack - again fixed size. Limit set at start up. Enough analysis done that we won't overrun it due to control of parameters passed to a function and eliminating [or strictly controlling] recursion.

In a real time system - we put up with a lot of restrictions to make those deadlines. At 80hz, we don't have a lot of time to do any unnecessary tasks. We also have some systems that go into a "safe mode" if the jitter on delivery messages exceeds 50 microseconds. With those kind of requirements, management of storage in general, and garbage collection in particular is not something we want to spend CPU cycles on.

[ Parent ]

Missed point (none / 0) (#153)
by Paul Johnson on Fri Oct 13, 2000 at 11:58:08 AM EST

You missed the point. Dynamic allocation isn't just calling malloc(), its any scheme which allocates storage space at run time. If you allocate a slot in an array at run time, or even a stack frame, then you are doing dynamic allocation. The stuff with preallocating the array is just an implementation detail to accomodate the real-time constraints.

Paul.
You are lost in a twisty maze of little standards, all different.
[ Parent ]

No and yes (none / 0) (#154)
by Maniac on Fri Oct 13, 2000 at 01:41:28 PM EST

If I take the first statement to its logical conclusion - then writing items to an array and incrementing the "last used" index is "dynamic allocation". I don't agree with that.

I do agree with the comment about the stack frame and said so in my last message. To help explain, that is an artifact of the tools (I mentioned the OS before, its the compiler in this case) being used - not the intent of the code we are writing. If I rule out recursion, the compiler COULD statically allocate the storage of parameters passed. However, that is a particularly inefficient use of memory and not used in any product I've seen in years.

[ Parent ]

Degrees of dynamism (none / 0) (#160)
by Paul Johnson on Sat Oct 14, 2000 at 07:10:27 AM EST

Perhaps it would be more accurate to say that there are degrees of dynamism in storage management. The key point is not actually allocation, its deallocation. Allocating space for data is a local decision (I have data and I need somewhere to keep it). However if the data is used globally (i.e. by other parts of the system) then deallocation also becomes a global issue: memory cannot be deallocated until the whole system has finished with the data it contains. This is the defining characteristic of dynamic allocation, and its a systemic issue: it cannot be removed by changing programming style.

Paul.
You are lost in a twisty maze of little standards, all different.
[ Parent ]

The poll is missing some options... (4.00 / 2) (#92)
by XScott on Tue Oct 10, 2000 at 06:45:45 PM EST

I would select "Not Matter because I wouldn't use it in C++" (assuming the feature would be optional).

If I want high level programming where I'm willing to trade something (performance probably) for ease of implementation, I'll use the higher level language. If I want "portable assembler" where I have a very good idea of what instructions are going to be generated (plus or minus peephole optimizations), I'll use C++.


-- Of course I think I'm right. If I thought I was wrong, I'd change my mind.
Re: The poll is missing some options... (4.00 / 2) (#99)
by Delirium on Tue Oct 10, 2000 at 07:20:19 PM EST

How can you possibly call C++ anything resembling "portable assembler"? If you were talking about straight C I could see this argument, to an extent, but do you really seriously think that you know what instructions your virtually-inherited class is going to generate? Many parts of C++ are insanely high-level, and it would take someone intimitely familiar with the compiler internals to even begin to tell you what sorts of instructions would be generated.

[ Parent ]
Re: The poll is missing some options... (3.33 / 3) (#110)
by XScott on Tue Oct 10, 2000 at 10:05:03 PM EST

You don't have to be that familiar with the compiler internals to know what's going on under the hood. I can guarantee with reasonable certainty that a virtual function call will:
  • Load the address of the vtable as an offset from the this pointer.
  • Load the address of the virtual function from the vtable.
  • Push arguments and return address for whatever calling convention.
  • Call the function.
  • Store result for whatever calling convention.

I know I can't 100% rely on this particular implementation of virtual functions based on any standard, but I can be pretty certain of it.

Can you tell me of a different implementation of virtual functions which 1) implements the correct semantics, 2) isn't woefully inefficient, and 3) is implemented by any commonly used C++ compiler?

I'm willing to put some amount of money on g++, Visual C++, Borland C++, and MetroWerks (sp?) all implementing virtual functions in this way. That's pretty portable for my tastes.

I admit that multiple inheritance complicates this a bit. I honestly don't know much about how that is implemented for any given compiler, and I can imagine more than one scenerio. Fortunately for me I don't use it for anything, so I can continue to pretend that C++ is reasonably portable assembler.

Even with MI though, I can be reasonably certain it's going to load the correct vtable from somewhere and then call the function pointer. So while I don't know the exact instructions I'm unlikely to be terribly surprized at what I find if I look at the assembly.

Compare this to any high level language like PERL, Python, VB or whatever, and I can't venture the vaguest guess at what instructions are going to execute. (Other than a byte code interpreter doing something.)


-- Of course I think I'm right. If I thought I was wrong, I'd change my mind.
[ Parent ]
Re: The poll is missing some options... (none / 0) (#122)
by rong on Wed Oct 11, 2000 at 10:20:57 AM EST

Aside from virtual functions, there also exist other aspects of c++ where the code generated requires more forethought than c. Particularly, the creation and destruction of temporaries, which is a source of much inefficiency in some c++ applications. Fortunately, in most cases, one does not need an intimate understanding of the specifics of a compiler implementation to recognize what's going to happen under the hood. I'd recommend picking up a copy of "Efficient C++" by Bulka and Mayhew for some insight into the important issues.

[ Parent ]
Re: The poll is missing some options... (none / 0) (#127)
by XScott on Wed Oct 11, 2000 at 02:03:53 PM EST

I agree with you on the copy constructors and assignment operators. I've been bit once or twice by that before.


-- Of course I think I'm right. If I thought I was wrong, I'd change my mind.
[ Parent ]
Re: The poll is missing some options... (3.00 / 1) (#137)
by Delirium on Wed Oct 11, 2000 at 08:31:44 PM EST

I think it's still a bit misleading to say that C++ is a portable assembler. The high-level concepts are not directly analogous to anything in assembly code. While someone intimately familiar with the language may be able to tell you what an object translates to in assembly, there is no such concept in machine code. Defining objects, member functions, etc. are all higher-level concepts that make C++ something more than just a portable assembler, even if you can mentally picture what the resulting code from them would be. C, on the other hand, is much more like a portable assembler.

[ Parent ]
Re: The poll is missing some options... (3.00 / 1) (#138)
by XScott on Wed Oct 11, 2000 at 08:58:04 PM EST

I suppose that is what I mean then. In C++ (and of course C), I'm unlikely to be surprized by the generated instructions.

If I was writing assembly code directly, I'd probably use similar abstractions. The result just wouldn't be very readable.

It's odd to me that you distinguish C as closer to portable assembler than C++. Most things in C++ seem like a pretty obvious translation to C. For instance:
   // Call a method on an object
   cFoos *f= new cFoos("bar.txt");
   f->bar(2.0);

   /* Call a method on an object */
   foos *f= foos_create("bar.txt");
   foos_bar(f, 2.0);



-- Of course I think I'm right. If I thought I was wrong, I'd change my mind.
[ Parent ]
Re: The poll is missing some options... (none / 0) (#140)
by Delirium on Wed Oct 11, 2000 at 09:59:28 PM EST

Well, I suppose it's just the level of abstraction that C++ contains, but which C and assembly do not. In your example, the C code is much like the resulting assembly code - foos_create() and foos_bar() are two completely separate functions as far as the computer and compiler is concerned. They're only linked in the programmer's head by the fact that foos_bar() takes as one of its arguments the structure returned by foos_create(). In the C++ example, there is actually an object being created, whose member function is then called - they're linked by the language itself, being part of the same object - something that doesn't really exist at the machine level.

[ Parent ]
Re: The poll is missing some options... (none / 0) (#151)
by XScott on Fri Oct 13, 2000 at 12:45:31 AM EST

They're only linked in the programmer's head by the fact that foos_bar() takes as one of its arguments the structure returned by foos_create().
They're also related by the type of pointer with which they manipulate (if it's any modern C compiler that does rudimentary type checking). The C++ compiler only goes one tiny little step farther in using the the pointer type to help identify which function you wanted to call with the arrow operator. Other than that, the C and C++ code above is very much the same, and you won't be too suprized by the assembly instructions for either one. So I still claim that C++ is portable assembly.


-- Of course I think I'm right. If I thought I was wrong, I'd change my mind.
[ Parent ]
Leaks with GCed languages too (2.00 / 1) (#121)
by maketo on Wed Oct 11, 2000 at 10:15:49 AM EST

All below said - I have seen a lot of bad Java code with memory leaks.
agents, bugs, nanites....see the connection?
GC is advancing a lot. (4.25 / 4) (#123)
by Nelson on Wed Oct 11, 2000 at 11:37:30 AM EST

There are some more advantages and disadvantages. First off you need to understand garbage collection. Everybody and his brother know reference counting and mark and sweep but there are more sophisticated garbage collectors, two-space and generational. With these newer collectors memory allocation and deallocation is usually faster than normal allocation and deallocation. also, they can compact memory which is where the real savings comes in to play, UNIX has a very simple memory model for user applications there is a stack pointer and a heap pointer (brk) as you allocate heap brk is moved up. If you allocate lots of garbage on the heap and then allocate something longterm near brk, you can free the garbage but brk never goes down. That means the kernel has to swap out the "free pages" and keep track even though that memory isn't in use. It's not a real big deal most of the time but a generational or two-space collector will compact memory allowing the kernel you to lower brk. SML/NJ uses a two-space collector and it is very fast. There have also been advances in multiprocessor smart collectors, the IBM Haifa collector is one, garbage collection happens on a second processor and there is no performance hit, the world doesn't stop and there is no pre or post allocation hit to bump regerences or anything like that; at that point GC starts to become reasonable for real-time systems.

As for fitting GC in to C++, I think that is trouble. It breaks the model. It's already complex enough and a large part of that complexity comes from supporting legacy C code, I don't see GC being added, or rather a modern and compelling GC being added and keeping the compatibility. That's the big issue. As for GC itself, I'm personally of the belief that unless you're building an embedded or real-time development platform then GC should be part of it. Development speed is just part of it, the real benefit is that entire classes of bugs go away, software is getting so sophisticated that we need more hardware assist to write it and debug it, GC is almost perfect in that it doesn't do too much and it doesn't restrict the design of your code but it solves real problems that affect most applications (leaks.)

I think the nay sayers are like the anti-compiler types from 20-30 years ago. Back in the day, real programmers wrote machine code or assembly, compilers generated big, bloated, slow code and didn't give them full control of the machine. Today, compiler generate better code than most programmers are capable of doing if they did it by hand. GC is the same, it's shunned by "real programmers" but the benefits out weigh the costs in most environments and it's getting to the point where there aren't any costs.

Re: GC is advancing a lot. (none / 0) (#124)
by Xerithane on Wed Oct 11, 2000 at 12:42:23 PM EST

Do you have any information on the generational and two-space GC you mentioned?
I'm interested in learning about it - not really writing any myself, but the usage I want to start incorporating.
nerdfarm.org.
[ Parent ]
Good GC references (5.00 / 1) (#156)
by Xenophon Fenderson, the Carbon(d)ated on Fri Oct 13, 2000 at 04:59:08 PM EST

There are quite a few good archives around the net relating to GC (and memory management in general). You should start with the GC mailing list and the GC FAQ. Then you should read through the excellent Memory Management Reference. From there, work your way through their great bibliography. I found Dynamic Storage Allocation: A Survey and Critical Review (by Wilson, et al) and Uniprocessor Garbage Collection Techniques (by Wilson, see also the larger draft version of the same) to be of immense value. The OOPS Research Group has quite an archive of papers (including the three mentioned above) and source code stored at ftp://ftp.cs.utexas.edu/pub/garbage/. Our list of excellent GC references is rounded out by Henry Baker's FTP site and Hans Boehm's FTP site (which is the home of the famous and widely-ported Boehm-Demers-Weisner conservative garbage collector for C and C++).



--
Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, mhm21x16, and the Patron Saint of All Things Plastic fnord
I'm proud of my Northern Tibetian heritage!
[ Parent ]
Re: GC is advancing a lot. (none / 0) (#126)
by iostream on Wed Oct 11, 2000 at 01:53:25 PM EST

As for fitting GC in to C++, I think that is trouble. It breaks the model. It's already complex enough and a large part of that complexity comes from supporting legacy C code, I don't see GC being added, or rather a modern and compelling GC being added and keeping the compatibility

I think it would be assumed that you are writing "pure C++" if you are going to use GC with C++. As long as you don't use some techniques which you probably shouldn't be using anyway, you should be fine.

iostream

[ Parent ]
Re: GC is advancing a lot. (2.00 / 1) (#130)
by jovlinger on Wed Oct 11, 2000 at 04:44:58 PM EST

Well, shouldn't isn't really strong enough. I'm no C/C++ guru, but I believe pointer arithmetic is legal in the language spec. If it is legal to create pointers from math, tracking which objects are live becomes a hassle and a half. Nigh impossible.

The alternative is to change the language, which is also Nigh impossible. You can't really go and outlaw pointermath, so the only option open is to make a new kind of pointer, which explicitly cannot be manipulated in that way. So now your language is even messier (who would have thought it possible for C++ to get hairier).

Johan

[ Parent ]

Pointers (1.00 / 1) (#157)
by royh on Fri Oct 13, 2000 at 05:51:10 PM EST

You can't really go and outlaw pointermath, so the only option open is to make a new kind of pointer, which explicitly cannot be manipulated in that way.

You mean like constant pointers? Just do this:

type* const foo;


[ Parent ]
Re: GC is advancing a lot. (3.33 / 6) (#128)
by your_desired_username on Wed Oct 11, 2000 at 04:02:45 PM EST

the world doesn't stop

A two-space or generational collector cannot allow a reference to be
  changed or copied while it is working - if such a thing happens, the
  marking or the copying (both can be implemented on top of
  mark and sweep or stop and copy) will be invalidated, leading to
  dangling references and/or uncollected garbage. There are two
  solutions to this:

  (0) Stop the world while running the gc.

  (1) Put a mutex around all the references. While the gc is running,
      it holds the mutex. Any time a thread tries to change a
      reference, it blocks, and is stopped until the gc is done.

Both require stopping *something*, though (1) is generally better than
  (0), except that it is harder to implement.

I suspect that changing and copying references is not common in SML,
  and so this is probably not a big problem in SML.

For C++, references are not changed often, but they are copied
  often. It may be a problem. In addition, (1) works best with
  multi-threaded apps and it requires at least 2 threads - the gc and
  the  app - so (1) seems to imply/require builtin-threading. C++ does
  not have built-in threading. (For the code I write, built-in
  threading is far more valuable than gc - but that is a different
  issue.)  

As for fitting GC in to C++, I think that is trouble.

I think the nay sayers are like the anti-compiler types from 20-30
  years ago. 

hmmm... I think you qualify as a naysayer in this context. Are you
  like the 'anti-compiler people of 20-30 years ago'?

IOWs, there are many other issues than just the unwillingness of 'real
  programmers' to embrace technology that makes some people's lives
  easier.

I do think that C++ should include optional gc - and it should be
  optional in several ways:
  
  (0) What objects are gc'd.

  (1) What externally visible characteristics the gc algorithm
      has. For example, many real-time systems cannot use any gc
      algorithm that might stop a thread.


[ Parent ]
Optional GC a bad idea (4.66 / 3) (#144)
by Paul Johnson on Thu Oct 12, 2000 at 04:45:28 AM EST

The problem is that C++ with GC and C++ without GC are two different languages and you program for them in two different ways. Worse yet, they are only source-compatible in one direction (code for no-GC can run (inefficiently) on a with-GC environment.

GC isn't just about laziness: not having to keep track of your garbage allows you to program in different ways. Hidden inter-module dependencies drop away, as do large chunks of API designed to tell module A that module B has finished with a resource.

So, if you want to develop a reusable module you will have to develop it on the assumption of no-GC. Which means it will run slower because of all the garbage-tracking overhead. If it hands out resources to other modules then it automatically forces those modules to keep track as well because the API says that they have to call ResourceFree() at some point. So you lose all the benefits of having GC whilst still imposing the costs on yourself.

The last language to make GC optional was Ada. Nobody offered Ada GC (AFAIK).

Paul.
You are lost in a twisty maze of little standards, all different.

There's more to resource management than memory (3.00 / 1) (#147)
by jez on Thu Oct 12, 2000 at 09:57:20 AM EST

Don't forget that the C++'s constructor/destructor pair allow you to manage more than simply memory allocation within the object. Deterministic object destruction allows fine-grained control of sockets/file descriptors/mutexes, etc, etc precisely because you know when the object will be destroyed.

This means in many, perhaps even most, cases you simply don't need to manually manage large numbers of objects. You can use management classes like std::auto_ptr to manage it for you in many cases. If you manage your strings using std::string or your dynamic arrays in std::vector or std::deque, you get type-safety, exception-safety, memory-management and performance guarantees.

I'm probably not explaining very well. Consider

void updatedb()
{
dbLock lock; // aquire database lock in the constructor

// do some db update, possibly throwing

} // <- lock released here in destructor, regardless of whether the function completed ok, or threw

In Java, you have to do something along the lines of (forgive me, not Java expert)
void A::updatedb()
{
dbLock lock = new dbLock;
lock.lock();

try {
// do some updates;
}
finally {
lock.release();
}
}

OK, I don't need to manually deallocate the memory (but I didn't last time either - it was on the stack remember), but I need to manually manage the database lock. If it's easy to forget to deallocate memory, then surely it's as easy to forget to release a databse lock or a file handle?

memory leaks with GC (2.00 / 1) (#150)
by /ASCII on Thu Oct 12, 2000 at 10:54:18 AM EST

Actually, GCs only make finding and eliminating leaks easier. It is still possible to have some types of leaks. Think about the eventmodel in AWT/Swing, for instance. If a frame or a component in the frame is listening for some event outside of the frame, the frame will never be garbagecollected. The frame can be explicitly destoyed, but the object will still be there, taking up loads of RAM. So you have to remember to clear a lot of variables, and to call RemoveXXXListener, etc.

On a frustrating sidenote, filestreams aren't garbagecollected the way I think would be intuitive. If no more references exist to a filestream, it isn't closed and GC:d, instead you have just caused a file-leak. If you repeat it enough times you will crash the app or the OS, depending on implementation.


"The time has come", the Walrus said, "To talk of many things: Of shoes and ships and sealing wax, of cabbages and kings."

weak references (none / 0) (#155)
by Xenophon Fenderson, the Carbon(d)ated on Fri Oct 13, 2000 at 04:26:49 PM EST

It is still possible to have some types of leaks . . . you have to remember to clear a lot of variables, and to call RemoveXXXListener, etc.

A GC trick called "weak references" may help here. Weak references are pointers to a collectable object that are themselved not used when determining the liveness of the object. When the object is GCed, the collector knows to point the weak references to the nil object. Not all GCs support this, and it is still non-standard (i.e. experimental) in languages that traditionally have GC support, such as Common Lisp.



--
Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, mhm21x16, and the Patron Saint of All Things Plastic fnord
I'm proud of my Northern Tibetian heritage!
[ Parent ]
The Ramifications Of A Garbage Collected C++ | 163 comments (161 topical, 2 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!