Re: [Maria-developers] [Commits] Rev 3353: Performed re-factoring and re-structuring of the code for mwl#248: in file:///home/igor/maria/maria-5.5-mwl248-changes/
Davi Arnaut <davi@twitter.com> writes:
On Thu, Jul 26, 2012 at 5:50 PM, Igor Babaev <igor@askmonty.org> wrote:
+ bzero(column_stats, sizeof(Column_statistics) * cnt);
That's not allowed for non-POD types.
Can you elaborate on exactly when bzero() (or memset() or similar) is allowed or not allowed? I searched in my C++ reference, and did not really find anything ... in fact I did not find anything that said memset(p, 0, sizeof(*p)) would _ever_ be allowed for a class. It is my understanding that even for C, memset(..., 0, ...) is only valid for integer types. Initialising with memset() floating-point and even pointers values is not well-defined! Or did I miss something? I think this is an important issue, as memset() of a C++ class is certainly wrong in many cases, and can lead to subtle and platform-dependent failures. So let's point out clearly the rules that apply, or define such rules if necessary: 1. Does the C and C++ standards define suitable rules? If so, we should use them. However, I suspect that memset() is invalid in standard C and C++ except for arrays of integers, which is excessively restrictive. 2. If C/C++ standard is not sufficient, we need to agree on a coding style (and stay within what works on all reasonable compilers/platforms). I would much prefer to find an existing standards rule or convention. But failing that I would suggest: - Only memset() and memcpy() structs. - Virtual functions are definitely out (in struct as well as members). - Constructors and destructors also must not be defined for such structs (or its members). - Derived classes also should never be memset()'ed. Class inheritance is likely to need extra info on some (present or future) platforms and compilers. - Do not have private: methods in such memset() structs. I do not think it matters to the code generated, but private: is meaningless if arbitrary code is manipulating the memory of the struct directly. Usually I would have no methods at all in structs that I plan to do memset() on. But I suppose we also need to look at what existing code does. Comments? - Kristian.
Hi!
"Kristian" == Kristian Nielsen <knielsen@knielsen-hq.org> writes:
Kristian> Davi Arnaut <davi@twitter.com> writes:
On Thu, Jul 26, 2012 at 5:50 PM, Igor Babaev <igor@askmonty.org> wrote:
+ bzero(column_stats, sizeof(Column_statistics) * cnt);
That's not allowed for non-POD types.
Kristian> Can you elaborate on exactly when bzero() (or memset() or similar) is allowed Kristian> or not allowed? Kristian> I searched in my C++ reference, and did not really find anything ... in fact I Kristian> did not find anything that said memset(p, 0, sizeof(*p)) would _ever_ be Kristian> allowed for a class. In practice it's allowed for any class without any virtual elements and initialization function. Kristian> It is my understanding that even for C, memset(..., 0, ...) is only valid for Kristian> integer types. Initialising with memset() floating-point and even pointers Kristian> values is not well-defined! Or did I miss something? bzero is safe with floating point numbers using the IEEE representation. It's also safe with pointers in all C/c++ implementations I know of as NULL pointer is defined as 0. <cut> Kristian> 2. If C/C++ standard is not sufficient, we need to agree on a coding style Kristian> (and stay within what works on all reasonable compilers/platforms). Kristian> I would much prefer to find an existing standards rule or convention. But Kristian> failing that I would suggest: Kristian> - Only memset() and memcpy() structs. However a calls without virtual functions is same as a struct in memory representation. Kristian> - Virtual functions are definitely out (in struct as well as members). Agree. Kristian> - Constructors and destructors also must not be defined for such structs (or Kristian> its members). Agree. Kristian> - Derived classes also should never be memset()'ed. Class inheritance is Kristian> likely to need extra info on some (present or future) platforms and Kristian> compilers. Agree. Kristian> - Do not have private: methods in such memset() structs. I do not think it Kristian> matters to the code generated, but private: is meaningless if arbitrary Kristian> code is manipulating the memory of the struct directly. Usually I would Kristian> have no methods at all in structs that I plan to do memset() on. Not sure if private matters (don't think it does). Kristian> But I suppose we also need to look at what existing code does. Regards, Monty
participants (2)
-
Kristian Nielsen -
Michael Widenius