Topic: `long long
Author: pcurran@acm.gov (Peter Curran)
Date: 1997/11/05 Raw View
On 04 Nov 97 13:18:53 GMT in article <m3pvoi3uqh.fsf@gabi-soft.fr>
kanze@gabi-soft.fr (J. Kanze) (J. Kanze) wrote:
>pcurran@acm.gov (Peter Curran) writes:
>
> |> On 31 Oct 97 14:16:22 GMT in article <m3d8km11wm.fsf@gabi-soft.fr>
> |> kanze@gabi-soft.fr (J. Kanze) (J. Kanze) wrote:
> |>
> |> >Even easier: my file is called myinttypes.h; it either includes
> |> >inttypes.h, or fakes it. The two versions are in separate directories;
> |> >which one I use depends on the -I option given to the compiler (and once
> |> >again, I've avoided a #define:-).
> |>
> |> This, of course, is non-portable:
> |>
> |> - there is no guarantee that a compiler provides a -I option (or even
> |> has the concept of an "option")
>
>I know this. Of course, the part of the make file which defines that
>actual option used is also in a system dependant directory:-).
I didn't mean to imply that there was anything wrong with what you are doing -
you have to get going somehow. I just meant that avoiding a reference to an
as-yet-unstandardized #define is not really much more reliable than using it.
Either approach is a bit risky, if you need to move to "extreme" systems, and
worry about "extreme" portability, but with either approach, everything is going
to work fine in all the systems you are likely to be interested in.
--
Peter Curran pcurran@acm.gov
(change gov to org for actual address)
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: pcurran@acm.gov (Peter Curran)
Date: 1997/11/05 Raw View
On 03 Nov 97 07:29:15 GMT in article <danpop.878509879@news.cern.ch>
Dan.Pop@cern.ch (Dan Pop) (Dan Pop) wrote:
>In <63dlpi$s96@news.inforamp.net> pcurran@acm.gov (Peter Curran) writes:
>
>> - there is no guarantee that system headers are accessible using the
>> double-quote form of #include statement
>
>If by "system headers" your mean the headers described in the standard,
>then such a guarantee DOES exist (unless the standard changed behind my
>back). <snip>
You're right - I haven't read that section closely enough. Thanks.
--
Peter Curran pcurran@acm.gov
(change gov to org for actual address)
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1997/11/04 Raw View
pcurran@acm.gov (Peter Curran) writes:
|> On 31 Oct 97 14:16:22 GMT in article <m3d8km11wm.fsf@gabi-soft.fr>
|> kanze@gabi-soft.fr (J. Kanze) (J. Kanze) wrote:
|>
|> >Even easier: my file is called myinttypes.h; it either includes
|> >inttypes.h, or fakes it. The two versions are in separate directories;
|> >which one I use depends on the -I option given to the compiler (and once
|> >again, I've avoided a #define:-).
|>
|> This, of course, is non-portable:
|>
|> - there is no guarantee that a compiler provides a -I option (or even
|> has the concept of an "option")
I know this. Of course, the part of the make file which defines that
actual option used is also in a system dependant directory:-).
There is, of course, no guarantee that any such option exists. Except
the fact that compiler implementors want people to use their compilers.
|> - there is no guarantee that system headers exist in a "directory"
|> - there is no guarantee that system headers are accessible using the
|> double-quote form of #include statement
Since myinttypes.h is not a system header, there is no problem here.
There is the problem of a system without directories. At one time, I
used the form #include MACHINE_FILE, with a -DMACHINE_FILE=\"xyz\" (or
its equivalent) in the command line. This doesn't extend easily to more
than one file (in C++, I currently have 12, and will soon be adding
another:-).
If a machine doesn't have directories, I'm going to have trouble with my
source code version control anyway. So what I'll doubtlessly do is
maintain the sources on a machine which does have directories, and just
copy over the relevant bits to the target machine when I want to
generate the libraries and/or binaries.
|> - etc.
|>
|> IMHO, providing your own version of <inttypes.h> is a good idea, but for
|> different reasons. You can define your own set of types, etc., avoiding
|> what most commentators have agreed are unfortunate name choices in
|> <inttypes.h>. You can eliminate features that you don't want/need to use,
|> etc. Your own include file can include <inttypes.h> if it is available,
|> or just use C89 features otherwise.
|>
|> For example - most programs do not need 64 bit ints. However, C9X will
|> force a lot of code to use this size (e.g. via intmax_t, etc., since this
|> type has to be at least 64 bits, and its use is virtually mandatory in
|> some situations) and perhaps pay a considerable performance penalty on
|> hardware that does not support it well. If you define your own header,
|> with largest-integer types that you define yourself, you can define these
|> as 32-bit types, if that is appropriate for the code you are working on.
Of course, if you define your own header, you'll find that your types
are not compatible with those in the libraries you use.
|> And, of course, providing your own definitions above those of the standard
|> provides you with a level of protection from the almost inevitable changes
|> to <inttypes.h> if C0X ever appears.
I'd like to say that you really don't have to worry here -- that the
standards committee would never break working code if it could help it.
Regretfully, given long long...
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
I'm looking for a job -- Je recherche du travail
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: "Clive D.W. Feather" <clive@on-the-train.demon.co.uk>
Date: 1997/11/01 Raw View
In article <6gpspaEmw-B@khms.westfalen.de>, Kai Henningsen
<kaih=6gpspaEmw-B@khms.westfalen.de> writes
>I expect there to be a #define that says "this is C9X" (what will it be?),
The value of __STDC_VERSION__ will be changed from its present setting
to something new (IIRC, it's currently 199507L and will become something
like 199910L).
--
Clive D.W. Feather | Director of Software Development | Home email:
Tel: +44 181 371 1138 | Demon Internet Ltd. | <clive@davros.org>
Fax: +44 181 371 1037 | <clive@demon.net> |
Written on my laptop; please observe the Reply-To address |
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: pcurran@acm.gov (Peter Curran)
Date: 1997/11/01 Raw View
On 31 Oct 97 14:16:22 GMT in article <m3d8km11wm.fsf@gabi-soft.fr>
kanze@gabi-soft.fr (J. Kanze) (J. Kanze) wrote:
>Even easier: my file is called myinttypes.h; it either includes
>inttypes.h, or fakes it. The two versions are in separate directories;
>which one I use depends on the -I option given to the compiler (and once
>again, I've avoided a #define:-).
This, of course, is non-portable:
- there is no guarantee that a compiler provides a -I option (or even has
the concept of an "option")
- there is no guarantee that system headers exist in a "directory"
- there is no guarantee that system headers are accessible using the
double-quote form of #include statement
- etc.
IMHO, providing your own version of <inttypes.h> is a good idea, but for
different reasons. You can define your own set of types, etc., avoiding what
most commentators have agreed are unfortunate name choices in <inttypes.h>. You
can eliminate features that you don't want/need to use, etc. Your own include
file can include <inttypes.h> if it is available, or just use C89 features
otherwise.
For example - most programs do not need 64 bit ints. However, C9X will force a
lot of code to use this size (e.g. via intmax_t, etc., since this type has to be
at least 64 bits, and its use is virtually mandatory in some situations) and
perhaps pay a considerable performance penalty on hardware that does not support
it well. If you define your own header, with largest-integer types that you
define yourself, you can define these as 32-bit types, if that is appropriate
for the code you are working on.
And, of course, providing your own definitions above those of the standard
provides you with a level of protection from the almost inevitable changes to
<inttypes.h> if C0X ever appears.
--
Peter Curran pcurran@acm.gov
(change gov to org for actual address)
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Dan.Pop@cern.ch (Dan Pop)
Date: 1997/11/03 Raw View
In <63dlpi$s96@news.inforamp.net> pcurran@acm.gov (Peter Curran) writes:
> - there is no guarantee that system headers are accessible using the
> double-quote form of #include statement
If by "system headers" your mean the headers described in the standard,
then such a guarantee DOES exist (unless the standard changed behind my
back). From ANSI Classic 3.8.2:
A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the
source file identified by the specified sequence between the
delimiters. The named source file is searched for in an
implementation-defined manner. If this search is not supported, or if
the search fails, the directive is reprocessed as if it read
# include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any)
from the original directive.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan.Pop@cern.ch
Mail: CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1997/10/31 Raw View
kaih=6gpspaEmw-B@khms.westfalen.de (Kai Henningsen) writes:
|> kanze@gabi-soft.fr (J. Kanze) wrote on 29.10.97:
|>
|> > Well, it's more than just a moral issue. While cleaning up some code
|> > yesterday, I noticed a very real case in my code which will break if
|> > size_t can be longer than unsigned long. Now the C committee have given
|> > me another solution, but it won't work in current compilers. Which
|>
|> That's wrong, of course. It's pretty easy to hack up an inttypes.h header
|> for a current compiler containing what you really need to solve this
|> problem (it doesn't need to contain any of the other fancy stuff, as you
|> don't actually use that in your current program).
|>
|> It's just that the compiler doesn't do this for you, not that it can't be
|> done at all.
I guess your right. I mainly work in C++ (I note that this is posted to
both the C and the C++ standards groups), so such schenanigans are old
hat -- I already do something similar for the iostream and the exception
handling includes, am in the process for doing it for <string>.
|> > means that until all compilers implement the new standard, there is NO
|> > portable solution, what so ever.
|>
|> I expect there to be a #define that says "this is C9X" (what will it be?),
|> so an #ifdef based on that one could either pull in the C9X inttypes.h, or
|> your own version for pre-C9X systems.
Even easier: my file is called myinttypes.h; it either includes
inttypes.h, or fakes it. The two versions are in separate directories;
which one I use depends on the -I option given to the compiler (and once
again, I've avoided a #define:-).
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
I'm looking for a job -- Je recherche du travail
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: kaih=6gpspaEmw-B@khms.westfalen.de (Kai Henningsen)
Date: 1997/10/30 Raw View
kanze@gabi-soft.fr (J. Kanze) wrote on 29.10.97 in <m3hga0q13m.fsf@gabi-soft.fr>:
> Well, it's more than just a moral issue. While cleaning up some code
> yesterday, I noticed a very real case in my code which will break if
> size_t can be longer than unsigned long. Now the C committee have given
> me another solution, but it won't work in current compilers. Which
That's wrong, of course. It's pretty easy to hack up an inttypes.h header
for a current compiler containing what you really need to solve this
problem (it doesn't need to contain any of the other fancy stuff, as you
don't actually use that in your current program).
It's just that the compiler doesn't do this for you, not that it can't be
done at all.
> means that until all compilers implement the new standard, there is NO
> portable solution, what so ever.
I expect there to be a #define that says "this is C9X" (what will it be?),
so an #ifdef based on that one could either pull in the C9X inttypes.h, or
your own version for pre-C9X systems.
Kai
--
Internet: kai@khms.westfalen.de
Bang: major_backbone!khms.westfalen.de!kai
http://www.westfalen.de/private/khms/
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]