maria-developers team mailing list archive
Mailing list archive
Re: [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/
>>>>> "Kristian" == Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:
Kristian> Davi Arnaut <davi@xxxxxxxxxxx> writes:
>> On Thu, Jul 26, 2012 at 5:50 PM, Igor Babaev <igor@xxxxxxxxxxxx> 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
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.
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
Kristian> - Virtual functions are definitely out (in struct as well as members).
Kristian> - Constructors and destructors also must not be defined for such structs (or
Kristian> its members).
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> - 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.