Why does C++ think my class is copy-constructible when it can't be?

64 pointsposted 8 months ago
by ibobev
(devblogs.microsoft.com)

36 Comments

rich_sasha

8 months ago

I used to code C++ in early 00s and used to think I know the language OK. Then I stopped using it, meanwhile C++11 and friends came, along with lambda syntax, move semantics etc. - that was a jump but I could still just about follow.

Now I don't follow anymore. It's a new language on top of new language on top of new language. On top of C++. On top of C.

Night_Thastus

8 months ago

C++11 introduces a lot of things that make it far, far easier to work with. I would not want to go back to a pre-11 environment.

As for everything after that, you don't need to use those features. You can still write C++ like it's '11 and be none the lesser. That's what I do. Keep it simple.

Bekwnn

8 months ago

In a similar boat with C++, but even the complexity of fundamental "simple C++" issues and lack of syntax sugar made me gravitate away from C++ to better-C style languages ultimately landing on Zig.

Using another language has only made me feel C++'s shortcomings more strongly than before.

Stroustrup even gave a talk about what a new C++ next language would look like and lands on many things better C languages already have implemented.

Sadly it's doubtful for gamedev to move away from C++ anytime soon. I am enjoying Vulkan+SDL in Zig on a personal project and can only hope that space of the language's community continues to grow.

Night_Thastus

8 months ago

I find a lot of the syntactic sugar problems can be solved with a library. I use QT for a lot of my work and it is a fantastic library that saves me a lot of time. Using its strings are a breeze, not to mention QFile/QFileInfo/QDir for anything file related, QProcess for running external processes, etc. It's rich, well documented, and highly functional.

addaon

8 months ago

Yeah. C++11 was very much a new language “on top of” C++ — but it was a so much better language that learning it was a joy, and using anything predating it would be crazy. The minor tweaks since then are at times visually stunning (and not always in a good way), but are in the end quite minor, and can be safely ignored.

bennettnate5

8 months ago

The frustrating thing with layer-cake languages like C++ is that it can technically have all the ergonomic APIs that make life nice to write, yet have all this cruft and esoteric edge-case behavior that makes it so, so hard to read. I can't safely ignore features in C++ that others are using when I'm evaluating the correctness and security implications of already written code. And barring a strictly enforced (e.g. mandatory lint before merging) coding convention that bars all the nasty sharp points and legacy APIs, even a new project will gradually accrue the bad bits from devs who are used to using C++ that way.

Night_Thastus

8 months ago

All languages that are sufficiently widely used eventually become 'layer-cake' languages.

It's inevitable once you have multiple big groups of people with very different needs. And once language design and best practices has evolved from where it was when the language was originally developed.

The only ones that escape this problem aren't widely used enough to have much demand for new features or changes.

rich_sasha

8 months ago

Yeah, I'm not saying these are bad changes! Only that it's so changed that I cannot read modern non-noddy C++, having been previously at least conversational, maybe fluent in it.

adrian_b

8 months ago

There are also some features that have been introduced later, but which are so simple that they do not increase the cognitive load, so there is no need to avoid them.

For example, C++14 has introduced a digit separator in numbers, some 35 years after Ada. For me this is an extremely useful feature, because I have to use big constants from time to time, even if I hate any contributor to the C++ standard who has thought that instead of using underscore as the digit separator, like in Ada and in many languages that have followed Ada, it is a good idea to replace the underscore with the apostrophe.

There has never been any valid argument for using the apostrophe instead of the underscore. Underscore would have introduced a few subtle complications when parsing legacy programs, but that is also true for the apostrophe. Such complications could have been trivially avoided by forbidding a number to start with a separator.

dh2022

8 months ago

I have the same feeling. It seems to me these copy/move semantics are done for performance reasons, and at the same time are very hard to follow / use / implement correctly. Today I would rather use C or assembly language than C++. At least I know what I am doing.

acchow

8 months ago

Not just performance. They enable smart pointers, reducing memory leaks and simplifying memory management

ainiriand

8 months ago

They are a shot in the foot waiting to happen.

sitzkrieg

8 months ago

because people began to understand c++ again, the arsenal has expanded

saurik

8 months ago

The =default syntax might be new, but this should work the same if you use {}... I think this semantic has been the same the whole time I've used C++ (which seems to be a lot longer than you)? (Or like, is the issue with using the is copy constructable check from the standard library? Back in the late 90s we all had those, just in bespoke libraries.)

rramadass

8 months ago

> I think this semantic has been the same the whole time

Yes; When you provide any of the "standard" ctors the compiler goes hands off leaving it entirely up to you to do the calls to any of the base ctors.

The article was just Raymond being surprised since as somebody else has already pointed out the api name is a bit of a misnomer.

saurik

8 months ago

Yeah: I am not responding to the article, or Raymond's surprise; I am responding to the comment of someone here annoyed at recent C++.

pjmlp

8 months ago

If only C added the C++ niceties in regards to bounds checking types, namespaces, modules, strongly typed enumerations,...

Still waiting for that C+ to come out of WG14.

sph

8 months ago

I have the same issue. Every time I feel I want to get better at C++ and learn what changed in the past 2 decades, I also have to contend with the fact that I'll have to learn cmake, that package management is non-existent, that compile times are atrocious and let's not forget the whole template abomination.

The day I need the performance and guarantees C++ can give me is the day I'll dive deep into Rust instead.

rramadass

8 months ago

The article points out this;

The rule for determining copy constructibility is whether a non-deleted copy constructor is present. In the case of Derived, it is present. It may not be instantiatable, but that’s not what is_copy_constructible looks for.

That is what you need to know.

HelloNurse

8 months ago

It's the best that a compiler can be reasonably expected to do.

calmbonsai

8 months ago

C++ is the language you get when the design praxis is "yes to everything".

It was my "daily driver" in the late '90s, but I would never touch it again outside of specific domains such as gaming.

kazinator

8 months ago

This whole article is a very verbose way to reach the conclusion that std::is_copy_constructible_v is a poorly chosen name, not reflecting the actual truth that the construct provides.

If it were called std::has_copy_constructor, there would be no need to write even the title of this article, let alone the body.

Also, maybe this should require a diagnostic due to it being statically obvious that it is calling a deleted constructor:

  Derived(Derived const& d) : Base<T>(d) {}
... and if we use regular non-template classes, it does!

Clang:

  #include <type_traits>

  struct Base
  {
    // Default-constructible
    Base() = default;

    // Not copy-constructible
    Base(Base const &) = delete;
  };

  struct Derived : Base
  {
    Derived() = default;
    Derived(Derived const& d) : Base(d) { }
  };
Clang:

  copy-constructor.cc:15:33: error: call to deleted constructor of 'Base'
     15 |     Derived(Derived const& d) : Base(d) { }
        |                                 ^    ~
  copy-constructor.cc:9:5: note: 'Base' has been explicitly marked deleted here
      9 |     Base(Base const &) = delete;
        |     ^
  1 error generated.
If the program requires a diagnostic which allows it to be rejected entirely, it then doesn't matter what is_copy_constructible returned.

The only reason we don't get a diagnostic is that the language plays it loose with templates, in many cases deferring type checks until instantiation.

It is possible to argue that is_copy_constructible isn't necessarily badly named, but rather foiled by templates.

celrod

8 months ago

I agree.

The problem with eager diagnostics and templates is that the program could define a `Base<int>` specialization that has a working copy constructor later. [0]

I think if you define an explicit instantiation definition, it should type check at that point and error. [1] I find myself sometimes defining explicit instantiations to make clangd useful (can also help avoid repeated instantiations if you use explicit declarations in other TUs).

[0] https://en.cppreference.com/w/cpp/language/template_speciali...

[1] https://en.cppreference.com/w/cpp/language/class_template.ht...

muststopmyths

8 months ago

I would argue that has_copy_constructor would also have the same issue in naming since most people would assume that has_copy_constructor means the damn thing works for copying.

Too many traits is my diagnosis, so I agree with "foiled by templates". Like almost any attempt to make a sane C++ codebase.

HelloNurse

8 months ago

> most people would assume that has_copy_constructor means the damn thing works for copying

Assumptions that something "works" in C++ are generally too nuanced and optimistic to be a good idea. Calling the test "has_copy_constructor" would at least make explicit that it is a test about what declarations a class contains, which is a very rough compile-time approximation of being copy-constructible in practice: a valid declaration is only the first step towards calling a constructor without runtime errors and other trouble.

quuxplusone

8 months ago

> If it were called std::has_copy_constructor, there would be no need to write even the title of this article

Ah, but then someone might ask "Why does the library report that my type has no copy constructor, when it is in fact copyable?" And then the blog post would have to be about how it's possible for a type to be copy-constructed using a constructor (or constructor template) that is not itself a copy constructor.

Of course, the existing state of C++ doesn't prevent us from having to write that blog post, either!

unddoch

8 months ago

It wouldn't be the same trait, for example

https://stackoverflow.com/questions/43606777/why-is-class-wi...

kazinator

8 months ago

You mean, it still wouldn't be an accurate name? Maybe has_const_copy_constructor?

unddoch

8 months ago

I guess it's better, but with C++ being C++, you will then need to decide if you consider

struct A { A(const volatile& A); };

as a class with a const copy constructor. Maybe someone cares?

Proper templated classes don't behave like this. If you manually define a copy constructor in a template class it has to work. And if it works only conditionally (like in many container classes) you need to add constraints on your constructors (>C++20) or derive from appropriately specialized base classes (e.g. std::_Optional_base in libstdc++).

It sucks to tell users "you're holding it wrong", but I don't think there's a way to make it simpler without breaking everything written since C++11.

kazinator

8 months ago

The extra qualification doesn't prevent it from taking const objects, so ...

keybored

8 months ago

Sometimes C++ let’s me read a Raymond Chen article. Which is nice of it.

etbebl

8 months ago

The real wtf here is templates, right? Am I right in thinking that if Derived wasn't a template, its copy constructor that tries to use a deleted parent copy constructor would fail to compile?

revskill

8 months ago

[flagged]

user

8 months ago

[deleted]