Deep C and C++ (2011) • Hacker News Board

Re: Deep C and C++ (2011)

#231

Post by pandaman » Thu, Oct 24, 2013, 4:41 PM UTC

cousin_it wrote: post #229

pandaman wrote: post #228

Earlier quoted context omitted.

Sure, generic functions are awesome when you don't care about performance. This is why C++ does not have them. If you knew nothing about C++ and somebody told you "here, we have a language with zero run-time overhead, can you guess if we managed to implement generic functions?" what would you say? Function templates are not generic functions. Same as template classes are not types. They play really well with the rest…

I guess it's a matter of taste. Almost every time I get puzzled by some design decision in C++, it makes sense at first but then falls apart on closer inspection. The most recent example amused me so much that I wrote a blog post about it: http://slepnev.blogspot.ch/2013/07/printing-int-in-c.html . My experience with Haskell so far has been the opposite, design decisions make no sense at first but then turn out to be…

C++ library is not something that is supposed to be very useful, it's something that is supposed to be available. I, for one, never used that library in my 15 years of professional programming.

Even though the library is covered by the same standard as the language it's not a part of the language and, in practice, is not even available all the time.

Re: Deep C and C++ (2011)

#232

Post by pandaman » Thu, Oct 24, 2013, 4:49 PM UTC

pkolaczk wrote: post #230

pandaman wrote: post #228

Earlier quoted context omitted.

Sure, generic functions are awesome when you don't care about performance. This is why C++ does not have them. If you knew nothing about C++ and somebody told you "here, we have a language with zero run-time overhead, can you guess if we managed to implement generic functions?" what would you say? Function templates are not generic functions. Same as template classes are not types. They play really well with the rest…

Generic functions like in Java/C# can be implemented efficiently and with zero overhead. There is nothing that prevents a JIT compiler to generate several versions of the code optimised for different types at runtime, exactly like C++ does at compile-time. Some VMs already do that to some extent in order e.g. to better inline calls for the generic argument. Still, those optimisations are in their infancy, but the sit…

How do you figure out the types at run time with zero overhead? I guess we have different concept of "zero".

As for the price of my skills - my paycheck told me that. And sure, it could be low demand (there are vacancies in my field, that had been open for years, but I don't really know what kind of demand there is for Python, could be decades for all I care). I am just happy for my compensation and if others have more expensive skills - I am happy for them too :)

Re: Deep C and C++ (2011)

#233

Post by pkolaczk » Thu, Oct 24, 2013, 4:52 PM UTC

cousin_it wrote: post #229

pandaman wrote: post #228

Earlier quoted context omitted.

Sure, generic functions are awesome when you don't care about performance. This is why C++ does not have them. If you knew nothing about C++ and somebody told you "here, we have a language with zero run-time overhead, can you guess if we managed to implement generic functions?" what would you say? Function templates are not generic functions. Same as template classes are not types. They play really well with the rest…

I guess it's a matter of taste. Almost every time I get puzzled by some design decision in C++, it makes sense at first but then falls apart on closer inspection. The most recent example amused me so much that I wrote a blog post about it: http://slepnev.blogspot.ch/2013/07/printing-int-in-c.html . My experience with Haskell so far has been the opposite, design decisions make no sense at first but then turn out to be…

@pandaman: Just a minor nitpick about the statement that C++ library is not a part of the language: How come 'new' (builtin language operator, and reserverd keyword) can throw 'std::bad_alloc' (library construct) then? ;)

Re: Deep C and C++ (2011)

#234

Post by pkolaczk » Thu, Oct 24, 2013, 5:04 PM UTC

pkolaczk wrote: post #230

pandaman wrote: post #228

Earlier quoted context omitted.

Sure, generic functions are awesome when you don't care about performance. This is why C++ does not have them. If you knew nothing about C++ and somebody told you "here, we have a language with zero run-time overhead, can you guess if we managed to implement generic functions?" what would you say? Function templates are not generic functions. Same as template classes are not types. They play really well with the rest…

Generic functions like in Java/C# can be implemented efficiently and with zero overhead. There is nothing that prevents a JIT compiler to generate several versions of the code optimised for different types at runtime, exactly like C++ does at compile-time. Some VMs already do that to some extent in order e.g. to better inline calls for the generic argument. Still, those optimisations are in their infancy, but the sit…

Nothing is truly zero overhead. C++ templates are neither, because they create some overhead in code size which is obviously non-free (both space-wise and time-wise). Zero-overhead for me = optimized to the point that noone can notice. There is no problem for a VM to generate 10 versions of a tight loop, every one optimised for particular type, with a switch for the type right before entering the loop, or the whole method, or even a whole call-tree.

Re: Deep C and C++ (2011)

#235

Post by pandaman » Thu, Oct 24, 2013, 5:28 PM UTC

pkolaczk wrote: post #233

cousin_it wrote: post #229

Earlier quoted context omitted.

I guess it's a matter of taste. Almost every time I get puzzled by some design decision in C++, it makes sense at first but then falls apart on closer inspection. The most recent example amused me so much that I wrote a blog post about it: http://slepnev.blogspot.ch/2013/07/printing-int-in-c.html . My experience with Haskell so far has been the opposite, design decisions make no sense at first but then turn out to be…

@pandaman: Just a minor nitpick about the statement that C++ library is not a part of the language: How come 'new' (builtin language operator, and reserverd keyword) can throw 'std::bad_alloc' (library construct) then? ;)

New itself does not throw, the allocation function does. Nobody makes you use the library allocation functions.

A better nitpick would be dynamic_cast throwing under some conditions. But then, how does it make iostreams the part of the language? There is just a typedef in the std namespace that aliases the type for some optional, compiler specific, data.

Re: Deep C and C++ (2011)

#236

Post by pkolaczk » Thu, Oct 24, 2013, 5:33 PM UTC

cousin_it wrote: post #229

pandaman wrote: post #228

Earlier quoted context omitted.

Sure, generic functions are awesome when you don't care about performance. This is why C++ does not have them. If you knew nothing about C++ and somebody told you "here, we have a language with zero run-time overhead, can you guess if we managed to implement generic functions?" what would you say? Function templates are not generic functions. Same as template classes are not types. They play really well with the rest…

I guess it's a matter of taste. Almost every time I get puzzled by some design decision in C++, it makes sense at first but then falls apart on closer inspection. The most recent example amused me so much that I wrote a blog post about it: http://slepnev.blogspot.ch/2013/07/printing-int-in-c.html . My experience with Haskell so far has been the opposite, design decisions make no sense at first but then turn out to be…

@cousin_it: I have exactly the same feeling about C++ and Haskell. Another feature of this kind is inability to do virtual calls from constructors / destructors. Sure, the explanation makes perfect sense and leaves you with a feeling that C++ got it right and the rest of the world got it wrong. C++ protects you from accessing not-fully initialized object, awesome isn't it? Unfortunately it gets in the way when using factory methods (which are perfrctly ok to be called from the constructor in other languages) and is a source of subtle bugs.

Re: Deep C and C++ (2011)

#237

Post by pandaman » Thu, Oct 24, 2013, 5:40 PM UTC

pkolaczk wrote: post #230

pandaman wrote: post #228

Earlier quoted context omitted.

Sure, generic functions are awesome when you don't care about performance. This is why C++ does not have them. If you knew nothing about C++ and somebody told you "here, we have a language with zero run-time overhead, can you guess if we managed to implement generic functions?" what would you say? Function templates are not generic functions. Same as template classes are not types. They play really well with the rest…

Generic functions like in Java/C# can be implemented efficiently and with zero overhead. There is nothing that prevents a JIT compiler to generate several versions of the code optimised for different types at runtime, exactly like C++ does at compile-time. Some VMs already do that to some extent in order e.g. to better inline calls for the generic argument. Still, those optimisations are in their infancy, but the sit…

We also mean different things by overhead. For me (and the C++ committee) it means something that is done in addition. So for me templates create zero overhead as the do not produce more code than the same, non-template code. In practice, templates produce less code as there is a higher chance to fold common code from the instantiations of the same template than from many handwritten functions.

Re: Deep C and C++ (2011)

#238

Post by chr13 » Fri, Oct 25, 2013, 12:51 AM UTC

dllthomas wrote: post #226

chr13 wrote: post #215

Earlier quoted context omitted.

So am I and I've mostly used a subset of C features to solve many problems. I've also seen some C 'experts' fail to come to a proper solution even if they know all the features.

"I've mostly used a subset of C features to solve many problems." Sure. What about code written by others? What about when you're debugging and something just isn't working the way you expect because you've unknowingly stepped outside that subset? (Most of the important concepts here aren't syntactic constructions you can avoid trivially by typing Y instead of X, and may or may not be detectable statically). Also, ma…

I guess you summed it up. Indeed having more depth in a language is very important and useful, I was just trying to make a point that these aren't the only things. Here is how I perceive a language,

It is made up of syntax and behaves in a certain way. If you read the documented features you'll know all of it. There may be some undocumented things which may not be of utmost importance. However, this is just the base of programming. And when you start dealing with 5-6 languages you can forget things if you don't have a good memory but the good thing is it's all documented and known features. Whereas while programming, one can often be involved in solving unknown problems, which can't be figured out just by googling.

Re: Deep C and C++ (2011)

#239

Post by pkolaczk » Fri, Oct 25, 2013, 8:07 AM UTC

pandaman wrote: post #237

pkolaczk wrote: post #230

Earlier quoted context omitted.

Generic functions like in Java/C# can be implemented efficiently and with zero overhead. There is nothing that prevents a JIT compiler to generate several versions of the code optimised for different types at runtime, exactly like C++ does at compile-time. Some VMs already do that to some extent in order e.g. to better inline calls for the generic argument. Still, those optimisations are in their infancy, but the sit…

We also mean different things by overhead. For me (and the C++ committee) it means something that is done in addition. So for me templates create zero overhead as the do not produce more code than the same, non-template code. In practice, templates produce less code as there is a higher chance to fold common code from the instantiations of the same template than from many handwritten functions.

Comparing to other generics implementations - they do add a lot of code, much more than is really needed to achieve good performance. Sure, some of this code can be reduced at linking stage, but for this to work you need to statically link everything which has its own set of problems (overhead of repeated code in every binary).

IMHO the approach is a great example of premature optimisation: generate 2^N versions then try to fold some similar ones to save space. Much better approach is: generate 1 version and specialize small parts when really needed. Technically, assuming sufficiently smart compiler, both would end up with exactly the same code, performing exactly the same, but the latter solution is preferable for other non-performance wise reasons (like better type checking, ability to distribute binary libraries, faster compile times, etc.).

BTW: I still often find Scala containers to be often much faster than C++ STL. But this is probably for much different reasons than template/generics implementation.

Re: Deep C and C++ (2011)

#240

Post by pandaman » Fri, Oct 25, 2013, 2:25 PM UTC

pkolaczk wrote: post #239

pandaman wrote: post #237

Earlier quoted context omitted.

We also mean different things by overhead. For me (and the C++ committee) it means something that is done in addition. So for me templates create zero overhead as the do not produce more code than the same, non-template code. In practice, templates produce less code as there is a higher chance to fold common code from the instantiations of the same template than from many handwritten functions.

Comparing to other generics implementations - they do add a lot of code, much more than is really needed to achieve good performance. Sure, some of this code can be reduced at linking stage, but for this to work you need to statically link everything which has its own set of problems (overhead of repeated code in every binary). IMHO the approach is a great example of premature optimisation: generate 2^N versions then…

I have lost you. Are you still arguing that C++ is internally inconsistent because it's not doing stuff that Java does? Are you arguing that templates add a lot more code than a VM and JIT compiler and languages with generic functions are as efficient as C++?

In the first case - I fail to see how it follows. In the second case - our levels of expertise is too far apart to discuss anything. I am not saying you are not qualified, I might be just too out of the loop and missing some dramatic advances in Java, Scala etc.