Greg Herlihy wrote:
> kanze wrote:
> > "Kristof Zelechovski" wrote:
> > > Uzytkownik "abadura" <abadura@o2.pl> napisal w wiadomosci
> > > >   I considered also implemenation with first coping to a help buffer,
> > > > but the size of the buffer is dynamic (value of n is not deterimned and
> > > > its maximal value can be to big to have a buffer that large "just in
> > > > case"). But the dynamic allocation is not possible because of
> > > > possibility of failur. And move cannot fail.

> > > It can throw if the assignment does.

> > Assignment of what.  The very first paragraph in Chapter 21 says
> > that charT (not yet named as such) must be a POD.  Which means
> > that 1) user defined operator= is forbidden, and 2) memcpy and
> > memmove are garanteed to work.  (This rather makes one wonder
> > why move, copy and assign are even part of char_traits.  Other
> > than to make more work for the implementors.)

> I believe that the POD restriction applies only to
> instantiations of the standard library's char_traits general
> template.

And to basic_string.  And (presumably) to instantiations of
basic_streambuf, et al., and (perhaps) to instantiations of the
classes in locale.

It's true that the standard doesn't really say, and that as
introductory text to Chapter 21, one might suppose it to be
limited to that chapter.  Except, of course, other chapters base
themselves on char_traits, as defined in the chapter.  And one
of the requirements on char_traits is that
char_traits<>::char_type be a "character container type",
whatever that is.

> Presumably a program would be free to define an explicit
> specialization of char_traits and use a non-POD type of its
> own as the specialized type.

Perhaps.  But how would you use it with e.g.  std::basic_string?
There the standard is clear: "For a char-like type charT[...]".

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Uzytkownik "abadura" <abadura@o2.pl> napisal w wiadomosci
news:1159133973.211868.19760@i42g2000cwa.googlegroups.com...
>   Lets consider another example lets have a type:
>
> struct my_char {
>   char code : 4;
> };
>
> char must be at least 7 bits long to store all values the Standard
> guarantees it is able to store, so 4 bits is less then the size of char
> type on any implementation. Now lets write char_traits for such a type.
> Writing copy is easy because of the precondition (even if we allow the
> overlap i described in point 1) it is still a portable implementation
> in a signle loop - back coping).
>   But what to do with move? We cannot use memcopy because it will not
> work as specification says. Note that we do not know how type my_char
> is stored in memory. This can be easly ilustrated by next example:
>
> my_char arr[2];
>
> How many "bytes" will be used by this array? Perhabs implementation has
> 8 bit char type and allows to "pack" somehow my_char so both will be in
> the same char and the array will ue one byte. This is the easy case

I do not think so.  The implementation is required to provide a value for
arr + 01 and would have to support bit pointers for that.  That is too
weird.

>   I considered also implemenation with first coping to a help buffer,
> but the size of the buffer is dynamic (value of n is not deterimned and
> its maximal value can be to big to have a buffer that large "just in
> case"). But the dynamic allocation is not possible because of
> possibility of failur. And move cannot fail.
>

It can throw if the assignment does.
Chris


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> >   I considered also implemenation with first coping to a help buffer,
> > but the size of the buffer is dynamic (value of n is not deterimned and
> > its maximal value can be to big to have a buffer that large "just in
> > case"). But the dynamic allocation is not possible because of
> > possibility of failur. And move cannot fail.
> >
>
> It can throw if the assignment does.

   As I remember the Standard did not mentioned anything about
exceptions so I think none can be thrown...

   Adam Badura

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Uzytkownik "abadura" <abadura@o2.pl> napisal w wiadomosci
news:1159472057.155629.46980@i3g2000cwc.googlegroups.com...
>> >   I considered also implemenation with first coping to a help buffer,
>> > but the size of the buffer is dynamic (value of n is not deterimned and
>> > its maximal value can be to big to have a buffer that large "just in
>> > case"). But the dynamic allocation is not possible because of
>> > possibility of failur. And move cannot fail.
>> >
>>
>> It can throw if the assignment does.
>
>   As I remember the Standard did not mentioned anything about
> exceptions so I think none can be thrown...
>

More precisely, it can suffer abnormal termination when the assignment
throws an exception.  It does not throw the exception itself and thus it is
conformant; the standard does not say that it must handle all exceptions
thrown below.

Chris


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Kristof Zelechovski" wrote:
> Uzytkownik "abadura" <abadura@o2.pl> napisal w wiadomosci
> news:1159133973.211868.19760@i42g2000cwa.googlegroups.com...
> >   Lets consider another example lets have a type:

> > struct my_char {
> >   char code : 4;
> > };

> > char must be at least 7 bits long to store all values the
> > Standard guarantees it is able to store, so 4 bits is less
> > then the size of char type on any implementation.

Except that I don't see any requirement that a char_traits on a
user defined type has to support anything that one would
normally call characters at all.  (Maybe if you use it to
instantiate a streambuf, I don't know.)

> > Now lets
> > write char_traits for such a type.  Writing copy is easy
> > because of the precondition (even if we allow the overlap i
> > described in point 1) it is still a portable implementation
> > in a signle loop - back coping).

> >   But what to do with move? We cannot use memcopy because it will not
> > work as specification says. Note that we do not know how type my_char
> > is stored in memory. This can be easly ilustrated by next example:

> > my_char arr[2];

> > How many "bytes" will be used by this array? Perhabs
> > implementation has 8 bit char type and allows to "pack"
> > somehow my_char so both will be in the same char and the
> > array will ue one byte. This is the easy case

> I do not think so.  The implementation is required to provide
> a value for arr + 01 and would have to support bit pointers
> for that.  That is too weird.

> >   I considered also implemenation with first coping to a help buffer,
> > but the size of the buffer is dynamic (value of n is not deterimned and
> > its maximal value can be to big to have a buffer that large "just in
> > case"). But the dynamic allocation is not possible because of
> > possibility of failur. And move cannot fail.

> It can throw if the assignment does.

Assignment of what.  The very first paragraph in Chapter 21 says
that charT (not yet named as such) must be a POD.  Which means
that 1) user defined operator= is forbidden, and 2) memcpy and
memmove are garanteed to work.  (This rather makes one wonder
why move, copy and assign are even part of char_traits.  Other
than to make more work for the implementors.)

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kanze wrote:
> "Kristof Zelechovski" wrote:
> > Uzytkownik "abadura" <abadura@o2.pl> napisal w wiadomosci
> > >   I considered also implemenation with first coping to a help buffer,
> > > but the size of the buffer is dynamic (value of n is not deterimned and
> > > its maximal value can be to big to have a buffer that large "just in
> > > case"). But the dynamic allocation is not possible because of
> > > possibility of failur. And move cannot fail.
>
> > It can throw if the assignment does.
>
> Assignment of what.  The very first paragraph in Chapter 21 says
> that charT (not yet named as such) must be a POD.  Which means
> that 1) user defined operator= is forbidden, and 2) memcpy and
> memmove are garanteed to work.  (This rather makes one wonder
> why move, copy and assign are even part of char_traits.  Other
> than to make more work for the implementors.)

I believe that the POD restriction applies only to instantiations of
the standard library's char_traits general template. Presumably a
program would be free to define an explicit specialization of
char_traits and use a non-POD type of its own as the specialized type.

Greg

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy wrote:
> kanze wrote:
>> "Kristof Zelechovski" wrote:
>>> Uzytkownik "abadura" <abadura@o2.pl> napisal w wiadomosci
>>>>   I considered also implemenation with first coping to a help buffer,
>>>> but the size of the buffer is dynamic (value of n is not deterimned and
>>>> its maximal value can be to big to have a buffer that large "just in
>>>> case"). But the dynamic allocation is not possible because of
>>>> possibility of failur. And move cannot fail.
>>> It can throw if the assignment does.
>> Assignment of what.  The very first paragraph in Chapter 21 says
>> that charT (not yet named as such) must be a POD.  Which means
>> that 1) user defined operator= is forbidden, and 2) memcpy and
>> memmove are garanteed to work.  (This rather makes one wonder
>> why move, copy and assign are even part of char_traits.  Other
>> than to make more work for the implementors.)
>
> I believe that the POD restriction applies only to instantiations of
> the standard library's char_traits general template.

I don't think so; the only specializations required to be
supported by the implementation are for character types
char and wchar_t.

> Presumably a
> program would be free to define an explicit specialization of
> char_traits and use a non-POD type of its own as the specialized type.

I think the intention is that all "character types" must
be PODs.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

   Some questions about char_traits move and copy member functions.

   In the Standard [21.1.1 Character traits requirements] we find that:

X ::assign(c,d)

assigns c=d.

X::move(s,p,n)

for each i in [0,n), performs X::assign(s[i],p[i]). Copies correctly
even where the ranges [p, p+n) and [s, s+n) overlap. yields: s.

X::copy(s,p,n)

pre: p not in [s,s+n). yields: s. for each i in [0,n), performs
X::assign(s[i],p[i]).

1) The precondition to copy "p not in [s,s+n)" does not guarantee that
[p,p+n) and [s,s+n) do not overlap. Simply lets consider an example
string

abcdefg

and have p point to "a", s point to "c" and n be equal to 3. Then
[p,p+n)=abc and [s,s+n)=cde. They overlap on character "c". And still
the precondition is fullified.
   I know the Standard does not say (describing copy) that those ranges
do not overlap but I have such an impression form the descritpion of
move and from any book I looked in for this.

2) Is is possible to write portable move implementation for char type
other the a build in type? I doubt.
   Lets consider another example lets have a type:

struct my_char {
   char code : 4;
};

char must be at least 7 bits long to store all values the Standard
guarantees it is able to store, so 4 bits is less then the size of char
type on any implementation. Now lets write char_traits for such a type.
Writing copy is easy because of the precondition (even if we allow the
overlap i described in point 1) it is still a portable implementation
in a signle loop - back coping).
   But what to do with move? We cannot use memcopy because it will not
work as specification says. Note that we do not know how type my_char
is stored in memory. This can be easly ilustrated by next example:

my_char arr[2];

How many "bytes" will be used by this array? Perhabs implementation has
8 bit char type and allows to "pack" somehow my_char so both will be in
the same char and the array will ue one byte. This is the easy case
when we can use memmove. But it is possible (and very propable) that
implementation will use two bytes and additional bits (beyond the 4 for
code member) will not be used.
   In the second case we cannot use memmove because it will also copy
thos unused bites (perhaps changing them) and tha Standard says that
this operation must behave like assing. assign operation would not
(according to its specification) copy those bits (and perhaps change
them in result). So move cannot do this either. So no memmove since we
do not know how the impelmentation will align the objects in memory
(wheather there will be unused bits).

   The first thing that comes to my head is to write for move a code
like this:

if(p < s) {
 use back coping [copy in loop from last character to first]
} else {
 use "normal" coping [copy in loop from first character to last]
}

but this code again is unportable. Because of pointer comparation. Tha
Standard says [5.9 Relational operators]

(...)
- If two pointers p and q of the same type point to the same object or
function, or both point one past the end of the same array, or are both
null, then p<=q and p>=q both yield true and p<q and p>q both yield
false.
- If two pointers p and q of the same type point to different objects
that are not members of the same object or elements of the same array
or to different functions, or if only one of them is null, the results
of p<q, p>q, p<=q, and p>=q are unspecified.
(...)

So the propsed code will work excelent if indeed p and s are from the
same array. But if we use move to copy onrelated memory blocks then the
comparation in the "if" is unspecified. So we have a problem.
   But on the other hand it is "only" unspecified and not undefined. So
we can use it safely without the worry of crash or something - only the
result for unrelated pointers can be "false" or "true" as the
implementation does. But if those blocks are unrelated than any copy
method (back coping or normal coping) is good so it is indeed no
difference what is the result of such comparation. (And as a wrote
earlier for releated blocks it is all OK.)

   I considered also implemenation with first coping to a help buffer,
but the size of the buffer is dynamic (value of n is not deterimned and
its maximal value can be to big to have a buffer that large "just in
case"). But the dynamic allocation is not possible because of
possibility of failur. And move cannot fail.


   But I dislike the implemantation basing on the "unspecified" and not
"undefined" result of comparation. Is there another way? Or perhaps
memmove can be used and I just do not understend the Standard?

   Adam Badura

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

abadura wrote:
> Some questions about char_traits move and copy member functions.
>
>    In the Standard [21.1.1 Character traits requirements] we find that:
>
> X::copy(s,p,n)
>
> pre: p not in [s,s+n). yields: s. for each i in [0,n), performs
> X::assign(s[i],p[i]).
>
> 1) The precondition to copy "p not in [s,s+n)" does not guarantee that
> [p,p+n) and [s,s+n) do not overlap. Simply lets consider an example
> string
>
> abcdefg
>
> and have p point to "a", s point to "c" and n be equal to 3. Then
> [p,p+n)=abc and [s,s+n)=cde. They overlap on character "c". And still
> the precondition is fullified.
>    I know the Standard does not say (describing copy) that those ranges
> do not overlap but I have such an impression form the descritpion of
> move and from any book I looked in for this.

Then your impression has been corrected. And it's always better to have
the actual constraints turn out to be looser than the supposed set of
constraints than the other way around. In the case of the char_traits
copy operation, the Standard does allow the source and destination
ranges to overlap - but only in a certain way. The intention of the
requirement is no doubt to ensure that the value of every character in
the source range will be certain not to change (as a result of the copy
operation) before that character has itself first been copied to the
destination range.

> 2) Is is possible to write portable move implementation for char type
> other the a build in type? I doubt.
>    Lets consider another example lets have a type:
>
> struct my_char {
>    char code : 4;
> };
>
> char must be at least 7 bits long to store all values the Standard
> guarantees it is able to store, so 4 bits is less then the size of char
> type on any implementation. Now lets write char_traits for such a type.
> Writing copy is easy because of the precondition (even if we allow the
> overlap i described in point 1) it is still a portable implementation
> in a signle loop - back coping).
>    But what to do with move? We cannot use memcopy because it will not
> work as specification says. Note that we do not know how type my_char
> is stored in memory. This can be easly ilustrated by next example:
>
> my_char arr[2];
>
> How many "bytes" will be used by this array?

    sizeof(my_char) * 2

Since sizeof returns the size of the type as an array element.

>    In the second case we cannot use memmove because it will also copy
> thos unused bites (perhaps changing them) and tha Standard says that
> this operation must behave like assing. assign operation would not
> (according to its specification) copy those bits (and perhaps change
> them in result). So move cannot do this either. So no memmove since we
> do not know how the impelmentation will align the objects in memory
> (wheather there will be unused bits).

Calling memmove is fine - in all likelihood the function will copy the
value of the "unused" bits. But it does not matter whether it does or
not. Because even if a program is able to ascertain their value from a
my_char object, the value obtained will be indeterminate according to
the Standard. So any program that relies on that value will have
indeterminate behavior - regardless of whether the my_char object has
ever been copied or not.

Greg

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> > my_char arr[2];
> >
> > How many "bytes" will be used by this array?
>
>     sizeof(my_char) * 2
>
> Since sizeof returns the size of the type as an array element.

   I think so also. But I am not so sure. Can you point specific part
of the Standard? Because it is not so obvious that

sizeof(my_char[2]) == sizeod(my_char)*2

The same is tru for objects. The size of object does not have to be
equal to the sum of the members (and base objects) sizes because for
aligment requiremnts for example.

   But this is not that important in this topic since the thing was
about those "unused bits".

> Calling memmove is fine - in all likelihood the function will copy the
> value of the "unused" bits. But it does not matter whether it does or
> not. Because even if a program is able to ascertain their value from a
> my_char object, the value obtained will be indeterminate according to
> the Standard. So any program that relies on that value will have
> indeterminate behavior - regardless of whether the my_char object has
> ever been copied or not.

   Again. I am not that sure. The Standard says clearly that "move"
must behave like "assign" applied to all characters in range. And
assign does not modify those bits. And even if there is no standard,
portable or any at all way to read or write those bits then we must
consider for example specific devices which use those bits for their
purposes or anything like this.

   Adam Badura

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

abadura ha scritto:
>>> my_char arr[2];
>>>
>>> How many "bytes" will be used by this array?
>>     sizeof(my_char) * 2
>>
>> Since sizeof returns the size of the type as an array element.
>
>    I think so also. But I am not so sure. Can you point specific part
> of the Standard? Because it is not so obvious that
>
> sizeof(my_char[2]) == sizeod(my_char)*2

   5.3.3/2: [...] When applied to an array, the result [of sizeof] is the
total number of bytes in the array. This implies that the size of an
array of n elements is n times the size of an element.

More explicit than that... ;-)

> The same is tru for objects. The size of object does not have to be
> equal to the sum of the members (and base objects) sizes because for
> aligment requiremnts for example.

This a completely different issue, because base-class subobjects can
have different layout from most-derived objects of the same type and
because of alignment issues. For an array you don't have this kind of
problems as all objects have the same type and sizeof() is expected to
take into account the possible padding between elements.

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> More explicit than that... ;-)

> This a completely different issue, because base-class subobjects can
> have different layout from most-derived objects of the same type and
> because of alignment issues. For an array you don't have this kind of
> problems as all objects have the same type and sizeof() is expected to
> take into account the possible padding between elements.

   OK
   You are right.
   However as I wrtoe in previous post this does not matter in the main
topic (but still its good to know, so thanks for info).

   Adam Badura

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

abadura wrote:
> Greg Herlihy wrote:
> > Calling memmove is fine - in all likelihood the function will copy the
> > value of the "unused" bits. But it does not matter whether it does or
> > not. Because even if a program is able to ascertain their value from a
> > my_char object, the value obtained will be indeterminate according to
> > the Standard. So any program that relies on that value will have
> > indeterminate behavior - regardless of whether the my_char object has
> > ever been copied or not.
>
>    Again. I am not that sure. The Standard says clearly that "move"
> must behave like "assign" applied to all characters in range. And
> assign does not modify those bits. And even if there is no standard,
> portable or any at all way to read or write those bits then we must
> consider for example specific devices which use those bits for their
> purposes or anything like this.

First, there is no doubt that memmove will copy the unused bits of a
C++ bitfield. The memmove routine simply sets the value of each byte in
the destination range to match the corresponding byte in the source
range - and does so completely oblivious to whether the C++ runtime, a
C++ program or anything else - considers the value being copied,
"significant".

The important point about my_char's unused bit-field bits is that they
do not participate in its value representation. In other words, however
those bits are set or however their values may change during an
object's lifetime, the value of the accessible (and significant) bits
will not be affected.

Therefore no C++ program needs to be concerned with preserving the
value of the unused bits in a bitfield - because any program that does
rely on their value is doing so without the support of the C++ Standard
- and is therefore on its own.

Greg

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> Therefore no C++ program needs to be concerned with preserving the
> value of the unused bits in a bitfield - because any program that does
> rely on their value is doing so without the support of the C++ Standard
> - and is therefore on its own.

   Then why does the Standard sae EXPLICITLY that move must behave like
assign applied to all characters? This forbids to copy those bits even
if they cannot be used in any other way. And what if I had an array
like:

int arr[10];

and then used move with arr cast to my_char*? Is this unsupported? For
POD types as well? Are you sure?
   And as I already mentioned it is not realy important wheather it is
supported or not as I think, because the condition of behaving like
assing in my opinion forbids to copy those bits.
   Can you point out where the Standard specifies that changes made to
"the environment" that cannot be seen by (proper) C++ code are not
considered as changes at all? And if you can can you also point out
where the Sandard says that those bits indeed cannot be accessed? For
as I know the Standard (I cannot give you specific point right now
because I don't have time to find it, but I know ther is one so if you
insist then I will post it with the next message) that every type can
be cast to array of chars and then for exampel copied by memcopy. So
there is way to access those bits (after the cast)...

   Adam Badura

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]