On 05/25/2017 05:35 AM, Martin Sebor wrote: > On 05/12/2017 07:04 AM, Martin Liška wrote: >> Third part removes TDF_* flags mentioned in the subject. These flags are used >> to enable all passes of specific type and Nathan has recently separated these >> by a new pair of macros. I hope moving these to a separate enum will help >> even more. > > Just as an FYI, the addition of the user-defined constructor makes > the class non-trivial and so unsafe to initialize by calling memset > in C++ 11 and later. In C++ 98 that GCC is compiled with, the class > is not a POD and so not safe to realloc (i.e., new objects must be > brought to life by calling a constructor). I noticed this by testing > my latest patch for the new -Wclass-memassign warning but I thought > it might be worth noting here as well.
Hi. Thanks for heads up. I'm not sure why the class is no longer POD as one can define constructors (but not copy-ctors) in order to preserve a type to be POD? I'm also interested what is the new warning -Wclass-memassign about? > > + /* Constructor. */ > + dump_file_info (); > + > + /* Constructor. */ > + dump_file_info (const char *_suffix, const char *_swtch, dump_kind _dkind, > + int _num); > + > > Also, making the ctor constexpr and defining it in the .c file will > trigger Clang -Wundefined-inline and makes the ctor unusable in other > sources. AFAICS, there is no constexpr context where the constexpr > ctor would be needed so I'm not sure I understand its purpose. Is > it constexpr to allow the static initialization of dump_files[0]? > (All the other elements of the array are dynamically initialized > by calling the other, non-constexpr ctor so that doesn't seem like > the answer.) Yep, that was Richi's objection to use constexpr and I know it's used just for the first elements of the array. Richi? Martin > > Martin
