 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Alessandro Molina
Guest
|
 Posted: Sat Sep 25, 2004 10:14 am Post subject: signed/unsigned as fundamental types |
 |
|
The standard defines signed int, unsigned int, etc. as fundamental types. I
was asking myself why they aren't defined as compound types.
defining them as compund types would make possible to unlink signed/unsigned
from int/short/long and use them even when int/short/long are typedeffed.
for something like:
template < typename T >
struct u { typedef unsigned T t; };
to do u<int>::t instead of unsigned int. I know that it's just syntactic
sugar and it's harder to read, it was just an example that came to my mind.
Is there any pratical reason for this limitation?
Wouldn't this be a good idea for next standard revision?
Thanks,
Alessandro
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
kanze@gabi-soft.fr
Guest
|
| Posted: Mon Sep 27, 2004 10:41 am Post subject: Re: signed/unsigned as fundamental types |
|
|
Alessandro Molina <amol (AT) sig11 (DOT) org> wrote
| Quote: | The standard defines signed int, unsigned int, etc. as fundamental
types. I was asking myself why they aren't defined as compound types.
|
Compounds of what? They're primative types because they are (typically)
implemented directly by the hardware.
| Quote: | defining them as compund types would make possible to unlink
signed/unsigned from int/short/long and use them even when
int/short/long are typedeffed. for something like:
template < typename T
struct u { typedef unsigned T t; };
|
That's a different issue. There are cases in template code where you
want the corresponding unsigned type; allowing something like this would
be a possible solution. (Note that you can add a const qualifier like
this.)
On the other hand, it's hard to imagine what this should mean if T were
a user defined type. Even if T is BigInteger, and there is also an
UnsignedBitInteger class, I can't quite see how the compiler is supposed
to make the connection. All of which suggests that some sort of
standard traits class, or maybe a typedef in numeric_limits, would be a
better solution.
--
James Kanze GABI Software http://www.gabi-soft.fr
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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Alessandro Molina
Guest
|
| Posted: Mon Sep 27, 2004 8:16 pm Post subject: Re: signed/unsigned as fundamental types |
|
|
| Quote: | The standard defines signed int, unsigned int, etc. as fundamental
types. I was asking myself why they aren't defined as compound types.
Compounds of what? They're primative types because they are (typically)
implemented directly by the hardware.
|
Good point, obvious thing that I didn't think about. They are actually
really that type.
| Quote: | defining them as compund types would make possible to unlink
signed/unsigned from int/short/long and use them even when
int/short/long are typedeffed. for something like:
template < typename T
struct u { typedef unsigned T t; };
That's a different issue. There are cases in template code where you
want the corresponding unsigned type; allowing something like this would
be a possible solution. (Note that you can add a const qualifier like
this.)
On the other hand, it's hard to imagine what this should mean if T were
a user defined type. Even if T is BigInteger, and there is also an
UnsignedBitInteger class, I can't quite see how the compiler is supposed
to make the connection. All of which suggests that some sort of
standard traits class, or maybe a typedef in numeric_limits, would be a
better solution.
|
That's an issue caused by the fact that not being a compound type the
keyword is 'unsigned int' and not 'unsigned' so the parser takes the
unsigned as 'unsigned int' because signed/unsigned/short by default imply
int and then tries to parse something like 'typedef unsigned int T t;'
which reports a parse error. (that's actually what happens with gcc, don't
know for other compilers)
About the problem with user defined types it's already defined in the
standard. On 7.1.5 it says: "signed or unsigned can be combined with char,
long, short, or int." so trying to compile unsigned BigInteger would report
an error even now.
But nothing would prevents use from specilizing the template for BigInteger
typedeffing UnsignedBigInteger as t.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Tue Sep 28, 2004 10:37 am Post subject: Re: signed/unsigned as fundamental types |
|
|
Alessandro Molina <amol (AT) sig11 (DOT) org> wrote
| Quote: | defining them as compund types would make possible to unlink
signed/unsigned from int/short/long and use them even when
int/short/long are typedeffed. for something like:
template < typename T
struct u { typedef unsigned T t; };
That's a different issue. There are cases in template code where
you want the corresponding unsigned type; allowing something like
this would be a possible solution. (Note that you can add a const
qualifier like this.)
On the other hand, it's hard to imagine what this should mean if T
were a user defined type. Even if T is BigInteger, and there is
also an UnsignedBitInteger class, I can't quite see how the
compiler is supposed to make the connection. All of which suggests
that some sort of standard traits class, or maybe a typedef in
numeric_limits, would be a better solution.
That's an issue caused by the fact that not being a compound type the
keyword is 'unsigned int' and not 'unsigned' so the parser takes the
unsigned as 'unsigned int' because signed/unsigned/short by default imply
int and then tries to parse something like 'typedef unsigned int T t;'
which reports a parse error. (that's actually what happens with gcc, don't
know for other compilers)
|
Implicit int has a long tradition in C (and thus in C++). We've gotten
rid of most of the worst aspects, but I think that declaring that the
int must be there after unsigned would break far too much code to even
be considered. For better or for worse, the fondamental types are:
unsigned char
signed char
char
unsigned short int
signed short int
unsigned int
signed int
unsigned long int
signed long int
float
double
long double
The order of the tokens is irrelevant (i.e. "signed char" and "char
signed" are the same type), and in many cases, you can simplify by
omitting part of the declaration. But the current language definition
is that these are the types; while there is a corresponance between
unsigned int and signed int, they remain two distinct types. It is not
a case where one type is more fundamental than the other, and the other
is made by "modifying" the more fundamental type.
I think part of your confusion is due to the fact that we almost
systematically omit the signed qualifier from all but char (and the
standard also omits in in §3.9.1), whereas the unsigned qualifier is
necessary (and we can omit the int). If you consider that the above is
a canonical list of the types, and that any other forms are just
synonyms for one of these, you basically have the situation in C++.
(There's an interesting anomaly in the C++ standard. The types are
described in §3.9.1, and the legal declarations for them are described
in §7.1.5. There is no specification of which type is actually specified
by any particular legal declaration, however. Most of the time, if not
always, I think it is fairly obvious. But I find the list in §6.7.2 of
the C standard much clearer.)
| Quote: | About the problem with user defined types it's already defined in the
standard. On 7.1.5 it says: "signed or unsigned can be combined with
char, long, short, or int." so trying to compile unsigned BigInteger
would report an error even now.
|
But you were talking about changing the language.
| Quote: | But nothing would prevents use from specilizing the template for
BigInteger typedeffing UnsignedBigInteger as t.
|
The problem is how to write a template on a type T which at some point
needs the corresponding unsigned type for T. Allowing something like
you suggested would solve this problem for the basic types, but not for
user defined integral types. Some sort of traits class solves it for
both.
--
James Kanze GABI Software http://www.gabi-soft.fr
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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Tue Sep 28, 2004 9:28 pm Post subject: Re: signed/unsigned as fundamental types |
|
|
In article <d6652001.0409272353.4a4fc7b8 (AT) posting (DOT) google.com>,
[email]kanze (AT) gabi-soft (DOT) fr[/email] writes
| Quote: | Implicit int has a long tradition in C (and thus in C++). We've gotten
rid of most of the worst aspects, but I think that declaring that the
int must be there after unsigned would break far too much code to even
be considered. For better or for worse, the fondamental types are:
unsigned char
signed char
char
unsigned short int
signed short int
unsigned int
signed int
unsigned long int
signed long int
float
double
long double
|
You missed bool and wchar_t
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Ben Hutchings
Guest
|
| Posted: Wed Sep 29, 2004 9:50 am Post subject: Re: signed/unsigned as fundamental types |
|
|
Alessandro Molina wrote:
<snip>
| Quote: | On the other hand, it's hard to imagine what this should mean if T were
a user defined type. Even if T is BigInteger, and there is also an
UnsignedBitInteger class, I can't quite see how the compiler is supposed
to make the connection. All of which suggests that some sort of
standard traits class, or maybe a typedef in numeric_limits, would be a
better solution.
That's an issue caused by the fact that not being a compound type the
keyword is 'unsigned int' and not 'unsigned'
|
No, the keyword is "unsigned" (standard C++ has no spaced keywords).
Syntactically "unsigned", "short" and "long" are treated similarly to
cv-qualifiers so that for example "int unsigned typedef long ulong;"
is a valid type alias definition. However, as you know they don't
semantically behave like qualifiers and they do have the additional
behaviour of implying "int" now that the general "implicit int" rule
is gone.
| Quote: | so the parser takes the unsigned as 'unsigned int' because
signed/unsigned/short by default imply int and then tries to parse
something like 'typedef unsigned int T t;' which reports a parse
error.
|
Yes; the compiler should decide that "T" cannot be qualified by
"unsigned" and therefore it must be part of the declarator, i.e. it is
the name being given to the type alias. It will then choke on the
following "t".
| Quote: | (that's actually what happens with gcc, don't know for other compilers)
snip |
VC++ behaves similarly.
--
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Eugene Gershnik
Guest
|
| Posted: Wed Sep 29, 2004 5:39 pm Post subject: Re: signed/unsigned as fundamental types |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:
| Quote: |
The problem is how to write a template on a type T which at some point
needs the corresponding unsigned type for T. Allowing something like
you suggested would solve this problem for the basic types, but not
for user defined integral types. Some sort of traits class solves it
for both.
|
//Warning: _not_ C++
type_modifier signedness
{
signed,
unsigned
};
template<signedness S = signed>
class big_integer
{
...
};
unsigned big_integer ui; //same as big_integer<unsigned>
signed big_integer si; //same as big_integer<signed>
big_integer i; //same as big_integer<>
I don't know how feasible is to parse this but it looks nice and allows for
any modifiers in addition to signed/unsigned.
--
Eugene
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Alessandro Molina
Guest
|
| Posted: Wed Sep 29, 2004 5:53 pm Post subject: Re: signed/unsigned as fundamental types |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:
| Quote: | Implicit int has a long tradition in C (and thus in C++). We've gotten
rid of most of the worst aspects, but I think that declaring that the
int must be there after unsigned would break far too much code to even
be considered.
|
I'm not saying that int must be there after unsigned to declare an unsigned
int. The idea was that parsing "unsigned T" should be postponed after the
substitution of T with the correct type so that if it's an int it can be
parsed correctly.
| Quote: | (There's an interesting anomaly in the C++ standard. The types are
described in §3.9.1, and the legal declarations for them are described
in §7.1.5. There is no specification of which type is actually specified
by any particular legal declaration, however. Most of the time, if not
always, I think it is fairly obvious. But I find the list in §6.7.2 of
the C standard much clearer.)
About the problem with user defined types it's already defined in the
standard. On 7.1.5 it says: "signed or unsigned can be combined with
char, long, short, or int." so trying to compile unsigned BigInteger
would report an error even now.
But you were talking about changing the language.
|
Nope 
I'm talking about changing the way it should be parsed.
Postponing the parsing of the unsigned after instancing the template would
solve the problem mantaining full compatibility with the old code.
This is already done for a lot of other things, so why shouldn't it be done
for 'unsigned'? It has to be parsed anyway because the compiler must
unserstand if it has a valid type after it or if it is by itself, so I
don't see any problem about moving that process after template
instantiation.
| Quote: |
But nothing would prevents use from specilizing the template for
BigInteger typedeffing UnsignedBigInteger as t.
The problem is how to write a template on a type T which at some point
needs the corresponding unsigned type for T. Allowing something like
you suggested would solve this problem for the basic types, but not for
user defined integral types. Some sort of traits class solves it for
both.
|
Actually doing unsigned Foobar doesn't work, so I don't understand why we
should make it work with T instead of Foobar. traits solve it perfectly,
that's the way I implemented all at the end, but they are quite longer to
write than just a one line template.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Fri Oct 01, 2004 5:25 pm Post subject: Re: signed/unsigned as fundamental types |
|
|
Alessandro Molina <amol (AT) sig11 (DOT) org> wrote
| Quote: | kanze (AT) gabi-soft (DOT) fr wrote:
Implicit int has a long tradition in C (and thus in C++). We've
gotten rid of most of the worst aspects, but I think that declaring
that the int must be there after unsigned would break far too much
code to even be considered.
I'm not saying that int must be there after unsigned to declare an
unsigned int. The idea was that parsing "unsigned T" should be
postponed after the substitution of T with the correct type so that if
it's an int it can be parsed correctly.
|
I think you're mixing things up. "Int", alone, is a synonym for "signed
int". Replacing T with "signed int", in your example, doesn't work.
The problem is that what you replace isn't a string, to be reparsed.
What you replace is a type. And types can only be modified by
qualifiers.
| Quote: | (There's an interesting anomaly in the C++ standard. The types are
described in §3.9.1, and the legal declarations for them are
described in §7.1.5. There is no specification of which type is
actually specified by any particular legal declaration, however.
Most of the time, if not always, I think it is fairly obvious. But
I find the list in §6.7.2 of the C standard much clearer.)
About the problem with user defined types it's already defined in
the standard. On 7.1.5 it says: "signed or unsigned can be
combined with char, long, short, or int." so trying to compile
unsigned BigInteger would report an error even now.
But you were talking about changing the language.
Nope :)
I'm talking about changing the way it should be parsed.
Postponing the parsing of the unsigned after instancing the template
would solve the problem mantaining full compatibility with the old
code.
|
You don't seem to understand. It would be trivial to change the grammar
to allow the keyword unsigned here. It would be impossible, however, to
give it any reasonable semantics compatible with the current situation.
What is substituted in a template is a type, not a string. Types can be
qualitfied, but they can't be changed. Consider the following (using
your initial template definition):
u< int > u1 ;
u< signed int > u2 ;
According to the standard, u1 and u2 both have the same type. The
keyword "int" is a valide means of specifying the type (signed) int, as
is the sequence "signed int" (and "int signed").
Templates are not macros.
| Quote: | This is already done for a lot of other things,
|
For example?
| Quote: | so why shouldn't it be done for 'unsigned'? It has to be parsed anyway
because the compiler must unserstand if it has a valid type after it
or if it is by itself, so I don't see any problem about moving that
process after template instantiation.
|
Because template instantiation does *NOT* involve textual substitution.
Consider something like:
typedef int I1 ;
typedef signed int I2 ;
typedef I1 I3 ;
u< I1 > u1 ;
u< I2 > u2 ;
u< I3 > u3 ;
Again, all of the variables have the same type (which is the same type
as the two variables in the preceding example).
Note that the problem isn't limited to templates. Given the above,
"unsigned I1" is also illegal, regardless of where it occurs.
If you really want to do this, you can. With the preprocessor. The
preprocessor does pure textual substitution; it implements macros.
Templates are not macros, and the do not do textual substitution, but
rather work on constituant elements of the language itself. The
language has no concept of a modifiable type (where modifiable is used
in the sense of type modifiers in the standard -- the language does
allow adding cv-qualifiers to a type). Signed int and unsigned int are
two completely different types, and there is no way of changing one into
the other.
--
James Kanze GABI Software http://www.gabi-soft.fr
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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Alessandro Molina
Guest
|
| Posted: Sun Oct 03, 2004 3:01 am Post subject: Re: signed/unsigned as fundamental types |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:
| Quote: | Alessandro Molina <amol (AT) sig11 (DOT) org> wrote in message
news:<H_m6d.11593$75.523493 (AT) news3 (DOT) tin.it>...
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:
Implicit int has a long tradition in C (and thus in C++). We've
gotten rid of most of the worst aspects, but I think that declaring
that the int must be there after unsigned would break far too much
code to even be considered.
I'm not saying that int must be there after unsigned to declare an
unsigned int. The idea was that parsing "unsigned T" should be
postponed after the substitution of T with the correct type so that if
it's an int it can be parsed correctly.
I think you're mixing things up. "Int", alone, is a synonym for "signed
int". Replacing T with "signed int", in your example, doesn't work.
The problem is that what you replace isn't a string, to be reparsed.
What you replace is a type. And types can only be modified by
qualifiers.
|
I mean, I can't do typedef int foo and then say unsigned foo; and that's the
current situation, everybody knows it. Unsigned is a type, foo is a type,
it would be like trying to say "bool float".
I'm actually speaking about the meaning of signed/unsigned. Isn't it a
qualifier for us? (us = human kind), isn't the language studied to be used
by humans? So why isn't it a qualifier in the language?
"You can't do that because unsigned is a type". Thanks, I'm quite able to
read §3.9.1 by myself ;)
"If you make it a qualifier you would have problems with own defined types".
I don't see why, because it's already specified that from the "sintactical
point of view" they don't work with own defined types.
I have got answers which has to do with the compiler or with the current
status of their definition, but I'm interested in the ancestral reason. Why
at the first point signed/unsigned has been defined as types and not as
qualifiers (at C time)?
Ben got the point of my question. unsigned/signed sintactically are already
treated similary to cv-qualifiers (I said wrong saying that "unsigned int"
is the keyword, I made it simplier to make it easier to understand. What I
was trying to say is that its meaning is "unsigned int" so it would be like
not having any "unsigned" keyword but only "unsigned int" just written
differently) why not making them qualifiers at all? We would have the same
problems we already solved for other things, so it would have been trivial
to solve it even for signed/unsigned.
Phear of people writing "signed unsigned T"? Standard already have a
solution for "volatile const T", just apply the same.
Phear of templates not having to treat with foundamental types? they already
do it, you can instance a template with coumpound types and even a template
with a constant value instead of a type.
Phear of people trying to do unsigned OwnType? You already specified that
they can't do it.
Apart from having different implementation (cv-qualifiers are "like
directives" for the compiler and signedness has a corrispondence on
hardware level), I can't see any difference in the problems that they rise.
So why they aren't treated the same way?
Mine is just "philosophy", I would like a pholosophic answer. I already know
that they are types, and I already know that templates are not macroes,
this is written on page 2 of every book. Sorry if I seem a bit irritated,
but indeed (probably cause of my bad english) I've got answers to a
question that I didn't ask and more I tried to explain what really I wanted
to know more I got answers far from it :P
I'll try to post the question from a different point of view:
Think of a new language. Writing a new C why wouldn't you make
signed/unsigned specifiers?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Mon Oct 04, 2004 7:30 pm Post subject: Re: signed/unsigned as fundamental types |
|
|
Alessandro Molina <amol (AT) sig11 (DOT) org> wrote
| Quote: | kanze (AT) gabi-soft (DOT) fr wrote:
Alessandro Molina <amol (AT) sig11 (DOT) org> wrote in message
news:<H_m6d.11593$75.523493 (AT) news3 (DOT) tin.it>...
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:
Implicit int has a long tradition in C (and thus in C++).
We've gotten rid of most of the worst aspects, but I think that
declaring that the int must be there after unsigned would break
far too much code to even be considered.
I'm not saying that int must be there after unsigned to declare
an unsigned int. The idea was that parsing "unsigned T" should be
postponed after the substitution of T with the correct type so
that if it's an int it can be parsed correctly.
I think you're mixing things up. "Int", alone, is a synonym for
"signed int". Replacing T with "signed int", in your example,
doesn't work.
The problem is that what you replace isn't a string, to be reparsed.
What you replace is a type. And types can only be modified by
qualifiers.
I mean, I can't do typedef int foo and then say unsigned foo; and
that's the current situation, everybody knows it. Unsigned is a type,
foo is a type, it would be like trying to say "bool float".
I'm actually speaking about the meaning of signed/unsigned. Isn't it a
qualifier for us? (us = human kind), isn't the language studied to be
used by humans? So why isn't it a qualifier in the language?
|
Probably because there isn't any unqualified int type.
| Quote: | "You can't do that because unsigned is a type". Thanks, I'm quite able
to read §3.9.1 by myself ;)
"If you make it a qualifier you would have problems with own defined
types". I don't see why, because it's already specified that from the
"sintactical point of view" they don't work with own defined types.
|
But if I am considering it from a human point of view... When I say
unsigned BigDecimal, I know what I mean. I mean, unsigned is a
qualifier for us humans, and it is clear what I mean.
(It's actually much less clearer than that, because for humans, unsigned
normally suggests an abstraction of cardinal, whereas the C++ unsigned
is something else entirely.)
| Quote: | I have got answers which has to do with the compiler or with the
current status of their definition, but I'm interested in the
ancestral reason. Why at the first point signed/unsigned has been
defined as types and not as qualifiers (at C time)?
|
Because there was never an int type that was neither signed nor
unsigned? Actually, I don't know, because in the original C, there was
nl keyword signed. Maybe it was because the implementors were thinking
in terms of unsigned vs. int, and not unsigned int vs. int.
| Quote: | Ben got the point of my question. unsigned/signed sintactically are
already treated similary to cv-qualifiers (I said wrong saying that
"unsigned int" is the keyword, I made it simplier to make it easier to
understand. What I was trying to say is that its meaning is "unsigned
int" so it would be like not having any "unsigned" keyword but only
"unsigned int" just written differently) why not making them
qualifiers at all?
|
Because unsigned/signed are NOT treated similarly to cv-qualifiers.
Except in the sense that short and long are, too. (And static, and
extern.) How about "typedef long T", where T can be one of unsigned,
int or double?
| Quote: | We would have the same problems we already solved for other things, so
it would have been trivial to solve it even for signed/unsigned.
|
Not really. cv-qualifiers really are qualifiers, which can be added or
removed (by means of a const_cast). That's not the case of unsigned (or
long). Think about it: do you also want to support such a cast?
| Quote: | Phear of people writing "signed unsigned T"? Standard already have a
solution for "volatile const T", just apply the same.
|
Not the same. Volatile and const are orthogonal -- in fact, more than
half of the volatile I've used in real programs have also been const.
Whereas unsigned signed is a contradition.
But I don't think that that is the problem. Perhaps I just lack
imagination, but I can't really figure out how you can separate out
something which is to be modified from the unsigned/signed (int).
| Quote: | Phear of templates not having to treat with foundamental types? they
already do it, you can instance a template with coumpound types and
even a template with a constant value instead of a type. Phear of
people trying to do unsigned OwnType? You already specified that they
can't do it.
|
It's really the latter that makes me hestitate the most. Because in my
mind, something like unsigned BigDecimal makes just as much sense as
unsigned int. So if unsigned is just a modifier, why shouldn't it work.
| Quote: | Apart from having different implementation (cv-qualifiers are "like
directives" for the compiler and signedness has a corrispondence on
hardware level), I can't see any difference in the problems that they
rise. So why they aren't treated the same way?
|
Intuitively, I don't think they can be, but my intuition my be
influenced by the C compilers I've worked on. So all I can say is: try
it.
| Quote: | Mine is just "philosophy", I would like a pholosophic answer. I
already know that they are types, and I already know that templates
are not macroes, this is written on page 2 of every book. Sorry if I
seem a bit irritated, but indeed (probably cause of my bad english)
I've got answers to a question that I didn't ask and more I tried to
explain what really I wanted to know more I got answers far from it 
|
If it's philosophy, I'd say that the first question would be: what is
the type that the unsigned is trying to modify? Or what is it that the
unsigned is trying to modify in order to create a type?
| Quote: | I'll try to post the question from a different point of view: Think of
a new language. Writing a new C why wouldn't you make signed/unsigned
specifiers?
|
Probably because I wouldn't have them. I'd use something more along the
lines of what Ada has, where you can define subrange types.
--
James Kanze GABI Software http://www.gabi-soft.fr
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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
