Re: [Boost-users] size_type doubts / integer library..

From: Andrea Denzler (andrea_at_[hidden])
Date: 2008-08-18 12:15:50

> You never said anything like that in your previous email. However, you do
> realize that the standard says very few things about binary layout? So
> sizeof(struct { char a; int b; }) is usually > sizeof(char) + sizeof(int).

It's more than 20 years that I code in C and Assembler, so yes, I know this.

Sometimes it's important to care about the memory usage despite memory
alignment performance issues. Using 16bit and not 32bit reduce memory usage
a lot.

> You can also write your own template type that takes bitsize (or value
> range)
> and resolves to the smallest native integral able to satisfy the
> requirement.

Sure, we know all that C/C++ fortunately allows to do that. But if such
tasks, like cross platform serialization are so common, why not introducing
them as a standard like with the STL.

> > wchar_t is horribly defined. Sometimes 1 byte, on windows 2 byte, on
> most
> > unix platforms 4 byte. Not only the size is different but also the
> So you are saying the standard should have decided on a byte size for
> wchar_t

What I mean is that there should be a crossplatform solution for defining
all characters. Unicode DO THIS. wchar_t not. So wchar_t is useless for real
crossplatform i18n applications. On Windows it even breaks the definition of
the wchar_t requiring that one wide char represent all possible characters
for that system, that's not true on Windows because for rare combinations
you need two wchar_t.

> No here I think you are wrong. wchar_t is not supposed to help you work
> with Unicode. 

The effect is that wchar_t is confusing and useless for crossplatform i18n.
Once you realize this, you just avoid to use wchar_t. Nice for being a
standard. I want to create applications running on different platforms
without a nightmare.

> You are saying that besides the native integral types (and native
> character types) C++ should offer you some fixed integer types (and some
> fixed character encoding types). C++0x will offer both from what I
understand.

Yes, fixed integral types is enough. 

A Unicode point is just a number. Sure a standard function for
decoding/encoding from the current locale to Unicode characters is welcome.
Even better if I can write directly a Unicode text to a i/o stream.

> Yes, that's what all people do in their portable layer creating portable
> types. Notice that just integer size and byte endianess is not all it
> takes to make it portable. 

Since it's so widely used why not introduce in the standard a common
serialization encoding for (fixed size) integral types for all applications?
Why everyone must invent hot water again?

> I haven't described this to advertise the library just to say that IMO it
> is quite normal for a low level language like C++ to provide native types
> of  which representation depend largely on the platform. 

Yes, I know this very well.. in the past performance issues was much more
important than today. And 30 years ago issues like crossplatform
serialization or i18n didn't exist. But today it's different.

> Huh? Where in the standard does it says that the unsigned type has to use
> all the bits? 

I want that my code is portable. I have a overflow because on common
platforms the unsigned type use all bit's when handling signed/unsigned. Are
you telling me to compile only on Unisys MCP to avoid the overflow?

> Of course there is a need (otherwise they wouldn't be in C++0x). I'm just
> saying C++ native types are not flawed because of not providing that. They
> are not the tool for that, plain simple.

The simple fact that -1 < 2U returns false without giving me any warning is
a issue. C++ is IMHO the best language in the world, I love it, I loved C
since the first day long time ago. But there are issues... there is plenty
of room to improve it. Do you really think that a over 30 years old language
has no issues today???

The best path is to extend and improve it... so that I benefit new features
on existing code.