What if anything have we learned from C++? [video] • Hacker News Board

Re: What if anything have we learned from C++? [video]

#51

Post by f00fc0d3 » Fri, Jul 24, 2015, 1:32 PM UTC

ksherlock wrote: post #46

f00fc0d3 wrote: post #27

Earlier quoted context omitted.

C99 is nice, but C still lacks generic. I am not talking about C++ template nonsense, but not having to write max element search for every primitive type. I am working in DSP project which was started with typical C++ OO BS, finally with ended up with C compiled as C++ + some simple templates for cases as above.

C11 has type generic macros. You can build your own with the _Generic statement. int maxi(int, int); double: maxd(double, double); ... #define max(x) _Generic((x), int: maxi, double: maxd, ...default: maxi)

Yeah, but you still need to write those maxi, maxd :-(

Re: What if anything have we learned from C++? [video]

#52

Post by eots » Fri, Jul 24, 2015, 2:16 PM UTC

pjc50 wrote: post #50

eutectic wrote: post #43

Earlier quoted context omitted.

It also has bad performance if you need to pass function pointers around.

Is this noticeably worse than calling through the vtable?

In C++ generics don't involve calling through a vtable.

Re: What if anything have we learned from C++? [video]

#53

Post by restalis » Fri, Jul 24, 2015, 2:21 PM UTC

xamuel wrote: post #41

blub wrote: post #22

Earlier quoted context omitted.

I hold the exact opposite opinion, and would never want to work on a plain C project. It is so low level that one has to write a lot of plumbing code to take care of error handling and resource management. It's also missing pretty much all higher-level concepts that are fast and can make code easier to write, read and less error-prone. Overall, it's simply not fun to write C code, there's a lot of tedious manual work…

>plumbing code to take care of error handling This becomes much simpler once you learn how to write your own variadic functions (it's not that hard, though I do admit it could be prettier). Then you just write one single logerrf function or whatever, which 9 times out of 10 you can carry with minor modifications to your next project. Java does try/catch better in the sense that with checked exceptions you can force l…

"I don't like C++ malloc'ing things behind my back. I see it as trading maintainability for instant gratification."

I agree and I want to add that for a language "with a bias towards system programming" C++ makes strange assumptions about the memory. It assumes that there is only one kind of memory available for every operation (and it does its thing with that by default). Then it goes and further assumes that there is only one way (no finer further details whatsoever) of getting that one and only type memory. It's exactly the one boot fits all kind of thinking that Mr. Stroustrup suggests that C++ hasn't.

Re: What if anything have we learned from C++? [video]

#54

Post by toolslive » Fri, Jul 24, 2015, 4:15 PM UTC

acqq wrote: post #19

toolslive wrote: post #7

"most researchers prefer an inefficient language because it's easier to get a paper to improve an inefficient language... I've seen dozens of papers on getting lisp almost as fast as C++, on getting Java almost as fast as C++. You can't do that with C++". A paper from the man himself on getting a type switch in C++ almost as fast as what you get in OCaml. http://www.stroustrup.com/OOPSLA-typeswitch-draft.pdf Lot's of…

It appears according to the abstract that it beats other languages while being implemented as "just a library": "Our library-only implementation (...) For many uses, it equals or outperforms equivalent code in languages with built-in type-switching constructs, such as OCaml and Haskell" In my opinion major weakness of C++ is just that the linker features more or less remained out of the language design. Turbo Pascal…

figure 5 in the paper.

Re: What if anything have we learned from C++? [video]

#55

Post by GFK_of_xmaspast » Fri, Jul 24, 2015, 5:56 PM UTC

realharo wrote: post #13

I really wish there was a "syntactic-sugar-on-top-of-C++" language that would compile down to C++ and have 100% compatibility with the existing C++ ecosystem (so that you can just directly use a class from any C++ library). Something like TypeScript is to JavaScript, or like Kotlin is to Java. Would make the experience much nicer without having to wait on the slow C++ standardization process or deal with all the back…

It's called "C++11."

Re: What if anything have we learned from C++? [video]

#56

Post by datenwolf » Sat, Jul 25, 2015, 10:02 AM UTC

nly wrote: post #47

datenwolf wrote: post #45

Earlier quoted context omitted.

> You only get ABIstab in C if you never change the size or layout of your structs Well, and you can append new elements to a struct and are guaranteed that the initial sequence of common elements is identical. This is not mentioned explicitly in the C language standard, but it follows as a corollary from point 6.5.2.2.5 of the language standard: > One special guarantee is made in order to simplify the use of unions:…

You get the same guarantee in C++, as well as a language mechanism to exploit it (inheritance). You still can't pass structs by value across library boundaries in either language without fixing your ABI though. This isn't a language intrinsic problem: it boils down to the linker model, which only C and C++ share.

> This isn't a language intrinsic problem: it boils down to the linker model, which only C and C++ share

The linker coudln't care less about this part of the ABI (calling conventions). For example passing a function pointer to a different library (callback) the linker is completely oblivious to. Heck, the functions which pointers are being being passed around could have been compiled at runtime (JIT).

Calling convention ABIs are a compiler thing, as it's the compiler that emits the machine code that's responsible for setting up the frame in which a function executes. And calling conventions is, where C and C++ differ. On the language level there are not calling conventions (how could there be, as those strongly depend on the machine architecture). However for the various operating systems out there you can find detailed calling conventions for C, but seldomly for C++. And these platform specific C calling conventions usually tightly control both how function (stack) frames are created, which registers may be clobbered, but they also control the memory layout that a C compiler for that platform shall apply on structs. For example the SysV AMD64 ABI strictly nails down the specifics of aggregate type memory layout and function parameter passing. All compilers following that spec will produce code that's compatible with each other, even across library boundaries.