quote:Original post by Ready4Dis
Sounds more like a case of bad planning and bad variable naming.

Sounds like you don''t know what you are talking about. My point is that c++ provides mechanisms in the language that you have to hack around as a C developer. All the planning in the world isn''t going to make an C implementation of virtual functions pretty.

Using c++ doesn''t mean having large class heirarchies, or making everything a virtual function. You have that option, and in many cases polymorphism is exactly what you want. In other cases, it falls woefully short(as anyone who has used generic functions in Lisp knows). You don''t have to sacrifice performance for productivity in c++ - you simply have more language idioms available to express your problem.

Did you actually profile your raytracer? I ask because I wrote a raytracer in c++, using a class heirarchy for intersections, and almost no time was spent on virtual function calls - it was all in the intersect code itself, and in the spatial subdivision tree.

Let me reiterate that c++ is hardly the best solution to C. In particular, most of the C features that were included in c++ for compatibility are to blame for c++''s problems. However, properly written c++ is orders of magnitude safer and more productive than C code is. I guarantee you that almost all buffer overruns in c++ code are due to somebody writing C-style code, and wouldn''t exist if the coder used std::string, std::vector, std::stringstream, or such.

quote:Original post by Sphet As for some of the claims that C is a language for bugs and for buffer overuns, I would suspect that most people started with C, learned from their mistakes at the same time that they took on C++. There''s nothing different in C then C++ when writing debug code that does bounds checking with memory fences and the like. You can write equally buggy ode in C++.

Not exactly. Most buffer overuns are of the form:


Here''s another classic:


I can really go on and on. Like I said before, you certainly can program poorly in c++ (all the C code I showed is valid c++) - but it is poor style. Proper c++ uses the standard library''s mechanisms:
strings for string manipulation
vectors for dynamic arrays
stringstreams for formatting
streams for type-safe IO
etc...

The point that is missed in the this whole C versus C++ argument is that fact that it is MUCH easier for any language e.g. Python, Ruby, Lisp, Cobol, Pascal, etc. to interface to a library if it is written in C.

C is the lowest common denominator.

I really love it that SDL and OpenGL are written in C. OpenGL especially; it is written in C not only for speed, but because the designers are aware that C/C++ are not the only languages on the planet. That there are other languages out there. And users of these languages would also like to interface to the OpenGL libraries without having to cope with the C++ compiler name mangling, or having to write a C wrapper to go around each and every C++ function/method call.

HairyTroll, you''ve made a very good point. Kudos. I hadn''t thought about the value of a language''s ability to interface. You''re right - the C++ name mangling can really be a pain.

Okay, and what if he didn''t allocate a large enough buffer? Reallocate? Miss out on part of your input? Whatever the solution, it is empirically less optimal than the c++ solution.

Even snprintf is still too low level. Now you have to worry about buffer size - and it still suffers from the same lack of type information that sprintf has.

Of course (responding to the title "C is unnecessary") one could argue that c++ isn''t any more necessary.