Re: completed my Varaint class.

From: Richard Heathfield (invalid_at_address.co.uk.invalid)
Date: 01/26/04 

Date: Mon, 26 Jan 2004 20:14:20 +0000

Jumbo wrote:

>
> "Richard Heathfield" <invalid@address.co.uk.invalid> wrote in message
> news:40152574@news2.power.net.uk...
>> Attila Feher wrote:
>>
>> >> "Ian Woods" <newspub2@wuggyNOCAPS.org> wrote in message
>> >> Your telling me MSVC++ is non conforming , who you think I'm gonna
>> >> believe, you or Microsoft?
>> >
>> > Believe Microsoft.
>>
>> Not only did Ian not say that (which you have already worked out, of
>> course), but Ian didn't even say that MSVC++ was non-conforming. He said
>> that Jumbo's code is non-conforming (which is true).
>>
>> <snip>
>>
>> --
>
> Mike said that the definition of size_t can only be defined in an included
> header with the #include directive.

Actually, he said "If your code uses 'size_t' without #including a standard
header which is defined to declare it, your code is not compliant."

> What I am asking is why and who says so?

The exact type of size_t can vary from one implementation to another. The
Standard says relatively little about it, but it does say that size_t is an
unsigned integral type, and we can deduce from other parts of the Standard
that it must have at least 15 value bits (in C90, or 16 in C99) but can
have more. If you adopt the very simple procedure of getting your size_t
definition from a standard header, then your code will be portable (in that
respect, at least) from one implementation to another. If you roll your own
definition, then you no longer have that guarantee. That's what Mike means
by your code not being "compliant".

As for "who says so?", well, ISO says so. If you don't give a jot whether
your code works anywhere except MSVC++, then that's entirely up to you, but
on /this/ channel we don't assume people are using MSVC++ when giving them
C or C++ advice.

> And also what I am saying is what difference does it make it it is defined
> in an included header than if it were defined at the top of the page?

Your definition:
#define unsigned integer size_t

wouldn't actually work anyway, since it doesn't define a size_t type at all.

> I don't know if yous are agreeing with this or not.
> Are you saying that the standards state this , and if so why?

The Standard exists to make it possible to write C (or, in the case of C++,
C++!) programs that can work correctly on disparate compilers. If you
define your own size_t type, then you cost yourself portability with no
apparent gain in mind. You don't even save typing, since even a marginally
more correct (but still not portable!) definition of size_t, such as:

typedef unsigned long size_t;

takes more characters than

#include <stddef.h>

> What is the point in this?

I have no idea what point you are trying to make. It appears you would
rather spend more time and effort writing non-portable code than I would
spend writing the portable equivalent. 

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Relevant Pages

  • Re: completed my Varaint class.
    ... > Standard says relatively little about it, but it does say that size_t is ... > unsigned integral type, and we can deduce from other parts of the Standard ... > definition from a standard header, then your code will be portable (in ... > define your own size_t type, then you cost yourself portability with no ...
    (alt.comp.lang.learn.c-cpp)
  • Re: conio (nonstandard) question
    ... The reason that there is no such header in the standard is ... one of portability I would imagine, ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Automatically generate variables
    ... Must be C by your definition since crapit might possibly be a header that makes it C. ... I knew it was *the* windows windows.h header because the ... Given certain assumptions the C code was valid C code, however from what I remember it certainly was not a C program solving the problem since it not only relied on non-C APIs but also relied on external programs that in general are *not* installed on machine. ... You, on the other hand, just said that it might be C even if it goes beyond what the standard defined and gave no outer limit on what could be considered C. ...
    (comp.lang.c)
  • Re: Need help on modifying and assembly of a small program!
    ... care for "international support" at the moment...BUT will you care _LATER_? ... make your keyboard driver use "keymaps" or something (which simply ... that there's a kind of "standard" for typing English with their Cyrillic ... This is the "portability" of the OS source ...
    (alt.lang.asm)
  • Re: removing a loop cause it to go at half the speed?
    ... The concepts are also useful because they are well defined by the same standard that defined the C language. ... If the standard says it is undefined behaviour then even if your implementation defines it you know that you will have to check whether it is documented for *every* system you want to use it on in the future, and you may well come across a system which leaves it completely undefined and possibly even causes random behaviour. ... or you will have on some other platform. ... Portability is not always easy or possible, but the starting point is knowing what the C standard guarantees and what it doesn't. ...
    (comp.lang.c)