Although the C language has been around for close to 30 years, its appeal has not yet worn off. It continues to attract a large number of people who must develop new skills for writing new applications, or for porting or maintaining existing applications.
Best practices for programming in C
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This article is over a year old, and I know I have either seen it here or on slashdot before.
And C is 30 years old, so it doesn’t matter if the article is old. The article remains relevant.
I’ve seen some of these tricks but I’d add a few other gotcha’s that I’ve come across while programming but most would find them a little anal. I still prefer C over C++. Still holding out.
but what it covers is pretty much basic stuff…An article about best pratice for writting modern C would be great
it’s just boring day in IT
Well, in my opinion… best practice in C would be to stop using it. There are enough superior languages.
The superior language is C. Or assembler
Oops for got to add imho after …language is C
Good argument. When will we see the next topic about QBasic and COBOL? I’d kill to have some topics about that.
Such as?
http://www.informit.com/articles/article.asp?p=350919
Which languages? Well, how about all those languages that don’t encourage my favourite vulnerability: Buffer Overflows (BTW don’t tell me that a professional C developer can write code that doesn’t contain Buffer Overflows… which would imply that most software, ranging from client apps to all kinds of servers were/are written by inexperienced novices judging from the constant flow of BufferOverflow vulnerability news);
That’s actually the one thing missing from this (otherwise quite good) article; it should tell people to never use strcpy()… strncpy() doesn’t solve all problems, but it’s a first step.
…which is also more fun to read: http://mindprod.com/unmain.html
How much of the software out there is still developed with C ?
I tried using Hex editors to find evidence of C usage. Is this a good method. I can find snipits of code saying C++ classes. Is there a better way to find out if software was written with c or c++ ?
How ’bout using a decent compiler? Such as GCC with OpenBSD’s ProPolice which nukes buffer overflows quite nicely?
Or using decent hardware for that matter, as in: CPU’s with a no-execute (w^x) bit.
how many CPU cycles spend during simple
int a;
float b;
….
a = b;
and do you can keep in mind all such optimization with complex C++ classes ?
My choice is pure c + assembler. C++ for lazy RAD newbies.
You are absolutely right. Just stop using C. Example like in the Linux kernel. Yeah right. Sigh.
How ’bout using a decent compiler? Such as GCC with OpenBSD’s ProPolice which nukes buffer overflows quite nicely?
Or using decent hardware for that matter, as in: CPU’s with a no-execute (w^x) bit.
These are workarounds, not fixes.
You are right when you say that those are workarounds. The solution probably will be in the CPU designs in the future.
“C++ for lazy RAD newbies.”
No. It’s for people who prefer spend their energy in building more advanced and complex programs, rather than waste it to do the compiler’s job.
As for your example, I don’t see what’s your problem… It wouldn’t take any more cycles than in C. And most probably not more than hand-coding it in assembler.
… is how all you C people out there handle your 32bit / 64 bit printf statements without banging your head on monitors and the like. ;o).
I’ve heard of people who cast their integers to long. What’s your take lads’n lassies ?
I disagree
C is not a very forgiving language.
But good architecture can prevent such bugs.
See http://vsftpd.beasts.org/IMPLEMENTATION
My choice is pure c + assembler. C++ for lazy RAD newbies.
Assembler? Maybe if you’re doing *really* low-level stuff. Both else? A good C compiler optimizes better than you ever could spending a reasonable amount of time, in most cases. And you can code portable using C.
And about “lazy RAD newbies”. If you consider code reuse, clean interfaces and abstraction as “lazy”, okay. I’d call it “productive”.
Reinventing the wheel all the time and using 5 statements to copy some strings or such is just a waste of time and additionally error-prone. Why should one want to code low-level when there is no need for it?
If all these C gurus would use some neat and well tested string class, there were a lot less buffer overflows.
> You are absolutely right. Just stop using C. Example like
> in the Linux kernel. Yeah right. Sigh.
OS kernels are a good point to start using better languages. Of course you can’t just write the next Linux driver in another language… you choose a superior language for a new project, in existing projects you have to use what’s used before.
See JNode for example, and what problems they avoided just by not using C. http://www.jnode.org
> How ’bout using a decent compiler? Such as GCC with
> OpenBSD’s ProPolice which nukes buffer overflows quite
> nicely?
* What about memory management? – very well handled with garbage collectors… not in C. Note that conservative GCs don’t count since they don’t work reliably.
* What about data aliasing? – very well handled in purely functional languages… not in C.
* What about a proper module system, at least some kind of namespaces?
* Why does C need CPU protection features to run a program in a sandbox? Other languages such as Java don’t need it.
* C is not portable without serious restrictions. Anyone claiming different has probably not tried to port a big project (try porting a 3d engine for example).
The same applies to assembler. The same applies to C++, maybe with the exception of namespaces (I have no experience with C++ namespaces).
My favorite language is C. C++ is good but I think it is easy to write bad code in C++. Maybe it’s just with me. Sure OOP is cool and stuff but it definitely is not the end-all and be-all.
You people and your language wars. Get over it..
What about memory management? – very well handled with garbage collectors… not in C. Note that conservative GCs don’t count since they don’t work reliably.
Garbage collection works great… in Lisp. Java’s memory management is horrible… extremely conservative on computation time and very leaky and wasteful, which it attempts to mitigate by awful arbitrary limits on heap size. System.gc() is a complete joke, and debugging memory problems on complex Java applications is nearly impossible.
Why does C need CPU protection features to run a program in a sandbox? Other languages such as Java don’t need it.
Hardware page protections are not a “sandbox”, they’re a silver bullet to buffer overflows. Attempting to point the CPU instruction pointer at data in stack or heap space will generate a CPU exception.
In light of the recent JVM security problems:
http://news.com.com/Java+flaw+could+lead+to+Windows,+Linux+attacks/…
…it should be clear that “sandboxed” execution is only a band-aid on underlying architectural problems with computer security stemming from a lack of hardware memory protection.
@Morin:
“The same applies to C++, maybe with the exception of namespaces (I have no experience with C++ namespaces).”
– Memory management: you have to implement it yourself, but reference counting smart pointers aren’t hard to implement , and you can rely on the “resource acquisition is initialisation” idiom for most things. Of course, if you so choose, you can implement a garbage collector and get the endless joy of seeing your app bloating its heap with an endless stream of useless temporary objects, and perhaps even one day release it.
I’m sorry, but most java or .net apps I’ve seen have this tendency to baloon out of control and some of them seldom ever seem to free their stuff. One of the most fun ones is the openoffice launcher, which takes about 40meg right after I boot winXP. I means, this thing only display a trayicon…
– Data aliasing: okay, this one might be one of the weakest points of C++, even though there are solutions around (like restrict pointers)
– Sandbox: well, it’s more complicated than that. If you’re referring to the “execution prevention bit” of the AMD64, it’s actually only a bit that allow to forbid code execution from certain MMU pages (that is set for the heap and the stack). It’s not something new, just something that has always been there on other architectures and that x86 is missing for some reason.
But, anyway, even buffer overflows are dangerous only if they happen in a program running with sufficient privileges to do harmful things.
In windows, it means about every programs, all of the time, as by default, you log with admin provileges, and so run all apps you launch.
That’s no sandbox. If a program runs as a normal user with limited privileges, malicious code executing using a buffer overflow still won’t be able to do anything lethal.
So, this all boils down to a stupidely missing CPU feature used as a bandaid over the poor security policy of windows. It’s not a C language problem.
– Portability: well, I just so happen to have ported 3d engines. It’s not that hard as long, of course, that it’s written properly. Note that writing portable C is not really restrictive, unless you consider avoiding questionable castings and juggling with pointers a restriction.
Portable C++ is even easier, given you write C++ code in C++ style and you always use string instead of char arrays, vectors instead of plain arrays etc., which also buys you buffer overflow safety (I’m not sure about the vector, but I’m pretty sure that bound checking can be turned on on these)
@c0nst:
“C++ is good but I think it is easy to write bad code in C++.”
Of course. But it’s even easier to write bad code in C…
“Sure OOP is cool and stuff but it definitely is not the end-all and be-all.”
OOP is not the only benefit of C++ over C. There’s also generic programming, custom types, standard containers and algorithms…
>OS kernels are a good point to start using better languages. >Of course you can’t just write the next Linux driver in >another language… you choose a superior language for a new >project, in existing projects you have to use what’s used >before.
And what should be used instead? C++. I do not think so. The lower level you go the better.
There are still many things that it lacks like good automated garbage collection for one. Anyhow, still is still the preferred language for many low level programming efforts such as OS design. The problem with older documentation is that it often doesn’t cover safer programming techniques such as using strlcpy instead of strcpy and the likes. Poor programming habits happen in all languages. Hell poor language habits occur all the time. Knowing your programming language intimately and understand when you should, could or can’t use more secure methods such as strlcpy, can help make the software world safer.
By Jebus, Microsoft Visual Studio .Net 2003 Enterprise Architect doesn’t even support strlcpy for example. This is just one piece of very popular development software. It should be made safer, however, I believe 2005 will support it.
Try Advanced C Programming By Example or Expert C Programming for a more thorough analysis of advanced techniques.
Give me a break!
———————————–
best practice in C would be to stop using it. There are enough superior languages.
————————————
I dont think there is anything good to challange C on embeded level. There are more than millions of people who are earning money using C. Majority of the compilers of morden language are written in C. Majority of Linux/Unix kernel is developed in C… C & Assembly languages are never going to die!
The one who commented this seems has never used C and dont know anything about C. He seems to be living in the dream world supplied by Microsoft! I’m sure he is using languages provided by Microsoft!
Yes Tushar i agree with you. C is a very powerful language, you have your freedom with C , but it also puts responsibilities on you.
To use a quote from Spiderman, “With great power comes great responsibility.” That is C.
I support C (not C++) for a hardware abstraction layer. On top of that, nothing but a high level language. And C or C++ or even Java for that matter qualify. A language which just wraps Assembly isn’t high level. Well written high level is way easier and faster to write that well written low level (that’s why it’s called high level) and results in a sounder product.
And just because java’s gc is inefficient, it doesn’t mean gc doesn’t work. Lisp’s works. Smalltalk’s works. Ever used Smalltalk? Nay? Got numbed by ifTrue:ifFalse:? Got panicked by oh I can’t use vim? Felt cheated by how easy it looks? Whoa, there must be some catch to it.
Face it, anything you say against higher level than C/C++ can be said to support Assembly agaunst C/C++.
The one who commented this seems has never used C and dont know anything about C.
That’s a childish remark. Quite the contrary, actually. It takes a good knowlege of C to understand why it is evil. But it has its scope.
He seems to be living in the dream world supplied by Microsoft! I’m sure he is using languages provided by Microsoft!
Uh, MSVC is probably the most used C/C++ compiler ever. What do you think most of that software for Windows is written in (the rest is VB)? Microsoft is a major part of the success of C/C++.
Embedded programming, kernel hacking, and real-time systems are not likely to be done in C++, Java, or .NET anytime soon. And if you think that that’s not a big part of the software world, take a look around you – PDAs, Cel Phones, cars, TV’s, DVD players, MP3 players – these devices outnumber your desktop systems by more than 100 to 1.
There are research projects to do some of those things in higher level languages, but that’s exactly what they are – research projects.
No, C isn’t going anywhere.
Some of his examples can easily be killed by saying “Do only one thing at a time”. Complexity will alway cause errors. For example his a[i] = i++; should never be written as such. Because it is doing two things in one statement. it should be either a[i] = i; i++; or i++; a[i] = i;
Also if you make every code block enclosed in {} curly braces, you will never have a dangling else or if or whatever. It may seem like more mess but it makes sure that you know what each piece of code is doing. This also applies to other languages like Perl.
I remember that I sent an email to one of the authors and he answered that he would have been edit few “typos”.
After more than one year I see that:
for(i=0 to 100)
and
for(elementnumber=0 to 100)
are still there.
That’s not C, I’m sorry.
I’m an embedded programmer so C is my “daily toy”,
thanks for the article link Eugenia.
@Andrea:
After more than one year I see that:
for(i=0 to 100)
and
for(elementnumber=0 to 100)
are still there.
That’s not C, I’m sorry.
Of course it’s not. Did anyone claim that? It’s pseudo code which addresses some variable naming issue. Which is quite language independent.
Of course it’s not. Did anyone claim that? It’s pseudo code which addresses some variable naming issue. Which is quite language independent.
But that is exactly the problem. This article is about C and they use C examples all the time. Thus, they should not put a couple of examples using pseudo code in the article – at least without a warning.
My .002 cent
There’s really nothing wrong with low-level/driver/realtime code in C++. It would be wrong in java or .net, if only due to the fact these languages aren’t natively compiled.
I worked on C++ gameboy advance games, where everything was in C++, including all the low-level code and interrupt manager. There was seldom any assembly at all.
Try Symbian OS, it’s 90% C++, some assembler and very little ‘c’. And yes.. ISR’s / DFC’s all done using classes.
http://www.symbian.com/developer
I’ve not seen much of the lower levels of Be.. but wasn’t that mostly done in C++ as well ?
Try Symbian OS, it’s 90% C++, some assembler and very little ‘c’. And yes.. ISR’s / DFC’s all done using classes.
From what I’ve heard, C++ for Symbian is rather different from normal C++ though.
I’ve not seen much of the lower levels of Be.. but wasn’t that mostly done in C++ as well?
Yes, my guess is that everything but the kernel was C++ in BeOS. However, it could still be C++ even if most of the coding style was done like in plain C. That said, the Be API is one of the best designed C++ APIs around.
Personally I’d be inclined to use “const <type>” for global constants and “inline” instead of macros, e.g.
inline int strequals (const char *left, const char *right)
{ return strcmp (left, right) == 0;
}
These have been part of the C standard since the mid-nineties, and have been supported by compilers for event longer. The advantage is they’re type-safe, which prevents a lot of the bugs macros can cause
> Memory management: you have to implement it yourself, but […]
Exactly *that* is the point why higher-level languages exist. You can do anything in C or even assembler if you do it yourself. I agree that Java/.NET memory management might not be the silver bullet, but I think it’s a hint in the right direction.
> [about sandboxing]
You musunderstood me. I was not talking about buffer overflows, but about that protection that doesn’t allow me to overwrite data in kernel space. C needs such a thing. Java doesn’t due to its strong type system.
> …it should be clear that “sandboxed” execution is only
> a band-aid on underlying architectural problems with
> computer security stemming from a lack of hardware memory
> protection.
No. Hardware memory protection is (or better: is used for) sandboxing. That’s what “run every process in its own address space” is all about. And it’s only a band-aid for *proper* sandboxing. Again, Java is a step in the right direction, and so is Lisp.
> In light of the recent JVM security problems:
> http://news.com.com/Java+flaw+could+lead+to+Windows,+Linux+attacks/…..
If we start talking about *bugs*, what about the hundreds of bugs already found in the Linux and Windows kernels, and what about hundreds yet to be found?
> Portable C++ is even easier [..]
No global variables since they cause problems with Windows DLLs. No templates,STL,exceptions since they are not supported by all compilers. Lots of macros to deal with name mangling in DLLs. Always problems when plugins were compiled with different compilers than the main program.
If that’s “not restrictive” in your opinion, yes then it’s portable.
> [OS kernels]
> And what should be used instead? C++. I do not think so.
> The lower level you go the better.
Then you should go on and write everything in assembler. I prefer “the higher level you go the better”.
> I dont think there is anything good to challange C on
> embeded level. […]
C can be used in small embedded systems because it shows its weaknesses only for big projects. As soon as the code grows, you face the same problems as for desktop/server programs and are better off with a higher-level language. That’s not even an indication that C is better for small projects, it’s just used that way.
The rest of your comment needs no response. Grow up!
>Then you should go on and write everything in assembler. I prefer “the higher level you go the better”.
I will not write everything in assembly, but I can assure u that if I need it I will use it. OS development with C++, no way. C is better a choice, not to say the right one.
>The rest of your comment needs no response. Grow up!
You are mixing my comments with somebody else. Probably the other person needs to grow up (nice comeback), but you should learn how to read.
An all time classic:
http://kerneltrap.org/node/view/2067
the real challenge is to choose the right tool for the right job. I’d be stupid to do assembler for a GUI as it would be to use VB to write a driver.
C is a good language for professional developpers who know how to use it and can handle itspitfalls/limitations.
There is a lot more than language features to take into account to choose a language. Libraries availability, potential target platforms and so on are big criteria.
> Portable C++ is even easier [..]
No global variables since they cause problems with Windows DLLs. No templates,STL,exceptions since they are not supported by all compilers. Lots of macros to deal with name mangling in DLLs. Always problems when plugins were compiled with different compilers than the main program.
It’s not fair to count platforms which are broken. After all, I am willing to bet that there are more plaftorms for which GCC (which is a pretty decent C++ compiler) can compile your code, than there are platforms for which any of the “safe” languages exist.
> You are mixing my comments with somebody else. Probably
> the other person needs to grow up (nice comeback), but you
> should learn how to read.
Yes I mixed it up since I didn’t want to multi-post. I meant Tushar Gokhale from whom I quoted that last paragraph. Sorry if that caused confusion.
> It’s not fair to count platforms which are broken.
Admitted, it was unfair. Better examples are datatypes with different meaning on different platforms (int for example). Or the contents of the standard library (just compare Windows and Linux here – and by “standard” I mean what you use to write programs and not what some committee declared standard).
To some extent it is portable. But then, I’ve made much better experience in writing portable programs in Java, for example.
>I’m sorry, but most java or .net apps I’ve seen have this >tendency to baloon out of control and some of them seldom >ever seem to free their stuff. One of the most fun ones is >the openoffice launcher, which takes about 40meg right after
>I boot winXP. I means, this thing only display a trayicon…
Erm……. you *do* know that OpenOffice is written in C++ and not Java?
C is a terrible language. However it is low level enough that it still has its place for certain things. But more and more the number of things which C is appropriate for is declining.
C++ is perhaps an even more terrible language. The requirement that C++ be backwards compatible with C is the fundamental reason for this. Of course the advantage of legacy code compatability would be argued, but consider that Python, a language much more elegant and expressive than C++, can have C routines embedded.
I suppose Stroustrup accomplished his goals with C++ (oo and generic programming in a C like language), but that really isn’t much of a goal. The most unfortunate thing about C/C++ is their inertia. It has even carried into languages like Java resulting in more misdesign.
My biggest complaint about C++ is that it makes programming in any other style than OO a pain. I’d like to see languages like Python become more popular; languages where functions are first class objects.. Python is so wonderful because it doesn’t push a style upon the programmer. For some problems object-oriented programming fits; but for a _lot_ of tasks it simply doesn’t. Java has continued this stylistic elitism and yet another generation of brainwashed, braindamaged programmers are coming through the university system.
> Memory management: you have to implement it yourself, but […]
Exactly *that* is the point why higher-level languages exist. You can do anything in C or even assembler if you do it yourself. I agree that Java/.NET memory management might not be the silver bullet, but I think it’s a hint in the right direction.
So what ? It’s not like you have to actively manage memory once you have implemented your memory management tools. You usually mostly have to use your own pointer types instead of the regular ones. And before you object, personally I prefer to have a syntax that clearly distinguish when something is a pointer to a shared object, or a copy, and not something that always implicitely pass everything as references.
Another thing is that java or .net garbage collector only manage memory. Everything else (files, sockets, and stuff) need to be explicitely freed in java, which imho kind of defeat the whole purpose of automated memory management.
In C++, you can have any kind of object freed automatically when they get out of scope, so you can use the same mechanisms to automatically manage all kind of resources, and not just memory. For instance, you can get hold of a mutex by creating a named variable holding an object that will lock the mutex. As soon as you leave the function, the object is destroyed and unlocks the mutex automatically.
How would you do that in java ?
> [about sandboxing]
You musunderstood me. I was not talking about buffer overflows, but about that protection that doesn’t allow me to overwrite data in kernel space. C needs such a thing. Java doesn’t due to its strong type system.
Yes. So what if the JVM has a bug somewhere that allows one to make it overwrite kernel or other processes memory ? You’d be happy to have hardware memory protection then.
Another thing that hardware memory protection helps with is that it let you work with 32 bits adresses. If all the memory as well as all the other hardware resources were mapped in the same adress space, you’d need to have 64 bits pointers everywhere.
> …it should be clear that “sandboxed” execution is only
> a band-aid on underlying architectural problems with
> computer security stemming from a lack of hardware memory
> protection.
No. Hardware memory protection is (or better: is used for) sandboxing. That’s what “run every process in its own address space” is all about. And it’s only a band-aid for *proper* sandboxing. Again, Java is a step in the right direction, and so is Lisp.
It’s assuming that the sandbowing architecture and implementation is bug free and flawless, which never occurs in the real world.
> Portable C++ is even easier [..]
No global variables since they cause problems with Windows DLLs.
I sure guess they would, if you just carelessly throw global variables in the global namespace. But anyway, global variables cause problems with a lot more things than that and are usualy considered distateful for a reason.
No templates,STL,exceptions since they are not supported by all compilers.
C++ was standardized 5-6 years ago, and now all the majors compilers (gcc, visual c, codewarrior) respect it fairly well. It includes STL, exceptions and whatnot. As there’s seldom any platform out there where gcc isn’t available, I think this argument is very outdated.
Lots of macros to deal with name mangling in DLLs.
Always problems when plugins were compiled with different compilers than the main program.
I give you that binary compatilibity is a problem currently with C++, and I hope they’ll improve it in the next revision of the standard.
It’s not really a portability problem, though. And there are solutions to achieve binary compatibility.
Better examples are datatypes with different meaning on different platforms (int for example).
It’s a moot point. First, because int kind of is 32 bits on about every platforms nowadays, and because it’s very easy to insulate yourself from any problems that might cause. It’s the kind of things that come from the fact that C++ creator chose to maintain a fairly good compatibility and portability from C. I don’t think these warts inherited from C invalidate the language as a whole, though.
Or the contents of the standard library (just compare Windows and Linux here – and by “standard” I mean what you use to write programs and not what some committee declared standard).
If by standard you mean the STL, well no, there’s no much problems out there anymore.
If you mean the api at large, well duh, windows and linux are different oses. Yeah, you will say “yeah but in java, you have the same framework everywhere”. It’s very nice, but java is kind of an os in the os, and some of it’s stuff is poorly integrated with some platforms (like swing on windows).
Anyway, if you want to write portable code, you have a wide choice of cross platforms libraries. To take your 3d engine example, well yes, if you use directx, it’s not portable.
However, nothing prevents you to use sdl and opengl.
C and C++ are both excellent languages, and accomplish things that other higher level languages fail to do. C and C++ do things that Java and .Net (or Python for that matter) don’t do, or do very well.
C usage is mostly in OS kernels, compilers, embedded programming (which is huge, by the way – just look at all the common household items that have computers with embedded programs, and look at PDAs and cell phones), scientific applications, games programming, and apps that have a need for speed.
C++ usage is mostly in games programming, large systems, databases, GUI programming, multi-platform application development, and large apps that need speed.
Most commercial, as well as open source, software is written in C or C++.
Java usage is in server side web development (J2EE), and micro Java (PDAs, Cell phones). It’s a failure everywhere else for the most part.
.Net usage is mostly for Windows apps, and little bit in the server side web development (ASP.Net).
Java and .Net are used mostly for corportate internal apps that have constantly evolving specifications and development speed is more important than program execution speed.
So until another language comes along that can be easily ported from C and C++ and does what they do only better, C and C++ aren’t going anywhere.
C and C++ have their traps and pitfalls, but as another poster said (from Spider-Man) “with great power comes great responsibility”. And with good programming practice and various tools, C and C++ pitfalls can be (mostly) easily avoided.
I personally like C and C++ a lot, because they are precision instruments with great power. And I like pure C for it’s simplicity and elegance and extreme efficiency, and I like C++ for it extra features, like OOP, namespacess, STL, generics, and exception handling.
And the proof is in the pudding. C is 30 years old, C++ is about 20, and they are still actively, widely used. After all these years C and C++ are still going strong.
>instance, you can get hold of a mutex by creating a named
>variable holding an object that will lock the mutex. As soon
>as you leave the function, the object is destroyed and
>unlocks the mutex automatically.
>How would you do that in java ?
synchronized(myObjectLock){
// locked.
// do critical stuff
}
// unlocked.
>C++ was standardized 5-6 years ago, and now all the majors
>compilers (gcc, visual c, codewarrior) respect it fairly
>well.
They might “respect” it, but they still don’t have a full implementation of the Standard (try using the “export” keyword…);
So I stupidely chose the wrong example. Alright. Replace “mutex” by “socket”, or “file” in my question then…
They might “respect” it, but they still don’t have a full implementation of the Standard (try using the “export” keyword…);
Yeah, that. It’s something they admitted was an error to add in the standard, and it’s hardly something hard to live without, which would explain why about no compiler except at most one (comeau c++) ever took the trouble of implementing it.
Got any example of non-implemented part of the standard that people might stumble upon in real-world utilisation of C++ ? :p
If you look at legacy code in a big company it generally looks like shit. By using basic common sense like that in the article, my C-programs works almost immediately every time. I won’t impress anyone with cool syntax, but it works.
I don’t think it is without a good reason most of Bjarnes articles about C++ are like this. C, C++, perl etc allows just about everything including writing good code. If you look at ada, you’ll write a small book just to do the most simple task, but once it’s through the compiler it works almost every time. With a proper coding style this can be done with C, C++ and perl as well.
The only bad thing I see with C++ is that the standard is so complex that even now, not all compilers can comply with a couple of years old standard.
Got any example of non-implemented part of the standard that people might stumble upon in real-world utilisation of C++ ? :p
In templates, some compilers have too loose rules. If you upgrade from GCC 3.3 to GCC 3.4, you’ll see that you were relying on wrong namespace lookup rules (unless you are a C++ guru). You can see the same problem in VStudio 2002. The “typename” keyword sometimes is required by the standard and not enforced, too.
What about C#? with the MOno and DotGNU ports. Can that keep the legacy of the others “C” as a popular language? I think the brightest comment is to choose the proper language in the proper situation. I dont like .NET but C# has proved to be extremely useful and popular. What do u think?