C++ strange warning about user-provided operator

GullRaDriel

First of all: I know I can silence that warning. But I want to fix it.

I tried my best at it without success.

So, there is a stuct like this:

#SelectExpand
  1struct image_tag_t {
constexpr image_tag_t(
) : c { 0, 0, 0, 0 }
{
}
  6
constexpr image_tag_t(
  char c0, char c1, char c2, char c3
) : c { c0, c1, c2, c3 }
{
}
 12
image_tag_t& operator=(const image_tag_t& other) {
  c[0] = other.c[0];
  c[1] = other.c[1];
  c[2] = other.c[2];
  c[3] = other.c[3];
  return *this;
}
 20
bool operator==(const image_tag_t& other) const {
  return (c[0] == other.c[0]) && (c[1] == other.c[1]) && (c[2] == other.c[2]) && (c[3] == other.c[3]);
}
 24
operator bool() const {
  return (c[0] != 0) || (c[1] != 0) || (c[2] != 0) || (c[3] != 0);
}
 28
 29private:
char c[4];
 31};

Why the hell is it complaining like this:

[ 58%] Building CXX object firmware/application/CMakeFiles/application.elf.dir/main.cpp.obj
/opt/portapack-mayhem/firmware/application/main.cpp: In function 'int main()':
/opt/portapack-mayhem/firmware/application/main.cpp:180:88: warning: implicitly-declared 'constexpr portapack::spi_flash::image_tag_t::image_tag_t(const portapack::spi_flash::image_tag_t&)' is deprecated [-Wdeprecated-copy]
  180 |  m4_init(portapack::spi_flash::image_tag_hackrf, portapack::memory::map::m4_code_hackrf);
      |                                                                                        ^
In file included from /opt/portapack-mayhem/firmware/application/core_control.hpp:28,
                 from /opt/portapack-mayhem/firmware/application/main.cpp:132:
/opt/portapack-mayhem/firmware/common/spi_image.hpp:48:15: note: because 'portapack::spi_flash::image_tag_t' has user-provided 'portapack::spi_flash::image_tag_t& portapack::spi_flash::image_tag_t::operator=(const portapack::spi_flash::image_tag_t&)'
   48 |  image_tag_t& operator=(const image_tag_t& other) {
      |               ^~~~~~~~
In file included from /opt/portapack-mayhem/firmware/application/main.cpp:132:
/opt/portapack-mayhem/firmware/application/core_control.hpp:30:54: note:   initializing argument 1 of 'void m4_init(portapack::spi_flash::image_tag_t, portapack::memory::region_t)'
   30 | void m4_init(const portapack::spi_flash::image_tag_t image_tag, const portapack::memory::region_t to);
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~

Edgar Reynaldo

Change the name of your struct.

GullRaDriel

What ?

SiegeLord

It's just saying that you need to explicitly define the copy constructor image_tag_t(const image_tag_t&). The reason why is that you've provided a custom assignment operator, which implies that you probably mean to insert the same custom logic into the copy constructor.

Alternatively, since you're not actually doing anything special in your custom assignment operator, you could just delete it which removes the need for a custom copy constructor.

This is an instance of this https://en.cppreference.com/w/cpp/language/rule_of_three, although you don't have a custom destructor either.

GullRaDriel

If I'm deleting the operator= it's complaining on lines like this (I agree I didn't report them on first post):

constexpr image_tag_t image_tag_acars { 'P', 'A', 'C', 'A' };

I fixed the warning using your answer. It is working but I would like to know it's done correctly (edit: or if I could have wrote it better):

  image_tag_t(const image_tag_t& other)
  {
    c[0] = other.c[0];
    c[1] = other.c[1];
    c[2] = other.c[2];
    c[3] = other.c[3];
  }

Edited

Kitty Cat

It would probably be better to write it as:

image_tag_t(const image_tag_t& other) = default;
image_tag_t& operator=(const image_tag_t& other) = default;

The default copy constructor/assignment operator behaves as though it copies each class member individually. If that's the behavior you want/need for copying your class, it's best to mark them as default. Given all members of your class being trivially copyable, the implicit/default copy operators will also make your class be considered trivially copyable, which allows the compiler to make stronger optimizations. A custom implementation of those operators, no matter what they're defined to do, makes the class non-trivially copyable.

GullRaDriel

It makes sense. I'll try. Thanks KittyCat, and hello BTW :-)

Thread #618350. Printed from Allegro.cc