Programming stuff - C++, Multiple Inheritance, Closures

[Nev]

My GOD, I could do a lot with closures in C++.

I want to go back to school someday and implement a language that's both speedy and fully modern - C# doesn't cut it (as I said before, I think it's rather teeming with corruption just under the surface .) I'd like support for closures and other better abstractions and implementations of functions as data types, mostly. But I REALLY would like to keep the multiple inheritance, too.

I'm interested to know from other programmers here - what's your feeling on multiple inheritance? I'm interested because we're using it for our current project, and I *absolutely* love it. I don't really understand why it gets such a bad reputation - and there are things that are possible with it that aren't possible anywhere else, I think. It allows a lot of code reusability when done right, and I'm a huge fan of code reusability and modularity.

I'd like to know if you guys feel that there are actually seriously bad things about it, or if you feel it's gotten maligned because it's somewhat tricky to use well.

I sort of take the position right now that it's more the latter, but I don't really know for sure, and I may be slightly biased on this . Off to have Bjarne Stroustrup's love child now...

[Ishamael]

Well in general I think C++ is a crappy language (too many features and lame syntax) and I think multiple inheritence is Satan's work.

Most of C++ features are probably mostly unnecessary in game development, judging by the work of some of the top people in the industry. Multiple inheritence specifically is almost certainly unnessessary. John Carmack was able to accomplish amazing things in C and only recently began using a stripped down version of C++ (he refers to it as C+) in his games. Brian Hook (former id and Everquest programmer) has a nice rant on C++ somewhere.

Based on my somewhat limited experience with C++ I agree with them. Of course I'm a Java whore, so consider the source.

[Nev]

Right! So that's two completely unbiased opinions, now.

Anyone else?

Why is multiple inheritance Satan's work, by the way?

[SineSwiper]

I still say that C and C++ are both crap. There's a much better way to design a low-level language. I wish somebody would bother to do it. Java is not the answer, since it's far from low-level.

[Nev]

(volunteers)

Actually, should I get enough money, I would like to go back to school with the intent of speccing out a next-generation language that still focuses on speed, since Java is generally too slow for serious gaming or other very, very speed-intensive applications. I love C++, but it lacks good support for some things I would really like to have - easy-to-use functors being the main one I can think of right now, but I also very much like the C# idea of properties, and there are others as well.

[Kupek]

I still say that C and C++ are both crap. There's a much better way to design a low-level language. I wish somebody would bother to do it. Java is not the answer, since it's far from low-level.

How much systems programming have you done? When I say "systems programming," I mean areas like kernel, library development, or applications which have sever performance restrictions.

As for the main question, multiiple inheritence is a tool like any other. There are times when it is the best option, and not using it results in convoluted solutions.

Mental, I understand your desire to make the next language - I share it - but keep in mind that there are already dozens of languages out there that tout themselves as the next big thing. From what I can tell, languages that catch on either fill a need, or have backing from an entitity that can force their use. Fortran caught on because it beat the hell out of assembly programming. C caught on because it was the right mixture of high and low level, and it was used to implement Unix. (I don't think the success of Unix and C can be seperated.) C++ caught on it allowd systems and application developers to use OO techniques (they were already using C). Java caught on because it had Sun's backing, but also because there needed to be a server-side language for large business applications that didn't have the quirks of C++.

You can find languages out there that basically tidy up a known language, often C++. These languages will not catch on because they don't fill a need.

[Nev]

I've thought about more or less the same thing, Kup. I've heard of probably at least a dozen academic languages that are similar to C++, but improved, though I know next to nothing about them.

I have a hunch that. as you said, it might take a fairly large and prominent company pushing something for a language to really take off - for example, the way Java did. However, if I ever found myself at the helm of a game company with some serious resources, I could see us implementing a language designed specifically for gaming, and developing at least an internal compiler and tools for use with it, even if it was never meant to be widely adopted. I'd love to do something that would be able to integrate both a modern functional and an object-oriented paradigm - I'd like to explore the possibilities of a language with very good first-class-citizen support for functions (if that terminology is right), as well as one with good RTTI support that isn't extremely slow, if such a thing is possible.

There have to be at least a few languages like that that are currently just academic that are out there. Is Scheme anything like that?

[Ishamael]

...
Why is multiple inheritance Satan's work, by the way?

It makes it too easy to complicate things that don't need to be complicated.

You mentioned code maintence and usability as reasons for liking C++. Multiple Inheretence makes this much harder than necessary because it makes it much harder to understand how things work in a non-trivial system. That pretty much goes for much of C++...

[Nev]

Well, I've always tended to be biased towards something that's harder to understand at first if, once you do fully understand it, it offers significant advantages later.

I'm a fan of multiple inheritance because I believe, when done right, it reduces the need for duplicated code, and I am very much against duplicated code wherever possible because of the need to update things in multiple places if changes need to be made.

[Zhuge Liang3]

The right tool for the right job. Coding in Java doesn't necessarily guard against hard to understand code. The C++ code of one particular programmer in my company is more clear, concise, and logical than any Java code I've seen to date. It all has to do with the person, not the language.

In general, the productivity scale (assuming you know what you're doing) looks something like
Java > C++ > C > assembly

The performance scale (assuming you know what you're doing) looks something like
assembly > C > C++ > Java

Other things that factor into the choice of language for a particular project include legacy systems, 3rd party libraries, hardware access capability, and team expertise.

Zhuge Liang

[SineSwiper]

The right tool for the right job. Coding in Java doesn't necessarily guard against hard to understand code. The C++ code of one particular programmer in my company is more clear, concise, and logical than any Java code I've seen to date. It all has to do with the person, not the language.

I can attest to that. Perl is fucking elegant! But, way too many people don't take advantage of that factor and code Perl like they were coding C. It doesn't work because it LOOKS like C code and that kinda defeats the purpose of coding it in Perl.

And Kupek, as you described, C is there mainly because of its successes with UNIX. It's been around for 20 years. Frankly, the language needs to be replaced. It would be great if all languages were developed by linguists, but most of the time they are designed by engineers that only understand their own language because they were the ones that designed it.

Some of the newer languages seem to a lot more elegant now, though. I just wish C would finally get replaced. It's old and busted. C++ is just adding classes to a busted language.

[Kupek]

Again, Sine, have you ever developed in the areas that C excels in?

Notice I also said that the successes of C and Unix can't be seperated, not that C rode on the success of Unix. Unix was implemented in a language that was high level enough to be portable and have constructs for structured programming, yet low level enough to implement an effecient kernel. Unix succeeded partly because people could compile it for whatever architecture they happened to work on. If C didn't have those properties, Unix wouldn't have made it out of Bell Labs.

C++ is more than C with classes. That is how it started out ("C With Classes" was actually the original name), but it is more than that now. C++ is the most powerful widely accepted high-level language; it allows the combination of procedural, OO, generic, and even functional and logic programming.

[Kupek]

In general, the productivity scale (assuming you know what you're doing) looks something like
Java > C++ > C > assembly

Heightened productivity in Java has nothing to do with the language itself, but is a result of the rich API for a variety of domains.

[Nev]

C++ is more than C with classes. That is how it started out ("C With Classes" was actually the original name), but it is more than that now. C++ is the most powerful widely accepted high-level language; it allows the combination of procedural, OO, generic, and even functional and logic programming.

Agreed, with the exception of logic programming, which I'm not familiar with and have no idea about (what is that, by the way?). But I think generics and first-class-citizen function support in C++ are much weaker than they could be (I'm assuming by "generics" you're mostly talking about template support).

[SineSwiper]

Notice I also said that the successes of C and Unix can't be seperated, not that C rode on the success of Unix. Unix was implemented in a language that was high level enough to be portable and have constructs for structured programming, yet low level enough to implement an effecient kernel. Unix succeeded partly because people could compile it for whatever architecture they happened to work on. If C didn't have those properties, Unix wouldn't have made it out of Bell Labs.

I'm not saying that C (and UNIX) wasn't a good language at the time, but it is outdated now. I also realize that I'm totally outclassed in this argument, seeing as I'm arguing with a near-professor of CS on the subject.

[Kupek]

Agreed, with the exception of logic programming, which I'm not familiar with and have no idea about (what is that, by the way?).

Logic programming differs from other paradigms in that you describe what a solution looks like instead of how to achieve that solution. The language runtime then explores all possible solutions looking for one that fits your defintion. This is not a runtime effecient way to solve problems, but it can be a programmer-time effecient way to solve problems. Sometimes it's far easier to express a solution in terms of rules and predicates than in terms of how to do it step-by-step. Prolog is the standard example of a logic programming language; <a href="http://cs.wwc.edu/~cs_dept/KU/PR/Prolog.html">this</a> is a decent introduction to logic programming in general and Prolog in particular, and <a href="http://www.swi-prolog.org/">this</a> is a good Prolog implementation.

I'm not saying that C (and UNIX) wasn't a good language at the time, but it is outdated now. I also realize that I'm totally outclassed in this argument, seeing as I'm arguing with a near-professor of CS on the subject.

I am years and years from that point, and there are plenty of areas in CS I don't know dick about. But my real point is that you're passing judgement on other people's tools when you've never really used these tools for their intended purpose.

[SineSwiper]

I am years and years from that point, and there are plenty of areas in CS I don't know dick about. But my real point is that you're passing judgement on other people's tools when you've never really used these tools for their intended purpose.

Jesus...what's beyond doctorate at that point? Demigod?

[Ishamael]

The greatest productivity increases from programming language over the last couple of decades has come from managed languages, not from OO or syntax or anything like that....IMO. Freeing programmers from worrying about pointers and where and how memory was getting allocated/deallocated was HUGE.

Now throw in the familiar C/C++ syntax they all know and love and there ya go.

[Zhuge Liang3]

In general, the productivity scale (assuming you know what you're doing) looks something like
Java > C++ > C > assembly

Heightened productivity in Java has nothing to do with the language itself, but is a result of the rich API for a variety of domains.

Po-tay-toe po-tah-toe. Bottom line is, in most cases, I spend less time writing an application in Java than I do in C++. The reason, be it the library or language syntax or language features, matters very little.

I'm partial to C++ myself, but I have no problems admitting Java saves me time compared to C++.

Zhuge Liang

[Nev]

I'd love to use a language that has a library set as rich as Java's is. I'd be very surprised if gaming evolves out of the need to have some of the fastest possible code in computing, though, and I'm quite happy with a gaming career at this point in my life, so I do tend to take more of an interest in compiled languages over the long term. (Though, for what it's worth, I don't know how Java truly compares speedwise to a natively compiled language on different platforms. Does anyone have any good references on that?)

In BREW, we don't even get to use the C++ STL, for a variety of reasons I can go into if anyone likes. I don't think it's coincidental that for the last few months I've been more and more often wishing for a language where the pure language syntax and functionality is as good as it could be.

Oddly, I may have to learn J2ME over the next few months (I have used Java, but not at a commercial level) because it is quite a popular platform for mobile devices. From what I understand, though, it's far slower than BREW is. Whether or not it's because of the need for the JVM or not, and if so, to what extent, I'm not actually sure.

I am years and years from that point, and there are plenty of areas in CS I don't know dick about. But my real point is that you're passing judgement on other people's tools when you've never really used these tools for their intended purpose.

Jesus...what's beyond doctorate at that point? Demigod?

I do tend to believe the best professors (and really, the most knowledgeable of people) continue to learn throughout their careers while maintaining an attitude of humility about knowledge - which is not the same as feigning ignorance.

I haven't seen a field yet where knowledge is perfect, nor a person, even a college professor, who knows perfectly everything that it's possible to know within a given field.

[Kupek]

Po-tay-toe po-tah-toe. Bottom line is, in most cases, I spend less time writing an application in Java than I do in C++. The reason, be it the library or language syntax or language features, matters very little.

I'm partial to C++ myself, but I have no problems admitting Java saves me time compared to C++.

I don't meant to sound like an apologist, but I do actually care about the difference between the language and the toolset it comes packaged with.

Jesus...what's beyond doctorate at that point? Demigod?

I meant that I'm years away from a doctorate, and that even then, a professor position (if I pursue one) is difficult to get. A Ph.D. does not guarantee entrance into academia.

[Andrew, Killer Bee]

Heightened productivity in Java has nothing to do with the language itself, but is a result of the rich API for a variety of domains.

I think you're discounting the strength of Java as a language here. Its class libraries are one of its strongest points fer sure, but you can basically fit Java the language in your head - it's simple, its design is clean, if you know OO then it makes sense (now the libraries, on the other hand... heh heh).

Unless you're Stroustrup you cannot fit C++ in your head - it just has too many layers.

I guess the point that I'm trying to make is that increased productivity in Java does have to do with the language itself, because you need to think less about the language to get things done in it.

I'm not saying that C (and UNIX) wasn't a good language at the time, but it is outdated now.

There are some things about C that suck (the lack of a boolean type, the song and dance you have to do to create a function with an argument list of variable length, the song and dance you have to do to treat functions as variables) but it remains a strong language for its purpose. Which languages would you like to see it replaced by? In what ways is it lacking for its purpose?

The greatest productivity increases from programming language over the last couple of decades has come from managed languages...

Word.

[Kupek]

I guess the point that I'm trying to make is that increased productivity in Java does have to do with the language itself, because you need to think less about the language to get things done in it.

I don't buy this since you can just learn the stuff in C++ that maps directly to Java and chug away. You can be productive in C++ without using all of its features; you don't need to fit it all in your head, but if you decide you need something more powerful, it's there. (And I actually do have most of C++ in my head.)

[SineSwiper]

Po-tay-toe po-tah-toe.

There are some things about C that suck (the lack of a boolean type, the song and dance you have to do to create a function with an argument list of variable length, the song and dance you have to do to treat functions as variables) but it remains a strong language for its purpose. Which languages would you like to see it replaced by? In what ways is it lacking for its purpose?

Well, what you described for one. The backwards-assed BS with pointers/references for another. (Sure, it could be considered an elementary deal for an experienced C programmer, but if you're going to use an asterisk to denote "pointer", then ALWAYS use that character to mean the same thing.) The fact that you HAVE to use Hungarian notation because the damn language doesn't use any characters to show type. (Even if it's split into groups, like numbers, strings, pointers, etc, because I know there's a lot of different types.)

C just isn't as elegant as the other more modern languages. Perl, PHP, Java all basically build off of C and fix a lot of the mistakes in the original language. It's a shame that Perl is too high-level, PHP is for web programming, and Java is too slow.

[Nev]

Just using this thread as a idea-board briefly, because I think I might get something interesting out of it. Below are some things that are coming out of my first large-scale project in C++.

<hr>

Things I like about C++:

new/delete -

Much as I love garbage collection, I actually think there's something nice about maintaining one's own memory. I believe it can really improve the hell out of performance, and cut down on memory use, if one knows what one's doing.

constructor syntax -

Now that I've really learned constructors the way they're properly done in C++, using : at instantiation, I absolutely love this. I didn't know that it was possible to create classes with no default constructors and still use them well. There's a technique I'm absolutely addicted to now - pass an reference type into the object's constructor if one is necessary, and, wherever possible, avoid the need for a separate constructor and initialization routine.

multiple inheritance -

I'll probably defend this until I die. When one is trying to create an class that uses functionality in an existing class using a single-inheritance-only language (like Java or C#), the only way to do it is to have a member object and wrap the important functions. I do think there are situations where multiple inheritance can result in smaller and cleaner code than single inheritance. Also, I tend to think that the temptation to duplicate code may be higher in singly-inherited languages, and I'm very, very against duplicated code in general.


<hr>

Things I don't like about C++:

const handling -

I very much don't like the way that putting the same keyword before or after a reference or pointer declaration drastically changes the effect - I think it's confusing, and I almost wish they had separate keywords for it. Also, this may be due to an improper understanding of const-correctness in C++ (which is probably my biggest lack, and one that I'm going to rectify when I get time), but it seems I end up tripping over the const-correctness of reference types more often than I should. I need to look into this more, but I do wonder if it might be possible to handle const-correctness with less confusing syntax and an easier learning curve in a different language.

reference types -

I'd be using these all over the place instead of pointers if I could, but I keep stumbling into the const-correctness issues described above. I initially didn't think a reference to a base class was compatible with its derived classes, and it seems it is, but I don't know that I feel like it's easy to use them - it seems I stumble over const-correctness with that more often than I should, and can't use them effectively due to errors about "conversions losing qualifiers". Again, this may be due to an incomplete understanding, but I also feel it's more unwieldy than it needs to be.

functions as first-class-citizens-

I think this is one of the weaker areas of the language. Firstly, I'm not exactly sure if it's possible to declare a reference to a function instead of just a pointer. I think I declared one the other day, but I had no idea how to use it, or even if it was real (the compiler declared an error converting something I was trying to use to _cdecl&, but I didn't know what that meant). The syntax seems very convoluted - putting the variable name in the middle of these hasn't ever seemed to be a good idea to me. And member function pointers are just worse on all counts, and I *know* those can't be declared as reference types. Declaring something as void (CDerived::*)() is not intuitive to me at all, and that's by far the easiest kind of member function pointer.

generics -

Templates just don't cut it for me. I do like the fact that there's no runtime performance hit for a template, but I've found it easy to glitch slightly in a templated object declaration, if it's complex, and get error messages from the planet Blargon (though this could apply to some of the const, reference, or function-pointer things as well). I also don't like that MSVC, at least, won't syntax-check a templated class or function until it's actually used, though this is necessary due to potential interactions between the templated typename and the code. It seems like speedier generics at a more fundamental level in the language ought to be possible.

<hr>

Anyway, just some musings on my end. Comments encouraged.

[Andrew, Killer Bee]

I don't buy this since you can just learn the stuff in C++ that maps directly to Java and chug away. You can be productive in C++ without using all of its features; you don't need to fit it all in your head, but if you decide you need something more powerful, it's there.

I don't find this is the case myself, areas of language that I'm not familar with have a way of biting me in the ass, rather than waiting politely for me to properly utilise them.

This could actually just be me, but I find myself fighting against C++ as a language, whereas I don't find myself fighting Java the language (I find myself fighting against its libraries instead ).

(And I actually do have most of C++ in my head.)

Showoff .

As to the original subject matter - I don't think multiple inheritance is inherantly evil, but it does bring out the worst in people. It's easy to write code that breaks in subtle ways when you use it.

[SineSwiper]

One rule of thumb that makes it infinitely easier for me to understand const usage in C++ is to read all const declarations from right to left. So const int* pAnInt is a pointer to a constant integer, whereas int *const pAnInt is a constant pointer to an integer. The rule actually works for pointer-to-pointer, references and more complicated things too. Note that some conversions involving const are not allowed. E.g. though it seems intuitive, conversion from int** to const int** is actually not allowed, due to some (logical) reasons that I cannot recall now :P

And if the language was written by a linquist... (Okay, I'll shut up about the greatness of Perl.)

[Kupek]

And if the language was written by a linquist... (Okay, I'll shut up about the greatness of Perl.)

Perl circumevents this issue; it does not solve it. C++ is a statically typed language; all variables must have a type declaration, and all uses of that variable are type-checked at compile time. Perl is dynamically typed. Variables have no set type, and the Perl runtime will happily use them in whatever context they're put into.

Static type checking vs. dynamic typing is a personal preference. For any non-trivial project, I find static type checking saves me a lot of grief; if I get a compile time type error, I probably made a semantic error as well.

I use Perl for all of my scripting needs, and there dynamic typing works well because most of the work is string maniuplation. Perl silently and correctly converts integer values to strings. But for the work I do in C and C++, that would almost certainly be an error, and I want to be notified about it.

C++ and Perl are languages for different domains. Making cross-comparisions like this doesn't really work. Also, keep in mind that Perl is implemented in C. You can legitamitely think of Perl as a fancy interface to a bunch of C routines.

[SineSwiper]

Perl circumevents this issue; it does not solve it. C++ is a statically typed language; all variables must have a type declaration, and all uses of that variable are type-checked at compile time. Perl is dynamically typed. Variables have no set type, and the Perl runtime will happily use them in whatever context they're put into.

I'm not talking about high-level versus low-level between the two languages. I'm talking about how the language is designed in terms of readability. In that example silvon was talking about (hi, new guy!), where the pointer declarations would be read right-to-left, it should have been designed to be looked at left-to-right, so that anybody could read it and not be confused. There's a lot of that in C, especially in the way references and pointers are declared and assigned.

[Kupek]

I'm not talking about high-level versus low-level between the two languages.

Nor am I. Perl has references, which are conceptually the same as pointers. But it doesn't have to deal with the issue of <tt>const</tt> because it has no concept of static typing.