← Back to team overview

maria-developers team 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
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.


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).


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>    compilers.


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.