What's your favorite language feature?

[0db]

All the features offered by ucPython on my graphing calculator.
Scripting in ucPython is more productive than CASIO-basic.

[SiliconWizard]

Note that you can replace the standard allocator with a garbage collector in C and C++ if you like that. A well known, and relatively well-behaved one is the Boehm GC: https://www.hboehm.info/gc/

It makes a good attempt at reclaiming most garbage in programs that match its limitations.

Scarcely general purpose.

I've not seen it fail in any significant way. A number of programming languages use Boehm as their GC -- and many others *should*.

I mostly agree with that. If someone is claiming the Boehm GC is flawed, please at least give details, and accurate facts and figures about it. It has been widely used indeed.

Hans Boehm was completely open about what it couldn't do. Apply those to arbitrary programs composed of components (e.g. libraries!) produced by people not working together. Then try to ensure correct operation.

If there is a strict control of all code in a particular environment (e.g. Apple's) then it becomes less intractible - although still difficult and somewhat limited.

So you're basically saying that all projects in which it has worked well must fall into this category. Maybe so. As Nominal Animal suggested, there are still many cases (obviously not ALL) in which just using it as a drop-in for malloc() mostly gives benefits without noticeable problems. It should certainly be tested with care, though. Another point, which may be part of what you are saying, is that ideally you must have access to ALL source code and recompile everything using the Boehm GC. I know there are ways to just kind of redirect malloc() calls at the executable level, but I would certainly suggest NOT doing this. Way too slippery.

But with your claims, it would have been nice to have more details on the exact limitations and how "difficult" it is to use properly. As it is, it's like we'll have to take your word for it. I absolutely don't think it's perfect, but it would have been interesting to have more detailed information if anyone is interested in possibly using a GC with C or C++. (All the more that there are other options, just the this one is one of the most popular.)

Now in the general sense, any allocator that is an integral part of a given language, rather than a third-party addition, is more likely to be more robust, easier to use, and more consistent. No real doubt about that, and if this is what you implied beyond the very case of the Boehm GC, then that's something to consider.

Note that I was merely pointing out an option for those that would be dead sure you can't have a GC with C or C++. I was not particularly advocating using one, as GCs have specific issues (however good they are) that you don't necessarily want to have to deal with, such as non-predictable execution times. I am also not 100% convinced about garbage collecting in general - it naturally leads to sloppy resource management. You may argue that it will almost always do a better job than even careful "manual" resource management, and I wouldn't necessarily disagree in the general case, but I'm still not sure it promotes completely healthy programming habits, or that it's even the best way of dealing with "automatic" resource (memory) management.

You sound as if you think people are claiming GC is a silver bullet, which would be stupid.

I don't know how you get that from what I said. If it was not clear, all I was saying is that there are actual options for a GC in C and C++, and then I additionally expressed my own (short) opinion on the potential benefits and drawbacks of GC in general.

We can also note that depending on the language you use, you may not have a choice. Some languages rely on GC and don't give you alternatives for dynamic allocation. For people using such a language, whether they consider GC a silver bullet or not doesn't matter - they just have to do with it.

[tggzzz]

Note that you can replace the standard allocator with a garbage collector in C and C++ if you like that. A well known, and relatively well-behaved one is the Boehm GC: https://www.hboehm.info/gc/

It makes a good attempt at reclaiming most garbage in programs that match its limitations.

Scarcely general purpose.

I've not seen it fail in any significant way. A number of programming languages use Boehm as their GC -- and many others *should*.

I mostly agree with that. If someone is claiming the Boehm GC is flawed, please at least give details, and accurate facts and figures about it. It has been widely used indeed.

Hans Boehm was completely open about what it couldn't do. Apply those to arbitrary programs composed of components (e.g. libraries!) produced by people not working together. Then try to ensure correct operation.

If there is a strict control of all code in a particular environment (e.g. Apple's) then it becomes less intractible - although still difficult and somewhat limited.

So you're basically saying that all projects in which it has worked well must fall into this category. Maybe so.

No I'm not saying that. If I say that all crows are black birds, it does not mean I say all black birds are crows.

As Nominal Animal suggested, there are still many cases (obviously not ALL) in which just using it as a drop-in for malloc() mostly gives benefits without noticeable problems.

The keywords there are "mostly" and "noticeable".

As Tony Hoare memorably put it "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

It is obvious which category a product made with Boehm's GC falls into.

It should certainly be tested with care, though.

Remember the old engineering adage: "you can't test/inspect quality into a product". Why is it that too much of the software industry doesn't comprehend that tests cannot show the absence of bugs, they can only show the presence of specific bugs?

Another point, which may be part of what you are saying, is that ideally you must have access to ALL source code and recompile everything using the Boehm GC. I know there are ways to just kind of redirect malloc() calls at the executable level, but I would certainly suggest NOT doing this. Way too slippery.

Absolutely. That is not practical for many reasons.

But with your claims, it would have been nice to have more details on the exact limitations and how "difficult" it is to use properly. As it is, it's like we'll have to take your word for it.

Do not take my word for it! Read the literature to understand what the creator (and others more knowledgeable than me) have said. I'm not going to repeat it poorly!

I absolutely don't think it's perfect, but it would have been interesting to have more detailed information if anyone is interested in possibly using a GC with C or C++. (All the more that there are other options, just the this one is one of the most popular.)

Popularity is irrelevant.

If I'm allowed to create a product that doesn't work, I can do it in 10 minutes flat.

Now in the general sense, any allocator that is an integral part of a given language, rather than a third-party addition, is more likely to be more robust, easier to use, and more consistent. No real doubt about that, and if this is what you implied beyond the very case of the Boehm GC, then that's something to consider.

I will try to stop people using inappropriate tools when more appropriate tools are available. Familiarity with an inappropriate tool is not a valid reason for using it.

For example, I've seen people open tin cans with scissors

...
We can also note that depending on the language you use, you may not have a choice. Some languages rely on GC and don't give you alternatives for dynamic allocation. For people using such a language, whether they consider GC a silver bullet or not doesn't matter - they just have to do with it.

That doesn't mean it is sensible, nor appropriate, nor correct.

Example. I've seen somebody that needed to get a value from one unix process to another running on a different processor. Since he only knew SQL he just had to use that. Yes, his solution was the first process updated a database table, and the second process polled the database table (using SQL SELECT) to spot changes.

Sane people would just have started with TCP/IP, not SQL!

[GeorgeOfTheJungle]

Sane people would just have started with TCP/IP, not SQL!

Or a pipe.

[brucehoult]

As Tony Hoare memorably put it "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

It is obvious which category a product made with Boehm's GC falls into.

Any program which uses explicit malloc() and free() which are not in the same control flow block (and which could therefore just as well use alloca() or even a local variable) has already exited from the first category.

It is an enormous simplification and contribution to reliability to debug the GC once, not debug every malloc() and free() in every program.

GC is a huge aid in making separately developed libraries work together. As are exceptions.

Very simple libraries can work ok without those, but as soon as you have anything that uses callbacks (or calls methods on an object you pass it, which can be of a derived class of the class the library was written for) then you need both.

It's very hard to see how substituting GC for free() in a C program that is bug-free can produce a buggy program. Some objects that would be free()d may never be collected if pointers to them are not zeroed after free() or overwritten with a new pointer sometime after. This effect is strictly limited and can not lead to a continuous leak that does not exist in the malloc/free version.

In C++ making delete a no-op results in destructors not being called. The vast majority of destructors do nothing more than delete other objects, in which case it doesn't matter.

The case that matters is if a destructor deallocates or closes some external resource such as a file or network port or sends a message to another process etc. However this is a rare style of programming. Usually such things are done by explicit function calls controlled by program logic, by nested control structures, or by RAII.

[tggzzz]

As Tony Hoare memorably put it "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

It is obvious which category a product made with Boehm's GC falls into.

Any program which uses explicit malloc() and free() which are not in the same control flow block (and which could therefore just as well use alloca() or even a local variable) has already exited from the first category.

It is an enormous simplification and contribution to reliability to debug the GC once, not debug every malloc() and free() in every program.

GC is a huge aid in making separately developed libraries work together. As are exceptions.

Very simple libraries can work ok without those, but as soon as you have anything that uses callbacks (or calls methods on an object you pass it, which can be of a derived class of the class the library was written for) then you need both.

Agreed on all counts.

It's very hard to see how substituting GC for free() in a C program that is bug-free can produce a buggy program. Some objects that would be free()d may never be collected if pointers to them are not zeroed after free() or overwritten with a new pointer sometime after. This effect is strictly limited and can not lead to a continuous leak that does not exist in the malloc/free version.

In C++ making delete a no-op results in destructors not being called. The vast majority of destructors do nothing more than delete other objects, in which case it doesn't matter.

The case that matters is if a destructor deallocates or closes some external resource such as a file or network port or sends a message to another process etc. However this is a rare style of programming. Usually such things are done by explicit function calls controlled by program logic, by nested control structures, or by RAII.

Here we are diving into discussing the characteristics of some programs plus libraries plus a/one GC retrofitted to a language that was not designed to allow GCs. At this point things are becoming complicated to the point of being intractable. It would be too easy to miss a particular case that does turn out to cause infrequent subtle problems, possibly only when more aggressive optimisations are enabled and/or when third party libraries are linked in.

Given the demonstrable inability of most C/C++ programmers to understand all the language and implementation "gotchas", it looks like building castles on sand. N.B. I'm quite prepared to believe that a relatively few experts could build a useful castle on sand.

Overall, if you need GC then:

• if you are starting from a clean sheet, then best to use a language designed with GC in mind. If desirable, it should then be possible to adopt programming styles that don't generate much (if any) garbage. At that point any "GC overhead" becomes moot. Some fintech Java libraries/products do that.
• if you can't start from a clean sheet but have to use pre-existing components, then predicting and ensuring there aren't subtle infrequent problems related to GC seems a tall order. Best to avoid GC altogether

Summary of the summary... We have enough interesting problems to solve in our various application domains. Life is too short to spend debugging additional uninteresting problems that are avoidably added by a tool. Let's concentrate on the application, not on the tools.

[brucehoult]

The first paper on BDW GC was published in 1988: https://hboehm.info/spe_gc_paper/preprint.pdf

That's over 30 years of experience with this software. on many CPU architectures, dozens of compilers, who knows how many thousands of programs. My own experience with Boehm GC is around 22 years.

If there were significant problems with the overall approach, in the face of C programmer habits or compiler optimizations, I think we'd know by now.

There *have* been problems found over the years, and they have been fixed or mitigated.

If you're going to write a program using dynamic memory allocation at all, I firmly believe if you use Boehm GC then it and its interaction with arbitrary C or C++ code is the LEAST LIKELY place you will encounter bugs, and using it instead of malloc/free or new/delete will VERY significantly decrease the overall probability of your having memory bugs.

[tggzzz]

The first paper on BDW GC was published in 1988: https://hboehm.info/spe_gc_paper/preprint.pdf

That's over 30 years of experience with this software. on many CPU architectures, dozens of compilers, who knows how many thousands of programs. My own experience with Boehm GC is around 22 years.

If there were significant problems with the overall approach, in the face of C programmer habits or compiler optimizations, I think we'd know by now.

There *have* been problems found over the years, and they have been fixed or mitigated.

If you're going to write a program using dynamic memory allocation at all, I firmly believe if you use Boehm GC then it and its interaction with arbitrary C or C++ code is the LEAST LIKELY place you will encounter bugs, and using it instead of malloc/free or new/delete will VERY significantly decrease the overall probability of your having memory bugs.

I thought it was a 90s invention rather than 88, and I'm sure your experience is valid. I'm not surprised there have been problems found (and fixed); I certainly haven't been following the subject. I'm mildly curious (in a rather prurient way) as to the way the bugs were found, reported, believed, and fixed. I don't expect you to set them out, though!

I also have no difficulty believing that it is less error prone than "traditional" malloc/free/new/delete. But that's an unacceptably low bar to set!

But overall the balance of probabilities is that if you are starting a new application with significant dynamic memory allocation, then there have long been better tools available. The existence of Boehm's GC highlights that - but doesn't change that.

[AntiProtonBoy]

Bit late to the party, but C++ destructors is easily the most favourite language feature. Literally a game changer in how you think about writing code.

[K8Philip]

Associative Arrays

[SiliconWizard]

Associative Arrays

Is that what we also call "dictionaries"? Such as tables as implemented in LUA.

If that's what you mean, then I definitely agree. Of course there are numerous libraries available to implement them in various languages, but having the feature "built-in" sounds nice. More generally speaking, having "dynamic tables" as a built-in feature is an extremely useful feature. You can emulate that in various ways when not available, but it's always more or less clunky.

Ideally, I'd like a general "dynamic table" data structure built in the language, where you could declare a given table to be either an ordered table, an unordered table (could lead to more efficient handling if order doesn't matter), or a dictionary (or associative array.) And yes, again you can find libraries for this in almost any language, but having that built-in could have a number of benefits (such as better optimization opportunities.)

[bd139]

Go channels is a winner for me. Nice concurrency primitive.

[tggzzz]

Go channels is a winner for me. Nice concurrency primitive.

...particularly when coupled with the select statement.

We have a lot to thank Tony Hoare for, since his CSP introduced the concepts 45 years ago. They then lead to Occam / xC / Go, and a few others.