Live data from Hacker News

Comparing C and C++ usage and performance with a real world project

nibblestew.blogspot.com

111–120 of 140 posts

Re: Comparing C and C++ usage and performance with a real world project

#111
post #9

according to dan saks, who apparently to some people is famous c++ is faster than c (well in the test setup he describes below) https://accu.org/content/conf2015/DanSaks-Embedded%20Program... Language Design Implementation Relative Performance either any inline 1 (fastest) C++ polystate non-inline 1.56 x fastest C++ bundled non-inline 1.65 x fastest C polystate non-inline 1.70 x fastest C bundled non-inline 1.79 x fa…

Over in D-land we've embraced the concept of using D as a "better C" :-) https://dlang.org/blog/2017/08/23/d-as-a-better-c/ This is not in the sense of tossing away C coded programs wholesale and rewriting it in D, but incrementally using D here and there for parts of a C program. That way, you've always got a working, usable program.

    if (existsCoffee)
        writeln("Drink coffee");
http://ddili.org/ders/d.en/if.html Sad that you adopted one of C's worst features. Why? Can you get rid of it and mandate the bracing every block?

Re: Comparing C and C++ usage and performance with a real world project

#112
post #93

It is nonsensical to consider memory leaks as reported by Valgrind on a program that uses Glib. It allocates and builds a whole context system and never frees it regularly, which confuses Valgrind. I am pretty certain almost all 'leaks' come from there. libglib should be put in Valgrind suppression file. It was a very bad choice to choose a program based on Glib for this kind of experiment.

I think what you have said here sums up the problem quite concisely. They might as well add core-foundation, qt-core and stllib based executables to the test for 'c' vs 'c++' to give a better cross section.

Re: Comparing C and C++ usage and performance with a real world project

#113

Earlier quoted context omitted.

Unfortunately it seems that the majority of C++ code out there is like that. It could be said that C++ makes it far easier than C to introduce unnecessary abstraction and indirection, without realising the true costs. I've noticed that using a lower-level language, where abstractions have to be built explicitly, tends to cause one to rethink the problem and often come up with an even simpler and more efficient soluti…

I've only written patches of C++ in a couple of tiny projects, and something I've had trouble with in both cases is trying to figure out the somewhat objectively "right" or "best" way to write it. It's not a language I'm fluent in (the vast majority of my experience has been in Objective-C and Swift) so I find myself spending a good chunk of time doing research trying to figure out what the most widely accepted/corre…

I would read books like Scott Meyers' Effective Modern C++, watch cppcon talks. There's a lot of very high quality C++ content out there these days.

Generally there's a lot of emphasis on RAII, clear ownership semantics, leveraging more of the standard library as its grown, using lambdas, avoiding shared mutable state, judicious but not excessive use of inheritance and in particular avoiding implementation inheritane, encapsulation.

It's not so much a middle ground in the sense you are thinking. The people I'm talking about don't advocate developers, particularly non expert, going crazy with templates. People do that on their own.

Hope that helps.

Re: Comparing C and C++ usage and performance with a real world project

#114
post #50

Earlier quoted context omitted.

"Using C++" does not mean "Using lots and lots of features of C++ just because". That some people do that is hardly a criticism of C++, more of the lousy programmers that write software like that.

Unfortunately it seems that the majority of C++ code out there is like that. It could be said that C++ makes it far easier than C to introduce unnecessary abstraction and indirection, without realising the true costs. I've noticed that using a lower-level language, where abstractions have to be built explicitly, tends to cause one to rethink the problem and often come up with an even simpler and more efficient soluti…

> Unfortunately it seems that the majority of C++ code out there is like that. It could be said that C++ makes it far easier than C to introduce unnecessary abstraction and indirection, without realising the true costs.

Citation needed? Better developers are more aware, in any language. There are some cases where idiomatic C++ may introduce more indirection over C (though I can't think of any); there are plenty where idiomatic C introduces more indirection than C++. However, with a little more effort and awareness, the faster and more maintainable solution is always accessible.

> I've noticed that using a lower-level language, where abstractions have to be built explicitly, tends to cause one to rethink the problem and often come up with an even simpler and more efficient solution, by approaching it from another direction which using a higher-level language may not even allow.

Having lots of developers, re-implement many things, mostly just results in much more buggy code. Getting things exactly right is hard. Having a bigger standard library and safer abstractions is a huge edge.

I don't think your anecdote has anything to do with C vs C++. I think basically some negative experiences with so-so C++ devs has colored your thinking rather than technical reasons.

Re: Comparing C and C++ usage and performance with a real world project

#115

Earlier quoted context omitted.

Unfortunately it seems that the majority of C++ code out there is like that. It could be said that C++ makes it far easier than C to introduce unnecessary abstraction and indirection, without realising the true costs. I've noticed that using a lower-level language, where abstractions have to be built explicitly, tends to cause one to rethink the problem and often come up with an even simpler and more efficient soluti…

I've only written patches of C++ in a couple of tiny projects, and something I've had trouble with in both cases is trying to figure out the somewhat objectively "right" or "best" way to write it. It's not a language I'm fluent in (the vast majority of my experience has been in Objective-C and Swift) so I find myself spending a good chunk of time doing research trying to figure out what the most widely accepted/corre…

The right way is, to speak in philosophical terms, totally a pragmatic choice. If nothing in C++ is working for you, don't use it. If a really obscure technology is making you go really fast, use it.

The one and only thing that muddies this picture is other people. Once you are collaborating on a program(whether on the same team, through end-user code, or through a library or API call) all your tricks, preferences and conventions are subject to other people's inept groping and misunderstanding. And that is where you get into standardized best practices. They are basically guaranteed to not actually be the best practice, but they're the one you can compromise on.

Re: Comparing C and C++ usage and performance with a real world project

#116

Earlier quoted context omitted.

You can get 90% of that benefit by using snippets in your favorite editor. I guess you could consider that "code generation", but "generative programming" means, to me, "check in the specification, not the production code".

You're assuming gnerative programming is used to completely replace direct programming. This doesn't have to be the case. It could also be used merely in an assistive role to supplement the ability to write code.

I'm not. That's what I'm referring to as "snippets", though other forms of scaffolding do apply. If your position is that people should use more sophisticated editing/authoring tools on a regular basis, that's not that controversial a statement.

I was just saying that full-blown code generation isn't merely writing in the same language but adopting a DSL as well, so we're not strictly comparing languages at that point.

Re: Comparing C and C++ usage and performance with a real world project

#117
post #111

Earlier quoted context omitted.

Over in D-land we've embraced the concept of using D as a "better C" :-) https://dlang.org/blog/2017/08/23/d-as-a-better-c/ This is not in the sense of tossing away C coded programs wholesale and rewriting it in D, but incrementally using D here and there for parts of a C program. That way, you've always got a working, usable program.

if (existsCoffee) writeln("Drink coffee"); http://ddili.org/ders/d.en/if.html Sad that you adopted one of C's worst features. Why? Can you get rid of it and mandate the bracing every block?

My take on C's biggest mistake:

https://digitalmars.com/articles/b44.html

Re: Comparing C and C++ usage and performance with a real world project

#118

Earlier quoted context omitted.

You're assuming gnerative programming is used to completely replace direct programming. This doesn't have to be the case. It could also be used merely in an assistive role to supplement the ability to write code.

I'm not. That's what I'm referring to as "snippets", though other forms of scaffolding do apply. If your position is that people should use more sophisticated editing/authoring tools on a regular basis, that's not that controversial a statement. I was just saying that full-blown code generation isn't merely writing in the same language but adopting a DSL as well, so we're not strictly comparing languages at that poin…

Right. Code generation has typically been associated with DSLs.

Here's one way it could be done simply. Let's say you wanted to automate the process of memory allocation and deallocation. You would need a way to describe to the code generator the mepory requirments of your structure. For that you would need a description outside of C. But that description could be embedded into the comments of your code and your code generator be designed to parse those comments to determine what needed to be done.

Knuth also came up with the idea of Literate Programming in which the description of a program is embedded as Latex in the code. This could work in a similar way. So, while you would use a DSL, the description would be inline with your code so the authoring process would be integrated and not 2-stream.

Re: Comparing C and C++ usage and performance with a real world project

#119
post #53

Earlier quoted context omitted.

That is absolutely false. C++ member functions are zero-cost abstractions, i.e. they have the same cost as any other function call. Member functions are _not_ function pointers that reside inside the struct. They don't take up space, they don't need dereferencing to call. They are just "syntatic sugar" to group functions more logically.

Please check your facts. C++ member functions are not as simple as function pointers inside structs.

You're right, they are simpler in fact. They have the same cost as free-standing functions.

Re: Comparing C and C++ usage and performance with a real world project

#120

Earlier quoted context omitted.

Please check your facts. C++ member functions are not as simple as function pointers inside structs.

You're right, they are simpler in fact. They have the same cost as free-standing functions.

Right. As is speech -- free.
Post reply on HN