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

101–110 of 123 posts

Re: Why C++ is vastly superior to C

#101

Post by Spyro7 »

mojuba wrote: post #93
Spyro7 wrote: post #80

Earlier quoted context omitted.

"our judgement of what's good or bad in general shouldn't really be a matter of taste and preference. Are we an engineering discipline or what?" You know what. It's a funny thing, but as I was typing my response to your original post, I actually said this exact same thing to myself, and I started to think. It would be incredible if there was some non-emotional, non-touchy-feely way to get at the value of one language…

Generally agreed, except: let's be careful with the notion of simplicity. I used the word "simplistic" which bears some negative flavor (pointlessly simple?). Lisp is relatively simple and yet powerful, i.e. it is not simplistic. C++ is incredibly complex (dare to write a full blown modern C++ compiler?) and powerful. Not surprisingly though, the simplicity of Lisp doesn't make it easier to grasp. From this point of…

mojuba, I have to thank you for that link. I confess that I had never read that document prior to today. The thing that I like most about it is that he leaves it open ended.

He doesn't pretend to have all of the answers but rather invites the reader to embark on a thought exercise. Ignoring the question of comparing languages, that is an excellent example of how to write concerning this type of topic.

On comparing languages, I have to say that comparing languages based on power does make sense - with power defined as programmer productivity. From this perspective, I can understand your view on Java.

But is it the language itself that is to blame or the spaghetti code that all too often results from inexperienced users? I recall that the JRuby team has done some interesting things within the limitations of the Java language.

Note: To those who down-voted the original comment, I did not think that the down-voting is the most optimum solution for when you have a different perspective on an issue. Wouldn't it be better for everyone to chime into the discussion and increase everyone's knowledge with your perspective on the issue? This type of thing is why I have to ignore votes and just try to learn.

Re: Why C++ is vastly superior to C

#102

Post by rbonvall »

mklencke wrote: post #59

The RAII benefits are definitely there and STL containers are pretty awesome, but you can still create generic containers in C by using void pointers. For example, a simple vector API: typedef struct { void *elements; int elem_size; int n; } Vector; Vector *vector_new(int elem_size); void vector_free(Vector *v); void vector_push(Vector *v, void *elem); void vector_pop(Vector *v); int vector_size(Vector *v); void *vec…

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).

Re: Why C++ is vastly superior to C

#103

Post by mojuba »

burgerbrain wrote: post #98
mojuba wrote: post #96

Earlier quoted context omitted.

By memory allocation I meant memory usage by the compiler itself. Plus libstdc++ which is not easy to get rid of, and if you do dump it, you at least cut off C++ exceptions. I once switched from C++ to C because g++ just couldn't handle the module even having all optimizations turned off. That was a huge automatically generated C module with thousands of functions. A rather rare situation but showed very clearly that…

Compiler speed/memory use are generally entirely irrelevant with embedded stuff. If you're natively building on your tiny target instead of cross compiling from your beefy workstation, you're doing it wrong. No, for the very real issues with C++ in small installations, you will have to look at the language itself.

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.

Re: Why C++ is vastly superior to C

#104

Post by dfox »

burgerbrain wrote: post #85
pinoyboy82 wrote: post #65

Earlier quoted context omitted.

Generally, people on Linux will be compiling using Makefiles, so just use make -j to speed it up.

Using -j with C++ builds will always still be significantly slower than using -j with C builds. Also, I believe the rule of thumb for the -j argument tends to be 2 times your number of cores. A surprising amount of build time is often spent on disk I/O, so you see worthwhile gains for quite a while running more jobs than cores.

GNU make also has -l (load limit) and make -j -l seems like better idea and in my experience works better. But still I tend to just run make -j without any limit which on modern systems works well enough.

Re: Why C++ is vastly superior to C

#105

Post by simoncion »

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…

Counterpoint to your counterpoint:

  void foo()
  {
  	typedef std::auto_ptr matAP;
  	matAP a(new Matrix(1000, 1000));
  	matAP b(new Matrix(1000, 1000));
  }

Re: Why C++ is vastly superior to C

#108

Post by mklencke »

rbonvall wrote: post #102
mklencke wrote: post #59

The RAII benefits are definitely there and STL containers are pretty awesome, but you can still create generic containers in C by using void pointers. For example, a simple vector API: typedef struct { void *elements; int elem_size; int n; } Vector; Vector *vector_new(int elem_size); void vector_free(Vector *v); void vector_push(Vector *v, void *elem); void vector_pop(Vector *v); int vector_size(Vector *v); void *vec…

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).

Re: Why C++ is vastly superior to C

#109

Post by burgerbrain »

mojuba wrote: post #103
burgerbrain wrote: post #98

Earlier quoted context omitted.

Compiler speed/memory use are generally entirely irrelevant with embedded stuff. If you're natively building on your tiny target instead of cross compiling from your beefy workstation, you're doing it wrong. No, for the very real issues with C++ in small installations, you will have to look at the language itself.

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.

Re: Why C++ is vastly superior to C

#110

Post by X-Istence »

CJefferson wrote: post #75
implicit wrote: post #39

Earlier quoted context omitted.

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…

In C++0x you can make those operator bool() explicit. Shouldn't have been there in the first place, and you still have to learn the difference between explicit and non-explicit operators, but at least now there is a way of making things behave.

Even if they were explicit it wouldn't have "solved" his issue. Since he is using them in an if statement the C++ compiler would have considered that an explicit conversion anyway in C++0x mode.

I don't have a C++0x compiler handy, or I would test it, but I do believe explicit is only meant for cases such as this:

a + 1;

where a has a bool() operator that returns 1 or 0, in the old mode if there was no way to get a to be a number it would look at the operator bool() see that it returns a number and use that. Using explicit on the bool() operator would make that illegal and most likely a compiler error.

Post reply on HN