My advice on implementing stuff in C:

Posted Oct 18, 2010 0:10 UTC (Mon) by HelloWorld (guest, #56129) [Link]

I'm wondering if I understood dskoll correctly,

I don't think so. I think that dskoll was talking about virtual inheritance. Say, you have code such as this:

struct A { int a; };
struct D1 : A { int d1; };
struct D2 : A { int d2; };
struct B : D1, D2 { int b; };

Then, B will inherit A::a twice, once from D1 and once from D2. So, inside B, you'll actually have two fields named a, and if you want to use one of them, you always have to use full qualification, that is, you have to write D1::a or D2::a instead of just plain a. Virtual inheritance solves this problem. If you change the code as follows,

struct A { int a; };
struct D1 : virtual A { int d1; };
struct D2 : virtual A { int d2; };
struct B : D1, D2 { int b; };

then the two A sub-objects in B will be collapsed to a single one. It's also explained in the C++ FAQ lite: http://www.parashift.com/c++-faq-lite/multiple-inheritance.html

Posted Oct 15, 2010 18:25 UTC (Fri) by HelloWorld (guest, #56129) [Link]

Oh, another victim of the C hacker syndrome. Please get well soon :)

Posted Oct 15, 2010 19:40 UTC (Fri) by Ed_L. (guest, #24287) [Link]

"But its not low level."

To a certain extent its a circular argument. As others have observed, if you want to do system level (low level) programming on *nix, then you will ultimately end up calling libc, which libraries like glibmm admittedly do a wonderful job of wrapping. For the most part. But for that small part they don't, I've yet to find a substitute for just calling libc (or a syscall) directly. And for me that's one of the beautiful things about C++: its not dogmatic, and allows one to write grotty Fortran when nothing else will do.

:-)

Posted Oct 15, 2010 20:29 UTC (Fri) by HelloWorld (guest, #56129) [Link]

I assert that "low level programming" is *not* what C++ is about. Modern C++ style recommends that you use smart pointers, rather than C pointers, for example.

How does that make the language any less "low level"? A smart pointer just automates stuff you'd normally do by hand (i. e. free resources or decrement a reference counter). It's just as efficient

Nor should you be using C strings, C arrays, C structures, C stdlib functions, C-like error handling, C macros, etc. Basically, modern C++ encourages using full high-level abstractions for data structures and algorithms, and is thus, fundamentally, high-level.

The use of C arrays isn't discouraged because they're "low-level", but because there are better alternatives. std::tr1::array is just as low-level-ish as a C array, it does't do bounds checking or anything fancy, and it's just as efficient. The difference is that it offers the interface of an STL container, allowing you to use STL algorithms with it.

The same basically applies to C macros. The MAX(x,y) macro kind of works, but std::max(x,y) works better. It'll complain if x and y are not of the same type, and it won't evaluate its arguments more than once. std::max isn't somehow higher-level than MAX, it just sucks less.

Some things in C++ actually raise the level of abstraction, for example with std::string you don't have to worry about memory allocation any longer, since the class will do it for you when needed. If you can't afford that, nobody is going to blame you for not using it. C++ was deliberately designed not to force some style of programming on the user, be it a high or a low level one (unlike C, which forces you to program on a low level of abstraction all the time).

Posted Oct 16, 2010 21:40 UTC (Sat) by jzbiciak (✭ supporter ✭, #5246) [Link]

Compatibility is no excuse because C++ is not compatible with C at the source level. C++ people always seem to demur on this issue, arguing that they're only incompatible at the fringes. As a primarily C developer who occasionally has to muck around w/ C++, getting real C code to compile in "extern C" mode is a nightmare. In my experience, I prefer to view C++ and C as not compatible at all; this makes for fewer headaches.

Hmmm... I haven't had too much trouble moving C code to C++. If your point is that the experience isn't edit-free, I'll give you that though. C++ is generally much pickier. My main issues have been that the C++ compiler is much more righteously indignant about const-abuse¹, and it wants me to explicitly cast pointers to void * (which you also mentioned).

I never thought I'd get into C++ much, but I have totally gotten hooked on templates and the stricter type checking. Modern compilers do a fantastic amount of work at compile time, and I love bringing that force to bear on programming problems. I also actually like that I have to propagate const around more proactively: it exposes thinkos in my design earlier. And I especially like the new reinterpret_cast vs. static_cast vs. dynamic_cast vs. const_cast. It's like having a torque wrench, flat head screwdriver, Philips head screwdriver and a hammer, rather than just having a 20lb sledge.

All that said, I've written way more C than I have C++ and still find C my default go-to language when writing in a compiled language. And lately, I've been writing a lot more Perl. You won't catch me CamelCasing in C or C++, although I will name classes Like::This in Perl. When in Rome...

What I don't understand is all the language hate between C and C++. Save your ire for Python. ;-)

(Just kidding on the Python part!)

---

¹ Yes, I know you can get the same with C code if you use a good compiler and crank up the compiler warnings. And believe me, I do crank them up.

Posted Oct 19, 2010 14:46 UTC (Tue) by HelloWorld (guest, #56129) [Link]

It does have to do with the name lookup rules in very non-obvious ways. I quote from "Design and Evolution of C++", page 141/142:

typedef int P();
typedef int Q();
class X {
  static P(Q); // define Q to be a P. 
               // equivalent to ''static int Q()''
               // the parentheses around Q are redundant

               // Q is no longer a type in this scope

  static Q(P); // define Q to be a function taking an argument of type P
               // and returning an int.
               // equivalent to ''static int Q(int());
};

Declaring two functions with the same name in the same scope is fine as long as their argument types differ sufficiently. Reverse the order of member declarations, and we define twi functions called P instead. Remove the typedef for either P or Q from the context, and we get yet other meanings.

This example ought to convince anybody that standards work is dangerous to your mental health. The rules we finally adopted makes[sic] this example undefined.

Note that this example -- like many others -- is based on the unfortunate ''implicit int'' rule inherited from C.