Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why C++ is vastly superior to C

warp.povusers.org

Post reply on HN
Print view View original

111–120 of 123 posts

Re: Why C++ is vastly superior to C

#111

Post by mojuba »

burgerbrain wrote: post #109
mojuba wrote: post #103

Earlier quoted context omitted.

Believe it or not, it was on a beefy workstation (I think the number of functions was tens of thousands actually). Of course I could have split the module or find some other solution, but the thing was, switching to C solved the problem. More importantly, I was able to switch on compiler optimizations.

I am not getting what makes this any different from any other very large build then.

The size of a single module with say 50,000 automatically generated functions 3 to 10 lines each. You want to try it? ;)

Re: Why C++ is vastly superior to C

#112

Post by anonymous246 »

implicit wrote: post #39
vixeria wrote: post #20

Earlier quoted context omitted.

What are some of these C++ features that interact in unpredictable ways? Just curious.

Implicit conversions come to mind. They don't need to interact with anything to be confusing. Consider this program: #include using std::cout; using std::endl; struct C { int x; C(int _x) : x(_x) {} operator bool() const { return 0 != x; } }; struct D { float f; D(float _f) : f(_f) {} operator bool() const { return 0.0f != f; } }; int main() { C c(9); D d(2.0f); if (c == d) { cout g++ 3.4.4 doesn't so much as warn th…

Yes, several people have already piled on. But if the compiler didn't say "Equal", then I would be claim it's confusing/inconsistent.

Are you saying that the funtion YOU wrote to convert C/D to a bool shouldn't be invoked when YOU are using C/D as booleans?

Re: Why C++ is vastly superior to C

#113

Post by anonymous246 »

ctz wrote: post #53

Counterpoint to the C++ fragment in "Error handling" section: void foo() { Matrix *a = new Matrix(1000, 1000); Matrix *b = new Matrix(1000, 1000); delete b; delete a; } Pretending exceptions solve error handling gets you a big fat zero. Look at boost: despite being written by C++ experts and held up as an excellent library (which it is!), it contains exception-unsafe portions. Why? Total exception safety is just as h…

I don't think it's because the Boost guys thought it "too hard". Having seen/used some of those libraries, I'm 100% sure they can handle the alleged "hardness".

C++ in general values performance over safety almost everywhere (just like C). That's probably why they made certain parts exception-unsafe.

Re: Why C++ is vastly superior to C

#114

Post by anonymous246 »

mklencke wrote: post #108
rbonvall wrote: post #102

Earlier quoted context omitted.

The problem with using void* pointers is that every access to an element costs one extra dereference operation. By using C++ templates, the compiler can create object code specifically compiled for each data type, without the need for pointers. (On the other hand, this can make C++ binaries much larger).

In this case, I'm not storing void pointers in the data structure, but I'm using the void pointer as a direct address into "elements". The memory layout is just a sequence of items of length elem_size. vector_push copies the item into that memory (and doubles the size of "elements" with realloc when necessary).

So you have a memcpy() call in vector_push? I wonder if that's less efficient than a straight-up assignment for small objects such as integers. The C++ equivalent can be further optimized during instruction generation by keeping things in the CPU registers as long as possible. In your C case, the int has to be written to memory before memcpy can load it into its buffer.

Re: Why C++ is vastly superior to C

#115

Post by huhtenberg »

tree_of_item wrote: post #38
jergosh wrote: post #34

This post boils down to "Take C, add support for OO, a crapload of new syntax, standard library that 10x as large and ta-da! you can find problems which have simpler solutions than in C." There's a great post by Linus Torvalds about C vs. C++ in the kernel. Some excerpts: "My point being, that C++ adds absolutely nothing interesting." "C++ is a mess. There's no design. It's just "add crud on top of C". And the crud i…

The author of the OP has a pretty well written rebuttal to everything Torvalds has said about C++: http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html

I looked at the rebuttal and I couldn't make past the part where he argues against this point - It's made more horrible by the fact that a lot of substandard programmers use it ... Even if the choice of C were to do nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C*

As someone who had substantial exposure to interviewing and hiring C and C++ programmers to add to a team of 250 it was bloody obvious that a lot of pure C++ programmers are the pompous know-it-alls who think they know C++, while C people are those with far more realistic self-assessment who actually do know the language. Linus got it absolutely right.

Re: Why C++ is vastly superior to C

#116

Post by edanm »

Interesting article. One major problem - it doesn't seem like the OP has ever actually used C for real world code. I say this as someone with a few years of experience with C (and a few years of C++).

None of the examples he showed of C code look like they were actually written by a C programmer. A lot of use of "goto"'s, for one thing. It looks like he tried reimplementing C++ in C.

Actually, that's exactly what he decided must be done: " If the C version wishes to match the C++ version in speed and memory usage, it will have to basically simulate the C++ implementation using a struct and functions which handle objects of that struct type (including things like initialization and destruction)."

So obviously, if you set out from the start with the assumption that to use a language, you have to reimplement another language in it, then of course you'll come to the conclusion that you should just use the other language. But that's not a conclusion that C programmers would be comfortable with.

By the way, as just one nitpick, I'd probably implement that Matrix with "void *" pointers, letting me substitute any struct I want in there later. Just my way of solving the "impossible to solve" problem he presents at the end.

Re: Why C++ is vastly superior to C

#117

Post by azth »

thedigitalengel wrote: post #54
jerf wrote: post #24

Earlier quoted context omitted.

http://yosefk.com/c++fqa/defective.html isn't strictly limited to answering that question, but it touches on it a lot. I know I'm flinging links around a lot here, but, well, this is all well-covered ground.

Most of the points mentioned in that particular link pertains why both C and C++ are inferior to languages like LISP and Python which have garbage collectors, weak type system and the like. The bitching about bad compile time errors has been mostly fixed in clang. Then only _inconsistency_ (in the correct sense of the term) in C++ I am aware of is the unordered initialization of static objects. So if you have "class…

I guess that's why the Google C++ style guide lists using static non-POD types as a no-no. :)

Re: Why C++ is vastly superior to C

#118

Post by mklencke »

anonymous246 wrote: post #114
mklencke wrote: post #108

Earlier quoted context omitted.

In this case, I'm not storing void pointers in the data structure, but I'm using the void pointer as a direct address into "elements". The memory layout is just a sequence of items of length elem_size. vector_push copies the item into that memory (and doubles the size of "elements" with realloc when necessary).

So you have a memcpy() call in vector_push? I wonder if that's less efficient than a straight-up assignment for small objects such as integers. The C++ equivalent can be further optimized during instruction generation by keeping things in the CPU registers as long as possible. In your C case, the int has to be written to memory before memcpy can load it into its buffer.

True, but that can be overcome by another function that just gives you an address to put a new item. You would say, for example:

  *(int *)vector_expand(v) = 2;

Re: Why C++ is vastly superior to C

#119

Post by blacksmythe »

Many people believe that C++ has useful features that improve the ability of the average programmer to write application programs. One problem is that different companies use different subsets. (The question of which language the Linux kernel should be written in is of limited interest.)

We could name a restricted subset of C++ as C+-. Many high quality and well-tested development tools for C+- already exist (the C++ tools). Now the problem remains of standardizing C+-. The most logical C+- variant to standardize on is the C++ subset used by the largest group of people, presumably the version defined by Google: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...

Now the question becomes is it easier for average programmers to build application programs using C or C+-? Using C+- or C? These are perhaps more useful questions than the long running C vs C++ debate.

Re: Why C++ is vastly superior to C

#120

Post by anonymous246 »

mklencke wrote: post #118
anonymous246 wrote: post #114

Earlier quoted context omitted.

So you have a memcpy() call in vector_push? I wonder if that's less efficient than a straight-up assignment for small objects such as integers. The C++ equivalent can be further optimized during instruction generation by keeping things in the CPU registers as long as possible. In your C case, the int has to be written to memory before memcpy can load it into its buffer.

True, but that can be overcome by another function that just gives you an address to put a new item. You would say, for example: *(int *)vector_expand(v) = 2;

This is a super-unclean API, but that's just IMHO.

We'll just have to agree to disagree that what you've shown above is an acceptable API for a vector module.

Post reply on HN