David R Tribble wrote:

> Perhaps 'istream' and 'ostream' are implemented as typedefs instead
> of actual class names?

Be careful here: you seem to imply that VC++ does the right
thing.

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <380F3FF2.E36309A3@tribble.com>,
  David R Tribble <david@tribble.com> wrote:
> Dave Hardenbrook wrote:
> >
> > francis@robinton.demon.co.uk says...
> >> The problem is that this is just one of several hundred functions
> >> that VC++ fails to place in namespace std
> >
> > One thing I've found in VC++ 6.0 is that when I use streams, even if
> > I've used the directive 'using namespace std', I have to explicitly
> > use scope resolution, e.g. 'std::istream' and 'std::ostream' or I
get
> > a compiler error saying there's a naming conflict.
> >
> > Has anyone else experienced this?  Is somewhere behind the scenes
VC++
> > declaring the iostream classes in the global namespace?
>
> Perhaps 'istream' and 'ostream' are implemented as typedefs instead
> of actual class names?

Of course they are.  The standard mandates that they be typedefs for
basic_istream<char, char_traits<char> > and basic_ostream<char,
char_traits<char> >.  This should not (and does not on VC++) cause a
problem with the using clause.


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

you haven't included both <iostream> AND <iostream.h> have you; resulting in
the stream stuff residing on both the std AND global namespaces??

Dave Hardenbrook <daveh47@mindspring.com> wrote in message
news:MPG.1277fbe649c1b12b989750@news.mindspring.com...
> In article <exHCwaAnBy$3EwcH@robinton.demon.co.uk>,
> francis@robinton.demon.co.uk says...
> > The problem is that this is just one of several hundred functions that
> > VC++ fails to place in namespace std
>
> One thing I've found in VC++ 6.0 is that when I use streams, even if I've
> used the directive 'using namespace std', I have to explicitly use scope
> resolution, e.g. 'std::istream' and 'std::ostream' or I get a compiler
> error saying there's a naming conflict.
>
> Has anyone else experienced this?  Is somewhere behind the scenes VC++
> declaring the iostream classes in the global namespace?
> --
>
>                               -- Dave
> ---
> [ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote in message <380CC323.308A1CDD@tribble.com>...
>Well, no, all three types are small integers, as well as all being
>"character" types.  And that's the whole problem, which is rooted in
>the history of C.

Having missed the boat on the compliance question, I think I've missed
the boat on this one too, so I'll share my thoughts for the entertainment
of others.

I had thought the whole point of declaring that plain char was a third type,
and not a "built-in typedef" for one of the other two, was to divide the
small
integers from the text. I also thought that wchar_t had been deliberately
separated from sign and unsigned shorts for the same reason.
In C++, this lets you overload the textual types one way and the integral
types another, which makes a big difference in (say) formatted I/O.

So I thought I'd prove this by pointing at how the ostream overloads <<
for the three types. To my disappointment, I discover that the signed and
unsigned variants are treated the same as the plain version. (27.6.2.5.4)

Suddenly I find myself agreeing with David. If one part of the standard
clearly
takes the view that signed and unsigned chars are never small itegers and
should be usable wherever plain char is, then so should the rest.

On the other hand, I find it curious that C++ has no way of representing
the smallest integral type available on the target machine. (At least, not
in a way that is always interpreted as an integer.)
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Ken Hagan" <K.Hagan@thermoteknix.co.uk> wrote:
>> Michael Rubenstein wrote:
>
>> >"Ken Hagan" wrote:
>
>> >> If your platform supports a full 8-bit character set but with
>> >> signed chars, your compiler is non-compliant. MSVC is an
>> >> example.
>
>> > How is this noncompliant?  The standard requires char to be at
>> > least 8 bits.  If it is signed the range must be at least -127 to
>> > 127.
>
>> It has always been my understanding that standard C required that the
>> signed-ness of a char was "appropriate" for the character set of the
>> machine. Problems with negative character values include array
>> indexing and conversions to and from int (Is 255 a legal character
>> value? Don't some library routines use -1 as EOF?), so I've taken
>> "appropriate" to mean that naturally occuring character values should
>> be positive...

James.Kanze@dresdner-bank.com wrote:
> I don't believe that standard C says anything about whether the
> signedness should be appropriate.  It does require that all of the
> characters in the basic character set be positive, but this isn't a
> problem, since all of the characters in the basic character set are in
> the original 7 bit US ASCII, and not any of the extended codesets.

For ASCII systems, that's true; they can make plain char either signed
or unsigned.  For other systems this may not be true; for EBCDIC,
plain char must be unsigned, since most of the characters in the
basic character set are greater than 0x80 (e.g., 'a'==0x81, 'A'==0xC1,
and '0'==0xF0).  Porting code between ASCII and EBCDIC compilers
can be quite a pain because of this.

>[...]
> Allowing a signed plain 8 bit char with an 8 bit character set is just
> plain wrong.  IMHO, it should have been forbidden by the C standard.
> But forbidding it would have meant that most of the existing
> implementations at the time would have had to change.  Which in turn
> would have meant that their customer's unportable code would have been
> broken.  Never mind that Kernighan and Richie said from the start that
> it was implementation dependant, and on the second machine to receive
> a C compiler, plain char was unsigned.  Vendors never like to make a
> customer look bad, so most plain char's continue to be signed.

Yep, hysterical raisins.  (Java, anyone?)

-- David R. Tribble, david@tribble.com, http://www.david.tribble.com --
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Dave Hardenbrook wrote:
>
> francis@robinton.demon.co.uk says...
>> The problem is that this is just one of several hundred functions
>> that VC++ fails to place in namespace std
>
> One thing I've found in VC++ 6.0 is that when I use streams, even if
> I've used the directive 'using namespace std', I have to explicitly
> use scope resolution, e.g. 'std::istream' and 'std::ostream' or I get
> a compiler error saying there's a naming conflict.
>
> Has anyone else experienced this?  Is somewhere behind the scenes VC++
> declaring the iostream classes in the global namespace?

Perhaps 'istream' and 'ostream' are implemented as typedefs instead
of actual class names?

-- David R. Tribble, david@tribble.com, http://www.david.tribble.com --
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.1277fbe649c1b12b989750@news.mindspring.com>,
  daveh47@mindspring.com (Dave Hardenbrook) wrote:
> In article <exHCwaAnBy$3EwcH@robinton.demon.co.uk>,
> francis@robinton.demon.co.uk says...
> > The problem is that this is just one of several hundred functions
that
> > VC++ fails to place in namespace std
>
> One thing I've found in VC++ 6.0 is that when I use streams, even if
I've
> used the directive 'using namespace std', I have to explicitly use
scope
> resolution, e.g. 'std::istream' and 'std::ostream' or I get a
compiler
> error saying there's a naming conflict.
>
> Has anyone else experienced this?  Is somewhere behind the scenes
VC++
> declaring the iostream classes in the global namespace?

This will only occur if you have included both <iostream> and
<iostream.h> somewhere within your compilation unit.  You need to be
*very* careful not to mix and match the standard headers with the
legacy headers.


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan <K.Hagan@thermoteknix.co.uk> wrote in message
news:newscache$7qzmjf$ze9$1@firewall.thermoteknix.co.uk...
> Michael Rubenstein wrote in message
> <7uwFOA6ugxAEN=TMkIps=UVER7x8@4ax.com>...
> >
> >On 14 Oct 99 12:31:17 GMT, "Ken Hagan"
> ><K.Hagan@thermoteknix.co.uk> wrote:
> >
> >>If your platform supports a full 8-bit character set but with signed chars,
> >>your compiler is non-compliant. MSVC is an example.
> >
> >How is this noncompliant?  The standard requires char to be at
> >least 8 bits.  If it is signed the range must be at least -127 to
> >127.
>
> It has always been my understanding that standard C required that
> the signed-ness of a char was "appropriate" for the character set of
> the machine. ...

No.  That was at best a recommendation. Just like 'int' is supposed to be
the natural word size, and the conversion of pointers to integers was
supposed to be 'unsurprising'. The corresponding wording in each of those
cases left enough wiggle room for a conforming implementation to ignore
those recommendations.

> ... Problems with negative character values include array
> indexing and conversions to and from int (Is 255 a legal character
> value? Don't some library routines use -1 as EOF?), so I've taken
> "appropriate" to mean that naturally occuring character values should
> be positive...

The standard mandates a large set (93? - my copy of the standard is not
readily available) of specific characters and escape sequences, and madates
that all of them be positive. My understanding is that this does not
prohibit the use of 8-bit code pages with signed characters, as long as none
of the required characters have the sign bit set.




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$7qzmjf$ze9$1@firewall.thermoteknix.co.uk>,
  "Ken Hagan" <K.Hagan@thermoteknix.co.uk> wrote:
> Michael Rubenstein wrote in message
> <7uwFOA6ugxAEN=TMkIps=UVER7x8@4ax.com>...

> >On 14 Oct 99 12:31:17 GMT, "Ken Hagan"
> ><K.Hagan@thermoteknix.co.uk> wrote:

> >>If your platform supports a full 8-bit character set but with signed
> >>chars, your compiler is non-compliant. MSVC is an example.

> >How is this noncompliant?  The standard requires char to be at least
> >8 bits.  If it is signed the range must be at least -127 to 127.

> It has always been my understanding that standard C required that the
> signed-ness of a char was "appropriate" for the character set of the
> machine. Problems with negative character values include array
> indexing and conversions to and from int (Is 255 a legal character
> value? Don't some library routines use -1 as EOF?), so I've taken
> "appropriate" to mean that naturally occuring character values should
> be positive...

I don't believe that standard C says anything about whether the
signedness should be appropriate.  It does require that all of the
characters in the basic character set be positive, but this isn't a
problem, since all of the characters in the basic character set are in
the original 7 bit US ASCII, and not any of the extended codesets.

> John Potter wrote in message <380648d5.10540281@news.csrlink.net>...

> >I'm sure glad to hear that.  Chapter and verse please.  Could you
> >also nail this down for 9 bit char which is signed on a platform
> >supporting full 8-bit character set?

> ...so the 9-bit char would be fine.

> Sadly, I can't quote anything, far less chapter and verse, so I'll
> crawl back into my hole and revise my understanding. However, I won't
> be revising my opinions of vendors that default to signed chars on a
> platform that touts its support for dozens of 8-bit code pages.

I sympathize with you -- I have argued similarly for over ten years.
But the problem isn't MS.  At least they offer an option.  The problem
is that when C was young, most people learned it on a PDP-11, then a
VAX, and took the behavior they saw for standard.  And the behavior they
saw was a plain char that was signed.  (On a PDP-11, there was some
justification.  An unsigned char suffered a real performance hit.)
Since then, compilers with unsigned plain char have been the exception:
all of the Solaris and AIX compilers I've seen have only supported
signed plain char.

Allowing a signed plain 8 bit char with an 8 bit character set is just
plain wrong.  IMHO, it should have been forbidden by the C standard.
But forbidding it would have meant that most of the existing
implementations at the time would have had to change.  Which in turn
would have meant that their customer's unportable code would have been
broken.  Never mind that Kernighan and Richie said from the start that
it was implementation dependant, and on the second machine to receive a
C compiler, plain char was unsigned.  Vendors never like to make a
customer look bad, so most plain char's continue to be signed.

--
James Kanze                    mailto:James.Kanze@dresdner-bank.com
Conseils en informatique orientie objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan wrote:
>=20
> David R Tribble wrote...
>> What would be nice is to have the standard strxxx() functions
>> overloaded for the other flavors of 'char', so that explicit casts
>> are not necessary when calling them, e.g.:
> [snip]
>> Some of us prefer to use 'unsigned char' instead of 'char' because
>> it is more well-behaved for 8-bit character sets.  Something like
>> the code above would be nice for us.
>=20
> I disagree. The signed and unsigned char types are very short
> integers.  Plain char is the only character type. I think this is an
> important (read: worth preserving) type distinction. For one thing,
> it makes it obvious to the next programmer why you've chosen the
> type. For another, it makes it obvious to the compiler, and you can
> overload functions according to whether the argument is intended to
> be a text character or a small integer.

Well, no, all three types are small integers, as well as all being
"character" types.  And that's the whole problem, which is rooted in
the history of C.  What *should* have happened is that 'char' means
a character type, and 'byte/signed byte/unsigned byte' (or something
similar) means a small integer.  (Java, anyone?)  But that's not what
happened, and rather than dictate that 'char' means 'unsigned char',
the ANSI/ISO C89 committee decided to leave it up to the vendors
as to whether 'char' is signed or not.

Which leaves us with sign-extension problems on compilers that make
'char' signed but still allow 8-bit character sets, which was the
state of affairs in 1989 with most compiler implementations.
Hysterical raisins, I'm afraid.  (I've pointed this out in the past,
for things like isprint('=FF') [y-diaresis] versus isprint(EOF), e.g.)

> If your platform supports a full 8-bit character set but with signed
> chars, your compiler is non-compliant. MSVC is an example. However,
> there is a switch to make chars "unsigned". (It is pure brain death
> that they chose to default things this way round.)

Unfortunately, they are compliant.  I agree that using anything
other than an unsigned type for 'char' is madness, but that's what
we're stuck with.

What I was suggesting was that the standard library functions could
be overloaded so that 'char' and 'unsigned char' (and perhaps 'signed
char' for completeness) be allowed to be intermixed a little more
easily (e.g., strlen(const unsigned char *)), so that we really could
use 'unsigned char' as a true "character" type.  Today, though,
it's simply another "small integer" type, and the "true" character
type 'char' is very non-portable and often ill-behaved.

Typically, I solve the problem by using a 'Char' typedef and writing
my own overloaded inline substitutions for strlen() et al.  But
that's exactly what my suggestion was trying to avoid.

-- David R. Tribble, david@tribble.com, http://www.david.tribble.com --
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <exHCwaAnBy$3EwcH@robinton.demon.co.uk>,
francis@robinton.demon.co.uk says...
> The problem is that this is just one of several hundred functions that
> VC++ fails to place in namespace std

One thing I've found in VC++ 6.0 is that when I use streams, even if I've
used the directive 'using namespace std', I have to explicitly use scope
resolution, e.g. 'std::istream' and 'std::ostream' or I get a compiler
error saying there's a naming conflict.

Has anyone else experienced this?  Is somewhere behind the scenes VC++
declaring the iostream classes in the global namespace?
--

                              -- Dave
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 14 Oct 99 12:31:17 GMT, "Ken Hagan" <K.Hagan@thermoteknix.co.uk>
wrote:

: If your platform supports a full 8-bit character set but with signed chars,
: your compiler is non-compliant.

I'm sure glad to hear that.  Chapter and verse please.  Could you
also nail this down for 9 bit char which is signed on a platform
supporting full 8-bit character set?

John


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Michael Rubenstein wrote in message
<7uwFOA6ugxAEN=TMkIps=UVER7x8@4ax.com>...
>
>On 14 Oct 99 12:31:17 GMT, "Ken Hagan"
><K.Hagan@thermoteknix.co.uk> wrote:
>
>>If your platform supports a full 8-bit character set but with signed
chars,
>>your compiler is non-compliant. MSVC is an example.
>
>How is this noncompliant?  The standard requires char to be at
>least 8 bits.  If it is signed the range must be at least -127 to
>127.

It has always been my understanding that standard C required that
the signed-ness of a char was "appropriate" for the character set of
the machine. Problems with negative character values include array
indexing and conversions to and from int (Is 255 a legal character
value? Don't some library routines use -1 as EOF?), so I've taken
"appropriate" to mean that naturally occuring character values should
be positive...

John Potter wrote in message <380648d5.10540281@news.csrlink.net>...
>
>I'm sure glad to hear that.  Chapter and verse please.  Could you
>also nail this down for 9 bit char which is signed on a platform
>supporting full 8-bit character set?
>

...so the 9-bit char would be fine.

Sadly, I can't quote anything, far less chapter and verse, so I'll crawl
back
into my hole and revise my understanding. However, I won't be revising my
opinions of vendors that default to signed chars on a platform that touts
its
support for dozens of 8-bit code pages.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Vesa A J Karvonen <vkarvone@cc.helsinki.fi> wrote in message
news:7u4m57$p1f$1@oravannahka.helsinki.fi...
...
> How often do you use signed chars or unsigned chars as small integers?
>
> I certainly don't remember ever seeing anyone do something like that,
> except when manipulating graphics data, in which case the most readable
> thing is to use a suitable typedef for unsigned char.

It's a fairly common occurance in my work - whenever sufficiently large
tables of data must be stored, if the possible range of values is small
enough that it can be scaled with adequate precision to the range of 0-255.
It might have something to do with the fact that the satellite I'm working
on is expected to produce a terabyte of raw data per day, and comparable
amounts of processed data.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pablo Halpern wrote:
>[...]
> Here is the quick workaround I put in my book (__The C++ Standard
> Library from Scratch__, Que publishers, due out this Nov or Dec.):
>
>    #ifndef MSC_VER_
>    using std::strlen;
>    #endif
>
> Code that uses strlen without std:: will now work with both MS and
> non-MS compilers.  The less-quick workaround (also in my book) is:
>
>    #ifdef MSC_VER_
>    namespace std
>    {
>      inline size_t strlen(const char* s) { return ::strlen(s); }
>    }
>
> This puts strlen both at global and namespace scope, so std::strlen
> works as it should.

What would be nice is to have the standard strxxx() functions
overloaded for the other flavors of 'char', so that explicit casts
are not necessary when calling them, e.g.:

    namespace std
    {
        inline size_t  strlen(const char *s)
        { return std::strlen(s); }

        inline size_t  strlen(const signed char *s)
        { return std::strlen((const char *)s); }

        inline size_t  strlen(const unsigned char *s)
        { return std::strlen((const char *)s); }

        etc...
    }

Some of us prefer to use 'unsigned char' instead of 'char' because
it is more well-behaved for 8-bit character sets.  Something like
the code above would be nice for us.

-- David R. Tribble, david@tribble.com, http://www.david.tribble.com --
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote in message <3804E78F.7B2B6B27@tribble.com>...
>What would be nice is to have the standard strxxx() functions
>overloaded for the other flavors of 'char', so that explicit casts
>are not necessary when calling them, e.g.:
[snip]
>Some of us prefer to use 'unsigned char' instead of 'char' because
>it is more well-behaved for 8-bit character sets.  Something like
>the code above would be nice for us.

I disagree. The signed and unsigned char types are very short integers.
Plain char is the only character type. I think this is an important (read:
worth preserving) type distinction. For one thing, it makes it obvious to
the next programmer why you've chosen the type. For another, it
makes it obvious to the compiler, and you can overload functions
according to whether the argument is intended to be a text character
or a small integer.

If your platform supports a full 8-bit character set but with signed chars,
your compiler is non-compliant. MSVC is an example. However, there
is a switch to make chars "unsigned". (It is pure brain death that they
chose to default things this way round.)
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan <K.Hagan@thermoteknix.co.uk> wrote:
> David R Tribble wrote in message <3804E78F.7B2B6B27@tribble.com>...
[snip]
> >Some of us prefer to use 'unsigned char' instead of 'char' because
> >it is more well-behaved for 8-bit character sets.  Something like
> >the code above would be nice for us.

> I disagree. The signed and unsigned char types are very short integers.
> Plain char is the only character type. I think this is an important (read:
> worth preserving) type distinction. For one thing, it makes it obvious to
> the next programmer why you've chosen the type.
[snip]

Another alternative is to use a typedef for the character type:

typedef unsigned char Char_Type;

It should be quite readable.

> For another, it
> makes it obvious to the compiler, and you can overload functions
> according to whether the argument is intended to be a text character
> or a small integer.
[snip]

How often do you use signed chars or unsigned chars as small integers?

I certainly don't remember ever seeing anyone do something like that,
except when manipulating graphics data, in which case the most readable
thing is to use a suitable typedef for unsigned char.

---
Vesa Karvonen


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 14 Oct 99 12:31:17 GMT, "Ken Hagan"
<K.Hagan@thermoteknix.co.uk> wrote:

>If your platform supports a full 8-bit character set but with signed chars,
>your compiler is non-compliant. MSVC is an example.

How is this noncompliant?  The standard requires char to be at
least 8 bits.  If it is signed the range must be at least -127 to
127.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow <francis@robinton.demon.co.uk> wrote:

>In article <38048ba1.366548248@news.internetconnect.net>, Pablo Halpern
><phalpern@newview.org> writes
>>The less-quick workaround (also in my book) is:
>>
>>#ifdef MSC_VER_
>>namespace std
>>{
>>  inline size_t strlen(const char* s) { return ::strlen(s); }
>>}
>>
>>This puts strlen both at global and namespace scope, so std::strlen
>>works as it should.
>
>Well I suppose patching a broken library implementation is acceptable
>even though the C++ Standard prohibits users from adding such items to
>namespace std.

If the library is non-coforming, it pretty much forces the user code to
be non-conforming ;-)

>The problem is that this is just one of several hundred functions that
>VC++ fails to place in namespace std

Yeah, I was tempted to write entire wrapper header files for all of the
commonly-used C functions, but decided to punt. I use one of my
workarounds on an ad-hoc basis whenever I need a C library name.
Typically, I only need a half-dozen or so functions in a medium-sized
project. The other workaround is to use the .h version (e.g. <time.h>
instead of <ctime>) and not use the std:: prefix for C library names.

P.S. Stan Brown pointed out to me that it should be _MSC_VER, not
MSC_VER_. I got it right in the book, but wrong in my usenet post.
(Thanks, Stan).

-------------------------------------------------------------
Pablo Halpern                            phalpern@newview.org

I am self-employed. Therefore, my opinions *do* represent
those of my employer.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"James Kuyper Jr." <kuyper@wizard.net> wrote:

>MS doesn't place a high priority on conformance to the new C++ standard.
>However, I'd recommend checking to see whether <string.h> gets included
>indirectly through some other header. There wouldn't be much point in
>implementing the <cstring> header file, if they didn't intend to do it
>right.

I've looked at the code and they definately got it wrong. <cstring> is
just a thin wrapper around <string.h> and it doesn't enclose it in
namespace std. The same problem occurs with all of the other c header
files. The worst part is that if you use std::strlen, the compiler will
complain that there is no such identifier.

Here is the quick workaround I put in my book (__The C++ Standard
Library from Scratch__, Que publishers, due out this Nov or Dec.):

#ifndef MSC_VER_
using std::strlen;
#endif

Code that uses strlen without std:: will now work with both MS and
non-MS compilers.  The less-quick workaround (also in my book) is:

#ifdef MSC_VER_
namespace std
{
  inline size_t strlen(const char* s) { return ::strlen(s); }
}

This puts strlen both at global and namespace scope, so std::strlen
works as it should.

-------------------------------------------------------------
Pablo Halpern                            phalpern@newview.org

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38048ba1.366548248@news.internetconnect.net>, Pablo Halpern
<phalpern@newview.org> writes
>The less-quick workaround (also in my book) is:
>
>#ifdef MSC_VER_
>namespace std
>{
>  inline size_t strlen(const char* s) { return ::strlen(s); }
>}
>
>This puts strlen both at global and namespace scope, so std::strlen
>works as it should.

Well I suppose patching a broken library implementation is acceptable
even though the C++ Standard prohibits users from adding such items to
namespace std.

The problem is that this is just one of several hundred functions that
VC++ fails to place in namespace std



Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jonathan H Lundquist <jhl@sssonline.com> writes:

> Should <cstring> declare strlen in namespace std or the global
> namespace.  Namespace std was my assumption until I happened to try it.
> MSVC puts it in the global namespace only.  Of course I realize it
> really doesn't matter here what MSVC does, so I tried to answer this
> from the standard.  D.7.1.1/4 makes reference to std::strlen, but other
> than that I can't find anything there which should answer my question.

It is supposed to be declared in namespace std.  See 17.4.1.2/4.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jonathan H Lundquist <jhl@sssonline.com> writes:

>Should <cstring> declare strlen in namespace std or the global
>namespace.

The standard requires that <cstring> declare all its objects, types,
and functions in namespace std and not in the global namespace.
Not all current compilers comply with the standard.

Refer to 17.4.1.2 and D.5 in the C++ standard.

--
Steve Clamage, stephen.clamage@sun.com
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Should <cstring> declare strlen in namespace std or the global
namespace.  Namespace std was my assumption until I happened to try it.
MSVC puts it in the global namespace only.  Of course I realize it
really doesn't matter here what MSVC does, so I tried to answer this
from the standard.  D.7.1.1/4 makes reference to std::strlen, but other
than that I can't find anything there which should answer my question.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jonathan H Lundquist <jhl@sssonline.com> wrote:

> Should <cstring> declare strlen in namespace std or the global
> namespace.  Namespace std was my assumption until I happened to try it.
> MSVC puts it in the global namespace only.  Of course I realize it
> really doesn't matter here what MSVC does, so I tried to answer this
> from the standard.  D.7.1.1/4 makes reference to std::strlen, but other
> than that I can't find anything there which should answer my question.

It should be in namespace std.

17.4.1.1/2 says that all library entities except macros, operator new and
operator delete are defined within namespace std or namespaces nested within
namespace std.

    -- Darin


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jonathan H Lundquist wrote:
>
> Should <cstring> declare strlen in namespace std or the global
> namespace.  Namespace std was my assumption until I happened to try it.
> MSVC puts it in the global namespace only.  Of course I realize it
> really doesn't matter here what MSVC does, so I tried to answer this
> from the standard.  D.7.1.1/4 makes reference to std::strlen, but other
> than that I can't find anything there which should answer my question.

Section 17.4.1.2 p4 requires that when the cname of C standard headers
are included, "the declarations and definitions (except for names which
are defined as macros in C) are within namespace scope (3.3.5) of the
namespace std."

MS doesn't place a high priority on conformance to the new C++ standard.
However, I'd recommend checking to see whether <string.h> gets included
indirectly through some other header. There wouldn't be much point in
implementing the <cstring> header file, if they didn't intend to do it
right.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]