How the STL Uses Explicit

https://quuxplusone.github.io/blog/2024/06/25/most-stl-ctors-arent-explicit-but-yours-still-should-be/

by jandeboevrie • 2 years ago

67 37 2 years ago

quuxplusone.github.io

jimbob45• 2 years ago

Was there ever a reason given as to why “explicit” was chosen over a hypothetical “implicit”?

In C++ because of how it developed the defaults are not optimal. For example, constructors and conversions are implicit and you have to make them explicit. Variables are default mutable and you have to make them const. Local primitive variables are default unitialized by default.

JTyQZSnP3cQGa8B• 2 years ago

Variables are default mutable and you have to make them const

Except for the captured variables in a lambda which are const unless you use the mutable keyword. Not a bad idea though.

cjensen• 2 years ago

I don't know, but a hypothetical 'implicit' would mean converting all unmarked constructors into explicit constructors... which would have broken a lot of existing code.

pjmlp2• 2 years ago

Many of the original C++ decisions come back to how it was supposed to be Typescript for C, which was a reason why it became widely used, and why some warts are the way they are.

Like having C structs magically turn into C++ ones, thus implicit rules like these.

Anyone that cares about C++ evolution should read "Design and Evolution of C++", not only for how it came to be, also for safety approaches over plain C, that Bjarne is stil arguing for to this day on WG21 meetings.

senkora2• 2 years ago

I don't understand. When does a C89 struct display implicit conversion behavior that would justify making C++ class constructors implicit by-default?

For example, the following code does not compile with either -std=c89 or -std=c++98, but does compile if we uncomment the constructor line:

    struct Foo {
      int x;

      /*public: Foo(int x) : x(x) {}*/
    };

    int main() {
      struct Foo foo = 5;
      return 0;
    }


    $ gcc -std=c89 tmp.c
    tmp.c: In function ‘main’:
    tmp.c:8:20: error: invalid initializer
        8 |   struct Foo foo = 5;
          |                    ^
    $ g++ -std=c++98 tmp.c
    tmp.c: In function ‘int main()’:
    tmp.c:8:20: error: conversion from ‘int’ to non-scalar 
    type ‘Foo’ requested
        8 |   struct Foo foo = 5;

Maybe I'm missing something?

lenkite• 2 years ago

I guess if Stroustrup had made "explicit" constructors the default, the C-graybeards would never have adopted C++. Far too much work in porting.

metadat3• 2 years ago

How can the C++ statement below even compile? Since "1" and "2" are strings (not even chars).

  std::vector<int> v = {"1", "2"} // UB

Rather than undefined behavior I'd expect a type violation error. But my C++ has gotten a bit rusty.

ramon156• 2 years ago

Id argue that c++ is not type safe. Yes, strings could be converted to ints in theory, but these types are obviously not the same, why not make it more explicit?

maleldil• 2 years ago

Type safety isn't binary but a spectrum. It's obvious that C++ is more type-safe than JS but less than Rust, which is less than Haskell.

mofeien• 2 years ago

I agree. C++ is statically typed, as in everything has a type known at compile time. But it is also weakly typed, as in types can be be converted into others implicitly which only makes sense a fraction of the time and readily introduces accidental UB at other times.

jandrewrogers• 2 years ago

You can make it both stricter and more explicit. This is a 30 year old API from when C++ was a very different language. In a modern context, this example was explicitly designed to be as loosely checked as it is, it isn't intrinsic.

Backward compatibility means they can't change this API to not allow these cases even if it is straightforward to do so.

GrantMoyer• 2 years ago

It's simple: "string" literals in C++ are pointers to characters. std::vector has a constructor which takes a begin and end iterator and creates a vector with contents copied from that range. Pointers are iterators in C++, and chars are implicitly convertible to ints, so overload resolution selects the aforementioned constructor. The pointer to "1" and the pointer to "2" don't point into the same object, so trying to iterate from one to the other eventually causes a dereference past the end of "1" which is undefined behavior.

metadat3• 2 years ago

I don't know about simple, haha, but thank you so much for explaining in depth!

jiggawatts• 2 years ago

This... this is why I gave up C++ programming and have not looked back.

mwkaufma2• 2 years ago

It's matching std::vector's implicit constructor which takes two iterators, which can be initialized with any pointer. Note that it won't compile with one, three, or more string-literal char*s, but exactly two.

metadat3• 2 years ago

Why only exactly two?

The whole "UB but it still compiles" thing, is pretty gross.

ycombinatrix• 2 years ago

my C++ has gotten a bit rusty

i see what you did there

How the STL Uses Explicit

Related Stories