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

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

youtube.com

Post reply on HN
Print view View original

41–50 of 56 posts

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

#41

Post by xamuel »

blub wrote: post #22
infradig wrote: post #2

After twenty years of using it? That I was wrong, that plain-old C really is better.

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 library users to at least acknowledge exceptions. Without checked exceptions, try/catch just hides the extra int *err argument under the rug, actually increasing the risk of library users not acknowledging edge cases.

>and resource management

I don't like C++ malloc'ing things behind my back. I see it as trading maintainability for instant gratification. The problem is compounded by the way C++ doesn't play nice with gdb/valgrind. Memory leaks and other memory errors are much easier to fix in C than C++.

>C is so tedious

It really isn't, though, if you use it right. Whatever syntactic tedium it has is more than compensated for by the lightning-fast compile time and the infinitely simpler compiler errors (due to no overloading, no templates...)

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

#42

Post by nly »

bluetomcat wrote: post #28
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.

Using statement expressions and the typeof extension, you are able to write function-like, type-generic, scope-insensitive macros like this one: #define MAX(a,b) ({ \ typeof (a) _a = (a); \ typeof (b) _b = (b); \ _a > _b ? _a : _b; \ }) The inability to write template functions can be compensated by designing your function so that it takes a function pointer where the type-specific action occurs.

Your MAX has no respect for namespaces or scopes. A real world macro is probably going to be called MYLIBRARY_MAX to avoid this. Secondly the C++ lambda solution is just easier to read.

    auto max = [](auto a, auto b) { 
        return (a > b) ? a : b;
    };

    max (3.1415, 42); // returns double
    max (42ul, 78u); // returns unsigned long
    max (17, 16); // returns int

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

#43

Post by eutectic »

pjc50 wrote: post #31
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.

C has a generic: "void *". It just doesn't have any type safety.

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

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

#44

Post by bluecalm »

nly wrote: post #39
bluecalm wrote: post #26

Earlier quoted context omitted.

Compiling to C would be better. Using C++ libraries from anything outside C++ compiled by the same exact compiler and same exact version of it as the library was is a royal pain. On the other hand using C libraries is super easy from any language and something compiled 10 years ago still works today.

You only get ABIstab in C if you never change the size or layout of your structs, or completely hide everything behind pointers and allocate everything on the heap (maybe a little on the stack if your library is amenable to using callbacks - blargk!). The rules[0] for C++ aren't really any different, you just notice it more. When you start shooting for ABIstab, without putting in a lot of extra work, you start losing…

>>C++98 code out of GCC has also been ABI stable for over 10 years now btw

I was specifically picking on Visual Studio and vendors who decided to distribute C++ dlls. Sometimes they provide several versions depending on which Visual Studio version you have installed at the moment.

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

#45

Post by datenwolf »

nly wrote: post #39
bluecalm wrote: post #26

Earlier quoted context omitted.

Compiling to C would be better. Using C++ libraries from anything outside C++ compiled by the same exact compiler and same exact version of it as the library was is a royal pain. On the other hand using C libraries is super easy from any language and something compiled 10 years ago still works today.

You only get ABIstab in C if you never change the size or layout of your structs, or completely hide everything behind pointers and allocate everything on the heap (maybe a little on the stack if your library is amenable to using callbacks - blargk!). The rules[0] for C++ aren't really any different, you just notice it more. When you start shooting for ABIstab, without putting in a lot of extra work, you start losing…

> 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: if a union containsseveral structures that share a common initial sequence (see below), and if the unionobject currently contains one of these structures, it is permitted to inspect the commoninitial part of any of them anywhere that a declaration of the complete type of the union isvisible. Two structures share acommon initial sequenceif corresponding members havecompatible types (and, for bit-fields, the same widths) for a sequence of one or moreinitial members.

Consider

a.h

    struct a { char aye; short bee; int cee; long dee; };
a.c

    #include "a.h"
    int aye(struct a a) { return a.aye; }
b.h

    struct b { char aye; short bee; int cee; long dee; double eee; };
b.c

    #include "b.h"
    int bee(struct b b) { return b.bee; }
Now if we add c.h

    #include "a.h"
    #include "b.h"

    union ab {
        struct a a;
        struct b b;
    };
The language standard warrants, that the common initial sequence of both structures can be used interchangeably in that union. Since however compilation units a.c and b.c are processed individually without knowledge of union ab this enforces the compiler to use the same memory layout for an initial sequence of member elements for either struct. Hence it is legal to extend structs without out altering the memory layout of the previous elements.

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

#46

Post by ksherlock »

f00fc0d3 wrote: post #27
bluetomcat wrote: post #17

Earlier quoted context omitted.

Coding in plain C99 with some discipline can actually get you most of the benefits of C++, without any of its quirks. The "object-orientedness" of C++ really boils down to implicitly passing the this pointer to member functions, inheritance + virtual functions, and namespaces. All of these can be emulated in what I would call "C with discipline". Just be consistent in your naming conventions, always use a common pref…

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)

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

#47

Post by nly »

datenwolf wrote: post #45
nly wrote: post #39

Earlier quoted context omitted.

You only get ABIstab in C if you never change the size or layout of your structs, or completely hide everything behind pointers and allocate everything on the heap (maybe a little on the stack if your library is amenable to using callbacks - blargk!). The rules[0] for C++ aren't really any different, you just notice it more. When you start shooting for ABIstab, without putting in a lot of extra work, you start losing…

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

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

#48

Post by JustSomeNobody »

cm2187 wrote: post #11

That introducing kids to programming using C++ will ensure they never want to try again.

Languages I learned as an early teen, in the oder I learned them: Commodore BASIC 6502 Assembly Pascal C C++ etc...

I think you severely underestimate kids.

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

#49

Post by [deleted] »

bluecalm wrote: post #44
nly wrote: post #39

Earlier quoted context omitted.

You only get ABIstab in C if you never change the size or layout of your structs, or completely hide everything behind pointers and allocate everything on the heap (maybe a little on the stack if your library is amenable to using callbacks - blargk!). The rules[0] for C++ aren't really any different, you just notice it more. When you start shooting for ABIstab, without putting in a lot of extra work, you start losing…

>>C++98 code out of GCC has also been ABI stable for over 10 years now btw I was specifically picking on Visual Studio and vendors who decided to distribute C++ dlls. Sometimes they provide several versions depending on which Visual Studio version you have installed at the moment.

[deleted]

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

#50

Post by pjc50 »

eutectic wrote: post #43
pjc50 wrote: post #31

Earlier quoted context omitted.

C has a generic: "void *". It just doesn't have any type safety.

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

Is this noticeably worse than calling through the vtable?
Post reply on HN