Comments on: C and C++ are not the same language.

By: COdE fr3@K

COdE fr3@K — Sun, 24 May 2009 12:44:23 +0000

Observer Done Differently…

In a recent post of Scott Wheeler’s (C and C++ are not the same language), he talked about differences between C and C++, and applications of different programming languages (C, C++, Java, Ruby) in his company.
In the post, Wheeler implemented observe…

By: Bojan

Bojan — Fri, 22 May 2009 10:23:45 +0000

> @Scott referring to @Bojan, And memory management, ie garbage collection.

The big bad wolf.

You have to have a bit of perspective on this subject. E.g. more often than not in my line of work manual memory management (optimized for particular usage pattern) has given me tremendous performance boost and predictable heap growth figures.
Yes, writing everyday enterprisy frontends and whatnot benefits greatly from automated memory management, no argument there. Fire-and-forget is usefull.
But I like to have a choice. Using a subset of boost libraries with a bit of RAII can significantly ease the pain of fiddling with memory management in C++, although it still requires a lot of discipline (but then again, it’s not like Java or any other VM out there will let you get away with reckless coding).

By: Joseph Garvin

Joseph Garvin — Fri, 22 May 2009 04:19:43 +0000

In addition to John Haugeland’s comments, I would add that anywhere a C programmer uses a function pointer, instead of doing something wildly different a C++ programmer may simply use a boost::function object. What you are calling “modern” C++ is not actually modern C++. I suggest reading the book ironically titled, “Modern C++”. Amazon link: http://www.amazon.com/Modern-Design-Programming-Patterns-Depth/dp/0201704315

By: Walter

Walter — Thu, 21 May 2009 19:46:20 +0000

Nobody would write the Java iterator like that. This is more idiomatic:

for(Listener listener : listeners)
{
listener.activate();
}

There’s no need to have a concrete FooListener class, nor a separate class to run it. Just put this in Foomatic.java and get rid of Callback.java altogether:

/* … */
public static void main(String[] args)
{
Listener listener = new Listener()
{
public void activate()
{ System.out.println(“Whoopee.”);
}
}

Foomatic foomatic = new Foomatic();
foomatic.addListener(listener);
foomatic.addListener(listener);
foomatic.activate();
}

By: Scott Wheeler

Scott Wheeler — Thu, 21 May 2009 17:29:26 +0000

@Ben — the listeners in the C example aren’t created by malloc — they’re just pointers to functions, so they don’t need to be freed. The thing being freed there is the array of pointers to those functions, which is created with the realloc call, and there, in fact, one free suffices.

By: Brad

Brad — Thu, 21 May 2009 16:07:42 +0000

Very nice article. I have to agree with your choice of C++. I came to the same decision a few years ago. I’m in the boost camp BTW At the same time, I can understand why folks dislike C++. It’s powerful and complex and intimidating and thus easy to screw-up at times. I encourage folks to try it and only use the parts they need (it’s a big language) to build and ship a product. It’s been my experience that once they do that, they love it too.

By: Ben

Ben — Thu, 21 May 2009 15:55:35 +0000

I mentioned this on HN, but I just wanted to support what you said about memory management being more of a hassle in C. Case in point, either you only freed one of your listeners in your C code (memory leak) or I’m still a dufus with C memory management.

Interesting post though. I’m reading C, Interfaces and Implementation and I find it fascinating to see C as C programmers C it, instead of someone more from C++ land.

By: Kman

Kman — Thu, 21 May 2009 14:26:28 +0000

given that a c++ compiler supports the c99 keyword “restrict” and that a program was written with it in mind, 100% of the time c++ will be faster than anything running on a VM. c++ compilers have a hard time optimizing pointer related logic, namely aliasing (stores affecting loads), but with “restrict” this is no longer an issue. of course if one is really after performance, i’m sure most compilers support their own extension to c++, such as __declspec() in msvc++. with these expensions, the generated assembly will be very close to what one might hand-write.

By: Zwieback

Zwieback — Thu, 21 May 2009 13:50:47 +0000

One thing is undeniable: of the popular languages C++ covers the most ground. I can write anything from device drivers to Enterprise apps to CAD programs in C++. Is it the best choice for any one of these? Maybe not but it comes close enough that it’s still a good choice for a first language.

By: Scott Wheeler

Scott Wheeler — Thu, 21 May 2009 12:53:08 +0000

@Peter

“C++ is slower” — not inherently, and this is naturally compiler dependent. But when writing high-performance C++, it does help to know how the features are implemented (e.g. what they’d look like in C) when using them. Note the benchmark here where C++ does the same or better than C in almost every category.

“RTTI overhead” — hasn’t really been a problem since GCC 2.95. Post 2.95 it’s been placed in a separate section of the binary and of course you can disable RTTI with compilation flags if you really care.

“C really isn’t either anymore. VM…” — that’s rarely the case. Occasionally JIT compilers will oust compiled languages, but not often. In benchmarks that we did internally comparing the numerics core of our recommendations engine in Java vs. C++, C++ was 2.5x faster.