Slashdot Mirror
C, Objective-C, C++... D! Future Or failure?
TDRighteo writes "OSNews is carrying a quick introduction to a programming language under development - D. Features include garbage collection, overrideable operators, full C compatibility, native compilation, inline assembler, and in-built support for unit testing and "Design by Contract". With all the discussion about the future of GNOME with Java/Mono, does D offer hope of a middle-road? Check out the comparison sheet."
I like this. It was about time someone saw the need of a cleaner, more modern version of C/C++ that takes the best features of the modern languages that are supplanting it in higher-level application development, like Java and Perl.
However, I it is doubful it will gain a foothold in the current ocean of multiple, semi-specialized languages.
The perfect sig is a lot like silence, only louder
I don't see D having the kind of successful adoption that Perl had/has or Python (to name two) yet neither of these were overnight successes. Only time and programmer support will tell if it has D chance!
Where the answers are...
I can understand many of the goals D is trying to achieve and like many of the features they have listed. However, I am surprised that D wants to be C compatible. IMHO, that has been the biggest problem with C++, it totally violates the thinking of the object oriented coder.
D is designed to address the shortcomings of C++. While a powerful language, years of history and unneeded complexity has bogged down that language. They want to overcome C++'s "history" while still maintaining C compatibility. Suddenly, I'm confused.
Karma: Bad (mostly due to all those "In Soviet Russia" jokes)
I don't know, I think objective-c handled it pretty well and clearly. It's a superset of c, and it's optional garbage collection is as simple as setting or not setting the auto-release flag when you construct your object.
I wish the article actually compared to objective-c, as the story's poster seemed to imply...
As you say, programmers don't want to spend time worrying about error checking. The problem with return values is that some functions return -1, some return NULL, and others return some magic number depending on the problem. You can come up with rules and standards, but these are often broken or forgotten while programming.
Exceptions provide an obvious answer to the problem of how to handle different types of problems. If a file doesn't exist and someone tries to open it, a FileNotFoundException is thrown. If a file exists but the permissions don't allow access, an IOException is thrown.
Exceptions also provide a MUCH cleaner way of propagating errors. If one method calls another method to open a file, and the file can't be opened, how do you tell the original caller that there was a problem? With exceptions, you simply declare that your method throws IOException, and then (typically) skip the try-catch-finally block.
Of course.
There are fads in programming just as there are in clothing and management methodologies. And there are always people telling you to adopt the flavor of the month, I mean wave of the future if you don't want to become obsolete.
And you can usually ignore them.
I sat out PL/1, which, well, gee, it had BIG BLUE behind it (in a day when IBM's domination was far more complete than Microsoft's is now). And it doesn't seem to have done me much harm.
True, you can score big by being the person who actually has the "two years experience in" (language-that's-only-existed-for-two-years) that the recruitment ads want, but if you go this route remember that it's easy to be knowledgeable in the latest language if you've just spent some unpaid years in college learning it. If you want to make a career out of always having the skill that's in demand, keep in mind that the only reason the skill is in demand is because it is rare--and you'll need to be quite clever at guessing the next fad, and dedicated about finding out how to educate yourself in it while keeping your day job.
"How to Do Nothing," kids activities, back in print!
In the end, it may come down to having extensive library support weather this language gets any attention or not. Without having easy to use, easily availiable libraries for sound,graphics,networking etc..., along with support examples and help with the libraries, it may not be worth using the language at all. Sure you can import C/C++ based libraries, but this will all be unmanaged C/C++ code and not protected D code with all the bennifits of D.
I've seen this language before, and I happen to think it's pretty cool. It's been almost ten years since we've seen a language that isn't compiled to bytecode and interpreted on a VM come out. If I need to write something that compiles to straight Linux ELF/Win32, I'm stuck with C (which I dearly love, but is 34 years old an not even OO) or C++ (g++ gives me terrible headaches, what with refusing to compile code with throw statements), and D is a pretty interesting bare-bones compiling language with very nice features.
Really, kudos to Walter Bright for this little piece. It needn't become popular, if it stays good it's plenty more than enough.
Looks like the D website has gotten a facelift since the last time I checked in on the language. I've had high hopes for the concept. I've often felt that C++ needed syntactic a facelift away from C; I especially hate the preprocessor, and am glad D looks to get rid of it.
The only thing about D that bothers me is the inclusion of the Garbage Collector and several other runtime components that occur in the background of your program. I'm not sure I really like that; it sounds a little *too* close to Java, if you get my drift. What I'd really love to see, and what I hope D inspires if not actually implements, is a language with the power of C/C++, but the easier syntax of Java.
D *seems* to be the first step in that direction. I hope it goes further.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
C has a masssive codebase, and some real code wizards - we're talking people with 30 years experience. There are mature, free compilers avaiable.
Walter Bright's D is free as in beer but not speech, and there's only the one compiler. Do we really need another language that's a bit like C++?
#define struct union
D is certainly a very interesting language;
However, there are many interesting languages. Over the years, I've explored Prolog, Modula-2/3, Oberon, Haskell, Ocaml, and others. All of those embody some very interesting concepts; in some cases. they may be "better" than mainstream languages.
But the fact remains that no one has ever paid me (or anyone else I know) to write code in Ocaml, Haskel, Oberon, Prolog, or D. For the most part, it is C, C++, and Java that feed my family; upon occasion, clients need Python and Fortran 95. I'd love to be paid for a project in D or Ocaml; I'm not going to bet the farm on that happening.
I wish the world of languages (both human and computer) was more diverse -- but reality suggests a hard road to popularity for original concepts like D. I respect and appreciate Walter Bright's abilities; his Zortech compiler paved the way for C++, and provided excellent optimization. I wish him luck in promoting his vision.
All about me
Agreed. Though it's generally bad practice for libraries to allocate their own memory for returned data, it happens.
Because it's not handled by D's garbage collection, it still needs to be freed. I'm sure this will make those developers who love to leak memory even worse.
I'd like them to come up with a better name. D makes it very hard to find information about it on the web. A name like "zlxrt" would be better since it would get zero hits that weren't about the language.
For the pedantic - I consider this post to be about the zlxrt language.
I don't understand why these people keep designing C-like languages that are nothing like C. By the time they are done, the resulting language has so many more features than C, the surface similarity is more of a boondogle than a benefit. While not perfect, C syntax is great for what C is, "human-readable assembly language". When you try to extend it to object oriented systems, the end result is a confusing mess.
There are far better syntax models for an object-oriented programming language than C. I wish people who feel a need to create new languages were willing to base their efforts on a framework more suited to their goals.
Bander (in curmudgeon mode)
What we need more of is science!
This is a very very big problem. Plugin problems, binary compatibility problems, DSO problems, vtable format problems, and all other things we hate in C++ and that absent in java/c++
I'm sure the gentleman will update his table once 1.5 comes out.
Templates.... great. It's like C++, but it's not.
Huh?
First off, it's link compatability with C. Secondly, no matter how archaic/simple/boneheaded you find C it's still the lingua franca of systems. More so, any system without any link level compatability with C is not really that useful.
I believe it all depends on what you want to do. For most system software (where security is very important) I would agree with you. Also for big application software (like word processing and stuff like that) I would also tend to agree.
However, I'm not sure I agree for software where security is little or no concern but speed is the main issue. One example of that kind of software is games. I'm author of a 3D engine in C++ and I also program in Java for a living. I think that for things like these low-level languages like C and C++ are still the way to go. You can argue that computers are getting faster and faster. But user expectations about what those games can do are also constantly rising.
Greetings,
Project Manager of Crystal Space (http://www.crystalspace3d.org). Support CS at http://tinyurl.com/cb3x4
No. Its a very nice feature.
Just about anything you need, there's a C library for it.
Think nice things like opengl,pam,openssl,GUI librairies, database
libraries, and heaps more.
Having access to those is very nice, and you don't have to wait anyone
to port those to a new language(which probably won't happen anyway.)
I'd imagine how far C++ had gotten if it couldn't use C libraries..
For those of us who don't like unpredictable...
pauses...
in our programs while the garbage collector does its work, will we be able to turn off garbage collection entirely or run the garbage collector only at specified times?
directly, them you're a good enough programmer to ensure that you've called for each new. And with std::auto_ptr, it's as easy as How much simpler does it need to be?I'll answer my own question: even if this is possible, if D ever becomes a serious language, we will be using libraries written by other people, libraries that do rely on garbage collection.
So, no, we won't (realistically) be able to turn off the garbage collector, which means that we won't be able to write real-time programs, and it'll even be touchy writing programs, such as, oh, audio or video players, that require near real-time performance. (Not to mention the disappointment we all felt with the various java window-widget APIs (AWT, Swing) that looked great but couldn't run fast enough to respond to the mouse.)
Look folks, taking care of your own garbage wasn't possible in C for a library writer (even ones returning opaque pointers to structs that allocated their own memory) because you had to rely on the library user to call your cleanup function(s).
But the library user could clean-up. The problem was essentially that some programs didn't care enough to be careful -- pointers actually had to be tracked.
Now, it's fine if a library user wants to add on a garbage collector by re-writing malloc to track allocations. But libraries, which are intended to be used by lots of programmers, to write code, and by lots and lots of end users who run code should not use garbage collectors themselves -- because that forces the library user to use garbage collection too.
But in C++, library writers can write libraries that take care of their own garbage even when used by careless users, because the compiler will automatically call class destructors which can do clean-up. (Yes, except in the case of derived classes -- the writer of the derived class has to explicitly write a dtor to ensure the parent class dtor is called.)
And in C++, with the Standard Template Library, there's little need for non-library writers to do explicit allocation at all -- std::vector and std::string and std::auto_ptr, just by themselves, take care of most of the problems of memory leaks and buffer overruns.
If you're using C++ and you feel that you're a good enough programmer that there's real need for you to be calling
So why complicate things with garbage collector and tracking down circular references and unpredictable pauses? Garbage collection is a bad answer for non-trivial programs, and pretty much necessary for trivial programs.
Opinions on the Twiddler2 hand-held keyboard?
Being a long-time C++ software engineer (10+ years), the biggest thing that irritates me about C++ is backwards compatibility with C. I would love to have to explicitly cast everything, including between signed and unsigned scalars: in such a case, it is perfectly clear to the programmer when he is performing a type-mismatched comparison or assignment, something that has bitten me often in the past.
In sum: C++'s biggest problem is its C legacy. Tear it away, add real type-safety, and you have a language much more powerful and safer than Java.
[ home ]
while (!asleep()) sheep++
Though it's generally bad practice for libraries to allocate their own memory for returned data, it happens.
It happens a lot. I've seen a few expensive C-based libraries that clearly show their designers struggled with the classic caller-callee allocation dillema and lost. Debugging memory leaks in programs that use these libraries is typically hopeless and requires high effort-versus-progress computationally-expensive run-time checks to find them. I like C quite a bit, but it is disheartening to see such a simple malloc() function cause so much pain.
Vote in November. You won't regret it.
So why not say it like it is: *Fortran* compatability, since that is what C was origionally designed to be compatible with. That way you could link with those pesky fortran math libraries.
Actually this is a good point. If I want Java help, I can search for "Java SOMETHING" and the search results will likely be good. "D SOMETHING" will not work.
Declare all your variables before executing code
Leads to cleaner code, in my opinion. C++ doesn't require you to do it, but I still do.
declare all your functions before using them
What's the big deal about this? If your tired of typing, you either need to learn to copy/paste, use an IDE that will generate code for you, or find a new industry.
C takes much more time to compoile than Java/C# because all the stupid headers take forever to parse.
Ever hear of "Make" and "Makefiles"? You don't need to keep recompiling things than havn't changed.
Pointers are a problem because they allow unsafe code that forces the hardware to make up for lack of security in the software. Repeat after me, security is a software problem.
Pointers, in some capacity, are needed for low level programming. If you don't need access to hardware, then you might have a reason to consider something besides C.
Which is why they do include support for interfaces. I don't think you understand the disadvantages of multiple inheritance. I've never found a situation where I actually required the additional functionality that multiple inheritance allows and coudn't be done better with just interfaces. Plus, if you were gonna copy multiple inheritance from c++ you'd need to copy all those nasty casting operators.
You have no idea what you're talking about. I have mod points, and already modded in this discussion, but you are spouting such clearly incorrect nonsense that I feel compelled to respond anyway, lest any newbies actually think you know what you're talking about, and repeat your nonsense.
What will you use for your low level device drivers?
C. There you go, congrats, you found one use for C. Now, I ask you: How many low-level device drivers have you written lately? I've never written any, and probably never will. I would wager that over 99% of Slashdot readers are in the same boat as me.
Or how about that code that needs run fast?
Sigh. Go read some benchmarks. JIT-compiled Java is just as fast as C/C++ for virtually everything. You are apparently unaware that compilers have been steadily advancing for several decades now, and are actually extremely sophisticated and smart. They are very good at what they do. When you execute a Java program, nothing is interpreted. It is compiled to optimized native code and executed full-speed.
Actually, in some cases, Java code is faster than C code. When you compile a C program for an x86 platform, you compile to the lowest common denominator. Your compiler cannot assume the presence of advanced instruction sets, like MMX or SSE2. It must restrict itself to outputting code that will run on a 386. A Java interpreter, on the other hand, already knows what platform it is running on, because the native compilation happens at run time, instead of compile time. Thus, it already knows what CPU it is running on, and can take advantage of the precise instruction set availble on the host CPU.
In fact, the java virtual machine and compiler are both written in C.
This was the comment that really had me screaming "You IDIOT!" at my monitor. The Java compiler is written in Java, not C. It lives in com.sun.javac.Main. Go look at the "javac.exe" executable. It's tiny. Know why? Because it's nothing more than a native bootstrapper that executes java com.sun.javac.Main <args>. The interpreter is, in fact, written in C. But the compiler is 100% Pure Java (TM).
Don't believe me? Look disassemble it and look at the code. That should be easy for you, what with your professed experience writing low-level device drivers, eh?
Like woodworking? Build your own picture frames.
Err...he said real-time applications. Because the behaviour of a garbage collector is often approaching non-deterministic (You don't know when it will run or how long for), it's not acceptable for real-time systems. Real-Time Java gets around this by having other memory models which don't involve using the heap, along with providing types of threads that can run in parallel with the garbage collector.
I agree with your post on most of your points.
However I just look as this forum and I can't fail to notice that most of the mainstream languages are so because of what they can offer to a certain target of people. For instance you can see how C / C++ remain unbeaten in the low-level programming field. A friend of mine told me perl is used a lot in science (and web programming as well). Something like Java is quite useful for multi-platform development. Visual Basic makes fast development for Windows true. And of course other languages have their purposes too.
So to put it simple, I get the feeling that the future will divide programmers into different fields of programming. Much more than we are split now, that is. So I am not sure that the "wave of the future" will be just one winner, like it's been in the past. I already can see that there are several winners for several different reasons.
My 2 cents,
Diego Rey
diegoT
Um, auto_ptr/reference counting is a form of garbage collection, just not a very good one. The trivial example given is certainly fine, but why not just put pfoo on the stack if it's that trivial. Reference counting has problems with circular references; most other garbage collection schemes do not. Note: any doubly-linked list or both-way parent-child relationship is circular.
There is overhead to auto_ptr; In the statement pfoo->do_Stuff(), the -> is an overloaded operator, requiring a function call. The implied destructor is also a function call. In the gc world, there are far better schemes than mark/sweep, which is the other one that most people think of when talking about gc. Incremental and concurrent gc is feasible.
Also, new and delete aren't free, by the way; they do things that aren't strictly necessary in a gc environment. Reference counting (smart pointers)has overhead at every assignment/function call, whereas most gc has far better overhead performance, especially for long-lived data. The argument that gc is too expensive holds little water.
Six score characters.
Brevity being wit's soul
I have enough space.
Pause times below 1/10th of a second are often the case,
That's not even remotely low enough for realtime audio applications. "Human interaction" includes realtime mixing of audio streams etc, not just displaying windows and moving a mouse pointer.
Yeah, nice FUD. Java is slow because it's bytecode
Bytecode is not slow if its jit compiled. Java can be as fast as compiled c in some cases where the jit engine has done a good job. That doesn't reduce GC latency though.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
After Java and C#, why do we need yet another rendition of "what C should have been"?
As far as I'm concerned the standards for C (89,99) are a reasonable place for this language given all its history.
More than anything else we need more standardization of libraries, in the same vein as libc or the STL, but updated to include almost 20 years worth of experience with all kinds of drivers.
Programmers don't need a new language as much as they need powerful, open, standardized, updated libraries.
"Provided by the management for your protection."
Yes, he said real time. Big deal. If he actually was informed about the topic, he'd know there are several GCs that are useable for *hard* realtime. They have *guaranteed* response times.
Sorry - the whole "GC is slow" is a myth, unless you implement a naive GC. But guess what - naive memory allocation by hand can kill performance, too. (It's not like malloc is a speed demon, after all...)
It's not like malloc is a speed demon, after all...
Malloc's usually pretty good, it's the performance of free that typically sucks. It all depends on the implementation, of course.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I have no problem when exceptions are done properly as in Java, but using them in C++ is an exercise in frustration.
As best I recall, both Objective C and C++ were introduced about the same time and for the same purpose: to add OOP support to C. For some reason the marketplace chose C++ and made it successful and widespread while Objective C languished. Why? I have no idea. . . From my admittedly limited experience with both languages, Objective C appears to be a lot easier to work with.
I agree that the world doesn't need yet another extended C. If you're going to build a modern buzzword-compliant language, build it from scratch!
Considering the era C came from, it's a fundamentally good procedural language. Not perfect. Probably not even great. Just good.
In particular, its terse syntax and heavy reliance on operators instead of keywords makes C code dense and hard to read. You can write readable C code, but it takes a conscious effort, some documenting, and some discipline *not* to use every clever coding trick that pops into your mind. (I've read one opinion that C really stands for Clever, because it encourages you to do all sorts of excessively clever things that you'll later regret.)
The reason why the whole software industry seems hell-bent on created mutated versions of C, several decades later, is beyond my understanding.
D drops archaic C++ features like the preprocessor
I'm a veteran C/C++ dev, and when I saw this I went cock-eyed. Macros are essential if you have a performance-critical section that has very redundant portions (that can otherwise be maintained with just a single macro called many times). If D has it's way, I suppose it'd want a dev to write a proc to replace his macro in this a situation--are they kidding? It'd be a turkey shoot for the compiler to it screw up the inlining (without you knowing about it), so you're getting non-optimal execution.
I've wondered why so many Java finatics, Sun, and now D finatics are so anti-macros. It's a real mystery to me--and it's not like they're significant for the compilers to implement and maintain--macro implementation for a preprocessor is nothing next to their C/C++ compiler. If you have piss-poor dev abuse macros, shame on the dev, not on the language.
G-Force music visualization
Multiple inheritance is awesome and indispensible- when you find a language that implements it well. See Eiffel.
How about StreamSocket. Okay, multiple inheritance isn't required in the strictest sense, but object-oriented programming isn't, either. MI makes this class make much more sense - it is both a stream and a socket.
In a language providing only support for multiple interfaces, you'd have to reimplement at least one of those in the derived class. You'd probably end up just dispatching all of the calls in the derived class to a shared implementation elsewhere. Not nearly as clean.
Or you could pull a Java and have a getStream() method on the StreamSocket. (Make the caller do the dispatching to the shared implementation.) I don't like it either.
Plus, if you were gonna copy multiple inheritance from c++ you'd need to copy all those nasty casting operators.
I don't see how eliminating MI makes any of them unnecessary:
This is horribly ugly, especially when all I want to do is compare two integers for size. Casting, parenthesis everywhere, comparison with some arbitrarily chosen integer, etc. With operator overloading and templates, the same thing is possible in a much cleaner and more intuitive fashion:
It doesn't take any 'work' to understand what this code does. A ten year old kid could probably tell you that it involves 'less than'. This is also type-safe (I don't have to worry about if my objects actually inherit from Comparable).
I like D. In my ideal world it would replace all uses of Java everywhere and anywhere, but unfortunately I doubt that will be the case.
Ah, the eternal anti-GC FUD of the ignorant.
Yes, clearly it would be complete lunacy to write video games in garbage-collected LISP, like Jak and Daxter, Ratchet and Clank and so on.
Obviously AT&T were insane to write their telephone exchange control software in garbage collected LISP.
And those massive overheads ensure that we'll never see NASA using LISP to control space probes.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Although this was moderated as "Funny", I think it's a serious question. It's common, when making what are essentially marketing comparisons, to leave out competitors that would make your target "less amazing".
They are ojbect collections. Not a collection of your specified type, until .net 2.0 comes out with generics. It won't have resizable arrays.
Have you ever been to a turkish prison?
The big drawback to single inheritance with interfaces is that you cannot use derivation to gather implementaions of those interfaces.
ATL is a very good example. There are a number of standard COM interfaces a COM object must support and the implementations of those interfaces are often boilerplate code. Via multiple inheritance, ATL allows you to combine the interfaces your object will support as well as the standard implementations for those interfaces.
Achieving the same end with single inheritance usually involves having an aggregate objects which implement the interfaces. Then in your class, you implement each interface to forward the calls to your member objects.
I admit I don't know D or Java, so perhaps they have some syntax features that make this process easier like:
If you have a better way of combining implementations with single inheritance and interface, then I'm all ears.
(From which many sensible people conclude that it's bad practice to write in C.)
... the language spec didn't write the code. With power should come responsibility.
Your 'many sensible people' would be ignoring that 'libraries allocate their own memory' and 'libraries that have fixed size return data' are not the only options.
Sure, you can do bad things in C. You can do "bad things" in pretty much any language - I just ran into an issue where a third party java library closed a stream I passed to it. It didn't create the stream, why should it assume I want it closed? It's a bogus design decision that limits the libraries usefulness - if I want a chunk of data processed by that library wrapped by other data that I write before and after the processing, I can't just write the data that goes first, pass my output stream to this lib, and then pass the data that I want after, I have to write the middle data out to a file somewhere and then reread and rewrite it. Should I now conclude that it's 'bad practice to write in java' because a third party came up with a poopy implementation of a util library?
I recognize that C allows worse things (buffer overflows, etc) to happen when such design errors are made. However, I think that anyone writing code in C should be aware of that - the code doesn't write itself, and the root of the problem is a given programmer following bad practices. You may blame the language for allowing it, but you can't blame the language for the presence of the given overflow
Code or be coded.
Yes, clearly it would be complete lunacy to write video games in garbage-collected LISP, like Jak and Daxter, Ratchet and Clank and so on.
It is a misrepresentation to claim that those games were "written in LISP".
One can say that the "behavioral and game logic" processing was written in LISP, but that's a minor part of the overall software work- especially if you count it in terms of percentage of CPU usage. (Which, since you're talking about performance, is what actually matters)
Games have used LISP to control higher-level flow since the 80s, but to claim that they're written in LISP is no more accurate than saying Mozilla was written in XUL.
And those massive overheads ensure that we'll never see NASA using LISP to control space probes.
Another misrepresentation. Actually reading that article plainly says that the performance-critical elements of the space-probe were written in C.
Furthermore, you cannot use LISP as an example to defend all GC. LISP programs naturally give the compiler more information, allowing it to make better optimizations. Frequently it can eliminate the need to actually execute much of the GC at runtime (converting it into logically static or stack allocations). But with an imperative language like Java, the overall code is less analyzable, so the GC can't reach the same heights of performance.
You make a number of good points. I agree that the instances where garbage collection is infinitely better than any other tool. However, there are also places where ownership is the better tool. I am not going to make the specious 'it is faster' argument here, because usually it doesn't matter.
An ideal language for me would be one where there is a GC (possibly as a default), but that also allowed ownership semantics where that is applicable. Now I am going to talk about situations that I have run across where GC wasn't that useful. Note that I am not making an argument that GC is bad (it is usually very good), but that there is a case to be made for a language where GC isn't required in all cases.
There are many cases where order of destruction is very important. There are cases where this is implicit. For instance, it is best that a 'successful completion' message is written to the log file before the log file is closes.
But there are cases where an elegant solution can depend on it. A good example of this would be streams. Streams, for the sake of argument, are objects that take in a variety of data, turn that data into bytes, and send those bytes someplace else.
Often, a stream will have attributes defining how it processes the incoming data. If the incoming is a bool and true, does it turn it into the character '1', the sequence of characters "true", or the byte 0x01? Floats (how many sig figs?), signed integers (put a sign at the front if its positive?), etc. also have choices to be made.
But if a caller sends a stream to a method for output and the method changes the state for some reason, later output might be unexpected. This is where a stack-based allocation could come in handy. A new kind of object can be created which saves the stream in its constructor and restores the stream in its destructor. If these happen at known points in the program, then all is well. If the destructor (or finalizer) is called at an undefined point, badness results.
Such a stream-state-saver object can be used by the caller to make sure that the method doesn't screw with the state. Or it could be used by the method to make sure that it doesn't step on the callers toes.
The other case where a GC might not be a help is if one were trying to develop a new kind of GC. There is no way in Java, for instance, for me to develop my new "tyrecius' patented GC" as a Java library in any kind of transparent way. I'd have to go in and modify the guts of the compiler/VM.
Finally, memory is just one kind of resource. GC's generally don't make dealing with other resources very easy. The best that one can do is to put the release of the resource in a finalizer of some kind and hope that the resource will be released in a timely manner. File Descriptors, network Sockets, database connections, etc. are all harder to deal with in an efficient and brainless way in a GC-only language.
Let me reiterate that GC is great to have in a language. But I tend to be nervous about a language if there is not a way to bypass it in the few instances when it becomes a problem.
char a[]="lbiitgt l e \n\n\0";main(){for(char*c=a; *(short*)c;c+=2){putchar(*(short*)c);}}
Strostrup does say that he's reasonably happy with the basic language. I don't agree. If the basic language was OK, there wouldn't be a need for C#, etc.
C++ has some major outstanding problems, dating from early bad design decisions. Not just C legacy problems, either. Here's a few of them:
-
The original C++ language had no templates, no exceptions, no run time type info, and no references. This led to a horrible programming style in the early years, with big ugly macros, no standard way of handling errors, wide use of unchecked downcasts, and "this" as an assignable pointer. Much of that legacy lives on in running code.
-
You can't implement safe smart pointers in C++.
No matter how hard you try, you can't make auto_ptr work right. It's been formally revised three times, without success. The problem is that you have to let a raw C pointer out of the encapsulation to do anything with the object, and that pointer isn't "special" to the language. There needs to be a const-like attribute that says "this pointer can't be deleted or copied to an outer scope". Then you can build safe encapsulations.
-
Iterators and references were both afterthoughts. They should have been a fundamental part of the language. C's ambiguous syntax for pointers, which makes a pointer to an object and a pointer within an array
indistinguishable, shouldn't have been perpetuated in C++.
-
A major effort should have been made to make built-in arrays obsolete. Even today, you still see extensive use of C arrays in C++ code. They should be unnecessary. To this day, you can't say "no C arrays or pointers allowed in C++ code" on a project. If you could, there'd be far fewer buffer overflows.
None of this is being fixed in C++. That's the problem