Reason #84883 I hate VB.net

morbiuswilters

@morbiuswilters said:
I have to disagree here. Smalltalk precedes C++, as do several other good OO languages. They weren't fast, usually, so I guess C++ was good there. I wouldn't consider C++ a high-performance language. It can be pretty good, but dynamic languages that run on a good VM (like the CLR) can kick ass. If you really need performance, C is still the way to go.
Why do you consider the speed of C and C++ to be different? C++ with classes, but without the use of virtual functions is effectively C as the class vtables will be full of direct function pointers. And polymorphism isn't going to introduce too much overhead scanning down the hierarchy to find the actual function.

Isn't C++ without virtual functions a bit cripled? I wouldn't consider shedding core OO features in the name of performance all that good of an idea. Then there's the matter of optimization--C is simple enough that compilers seem able to optimize more. C++ strings are slower than C strings (although safer) and in fact usually on par or even slower than doing string processing in perl. C++ has some wonky I/O performance problems on Linux with the way streams do buffering and handle the lower-level C API--it's possible to work around, but I find a lot of devs don't bother. Finally, C++ development (at least on Unix) never seems very performance-oriented (see MySQL for a rare example to the contrary); devs tend to do lots of abstraction, use getters/setters, rely on automatic memory management, etc. Ultimately, they focus on abstraction over performance (which is good) except that many modern "scripting" languages with good JIT VMs can meet or exceed C++ performance without the headaches of templates, memory management, painful debugging, etc.

I'm not really interested in starting a C++ flamewar, I just don't care for the language and in my experience C++ code on Unix is rarely as speedy as C.

tgape

@morbiuswilters said:

@OzPeter said:
Why do you consider the speed of C and C++ to be different? C++ with classes, but without the use of virtual functions is effectively C as the class vtables will be full of direct function pointers. And polymorphism isn't going to introduce too much overhead scanning down the hierarchy to find the actual function.
Isn't C++ without virtual functions a bit cripled? I wouldn't consider shedding core OO features in the name of performance all that good of an idea. Then there's the matter of optimization--C is simple enough that compilers seem able to optimize more. C++ strings are slower than C strings (although safer) and in fact usually on par or even slower than doing string processing in perl. C++ has some wonky I/O performance problems on Linux with the way streams do buffering and handle the lower-level C API--it's possible to work around, but I find a lot of devs don't bother. Finally, C++ development (at least on Unix) never seems very performance-oriented (see MySQL for a rare example to the contrary); devs tend to do lots of abstraction, use getters/setters, rely on automatic memory management, etc. Ultimately, they focus on abstraction over performance (which is good) except that many modern "scripting" languages with good JIT VMs can meet or exceed C++ performance without the headaches of templates, memory management, painful debugging, etc.

I'm not really interested in starting a C++ flamewar, I just don't care for the language and in my experience C++ code on Unix is rarely as speedy as C.

I think you're confusing the language with the programmers. One can write C++ code that gets better performance than the reasonable C equivalent. The fact that the vast majority of C++ programmers do not is irrelevant.

For what it's worth, I have encountered the situation where my performance-critical section benefited more from C++'s OO than from C's procedural exactly one time. I know because I wrote it first in C - a very nasty bit of C, involving many function pointers and other crud. (That version had a ~20% performance improvement from the switch-happy version.) The C++ would've been a win for legibility reasons alone; I actually considered the ~2% performance improvement a lucky bonus.

I've also seen a C++ strings class that had improved performance versus C's strings in the general case, rather than decreased performance. The big secret was it simply kept track of the length and allocation size, but otherwise didn't interfere with the basic character array access. (Well, it did overload pretty much every standard C character array function, but only so that they could access the character array directly.) Admittedly, it only had improved performance when used by someone who was performance clueless; the rest of us tend to avoid needless calls to strlen() and similar routines, so the fact that strlen and strcat didn't need to find the end of the string didn't help much.

As far as head-to-head performance goes, I've generally found identical performance between C code compiled with gcc and C code compiled with g++...

Now, in general terms, most of the C++ code I've encountered is dog slow. The reason for most of the C++ code I've seen is pretty obvious: getter methods (in class A) which merely call other getter methods (in class B, A's super), which call getter methods (in class C, B's super) that simply return a private value. When you have that kind of mentality, decent performance is impossible. (For what it's worth, in the specific application I'm thinking of, I removed the getter methods which simply called getter methods in a super class, and replaced their calls with calls to the super-class's getters, as well as the same change for the setters and it worked just fine - and had a noticeable performance boost. It was still slow, because there was an awful lot of excessive method calls that weren't so simple to fix.)

@tgape said:

The reason for most of the C++ code I've seen is pretty obvious: getter methods (in class A) which merely call other getter methods (in class B, A's super), which call getter methods (in class C, B's super) that simply return a private value. When you have that kind of mentality, decent performance is impossible.

Inline?

Edit: Oh wait, I read that better. Overriding a super class method to just call that same method is pretty retarded; but you're not saying if it's calling the same getter or a different getter.

The reason C++ is not as fast as C is because C++ is so complex that the C++ compilers are not as good at optimization as the C compilers.

HypocriteWorld

Go use Haskell, it's got all the nice syntax you want

-- C-like syntax --
do {
    x <- getX;
    y <- getY;
    return (x+y);
}
-- or Python-like syntax --
do
    x <- getX
    y <- getY
    return (x+y)

and the pure vs. action distinction

do
    x <- runThisParameterlessAction
    -- which is very different syntactically from --
    let y = getSomePropertyOf z
    return (x+y)

Of course, the common way to write the first block of code is actually

liftM2 (+) getX getY

Anyways, syntax is silly.

Ilya_Ehrenburg

@HypocriteWorld said:

Of course, the common way to write the first block of code is actually
liftM2 (+) getX getY
Anyways, syntax is silly.

I was under the impression it would nowadays be written

(+) <$> getX <*> getY

by most.

steenbergh

Áh, remember the days back when this thread was about Microsoft VB.Net?

bstorer

@steenbergh said:

Microsoft VB.Net?

Never heard of it. Does it have parens?

tgape

@Zecc said:

@tgape said:
The reason for most of the C++ code I've seen is pretty obvious: getter methods (in class A) which merely call other getter methods (in class B, A's super), which call getter methods (in class C, B's super) that simply return a private value. When you have that kind of mentality, decent performance is impossible.
Inline?
Edit: Oh wait, I read that better. Overriding a super class method to just call that same method is pretty retarded; but you're not saying if it's calling the same getter or a different getter.

Your sanity confused you. Fortunately, I see your presence of mind straightened you out.

Yes, the code was something along the lines of (forgive my syntax; I've not done C++ in quite some time - since the last time I gave a C++ example here, IIRC.)

int ClassC::getUID() {
   return self.UID;
}

int ClassB::getIDnumber() {
   return self.getUID();
}

long ClassA::UniqueNumber() {
   return (short)self.getIDnumber();
}

Yes, I do seem to recall the outer-most function returned a different type, and explicitly cast to yet another type on the return. I don't remember the types involved, however. None of these were declared as inline, so the compiler couldn't optimize them away.

My first round fix simply defined them all as inline, moving their definition into the header files, but then I went for the added clarity of restoring the names of the innermost class' methods, as the further removed from the original class, the worse the names got. That doing that actually fixed a few bugs, due to crap such as inappropriate casting, was a bonus. That it enabled the fixing of a few bugs because it made it more clear the wrong method was being called was kind of the point of the legibility enhancement.

Note: my code corrections were not accepted by the package maintainer; he claimed I didn't understand OOP. Since it was just a silly open source game, I wasn't really concerned.