next »

[Ordnas]

I am using Unity for my personal projects and there are many features of C# that I would like to see in C++ like delegates and property. Is there any particular features from other languages that you would like to see in C++?

[fluffrabbit]

I actually think that C++ has too many features. It's the features that bloat the compiler systems and make C++ an ever-evolving unmaintainable mess. C, assembly, and various VM environments is where I'm headed.

That said, C++ could use introspection and free-for-all heterogenous heap objects. JavaScript does this well with JSON, and it would be cool if C++ and other languages had a JSON-like notation and data management system built in.

[Daid]

Isn'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:

Code:

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.

[fluffrabbit]

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.

[InfiniteStateMachine]

I honestly can't think of anything due to how they would have to be implemented.

For example pattern matching is great but trying to implement that on top of c++ with the policy that new features need to be in the standard library would not work out well.Even c#'s pattern matching is a little rough. They kind of shoehorned it on to a switch statement.

The nerd in me likes the feature Herb Sutter was talking about for implementing keywords. I think the term is meta-classes. In practice it sounds like it probably wouldn't work well though. For example maybe one library's "interface" keyword accidentally clashes/leaks with another library's "interface" keyword. Not to mention a keyword having different semantics depending on where you are in the codebase could be quite confusing.

[qMopey]

What do you like about delegates and properties? Personally I hate both, but am very curious to learn something from you guys about them.

[fluffrabbit]

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

[InfiniteStateMachine]

What do you like about delegates and properties? Personally I hate both, but am very curious to learn something from you guys about them.

If it's properties vs getters and setters then I much prefer properties. Especially c#'s version and even more so with expression body syntax. EX public int SomeVal => _someVal.

If you aren't in a situation where you are using getters and setters then that's a different discussion.

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.

[InfiniteStateMachine]

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

I think the aviation industry uses something simlar to Misra C where I'm guessing something like the STL is probably banned. It's possible they are one of the critical industries that simply chooses to use a different language like Ada.

[fluffrabbit]

C with MISRA certification is preferred over Ada in aviation, Ada is just so old. Still, I feel like it could be a bit of a pain to have to write tons of vanilla C code to control these complex things, and there is a demand for higher-level but still mission-critical doodads, like realtime Java.

[InfiniteStateMachine]

C with MISRA certification is preferred over Ada in aviation, Ada is just so old. Still, I feel like it could be a bit of a pain to have to write tons of vanilla C code to control these complex things, and there is a demand for higher-level but still mission-critical doodads, like realtime Java.

I notice there is C with MISRA and C++ with MISRA. Is the C++ version generally not used in practice?

[fluffrabbit]

I don't work in that business so I don't know; MISRA C++ is a revelation to me. I'm a little surprised. Cool!

However, static analysis is another story. MISRA maintains its standards under a proprietary license, thus precluding something like CppCheck from supporting it out-of-the-box. The Joint Strike Fighter standards are free and from a similar era. Both standards unfortunately predate C++11. There is a C++14 addendum by another group, but then you're adding more complexity to compliance. Ideally, C++ should just be a safety-compliant language, period.

[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:

Code:

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.

Code:

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:

Code:

mutex my_mutex;

void function()
{
  shared_lock<mutex> 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:

Code:

mutex my_mutex;

void function()
{
  shared_lock<mutex>(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)

[Schrompf]

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.

[fluffrabbit]

My brain is taking a vacation. Frustrating how despite the number of safe C certifications there are, not one static analysis tool that is readily available and open source will enforce any one standard. And no, I'm not going to improve as a programmer, that's not on my todo list.

[InfiniteStateMachine]

I'm just not sure c++ is the language I'd want to be used for mission critical stuff due to a lot of concerns already talked about in this thread.

I guess we don't have a lot of real proven alternatives but I wonder if some of the verifiable languages might be good in the future for this stuff. F* is the only one I've read manual for  but I think Idris/Coq are more popular. Basically you can write a lot of customized code around your functions to get garauntees at compile time such as proving a function will complete.

https://www.fstar-lang.org/

[qMopey]

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.

Code:

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.

[Ordnas]

C++ has the reputation to be a language where you must minimize the runtime cost whenever is possible, but today C++ is used for many things, and when you need to work on the same code written by other 200 people, make the code simpler using fewer line of codes can make the difference.

[fluffrabbit]

C and C++ are well-known and compatible, but they aren't good for every use case. They're not as safe as Ada or D, they're not as beginner-friendly as JavaScript and Python, they're not as interesting as Kotlin, they just sorta sit there being fast and not doing much else. IMHO speed is overrated. If I hand C/C++ code to a Mac user, it can be compiled right away, but if I hand over some D, they have to go install something. Ehhh

[Daid]

I'm just not sure c++ is the language I'd want to be used for mission critical stuff due to a lot of concerns already talked about in this thread.

Got bad news for you. It's used for a lot of mission critical stuff, including medical devices. But generally, that is a limited subset.

In embedded realtime systems, there is one simple rule that rules out a lot of the complexity of C++. No dynamic memory, allocations happen on startup and that's it.



@qMopey, what do you think about std::array? It's simply a well known C array, wrapped in a small thing that adds the length as compile time constant. Keeping all the information about the array together, instead of having the classic mistake of using the wrong size and going out of bounds.



But I got one for the "what I would like to see in C++", making "enum class" an actual class, instead of being an "enum namespace" in disguise. And with that I mean, I want to add functions to my enums, just as I can with classes, and the name "enum class" implies.