Dylan

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

std::vector<T> is, no doubt, meant to be a safe good replacement for
C-arrays -- for the most uses. I however doubt that even a C-array of
char is required to have its address suitably aligned to meet the
requirement of an arbitrary type.

--
                                                        Gabriel Dos Reis
                                                         g...@cs.tamu.edu
         Texas A&M University -- Computer Science Department
        301, Bright Building -- College Station, TX 77843-3112

--
James Kanze           GABI Software        mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/     http://www.gabi-soft.fr
                    Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Why do you want to use unsigned char as the underlying type? Is it any
better than plain char when used as "raw memory" (where by "raw memory"
I mean that the only later use will involve reinterpret casts or object
copy).

Consider:

3.9/2 states that POD can be copied back and forth using array of char
OR unsigned char, preserving its value.

3.9.1/1:
"A char [...] AND unsigned char [...] have the same object representation."

There are other places where such properties are defined to be the same
for both char and unsigned char.

The only relevant place that shows some assymetry is 3.9/4:
"The object representation of an object of type T is the sequence of N
unsigned char objects taken up by the object of type T, where N equals
sizeof(T)."

This would state that unsigned char is better than plain char for "raw
memory" uses, but somehow I cannot believe it due to the 3.9.1/1 cited
above.

It was my habit to use unsigned char, but I resigned from it and now
consequently use char buffers when the "raw memory" is what I need.
I just found it more consistent with various API functions, where
pointer to char is expected as a buffer parameter.

I will be glad to know your opinion on this.

--
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

 >I cannot answer your specific question (I can only share your
 >assumptions that it is OK), but there is a place for spinning off a
 >related question.
 >
 >Why do you want to use unsigned char as the underlying type? Is it any
 >better than plain char when used as "raw memory" (where by "raw memory"
 >I mean that the only later use will involve reinterpret casts or object
 >copy).

This is a thorny issue. The question comes down to whether a signed
char may have padding bits and/or trap representations. I'm not sure
the C++ standard was written having in mind a definite answer to that
question. I guess the committee simply thought to make explicit, or
reword, what were the C90 requirements.

However, C90 wasn't particularly clear on this point and there was a
fundamental DR by Clive Feather:

http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_069.html

The response clarified many things that were in the committee
intentions but not explicitly spelt out in the standard text (note:
they didn't mean to change/fix the rules; just to clarify what was
always the case for any conforming C90 implementation). Based on that,
C99 is much more explicit and clear on this topics and there's text,
written by Clive Feather himself, that explicitly allows trap
representations in signed chars (see 6.2.6.2). A C99 implementation
where

    CHAR_BIT  =  10
    UCHAR_MAX =  1023
    SCHAR_MIN = -128
    SCHAR_MAX =  127

would be conforming (I don't know if it really exists, though).

In that scenario, and since C++ certainly aims at C compatibility in
this delicate area, I would say that if the C++ standard says anything
different from C99 that isn't intentional.

PS: You won't believe me but I simply gave up consulting the C++
standard for signed vs. unsigned char issues a long time ago, for the
reasons I said above; never noticed there's a related DR:

http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#350

I had the scruple to check the DR list before hitting the send button,
and it was there :) As you may see, it confirms that much of the
wording you quote was written without a clear intent.

Genny.

I don't know the reasons for the difference between C and C++ here, but
for some reason, they are different.

The key guarantee is just below (in the same paragraph): "For character
types, all bits of the object representation participate in the value
representation."  In the C standard, the equivalent guarantee, for this
and for the memcpy, only holds for unsigned char.  In the C++ standard,
the next sentence also gives food for thought: "For unsigned character
types, all possible bit patterns of the value representation represent
numbers."  I'm not too sure what this is meant to mean: could a 1's
complement machine arrange for all 0's to be positive, and trap on a
negative 0?  (But this would invalidate the memcpy guarantee, supposing
plain char was signed.)

  - I knew C before I knew C++, and got into the habit of unsigned char,

  - it also seems to be the prevailing usage.

The latter point is, IMHO, very important.  I only use plain char for
characters; if I want a small integer, I will use either unsigned char
or signed char, and if I want raw memory, I use unsigned char.
Independantly of what the language allows, this seems to correspond to a
long tradition, and thus communicates my intent better.

The actual type requested by the interface in my case is a dirent*.
However, the interface requires that there some free bytes behind the
dirent -- I can't just pass it "new dirent".  

Formally, the interface takes a struct ending with a VLA.  But we don't
have VLA's in C++ yet.  The correct solution would be to write a small
wrapper in C, and call it from C++.  But I don't have access to a C
compiler, so I'm stuck.  (And to be honest, the interface was designed
before VLA was adopted in C, and was intended to use some awful C
hackery, that is in fact undefined behavior in C, but happens to work on
most systems.)

--
James Kanze           GABI Software        mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/     http://www.gabi-soft.fr
                    Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

unsigned char * ptr = (unsigned char) operator new(requirement);

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

 > what I do not understand is why you do not just use operator new direct:
 >
 > unsigned char * ptr = (unsigned char) operator new(requirement);

Perhaps the storage should grow, preserving the old content.

 > Francis Glassborow      ACCU

thanks,
v

This is probably what I will end up doing.  The context is limited
enough that it isn't really a problem.  I just liked the idea that all
uses of new[] could be subsumed by std::vector; until this case, it has
always been the case in my code.

--
James Kanze           GABI Software        mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/     http://www.gabi-soft.fr
                    Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16