GCC Developers Look At Transitioning Their Codebase To C++11

[pal666]

Unless you mean for writing (i.e. arrays of non-const elements), then why?

both. because std::array is safer replacement

I'll occasionally even use stack-based arrays for writing, but I only do it when it's performance-critical code and I can prove that an out-of-bounds access can't occur.

it is advisable to leave proofing to compiler(by using std::array)

[pal666]

Enterprise distros are a few revs behind, on those compilers.

rhel has gcc 8 in devtoolset

[cynical]

static typing is the only thing which works

It works in the sense that it gives you a false sense of confidence that your code is correct. The only useful purpose I see is providing extra information to a compiler for performance reasons. Anyone relying on it for "provability" or whatever is lost. Consider if your data has to go over the wire, where does your type information go? Oh right, into the trash because your data is now bits. So you are only gaining a benefit as long as you are working as the master of your small world. The minute you need to interact with the outside world, it doesn't help you. Not to mention it doesn't catch anything except trivial errors.

Explain something to me. If there is a good type system out there, why do they all allow casts? It's like saying my nuclear reactor operates flawlessly, but in case it doesn't there is a safety latch over here. What do I need that for, I thought you said it operates flawlessly? You wouldn't need a method of escaping the type system if it was so great.

functions don't contain data, at least in c++

You are using a mechanism called a "function object" in order to do it. What do you think is the purpose of that? It is precisely to overcome this limitation. In practical terms, it is identical.

i know what functor is. my point is that if you are trying to explain lambdas to c++ programmers, you should use c++ meaning of terms

Is a functor a c++ concept? Or is a generic concept that is applicable to multiple languages? How about lambdas? I'm not saying what a lambda is in Scheme or JavaScript, that is just syntax. I'm saying what a lambda is in general, no matter whether it is implemented in C++ or Rust, or where ever.

they both target jvm

Which is the only thing they have in common. Otherwise, Kotlin is a better Java to be used on Android. Clojure is a Lisp on the JVM used for backend web development. There is hardly any overlap, and I don't care about Kotlin popularity because I have no intention of ever programming on Android...

[carewolf]

but that was some other c++, not c++98

Yeah, unstandardized C++. It was all de-facto and often incompatible between compilers.

[cynical]

c++ had proposal with similar syntax, it was rejected due to technical issues. you see, c++ committee has to design sane language, unlike javascript. but maybe someone comes with improved proposal in fufure

By the way, I don't know what you mean by this. The hash rocket is just sugar, C++ lambdas look almost identical to JavaScript lambdas. You use square brackets instead of a function keyword, big deal.

[coder]

it's not use after free, it's null pointer dereference. same goes about second example. for use after free you need delete p.get(); for example. you can do destructive things in c++ if you really want, but at least it tries to make them visible

Yeah, use of the address after free vs. use of the pointer after ownership transfer. Similar, but different. As you point out, the underlying mechanism of failure is different, with use of heap addresses after free clearly being the more pernicious.

I had gotten to thinking about the most common user error with unique_ptr<>, which would be some form of ownership violation involving transfer. To get a use of (heap address) after free, what I should've illustrated is a case of ownership violation without transfer:

int function_that_takes_ownership( int *int_ptr )
{
    // do some stuff...

    // then, an error occurs and the function decides to delete the ptr *now*,
    //  instead of keeping it around and deleting later.
    delete int_ptr;
    return -1;
}

Elsewhere...

std::unique_ptr< int > p( new int( 42 ) );
function_that_takes_ownership( p.get() );
std::cout << "p = " << (*p) << "\n";

Of course, the bigger problem would usually be writing to it, after free... and not immediately, either.

my argument works for simpler more common case, his argument doesn't

Yeah, he made both points. Credit where it's due, but AsuMagic is due more.


Like many things, it's a situation where the std improved the common case, but there's still a scenario where someone might reasonably prefer a C array. I'm not trying to argue against using std::array<> in the former case, or even necessarily the latter.

[coder]

both. because std::array is safer replacement
it is advisable to leave proofing to compiler(by using std::array)

Well, I see your point. However:

1. the programmer might know things the compiler doesn't and that aren't easily expressible in code.
2. the compiler is not guaranteed to maintain full visibility of relevant data or actually even do any assumed bounds-checking.

So, while I'd prefer std::array<>, any sense of security would be false. It might give the compiler a chance to save you from yourself, but it's not a guarantee.

[coder]

It works in the sense that it gives you a false sense of confidence that your code is correct.

This is an absolutist position I don't support. Static typing allows more errors to be detected at compile time than dynamic typing. Whether you consider this a net win probably has to do with external factors.

Consider if your data has to go over the wire, where does your type information go? Oh right, into the trash because your data is now bits.

Please, let's not be silly. It's not as if all of us here haven't done plenty of serialization/deserialization. Obviously, when you deserialize, you sanity-check/integrity-check/etc., which allows you to re-assert type guarantees.

Explain something to me. If there is a good type system out there, why do they all allow casts?

Which kind of casts? static_cast is perfectly sensible for converting numeric types. dynamic_cast is sensible for safely recovering static type information, when it's lost. reinterpret_cast is indeed a hack, but something of a nod to C++'s more primitive and pragmatic heritage.

IMO, it's a pointless waste of time to debate whether approach X is better than Y. It's like debating whether screws are better than nails. They each have their benefits and drawbacks. If you want a worthwhile discussion, I'd advise focusing on when and how best to use each tool.

[cynical]

This is an absolutist position I don't support. Static typing allows more errors to be detected at compile time than dynamic typing. Whether you consider this a net win probably has to do with external factors.

You do agree that you still need to write tests and check your logic though right? A type system does not stop you from making errors, only a certain class of errors. (not the most important ones imo) I'm not against typing, I just haven't found a type system that I like. My ideal world would be mostly type inference with optional, gradual annotations. (although honestly I kind of like runtime data validation more now, even with the performance hit)

Please, let's not be silly. It's not as if all of us here haven't done plenty of serialization/deserialization. Obviously, when you deserialize, you sanity-check/integrity-check/etc., which allows you to re-assert type guarantees.

I'm saying the same thing as you, that types do not extend past the local boundaries of your program, they do not persist with the data. That makes their guarantees less useful. (not that I'm saying they should, networks are already slow enough)

Which kind of casts? static_cast is perfectly sensible for converting numeric types. dynamic_cast is sensible for safely recovering static type information, when it's lost. reinterpret_cast is indeed a hack, but something of a nod to C++'s more primitive and pragmatic heritage.

All casts. If someone, even yourself, can just change the type out from under your feet at any time, that to me is the same as no guarantees. (an extreme statement to you I'm sure )

IMO, it's a pointless waste of time to debate whether approach X is better than Y. It's like debating whether screws are better than nails. They each have their benefits and drawbacks. If you want a worthwhile discussion, I'd advise focusing on when and how best to use each tool.

Agreed, I was responding to someone who claimed that static typing is the only thing that works. I happen to believe it has a lot more to do with personality than anything else. Some like to have clear specifications for all of their types, and to outsource that required knowledge to an external system that will yell at them if they get it wrong (and they like to have precise control over all of their program, masters of the universe). Others prefer to keep that information in their mind and instead retain the flexibility to change it as their perspectives change, and as the situation demands (and don't mind ambiguity). It's no surprise to me that at the lower/system level where change is slower, the former approach is favored, while at the higher/web level where change is more rapid, the latter is more highly valued.

[coder]

You do agree that you still need to write tests and check your logic though right?

I generally like trying to break my code, convincing myself that it works, before letting anyone else come into contact with it.

A type system does not stop you from making errors, only a certain class of errors. (not the most important ones imo)

It's funny, though, because anyone who's really used a statically-typed language has probably learned to use the type system as a tool and come to appreciate just how many errors it can catch.

For instance, I worked on one project where they had loads of time-related bugs, because they used standard numerical types to represent both timestamps and durations, and had no standard units. Once I introduced distinct timestamp and duration types (each of which had intrinsic units and accessor functions for getting specific units), those problems were completely solved.

If my C++ code compiles, I can be reasonably sure it's going to work as intended. On the other hand, Python code can have loads of things wrong with it, that you wouldn't know if you didn't hit that particular code path. I try to take Python on its own terms, though, and write more in idiom for that language. Still, it's hard not to be a bit annoyed when I find errors that every C++ (or even C) compiler would've caught.

At the other extreme, shell scripts are a context in which I think types would just completely get in the way.

As you mentioned, they can also facilitate a great many compile-time optimizations. In C++, it's not only about the compiler - function/operator overloads and template specializations are other mechanisms where static typing can enable performance enhancement.

All casts. If someone, even yourself, can just change the type out from under your feet at any time, that to me is the same as no guarantees. (an extreme statement to you I'm sure )

I don't know how you get away from using casts for numeric conversions, unless you're saying we should use built-in functions to do that. And that just amounts to basically the same thing by a different name.

As for dynamic_cast<>, for sure it's undesirable. Usually, it hints at a design deficiency in your code. However, it's occasionally quite useful. I don't have a great example, off hand, of where I wouldn't consider it ugly and something that should ideally be refactored away, but I'm sure I've seen a handful of such cases.

Most of the time I use reinterpret_cast I think is usually working with C libraries. Nothing much to be done about that.

I was responding to someone who claimed that static typing is the only thing that works.

I hope you didn't think my comment was only aimed at you.

I happen to believe it has a lot more to do with personality than anything else. Some like to have clear specifications for all of their types, and to outsource that required knowledge to an external system that will yell at them if they get it wrong (and they like to have precise control over all of their program, masters of the universe). Others prefer to keep that information in their mind and instead retain the flexibility to change it as their perspectives change, and as the situation demands (and don't mind ambiguity).

This sounds like you're talking at least as much about strongly/weakly-typed as static/dynamic typing.

If you use strong, dynamic-typing, then you don't get to change your perspective on what something is without either casts or using using multiple-inheritance or interfaces - none of which are exactly "fluid", since that stuff needs to be planned out somewhat in advance.