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

[pal666]

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;
}

that's longer way to write delete p.get(); which i mentioned. owning function should take unique_ptr, it will automatically solve this problem.
as usual, there is a guideline for that https://isocpp.github.io/CppCoreGuid...ip-of-a-widget

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.

not reasonably. if you have complex array, you are losing just 1 symbol per element compared to c version, which is not reasonable reason to prefer less safe variant:

using V = std::vector < int >;
std::array a { V{1,2,3}, V{1,2,3} };

note that using specification is a mirror of type specification before c array

[pal666]

[*]the programmer might know things the compiler doesn't and that aren't easily expressible in code.

he can keep that knowledge even with std::array

[*]the compiler is not guaranteed to maintain full visibility of relevant data or actually even do any assumed bounds-checking.

but compiler is guaranteed to do type checking, i.e. it will not allow passing array<x, 2> where array<x,3> is expected

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.

nothing is guaranteed in any language, you can still write program which doesn't work. type checking just solves large number of frequent errors

[pal666]

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.

performance is always good thing, but static type checking is the only thing which can be used to write correct by construction code. it is ridiculous to have your fedora installer spewing at you something like "this object doesn't have this field" because someone thought using dynamic languages for anything but one-off scripts is good idea

Consider if your data has to go over the wire, where does your type information go?

not every(again understatement) function call goes over the wire. you have to carefully write and test your serializers. in some cases it is done via code generation. static reflection will greatly improve that

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

that's one of c++ guiding principles. it doesn't forbid you to write bad programs. it only helps you to write good ones. c++ casts are very visible (read ugly and greppable). language has them in case you really need them, but guideline says avoid casts https://isocpp.github.io/CppCoreGuid...48-avoid-casts

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.

in pragmatical c++ terms function object is object of class with member operator(). function in c++ can't even be stored in variable, that only works with function pointers. which are not functions in case you were wondering

Is a functor a c++ concept?

actually c++ calls it function object, but people often use functor shorthand

Or is a generic concept that is applicable to multiple languages?

what about function or object? when teaching c++ programmers you are using c++ definitions

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.

if you are defining lambda in general as function, you have to define what function in general is. because c++ functions are not objects, so c++ programmers will be only confused by such definition

Which is the only thing they have in common. Otherwise, Kotlin is a better Java to be used on Android.

kotlin isn't better java and isn't for android. it's no more android than java is android. kotlin is better(for some definition of better) jvm-targetting(read interoperable with java) language

[pal666]

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.

syntax for omitting types, braces and return keyword when all your body is one return statement

[](auto&& a, auto&& b) { return a.id() < b.id(); } // C++14
[](a, b) => a.id() < b.id() // this proposal

[&](auto&& w) { return w.id() == id; } // C++14
w => w.id() == id // this proposal

http://open-std.org/JTC1/SC22/WG21/d...7/p0573r1.html

[coder]

he can keep that knowledge even with std::array

I'm not really arguing against it - just saying it's not a panacea.

nothing is guaranteed in any language, you can still write program which doesn't work. type checking just solves large number of frequent errors

Yeah, it sounds like we agree.

[cynical]

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.

As you said it is a matter of trade-offs, and to me the annoyances outweigh the benefits.

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.

That doesn't have anything to do with the type system though, it has to do with their poor choice of representation. Practically all dynamic languages have a standard representation for dates, or if not, I would do the same thing as you and make one.

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.

No you see this is exactly the kind of false sense of security that I'm talking about. The fact that it compiles tells you nothing about whether or not it is going to work correctly. All it tells you is that your types have correctly conformed to the type system, which you could call internal consistency. Those are completely different things. Also, what you are saying about Python is equally true for C++. A type system does not guarantee you are testing all code paths. Now here is an error you are never going to see regularly using Python, but is easy to trigger in C++ and the type system does nothing to save you:

#include <iostream>
 
    int main()
    {
      unsigned int x = 3;
      unsigned int y = 5;
    
      std::cout << x - y << '\n';
      return 0;
    }

Do you see what I mean when I say that type systems do not guarantee code correctness?

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.

Casting numeric types is always a terrible idea. At the very least you should be using boost or something to help try to avoid data loss. Ideally you would never do it. But my point is that if you have the ability to cast, you do not have type safety.

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

Well now I don't.

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.

Honestly, everyone has their own definition of strong typing so I would need to hear yours to know what you mean. It's not only about the design though, I can rapidly iterate on something and test it immediately in my browser in a dynamic language. I can even setup my workflow to immediately reload my page/application the minute I save. One downside that you simply cannot overcome in using a type system are the compile times.

[coder]

That doesn't have anything to do with the type system though, it has to do with their poor choice of representation. Practically all dynamic languages have a standard representation for dates, or if not, I would do the same thing as you and make one.

In our case, the units were a fairly minor issue. That's the only thing representation would solve.

However, by creating distinct types for timestamps and durations, then changing all of the parameters and variables to use these types, we could use the compiler to ensure that durations weren't getting into places that expected timestamps and vice versa. Furthermore, you couldn't do nonsensical things like adding two timestamps or multiplying a timestamp by anything, yet those operations were allowed for durations.

No you see this is exactly the kind of false sense of security that I'm talking about.

Please. We're not noobs. Nobody said that static typing guaranteed correctness - just that it could catch certain classes of errors.

The fact that it compiles tells you nothing about whether or not it is going to work correctly. All it tells you is that your types have correctly conformed to the type system, which you could call internal consistency. Those are completely different things. Also, what you are saying about Python is equally true for C++. A type system does not guarantee you are testing all code paths.

So, I guess you don't wear a seatbelt, because it can't save you from all traffic-related injuries?

Now here is an error you are never going to see regularly using Python, but is easy to trigger in C++ and the type system does nothing to save you:

The only reason Python doesn't have that problem has nothing to do with type safety and everything to do with how Python implements integer arithmetic. Anyway, I'm sure you can find better examples to illustrate your point, except it's a point that's not actually in dispute.

It's not only about the design though, I can rapidly iterate on something and test it immediately in my browser in a dynamic language. I can even setup my workflow to immediately reload my page/application the minute I save. One downside that you simply cannot overcome in using a type system are the compile times.

I don't personally use this stuff, but allegedly there are editors that will interactively evaluate C++, as well. I think this is one reason for LLVM's popularity - that you can build it into different sorts of tools, with that being one specific example I've encountered.

Anyway, I think this conversation has run its course. Thanks for sharing your views.

[tildearrow]

you can, pass array.data()

Thanks.

[tildearrow]

presumably that's nothing for java people

Sorry? I thought most Java apps were tiny? (Minecraft is ~20MB, code only)
Bloat has only been a trend lately.

[tildearrow]

No, yet multiple people are reading these posts!

Originally, I asked you to tell "us", meaning to post in the thread the results of any experiments you try. Consistent with that, I was thanking you for doing so.

The reason I didn't simply ask you to tell "me" what you found is that I thought it would seem more like a request to direct-message me. I didn't want to encourage that, since I thought there might be others also interested in your results.

I see. Sorry. I didn't mean to direct-message you.

Sure, nobody is making you use such tools, but they're provided for good reasons. It's worth understanding them and what they can do to mitigate verbosity of your code, since that hurts readability and ultimately reduces code quality.

One tip I'd share: when using deeply-nested names, I'll frequently use the using keyword at some local scope. Perhaps this is a more palatable compromise?

Thanks for the tip. I use "typedef std::string string;" often.