"Christopher Eltschka" <celtschk@web.de> wrote in message
news:9vq54m$nrr$1@news.tuwien.ac.at...

> Why not support all 4?
>
> case 1: integer<16>::fastest
> case 2: integer<16>::smallest
> case 3: integer<16>::exact
> case 4: integer<16>::emulate
>
> And, of course, unsigned variants.

Has anyone mentioned: http://www.boost.org/libs/integer/integer.htm?

-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://www.research.att.com/~austern/csc/faq.html                ]

"Tony" <tony@my.isp.net> writes:

> "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote in message
> news:slrn9ttjso.6uk.qrczak@qrnik.zagroda...
> > Tue, 30 Oct 2001 15:49:33 GMT, Tinct <tinct@163.com> pisze:
> >
> > > If programmer writes
> > > "integer(0,0x10000000000000000000000000000000000000000")", even
> > > longer than "long int", compiler should also (auto) generate a class
> > > to implement it. It means programer needn't care the platform and
> > > whether it is a 32-bit CPU or 64-bit CPU. It is essential for the
> > > usage in the future and for source code reuse.
> >
> > IMHO it's much more important to have unbounded integers than to be
> > able to generate integer types of an arbitrary size but with size
> > fixed in the type.
>
> Until you want to send something over a wire or write it to disk.

This should IMHO be solved with a generic binary I/O library, just as
text representation is solved with a generic text I/O library (that
is, iostreams).

This library should have sort of a locale mechanism for issues like
byte order, type sizes, etc (but may be much simpler). As a bonus,
conversions from/to UTF-8 and UTF-16 could be provided as well.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Nikolaos D. Bougalis" <nikb@webmaster.com> writes:

> "Ross Smith" <r-smith@ihug.co.nz> wrote in message
> news:3BDE08A3.4FF6C96C@ihug.co.nz...
>
> > Boost has an implementation of some of this.
>
>     Very cool. I was unaware.
>
> > It needs to be a bit more complicated than you imply, though. There are
> > at least four possible interpretations of "int<N>", and there are
> > circumstances where all four would be useful:
> >
> > (1) Give me the most efficient integer type with at least N bits.
> >
> > (2) Give me the smallest integer type, with at least N bits, that is
> > directly supported in hardware.
> >
> > (3) Give me a type with exactly N bits, or a compile-time error if no
> > such type is directly supported.
> >
> > (4) Give me a type with exactly N bits, generating the necessary
> > bit-twiddling code to emulate the type if it isn't directly supported.
>
>     I should have made mention of this in my original post. The decision
> of which of the four to provide, is something that needs extensive
> debate, should the proposal move forward. I am sure that there are
> points to be made for each of the 4 suggestions, however, in my
> experience only the first 3 are useful, and I lean more towards (2)
> with (1) being a close second. Since C99 supports the first 3, it would
> be nice to support the first 3 as well.

Why not support all 4?

case 1: integer<16>::fastest
case 2: integer<16>::smallest
case 3: integer<16>::exact
case 4: integer<16>::emulate

And, of course, unsigned variants.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Christopher Eltschka" <celtschk@web.de> wrote in message
news:9vq54m$nrr$1@news.tuwien.ac.at...
> "Nikolaos D. Bougalis" <nikb@webmaster.com> writes:
>
> > "Ross Smith" <r-smith@ihug.co.nz> wrote in message
> > news:3BDE08A3.4FF6C96C@ihug.co.nz...
> >
> > > Boost has an implementation of some of this.
> >
> >     Very cool. I was unaware.
> >
> > > It needs to be a bit more complicated than you imply, though. There
are
> > > at least four possible interpretations of "int<N>", and there are
> > > circumstances where all four would be useful:
> > >
> > > (1) Give me the most efficient integer type with at least N bits.
> > >
> > > (2) Give me the smallest integer type, with at least N bits, that is
> > > directly supported in hardware.
> > >
> > > (3) Give me a type with exactly N bits, or a compile-time error if no
> > > such type is directly supported.
> > >
> > > (4) Give me a type with exactly N bits, generating the necessary
> > > bit-twiddling code to emulate the type if it isn't directly supported.
> >
> >     I should have made mention of this in my original post. The decision
> > of which of the four to provide, is something that needs extensive
> > debate, should the proposal move forward. I am sure that there are
> > points to be made for each of the 4 suggestions, however, in my
> > experience only the first 3 are useful, and I lean more towards (2)
> > with (1) being a close second. Since C99 supports the first 3, it would
> > be nice to support the first 3 as well.
>
> Why not support all 4?
>
> case 1: integer<16>::fastest
> case 2: integer<16>::smallest
> case 3: integer<16>::exact
> case 4: integer<16>::emulate
>
> And, of course, unsigned variants.

You don't need all four, you can just have the exact number of bits or an
error.  You can generate the fourth with some templated class, and the other
three you could generate with constant expressions, conditionals, and their
ilk inside the 'templated' int parameter.

Assuming int is the most efficient primitive type:

( also assuming:  sizeof(char) * 8 == 8 )

(1) typedef int<sizeof(int) >= 4 ? sizeof(int) * 8 : (sizeof(long) >= 4 ?
sizeof(long) * 8 : sizeof(long long) * 8)> my_incoherent_int_type;
(2) implemented similarly
(3) typedef int<17> my_compile_time_error_most_likely; // except on my
custom PODUNKx86 3MHz processor :)

Note also, that you could significantly clean this up with recursive
templates that do this work for you to produce the compile-time constant.

#4 is requiring to much for a supposed 'primitive' type.  That is the domain
of classes.

Paul Mensonides

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Sounds like more of an application domain standard(s) is(are) required
rather than trying
to make it a language issue.

Tony

"Michiel Salters" <Michiel.Salters@cmg.nl> wrote in message
news:17OG7.18651$xS6.29959@www.newsranger.com...
> In article <BidG7.176152$W8.5854585@bgtnsc04-news.ops.worldnet.att.net>,
Tony
> says...
> >
> >"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote :
> >> Sat,  3 Nov 2001 20:13:22 GMT, Tony <tony@my.isp.net> pisze:
> >
> >> Text formats are much more portable and extensible
> >
> >And much slower and more complex.
> >
> >Tony
> >
> >======================================= MODERATOR'S COMMENT:
> > Warning:  topic drift, standard-related content flatlining.
>
> To get back to topic; since we're about to extend the standard, what
> do you think is a fast & portable way to store data ? XML ? ASN.1 ?
> How should those be handled , from a standard library's point of view?
>
> The only form of portable data we have now is text, and that indeed
> has real-world quality issues. Other "standard" forms usually can't be
> implemented on some platforms on which C++ can be implemented, if only
> for the assumption of 8 bits granularity. Can we find or create
> something better for the new standard?
>
> Regards,
>
> --
> Michiel Salters
> Consultant Technical Software Engineering
> CMG Trade, Transport & Industry
> Michiel.Salters@cmg.nl
>
> ---
> [ 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.research.att.com/~austern/csc/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://www.research.att.com/~austern/csc/faq.html                ]

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote in message
news:slrn9u8nv1.6qb.qrczak@qrnik.zagroda...
> Sat,  3 Nov 2001 20:13:22 GMT, Tony <tony@my.isp.net> pisze:

> Text formats are much more portable and extensible

And much slower and more complex.

Tony


======================================= MODERATOR'S COMMENT:
 Warning:  topic drift, standard-related content flatlining.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <BidG7.176152$W8.5854585@bgtnsc04-news.ops.worldnet.att.net>, Tony
says...
>
>"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote :
>> Sat,  3 Nov 2001 20:13:22 GMT, Tony <tony@my.isp.net> pisze:
>
>> Text formats are much more portable and extensible
>
>And much slower and more complex.
>
>Tony
>
>======================================= MODERATOR'S COMMENT:
> Warning:  topic drift, standard-related content flatlining.

To get back to topic; since we're about to extend the standard, what
do you think is a fast & portable way to store data ? XML ? ASN.1 ?
How should those be handled , from a standard library's point of view?

The only form of portable data we have now is text, and that indeed
has real-world quality issues. Other "standard" forms usually can't be
implemented on some platforms on which C++ can be implemented, if only
for the assumption of 8 bits granularity. Can we find or create
something better for the new standard?

Regards,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Fri,  9 Nov 2001 10:16:35 CST Michiel Salters wrote:
>The only form of portable data we have now is text, and that indeed

Are you considering as non-portable, let us say, IP packets, or SCSI
commands, or PDF files?

The only non-portable formats are those non-documented, not those
not-textual. That is, documented => portable.

--
jk

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <slrn9uuqp7.rr.jk@localhost.localdomain>, Eugene Karpachov says...
>
>Fri,  9 Nov 2001 10:16:35 CST Michiel Salters wrote:
>>The only form of portable data we have now is text, and that indeed
>
>Are you considering as non-portable, let us say, IP packets, or SCSI
>commands, or PDF files?
>
>The only non-portable formats are those non-documented, not those
>not-textual. That is, documented => portable.

Well, in the context of C++, portable for me means, portable across
C++ implementations, even if they're not 8-bits based (DSP/embedded).
IP packets are not portable in and by themselves, but an interface
to them could be. I.e we could specify that an IP packet is accessed
via an iterator to unsigned chars, and an exception is thrown if
any char written is >255.
PDF files and SCSI commands suffer from a similar problem; there's no
standard C++ interface (yet) to read and write them.

Regards,
Michiel Salters

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote in message
news:slrn9ttjso.6uk.qrczak@qrnik.zagroda...
> Tue, 30 Oct 2001 15:49:33 GMT, Tinct <tinct@163.com> pisze:
>
> > If programmer writes
> > "integer(0,0x10000000000000000000000000000000000000000")", even
> > longer than "long int", compiler should also (auto) generate a class
> > to implement it. It means programer needn't care the platform and
> > whether it is a 32-bit CPU or 64-bit CPU. It is essential for the
> > usage in the future and for source code reuse.
>
> IMHO it's much more important to have unbounded integers than to be
> able to generate integer types of an arbitrary size but with size
> fixed in the type.

Until you want to send something over a wire or write it to disk.

Tony

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Sat,  3 Nov 2001 20:13:22 GMT, Tony <tony@my.isp.net> pisze:

>> IMHO it's much more important to have unbounded integers than to be
>> able to generate integer types of an arbitrary size but with size
>> fixed in the type.
>
> Until you want to send something over a wire or write it to disk.

Not at all. Text formats are much more portable and extensible than
memory dumps and it's silly to impose arbitrary limits on numbers,
although I agree that usually 32 bits or 64 bits suffice.

--
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote...
> Not at all. Text formats are much more portable and
> extensible than memory dumps and it's silly to impose
> arbitrary limits on numbers, although I agree that
> usually 32 bits or 64 bits suffice.

Unfortunately, text formats are also typically several times larger and
slower to parse, making them unsuitable for big chunks of data (e.g.,
multimedia applications). Also unfortunately, we can't control the
format of every file in the world. Other people will use binary formats,
like it or not. If your code needs to read or write them, then you need
control over the exact sizes and positions of things.

The code we're working on in the office at present uses text files or a
database for all its own data, but it is essential that we can also
import and export data in certain industry-standard binary formats. The
code we use to do it is littered with platform-dependent #pragmas and
such, because that is simply orders of magnitude easier than writing
anything portable with C++ as it stands. This is one of the most glaring
weaknesses of the language in many contemporary programming
environments, and one desperately in need of fixing in the next revision
of the standard.

Regards,
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.research.att.com/~austern/csc/faq.html                ]

1. wrapper class of build-in type ( in STL )
   like wrapper_int,wrapper_double,wrapper_char..., template pointer
and reference.
example:
   class age : public wrapper_int { ... };
   class my_ref_int : reference < int > { ... };

2. None-null-terminate string literal, enhanced STL string
example:
   "abc" -> {'a','b','c','0'}
   _"abc" -> {'a','b','c'}

More functions should support None-null-terminate string operator.

3. describe math types more accurately:
   now: long int is 32bits or 16bits? It depends on implementation.
   Give programer a way to describe the range and decision.
example:
   integer(0,100) // min 0, max 100
   integer(-32768,32767) // min -32768, max 32767
   real_float(1E+10,1E-20)    //floating-point number, range
(-1E+10,-1E+10), minimal positive number is 1E-20
   real_fix(1E+2,1E-10)  // fixed-point number, range (-1E+2,1E+2),
decision 1E-10
System should map the description to short,long,float or double that
satisfy the requirement.
If none of build-in types satisfies the requirement, system should
generator a new math class to satisfy it!
some build-in type may be pre-defined as:
   type interger(-128,+127) char;
   ...

4. property
in fact, both Borland BCC 5 and Microsoft VC6 already support it.

This attribute can be applied to non-static       virtual data members
in a class or structure definition. The compiler treats
these       virtual data members       as data members by changing
their references into function calls.

When the compiler sees a data member declared with this
attribute on the right of a member-selection operator ( . or -> ),
it converts the operation to a get or put function,
depending on whether such an expression is an
l-value or an r-value. In more complicated contexts,
 such as "+=", a rewrite is performed by doing both get
 and put.

example:
class Date {
public:
 property(read=GetYear, write=SetYear) int year;
private:
void SetYear(int) ...
int GetTear() ...
int _year;
int _month;
int _date;
}

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Tinct wrote:
>
> 1. wrapper class of build-in type ( in STL )
>    like wrapper_int,wrapper_double,wrapper_char..., template pointer
> and reference.
> example:
>    class age : public wrapper_int { ... };
>    class my_ref_int : reference < int > { ... };

wrapper<int> would be more appropriate. Among other things, you can
create your own nonstd::wrapper<> template right now, and hope that
std::wrapper<> gets added to the standard someday.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Tinct" <tinct@163.com> wrote in message
news:5450facb.0110260049.66dc73c2@posting.google.com...

> 3. describe math types more accurately:
>    now: long int is 32bits or 16bits? It depends on implementation.
>    Give programer a way to describe the range and decision.
> example:
>    integer(0,100) // min 0, max 100
>    integer(-32768,32767) // min -32768, max 32767
>    real_float(1E+10,1E-20)    //floating-point number, range
> (-1E+10,-1E+10), minimal positive number is 1E-20
>    real_fix(1E+2,1E-10)  // fixed-point number, range (-1E+2,1E+2),
> decision 1E-10

    This is actually pretty interesting. I have thought about this as a
potential addition to the language, but went with syntax that I find
more suited to C++ than what you propose.

unsigned int<64> i; // 64 bit unsigned integer
int<8> j; // 8 bit integer

    This proposition has a few potential drawbacks -- the use of the
now standard types long & short should most likely be depreciated,
in favor of explicitly sized values to avoid confusion that would
result from conversion, although the standard could use them as
convenient 'aliases' with a platform dependant size.

    As I was thinking about this, it also dawned on me, that this
sort of syntax could be used to modify the syntax used for bitfields
now (yes, bitfields are evil 99% of the time)  so that instead of
writing "int fld : 2" one could write "int<2> fld"

    Type promotion rules for these explicitly sized integral types
could still apply as they do now, so just a short can always be
promoted to an int or a long, so can an int<8> be promoted to
an int<16> or an int<32>.

    It should also be noted, that this sort of syntax and system can
already be implemented using templates if you use "integer" as the
class name (or any other name you like) instead of the reserved
word "int."

    Nik Bougalis
    nikb@webmaster.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://www.research.att.com/~austern/csc/faq.html                ]

"Nikolaos D. Bougalis" wrote:
>
> "Tinct" <tinct@163.com> wrote in message
> news:5450facb.0110260049.66dc73c2@posting.google.com...
>
> > 3. describe math types more accurately:
> >    now: long int is 32bits or 16bits? It depends on implementation.
> >    Give programer a way to describe the range and decision.
> > example:
> >    integer(0,100) // min 0, max 100
> >    integer(-32768,32767) // min -32768, max 32767
> >    real_float(1E+10,1E-20)    //floating-point number, range
> > (-1E+10,-1E+10), minimal positive number is 1E-20
> >    real_fix(1E+2,1E-10)  // fixed-point number, range (-1E+2,1E+2),
> > decision 1E-10
>
>     This is actually pretty interesting. I have thought about this as a
> potential addition to the language, but went with syntax that I find
> more suited to C++ than what you propose.
>
> unsigned int<64> i; // 64 bit unsigned integer
> int<8> j; // 8 bit integer
>
>     This proposition has a few potential drawbacks -- the use of the
> now standard types long & short should most likely be depreciated,
> in favor of explicitly sized values to avoid confusion that would
> result from conversion, although the standard could use them as
> convenient 'aliases' with a platform dependant size.
>
>     As I was thinking about this, it also dawned on me, that this
> sort of syntax could be used to modify the syntax used for bitfields
> now (yes, bitfields are evil 99% of the time)  so that instead of
> writing "int fld : 2" one could write "int<2> fld"
>
>     Type promotion rules for these explicitly sized integral types
> could still apply as they do now, so just a short can always be
> promoted to an int or a long, so can an int<8> be promoted to
> an int<16> or an int<32>.
>
>     It should also be noted, that this sort of syntax and system can
> already be implemented using templates if you use "integer" as the
> class name (or any other name you like) instead of the reserved
> word "int."

Boost has an implementation of some of this.

It needs to be a bit more complicated than you imply, though. There are
at least four possible interpretations of "int<N>", and there are
circumstances where all four would be useful:

(1) Give me the most efficient integer type with at least N bits.

(2) Give me the smallest integer type, with at least N bits, that is
directly supported in hardware.

(3) Give me a type with exactly N bits, or a compile-time error if no
such type is directly supported.

(4) Give me a type with exactly N bits, generating the necessary
bit-twiddling code to emulate the type if it isn't directly supported.

C99 gives you the first three for certain limited values of N. Boost
gives you (1) and (2) for arbitrary N (up to the largest integer size
supported by the implementation). Bitfields give you (4). A unified
syntax for all four would definitely be useful. (Combined, I sincerely
hope, with saner arithmetic conversion rules than we have now.)

--
Ross Smith ...................................... Auckland, New Zealand
r-smith@ihug.co.nz ........................ http;//halflife.mani.ac.nz/
        "A wise man learns from the mistakes of others; a fool
        learns only from his own."     -- Gen. Aleksandr Lebed

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Thanks for you reply.

IMO, programmer writes "integer(0,100)" to describe a integer type
which cover range [0,100] and he don't care whether it is short,int or
long. The implementation of "integer(0,100)" depends on compilers. If
programmer writes
"integer(0,0x10000000000000000000000000000000000000000")", even longer
than "long int", compiler should also (auto) generate a class to
implement it. It means programer needn't care the platform and whether
it is a 32-bit CPU or 64-bit CPU. It is essential for the usage in the
future and for source code reuse.

So, I mean exact-in-description.

And, You mean exact-in-exchange. You care the object size and how to
exchange them. It is also important. But your opinion is of different
purpose from mine.

"Nikolaos D. Bougalis" <nikb@webmaster.com> wrote in message news:<9rj2gj$3jk$1@nntp.webmaster.com>...
>
>     This is actually pretty interesting. I have thought about this as a
> potential addition to the language, but went with syntax that I find
> more suited to C++ than what you propose.
>
> unsigned int<64> i; // 64 bit unsigned integer
> int<8> j; // 8 bit integer
>
>     This proposition has a few potential drawbacks -- the use of the
> now standard types long & short should most likely be depreciated,
> in favor of explicitly sized values to avoid confusion that would
> result from conversion, although the standard could use them as
> convenient 'aliases' with a platform dependant size.
>
>     As I was thinking about this, it also dawned on me, that this
> sort of syntax could be used to modify the syntax used for bitfields
> now (yes, bitfields are evil 99% of the time)  so that instead of
> writing "int fld : 2" one could write "int<2> fld"
>
>     Type promotion rules for these explicitly sized integral types
> could still apply as they do now, so just a short can always be
> promoted to an int or a long, so can an int<8> be promoted to
> an int<16> or an int<32>.
>
>     It should also be noted, that this sort of syntax and system can
> already be implemented using templates if you use "integer" as the
> class name (or any other name you like) instead of the reserved
> word "int."
>
>     Nik Bougalis
>     nikb@webmaster.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://www.research.att.com/~austern/csc/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://www.research.att.com/~austern/csc/faq.html                ]

Tue, 30 Oct 2001 15:49:33 GMT, Tinct <tinct@163.com> pisze:

> If programmer writes
> "integer(0,0x10000000000000000000000000000000000000000")", even
> longer than "long int", compiler should also (auto) generate a class
> to implement it. It means programer needn't care the platform and
> whether it is a 32-bit CPU or 64-bit CPU. It is essential for the
> usage in the future and for source code reuse.

IMHO it's much more important to have unbounded integers than to be
able to generate integer types of an arbitrary size but with size
fixed in the type.

--
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Nikolaos D. Bougalis"  wrote:

> yes, bitfields are evil 99% of the time

So you propose that we _only_ use bitfields.

Your logic is interresting.

  --   VB

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote in message news:<slrn9ttjso.6uk.qrczak@qrnik.zagroda>...
> Tue, 30 Oct 2001 15:49:33 GMT, Tinct <tinct@163.com> pisze:
>
> > If programmer writes
> > "integer(0,0x10000000000000000000000000000000000000000")", even
> > longer than "long int", compiler should also (auto) generate a class
> > to implement it. It means programer needn't care the platform and
> > whether it is a 32-bit CPU or 64-bit CPU. It is essential for the
> > usage in the future and for source code reuse.
>
> IMHO it's much more important to have unbounded integers than to be
> able to generate integer types of an arbitrary size but with size
> fixed in the type.

Do you mean c++ provides a class (for example: integer) supporting
unbounded integers? I think it could be realized by a class like
"vector<class digital>" or so.
We write integer literal as:
100, 100L(to indicate long), 100LL(to indicate long long), at future,
we will write 100LLL.... It looks ugly. So, I suggest that it should
be an uniform format for integer and real literals.  And as mentioned
above, an exact-in-description number type defination is provided in
c++. C++ language should accept interger/real number value/type of
arbitrary range independent on platform or CPU/RAM width.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

    Actually, I do not see where I proposed that we use bitfields.
I merely suggested that the new syntax could be used to eliminate
the ugly (and non-intuitive) "colon size" specification, and to allow
the language to accurately describe sized types without regard
to platform. That is, in my opinion, a benefit.

    Under my proposal, the compiler implementation would be
responsible for providing support for a few predetermined sizes,
namely 64, (perhaps 96) and 128, only if they were not available
on the platform natively -- on a SPARC64 or an Itanium, there is
no point whatsoever in providing int<64> as a template instead
of a built-in type, since support for it is built into the CPU.

    The current template support of C++ lends itself well to this,
both from a perspective of syntax (identical to a template) and
from an implementation standpoint: Think of a template class
called int, specialized for 32, 64 and 128, and this is exactly
what I proposed.

    -n

"Valentin Bonnard" <Valentin.Bonnard@free.fr> wrote in message
news:200110310132.CAA09230@brick.ens.fr...
> "Nikolaos D. Bougalis"  wrote:
>
> > yes, bitfields are evil 99% of the time
>
> So you propose that we _only_ use bitfields.
>
> Your logic is interresting.
>
>   -- VB
>
> ---
> [ 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.research.att.com/~austern/csc/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://www.research.att.com/~austern/csc/faq.html                ]

"Ross Smith" <r-smith@ihug.co.nz> wrote in message
news:3BDE08A3.4FF6C96C@ihug.co.nz...

> Boost has an implementation of some of this.

    Very cool. I was unaware.

> It needs to be a bit more complicated than you imply, though. There are
> at least four possible interpretations of "int<N>", and there are
> circumstances where all four would be useful:
>
> (1) Give me the most efficient integer type with at least N bits.
>
> (2) Give me the smallest integer type, with at least N bits, that is
> directly supported in hardware.
>
> (3) Give me a type with exactly N bits, or a compile-time error if no
> such type is directly supported.
>
> (4) Give me a type with exactly N bits, generating the necessary
> bit-twiddling code to emulate the type if it isn't directly supported.

    I should have made mention of this in my original post. The decision
of which of the four to provide, is something that needs extensive
debate, should the proposal move forward. I am sure that there are
points to be made for each of the 4 suggestions, however, in my
experience only the first 3 are useful, and I lean more towards (2)
with (1) being a close second. Since C99 supports the first 3, it would
be nice to support the first 3 as well.

    Thanks for your comments.

    -n


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hi,
tinct@163.com (Tinct) wrote:
> IMO, programmer writes "integer(0,100)" to describe a integer type
> which cover range [0,100] and he don't care whether it is short,int or
> long. The implementation of "integer(0,100)" depends on compilers. If
> programmer writes
> "integer(0,0x10000000000000000000000000000000000000000")", even longer
> than "long int", compiler should also (auto) generate a class to
> implement it. It means programer needn't care the platform and whether
> it is a 32-bit CPU or 64-bit CPU. It is essential for the usage in the
> future and for source code reuse.

Things like this are best implemented by a C++ class, possibly by a template
taking an integer as a range delimiter. Since integers are limited in size,
it would probably take an exponent 'e' such that the range is from 0 to
10 to the power of 'e' or something like this.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.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://www.research.att.com/~austern/csc/faq.html                ]

"Nikolaos D. Bougalis" <nikb@webmaster.com> wrote...
>     The current template support of C++ lends itself well to this,
> both from a perspective of syntax (identical to a template) and
> from an implementation standpoint: Think of a template class
> called int, specialized for 32, 64 and 128, and this is exactly
> what I proposed.

There was some considerable debate on this subject on
comp.lang.c++.moderated a few months back. Amongst other things, I
suggested the int<32> notation, the discussion moved onto the need to be
more specific about what that means, and several people contributed
ideas about how we might usefully extend that idea. Unfortunately, the
conversation fizzled out before there was an obvious concensus, but
certainly there were many potentially useful ideas mentioned. You might
like to take a look via Google News or some such.

Regards,
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.research.att.com/~austern/csc/faq.html                ]