proj-plbook-plChCtmLangs

Table of Contents for Programming Languages: a survey

C

Because it is so well-known and well-liked, C gets its own chapter.

See chapter on chapter on C.

C++

"In C++’s case, the Big Idea was high level object orientation without loss of performance compared to C." [1] (my note: and backwards compatibility with C; and close-to-the-metal low-level operation)

" C++ is a general-purpose programming language with a bias towards systems programming that

    is a better C
    supports data abstraction
    supports object-oriented programming
    supports generic programming " -- http://www.stroustrup.com/C++11FAQ.html#aims

" ...C++’s fundamental strengths:

Attributes:

Pros:

Cons:

Good for:

Best practices and style guides:

References:

Retrospectives:

People:

Tours and tutorials:

Reference/details:

Books:

Opinions:

"With C++ I at least have the escape hatch of going back to C. I started using some of the C++ 11, 14, 17 template and compile time programming stuff: constexpr, etc. Some of it is OK. There are lots of holes. When there’s a hole, I go back to a C macro! That has worked well enough many times. So ironically C++ has incredible complexity, but you can always avoid it by programming in C :) On the other hand, the template stuff can be useful. I kinda cringe when I realize someone’s first experience with systems programming could be in Rust. But then again I also cringe at how long it took to be productive in C and C++ too (more than a decade). We’re not there yet :) " -- [10]

on C++ interop:

Comparisons:

Examples of good code:

Best practices:

Misc:

Types:

C++ Features

References

References are kind of like pointers, but with a few differences. Some of these are:

For example, say you want to write a '++' operator for a type that doesn't have one. You have to use references for two reasons:

Links:

C++ Features: Concepts

discussion (with comparison to Rust trait syntax and semantics):

logicchains 1 day ago

parent prev next [–]

>That said, I've mostly reached the conclusion that much of this is unavoidable. Systems languages need to have lots of detail you just don't need in higher level languages like Haskell or Python, and trait impls on arbitrary types after the fact is very powerful and not something I would want to give up.

Have you checked out C++20 concepts? It supports aliases and doesn't require explicit trait instantiations, making it possible to right such generic code with much less boilerplate.

reply

loeg 1 day ago

root parent next [–]

My experience in C++ prior to 20 is that it is a lot more verbose/boilerplatey than Rust. I'd love to see that get better, but I think C++ is starting from significantly behind.

reply

jcelerier 1 day ago

root parent next [–]

C++17:

    template<typename T, std::enable_if_t<std::is_floating_point_v<T>, int>* = nullptr>
    void func(T fp) { ... }

C++20:

    void func(std::floating_point auto fp) { ... }

reply

Frizi 1 day ago

root parent next [–]

There is an equivalent syntax in Rust to both of those examples, and in both cases I find it less verbose. The template variant is roughly equivalent to:

    fn func<T: FloatingPoint>(fp: T) { ... }

And the "auto" variant is similar to impl argument in Rust:

    fn func(fp: impl FloatingPoint) { ... }

reply

jcelerier 1 day ago

root parent next [–]

I really don't see in which way the second case is less verbose especially if you add a non-void return type, e.g. i32. The first case would also be doable like this, which is pretty munch the exact same than your first example with the added "template" keyword

    template<std::floating_point T> 
    void func(T t) { ... }

(also, it's not really equivalent - if I'm not mistaken with traits you can only use what the trait declares ; in C++ you can for instance do something like

    template<typename T>
    concept CanBlah = requires (T t) { 
      t.blah();
    };

and still be able to do

    void func(CanBlah auto t) { 
      log << "func:" << t;
      t.blah();
    }

instead of polluting the prototype with all possible side concerns)

reply

tialaramex 1 day ago

root parent next [–]

> instead of polluting the prototype with all possible side concerns)

C++ Concepts are duck typed, and Rust's Traits are not, so in Rust you are expressing meaning here, and in C++ only making some claims about syntax which perhaps hint at meaning.

WG21 seems to dearly wish this wasn't so, offering Concepts which pretend to semantics they don't have, such as std::totally_ordered and I'm glad to see your "CanBlah?" concept doesn't do this, to be sure all things which match this requirement can, indeed blah() although we've no idea what that can or should do.

Once you've accepted that you only have duck typing anyway, you're probably going to have to explain in your documentation the actual requirements for this parameter t, as the prototype merely says it CanBlah? and that's not actually what we care about.

In contrast the Rust function we looked at actually does tell us what is required here, something which "implements FloatingPoint?", and that implementation (plus the data structure itself) is all that's being exposed.

reply

C++ features: coroutines

C++ Opinions

Favorite parts:

Critical:

Other: 

    def adder(amount):
        return lambda x: x + amount

C++

    auto adder(int amount) {
        return [=](int x){ return x + amount; };
    }" about the [=]: "turns out there are various forms of Lambda (of course there wouldn't just be one in C++), for ex:
    [a, &b], [this], [=], [&], []

Depending on how the variables are captured. " "The stuff in square brackets is the capture list. Unlike python, which implicitly captures the full outer scope by reference, C++ allows/requires you to specify which outer variables you want to reference in the lambda, and whether they are captured by value ("=") or reference ("&"). This allows C++ to implement the lambda with a simple static function in most cases, where python needs a bunch of tracking data to preserve the outer stack from collection." 00 [35]

Why it compiles slow:

C++ advanced practices

C++ Gotchas

"the major insecurities in C++ code: