October 10, 2019
[ad_1]
DaidIsn’t std::function about the same as a delegate?
Properties can be sort of emulated with operator overloading, but it’s clunky at best.
But yes, deprecating old stuff that you should no longer use should be a priority. Just marked as deprecated, so you can still use it, but get a warning. So far the only thing that I know off that this happened with is std::auto_ptr.
Right out ban “mutable”, “volatile” and “const_cast” by default.
Next, making things less verbose. It seems with every new addition and “you should be using X instead of Y”, the amount of syntax doubles. See old style cast vs new style cast.
And, kill odd syntax rules, like this being valid:
int main(int argc, char** argv)
{
int(n);
return 0;
}
You may guess what it does. Yes, it compiles. No it does not what you expect. Yes, it’s a source of bugs.
fluffrabbitAm I the only one who is bothered by abstract computer science concepts worming their way into programming languages? I understand that Bjorn or whatever he’s called meant for C++ to be a high-level language, but it won’t survive the apocalypse, I can tell you that much. Java might because it has that steampunk feel, terrible language though it is.
Someone somewhere is programming a flying car with C++20, and that car is going to crash because the programmer doesn’t really know what’s going on.
The STL uses heap allocations everywhere, which have unpredictable performance, so if you use STL functions in a loop, that loop is not guaranteed to execute in constant time. Maybe a “safe profile” of the STL could be created for aviation or something. They keep adding more to the regular STL, and they really need to stop.
More here. tl;dr no language is 100% guaranteed not to crash your spaceship, but C++ is especially difficult.
Daid
Ehh… `int(n)` looks like a C feature, so I would leave it up to the C standards people if that is the case. I would guess that `int(n)` is the same as `(int)n`, and `n` doesn’t exist, but it could also be the same as `int n`, which would simply be an unused variable.
Actually, it is not. C++ and C are different standards, even on the basic syntax. And, maybe that’s what should be primary, kill the die-hard C compatibility for sanity. A missing return statement should be an error, not a warning. There is already a bunch of stuff done, meaning that if you compile you C code with a C++ compiler, and it does not compile, you most likely have something that could lead to undefined behavior in your code.
Example:
int function();
In C, this is a function that takes any amount of integer parameters. In C++ is this a function that takes no parameters.
int example();
int example2(int num) {
return example(num);
}
int example(int num, int num2)
{
return num + num2;
}
So this compiles in C, and not in C++.
Why the “type(name);” variable deceleration is an issue is with RAII. In C++ you can lock a mutex like this:
mutex my_mutex;
void function()
{
shared_lock lock(my_mutex);
…
}
Which has the advantage of always unlocking when you exit the function, even with exceptions. No way to forget to unlock the mutex.
But:
mutex my_mutex;
void function()
{
shared_lock(my_mutex);
…
}
Does not lock the mutex, it just generates a local variable that shadows my_mutex.
Source how this caused bugs at facebook:
Am I the only one who is bothered by abstract computer science concepts worming their way into programming languages?
People complained exactly the same when C was introduced 
See:
(And if you use the stl in realtime embedded code, you are doing it wrong. C++ is more then the stl)
SchrompfLevel 6
C++ professional, game dev sparetime
Some people are purist, but I’m not. I like a lot of the modern C++, and it got way better over the years. But it’s a hell of a language to start learning in.
Personally, I don’t want properties. I think it solves the wrong problem, namely the Java-style “I meant these vars to be public, but styleguide said no” classes that are actually simple data holders. People write the member vars as private and then put a simple getter and setter for each and every of them… ok, but you simply have to step back and think about what you actually want to do. Bonus points for enforced documentation rules that force you to put a four lines comment above each and every of them. Tss.
I crave reflection. I want proper code generation, not that clumsy backward template meta programming. Simple allocators would be nice, the old custom allocator concept is over-engineered to death. Better language support for stuff that nowadays is a template mess with a stack trace five levels deep if you happen to debug it and unreadable errors in case you use them wrong. I’m looking at you, std::function.
Apart from that… I’m actually fine, thanks.
Snake World, multiplayer worm eats stuff and grows DevLogqMopey
As for delegates. It’s a similar argument. It really depends what I’m comparing them to. Ideally I prefer a language that doesn’t make the distinction between a value and a function.
I agree. A big problem with C++ is how complicated multiple inheritance can make things. A delegate-like thing in C language could be extremely simple.
struct var_t
{
void* data;
type_t* type;
union_t value;
};
struct delegate_t
{
var_t context;
void (*fn)();
};
var_t delegate_call(delegate_t* delegate, int param_count, var_t params[8]);
Ultimately all that’s needed is a single function pointer to store the address of the function to call, some type information represented by pointers to type structs (the type structs could be, for example, stored in a static table), and that’s about it.
The `data` pointer points to the actual referenced value in memory. It can be anywhere; on the heap, on the stack, or in the `value` member. `value` is just a union for common types, like int/float, to pass parameters by value. `context` is like the `this` pointer. It’s the first parameter to the called function, unless the `context` var is empty, then it is not used.
This is actually very similar to how my own ECS works for my game. I made a very similar system for calling system functions with type tables and function pointers.
In C++ it becomes very complicated to store a function pointer, since the size of the function pointer is implementation dependent and can vary quite wildly. std::function simply allocates the function pointer on the heap… Which is dumb in my opinion. All this complexity is pointless.
[ad_2]
Latest posts
March 4, 2021
March 4, 2021March 4, 2021