2

I always thought the following types are "fundamental types", so I thought my answer to this question would be correct, but surprisingly it got downvoted...

Searching the web, I found this. So, IBM says as well those types are fundamental types..

Well how do you interpret the Standard? Are the following types (and similar types), "fundamental types" according to the C++ standard ?

unsigned int
signed char
long double
short int
unsigned short int

EDIT:
Again related to this question: Comceau and gcc dont treat types like "long double", "short int" or "unsigned int" as "fundamental type"! (whereas ibm, intel and microsoft compilers do..) If they did treat such types as fundamental types, following code should compile: short int i = short int()

EDIT:
removed long long types, as i forgot they are not officially standard yet..

Community
  • 1
  • 1
smerlin
  • 6,446
  • 3
  • 35
  • 58
  • 1
    It looks like the downvote for your answer was because you said that `unsigned int` is a simple type specifier, which it isn't. It's two simple type specifiers which together specify a fundamental type. – Mike Seymour Mar 12 '10 at 12:34
  • @Mike: Please link to the section of the standard where it states that simple type specifiers specify a fundamental type... To my understanding its the other way round. – smerlin Mar 12 '10 at 17:17
  • You quoted it yourself in your answer. 7.1.5.2, "The simple-type-specifiers specify [...] one of the fundamental types". – Mike Seymour Mar 12 '10 at 18:14
  • I asked that question on the comp.lang.c++.moderated newsgroup a few weeks ago; I've added an answer with the response I received there (I apologize that I didn't post it sooner; it had totally slipped my mind). That having been said, I didn't downvote the answer and I appreciated everyone who took a stab at answering the question. – James McNellis Mar 12 '10 at 18:50
  • As for differing support, see my answer to the linked question. The standard doesn't prohibit handling the syntax error by forming a compound type specifier. – Potatoswatter Mar 13 '10 at 10:47

4 Answers4

5

long long is not supported by the current ISO C++03 standard. However, the C++0x draft standard does include this type:

3.9.1 Fundamental types

2 There are five standard signed integer types : “signed char”, “short int”, “int”, “long int”, and “long long int”.

ISO C99 added this particular data-type (though this was/is available on many compilers as a non-standard extension). C++03 does not fully support all C99 features. Quite a few C++ compilers do however allow this as an extension (e.g. Comeau requires --long_long).

dirkgently
  • 108,024
  • 16
  • 131
  • 187
4

Your logic error in your other answer was already explained by others. To let me explain to you again, given this statement:

The simple-type-specifiers specify either a previously-declared user-defined type or one of the fundamental types.

It does not mean that there are simple-type-specifiers for all fundamental types. It just means that each simple-type-specifier (or a combination of those - i think this sentence is not very clear) specify either a user defined type or one of the fundamental types. That statement also would apply to the following "sample-specifiers":

sample-specifier:
  int
  class-name

Each of my sample-specifiers specify either a previously declared user defined type, or one of the fundamental types (in my case, it's int). It does not mean that all previously declared user defined types can be denoted, nor does it mean that all fundamental types can be denoted. Now if another paragraph in the Standard says that type() works for type being a simple-type-specifier, that does not mean that it also must work for a combination of these. That's a totally invalid conclusion to do.

It's like when i say "decimal digits specify exclusively numbers from 0 to 9" and you say "you are wrong because they can't specify number 10". But what you did was to take a combination of two digits and then claim something i've never said. I think this is a pretty clear logical fallacy you do.

Johannes Schaub - litb
  • 496,577
  • 130
  • 894
  • 1,212
  • Of course this would been a logical fallacy IF i thought that `unsigned int` is NOT a simple type specifier... The problem was, that the Standard didnt say anywhere that a type like `unsigned int` is a combination of those. But it does NOW (check my answer),. – smerlin Mar 13 '10 at 10:14
  • @smerlin, yes it has been saying so for 12 years. Both `unsigned` and `int` are simple-type-specifiers. So they are a combination. Pretty straight forward. – Johannes Schaub - litb Mar 13 '10 at 14:04
  • i really dont know why i missed it -.- – smerlin Mar 18 '10 at 10:07
1

Infact, unsigned/long/short are variant of the int type. So you can use any combination of those keywords together ( like unsigned short int ) ;

But long long is not yet standard : it's supported by many compilers and will be standard in C++0x (the coming standard).

Klaim
  • 67,274
  • 36
  • 133
  • 188
0

I just took a look in the newest draft of the standard N3035 and it includes an additional table (§7.1.6.2) which lists all valid simple type specifiers and shows that unsigned int and similar types are in fact combinations of simple type specifiers.

simple-type-specifier:
    ::opt nested-name-specifieropt type-name
    ::opt nested-name-specifier template simple-template-id
    char
    char16_t
    char32_t
    wchar_t
    bool
    short
    int
    long
    signed
    unsigned
    float
    double
    void
    auto
    decltype ( expression )
type-name:
    class-name
    enum-name
    typedef-name
smerlin
  • 6,446
  • 3
  • 35
  • 58
  • 1
    `decltype` is a *simple* type specifier? Funny! – Potatoswatter Mar 13 '10 at 10:45
  • 1
    @smerlin, that "additional table" is the grammar, and has been there since 12 years. (just with char??_t, decltype and auto missing...). I thought you (and other participants of the discussion) are aware of that list. It comes straight before the table that we discussed, and defines the grammar production called "simple-type-specifier". It's the most important term to use in our discussion. No wonder you got it all wrong, since you missed it. :D – Johannes Schaub - litb Mar 13 '10 at 14:09