likeliv

That's right. C being more limited, it has a more simplistic ABI. But the parent comment was replying the "need for a stable, standard ABI, which C provide". Which is misleading as both C++ and C have the same level of stability and standardisation of their ABI. (I.e: none of them is standardized, but both of them are stable on practice)

unique_ptr does not have any memory overhead. (unless you use a custom deleter, but even then you could use one which does not use memory)

You seem to misunderstand what moc does. This page should help you: https://woboq.com/blog/moc-myths.html

Moc just adds some more generated code next to you valid C++ code, generally in a new translation unit. That generated code is just boiler plate which you could write by hand if you wanted. In a sense this is what verdigris does: it provides macros that makes makes it easier to "write it by hand" (the W_OBJECT_IMPL macro somehow expends to the code generated by moc)

No need to use Qt creator. Most C++ build systems support moc out of the box, or with minor adjustments.

C is already an anti pattern for a library.

It is soon 2020, there is no reasons to use C in new code. Because of security and also convenience.

Maybe it is a nice mental exercise (also try brainfuck and malbolge), but not something for production.

Since the sun isn't turning around the earth, I believe the sun is still where you point at.

> There are plenty of programs that exploit the programmer's knowledge of a particular compiler's actual, unspecified behavior as an optimization.

There are plenty of programs that have bugs.

Programmers who exploit undefined behavior on purpose are reckless.

There is an example of indexed vecteur in the rustc source code https://github.com/rust-lang/rust/blob/master/src/librustc_i...

> most of those languages (1) have a GC that makes boxing a much cheaper operation than in Rust

Why is that? I would intuitively think it is the other way. (Is a malloc/free pair not cheaper than an allocation on the GC heap + collecting its garbages?)

I disagree that the user of the macro needs to understand its output. The output of a macro is an implementation detail, and the documentation of the macro should be enough to use the macro without even looking at its output.

For example, no need to understand the magic behind the 'quote!' or the #[async_trait] macros to use them.

Right. Is it really accidental complexity? This is the implementation detail that the users of the language doesn't really need to know as they would just write 'async fn' (and #[async_trait] while waiting for the issues mentioned in this blog post get solved).

I know rust is not C or C++, but we are not programming in x86 assembly, but for the language "abstract machine". And if the compiler infer that this memory location is not used by other threads because we don't use an atomic operation, it can perform optimizations that could result in subtle bugs. That's what undefined behaviour is.

Although in this case, I guess this is probably fine since the non-atomic read can't race with a write.

Is that not an undefined behaviour?

Can't you get some values "out of thin air" (partial updates of some bits.) Or some intermediate values?

(For example, can the compiler decide to use this memory location to store some unrelated temporary result, as it knows it will erase it soon with a final value and that no other threads is supposed to access this)

I don't know if nuclear waste is actually worse than the waste from a chemical factory. Any industry has its risks for the environment.

That was just an example. But maybe 'x' is a BigInt type that use a memory allocation to store its contents. The ownership would be transferred to the return value

That was pre-c++11. Now using C++11, it is much simpler (using 'auto'). And the C++17 version is even simpler

https://code.woboq.org/qt5/qtbase/src/corelib/global/qglobal...

... and this is why I will never touch C++ and stay with simple C.

(Ah no..., wrong thread. This is actually about C. /s)

Point is that when you want to do a change in the "API" (or call it "protocol"), you need to touch the different repositories and coordinate to use the right versions together.

About the copy/paste of protobuf files, it works but makes it more difficult to keep them in sync.

And I did not say you need a single repo. I'm saying the stated disadvantages of multi repo are real.

One of the philosophies behind Go is to keep the language extra simple.

See "less is exponentially more".

The same way some electric bikes are restricted to a given speed to keep their user safe. Some people call it "crippled", while some other call it "simple and safe to use".

Would be nice if types could annotate their Drop trait with #[early_drop] if the drop has no visible side effect, do rust could free the memory earlier.

It is perfect fine to take by value something that is not Copy to transfer its ownership.

It is a compiler error to use the value after it was moved. And the compiler error is quite explicit about how to solve it

For example you can explicitly clone

    let y = add(x.clone());
    let z = add(x);

Why boot many VM instead of saving the state and restoring from there?

There is another tool called git-subtree that should solve these problems, I think. But I've never seen it in use

Calling eachother at network level is still a dependency. (And even a build dependency if you use something like protobuff or other protocol description files)