how to avoid reinterpret_cas t in this snippet?

[KK]

Hello all,
I have a unsigned char buffer 'buffer[1024]' and I need to convert the
first 12 bytes of it into a string. Below is a code that should work,
however, how can I avoid reinterpret_cas t operator?
Or Is there a simple way to get around this?
Thanks.
-KK
/* not tested yet */
typedef unsigned char BYTE
std::string GetStringFromBy teBuffer(const BYTE* const buffer, int pos )
{
const char *chAry = reinterpret_cas t <const char *> (buffer + pos);
std::string tmp(chAry,12);
return chAry;
}

[Alf P. Steinbach]

* Bob Hairgrove:

On Mon, 05 Dec 2005 01:06:01 GMT, al***@start.no (Alf P. Steinbach)
wrote:

Try

bcc32 -D"_RWSTD_COMPIL E_INSTANTIATE" -w-ccc -w-rch test_uchar.cpp

Hth.,
No, it doesn't really "help" (HTH == "hope this helps") <g>

The basic question remains:
Is it *required* by the C++ standard that your code compiles (and
links)?

Yes, but not that it "works". The working aspect is covered by
conversion from unsigned char to char (not pointers but values). And
this value conversion, although in-practice well-defined on all modern
platforms, is formally undefined behavior language-wise.

To make more sure that it works, not just compiles and links, one would
have to include a compile time assertion like

static unsigned char const polyanna = 156; // Say.
BOOST_STATIC_AS SERT(
static_cast<uns igned char>( static_cast<cha r>( polyanna ) ) ==
polyanna
);

And add the assumption that the original data consists of char values
casted to unsigned char -- but I think that borders on the ludicrious.

And if you think so, please explain why (and not just: "it
does").
By definition of the templated std::basic_stri ng constructor, which is
required to copy the values.

[I hope you realize that the above "hack" can create serious problems
with code that is distributed among different DLLs which rely on
things defined in the DLLs supplied by Borland (e.g., anything even
remotely depending on VCL)?]

No, I didn't realize that, and I don't know that, and it isn't a hack,
it's a compiler invocation. It sounds improbable. But, it's an old
compiler and I don't really care about its undocumented features. ;-)

Hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ron Natalie]

Alf P. Steinbach wrote:

* Ron Natalie:

Alf P. Steinbach wrote:

* Bob Hairgrove:
On Fri, 02 Dec 2005 09:58:35 GMT, al***@start.no (Alf P. Steinbach)
wrote:

>> Since char and unsigned char are different types, you must use either
>> a C-style cast or reinterpret_cas t, as you have done. There is really
>> no way to avoid it if you must pass unsigned char to this function.
> You're the second person to state that so I'm interesting in the
> reeasoning.
The reason? Because std::string has no constructor that takes unsigned
char* as an argument.
That is incorrect.

It is correct.

Nope.

There is NO constructor that takes ONLY a unsigned char* (or even
an unsigned char* and a integer like the OP's original intended use).

[Alf P. Steinbach]

* Ron Natalie:

Alf P. Steinbach wrote:

* Ron Natalie:

Alf P. Steinbach wrote:
* Bob Hairgrove:
> On Fri, 02 Dec 2005 09:58:35 GMT, al***@start.no (Alf P. Steinbach)
> wrote:
>
>>> Since char and unsigned char are different types, you must use either
>>> a C-style cast or reinterpret_cas t, as you have done. There is really
>>> no way to avoid it if you must pass unsigned char to this function.
>> You're the second person to state that so I'm interesting in the
>> reeasoning.
> The reason? Because std::string has no constructor that takes unsigned
> char* as an argument.
That is incorrect.
It is correct.

Nope.

There is NO constructor that takes ONLY a unsigned char* (or even
an unsigned char* and a integer like the OP's original intended use).

So?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?