Topic: Compiler features information (proposed ideas?)


Author: sbnaran@fermi.ceg.uiuc.edu (Siemel Naran)
Date: 1998/08/28
Raw View
On 28 Aug 1998 16:42:41 GMT, Christopher Eltschka

>The most interesting information is probably the existance.

Good point.  A builtin operator like 'builtin_types' would be
good.  This operator returns a builtin array of typeinfo
objects.  If it were a function, it would look like this:

typeinfo const (&builtin_signed_integral_types())[4];
// char,short,int,long (signed versions)

But we don't need an addition to the language in order to do
this.

>Say you want to specialize a template to any integer type on the
>platform. If you restrict yourself to the standard types, this
>can be simplified with the nice trick Vlad Harchev showed:

Since you know the types supported at compile time, you could just
define this macro yourself if you want by reading the compiler's
documentation.  Furthermore, you can add some lightweight user types
to the list, like complex<int> -- ideally, they should be optimized
just as well as builtin types.

>#define INTEGRAL_TYPES(arg) \

>#define SPECIALIZE_ON(T) \
>template<> struct to_specialize<T> { ... };
>
>INTEGRAL_TYPES(SPECIALIZE_ON)

This is going to be impossible to debug.  IMHO, a more viable
approach is to expand the template to_specialize for each type T
manually.  This is equivalent to doing the macro expansion by hand.
A non C++ tool would work best here.

Say the file that defines the partial specialization has the
name to_specialize.template.  To generate the specialization for
int, just use a command to copy the contents of
to_specialize.template into to_specialize.h but replace
every occurence of T with int or whatever.  For example,

gawk '{sub(/T/,"int",$0); print}' to_specialize.template >> to_specialize.h


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: "Vlad Harchev" <vladhar@imimail.ssau.ru>
Date: 1998/08/27
Raw View
   Modern compilers provide some additional builtin types not found in
standart ( like long long). If there exist instantiations of
 numeric limits for these type, then programmer can get information about
them. But the problem is that programmer can't know what types are supported
by the given compiler.  Also there may be useful to specialize some template
for  builtin types. The remaining of the message is dedicated to the
features that allow programmer to browse builtin types according to some
criteria.

   The only one way to allow the user to browse the types is with the use of
macros. The concepts: there is some macro the name of which programmer
knows - lets call it enumerator. The purpose of the macro is to enumerate
some identifiers, let they be A,B,C,D.; such macro accepts at least on
parameter - lets call it arg; that macro treats that parameter as the name
of some macro with one argument; in that case the body of the enumerator can
be defined as follows:

#define enumerator(arg)\
  arg(A) \
  arg(B) \
  arg(C) \
  arg(D)

To use the enumerator, the programmer should define macro that will be
passed to the enumerator. For example, the following code will try to dump
the objects named A,B,C,D

#define dump(x)  << "\n"  #x " is " << x
 cerr   enumerator(dump);

- will expand to :
cerr << "\n" "A" " is " << A << "\n" "B" " is " << B << "\n" "C" " is " << C
<< "\n" "D" " is " << D;

 The macros to be defined:

ARITHMETIC_TYPESxENUM
  STD_ARITHMETIC_TYPESxENUM
  EXTRA_ARITHMETIC_TYPESxENUM

INTEGRAL_TYPESxENUM
  STD_INTEGRAL_TYPESxENUM
  EXTRA_INTEGRAL_TYPESxENUM

 UNSIGNED_TYPESxENUM
  STD_UNSIGNED_TYPESxENUM
  EXTRA_UNSIGNED_TYPESxENUM

SIGNED_TYPESxENUM
  STD_SIGNED_TYPESxENUM
  EXTRA_SIGNED_TYPESxENUM

FLOATING_TYPESxENUM
  STD_FLOATING_TYPESxENUM
  EXTRA_FLOATING_TYPESxENUM

I think that the names of the macros are self-descriptive.

I suggest such feature to be standard some way - may be via technical
report.
I think the feature is useful for libraries.




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: sbnaran@fermi.ceg.uiuc.edu (Siemel Naran)
Date: 1998/08/27
Raw View
On 27 Aug 1998 16:26:11 GMT, Vlad Harchev <vladhar@imimail.ssau.ru> wrote:

>   Modern compilers provide some additional builtin types not found in
>standart ( like long long). If there exist instantiations of
> numeric limits for these type, then programmer can get information about
>them. But the problem is that programmer can't know what types are supported
>by the given compiler.  Also there may be useful to specialize some template
>for  builtin types. The remaining of the message is dedicated to the
>features that allow programmer to browse builtin types according to some
>criteria.

The extra types supported should be documented in the compiler's
documentation.

What information about the builtin types do you find useful?  I
can only think of sizeof.  I recently wrote a program that will
generate typedefs based on the sizeof.  If sizeof(short)==2 and
sizeof(int)==4, sizeof(long)==4, then assuming 1byte==8bit, the
program prints this.  Note that there is a bug to fix!

     typedef short int16;
     typedef int   int32; //
     typedef long  int32; // bug in my program: conflicts with above!


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/08/28
Raw View
Siemel Naran wrote:
>
> On 27 Aug 1998 16:26:11 GMT, Vlad Harchev <vladhar@imimail.ssau.ru> wrote:
>
> >   Modern compilers provide some additional builtin types not found in
> >standart ( like long long). If there exist instantiations of
> > numeric limits for these type, then programmer can get information about
> >them. But the problem is that programmer can't know what types are supported
> >by the given compiler.  Also there may be useful to specialize some template
> >for  builtin types. The remaining of the message is dedicated to the
> >features that allow programmer to browse builtin types according to some
> >criteria.
>
> The extra types supported should be documented in the compiler's
> documentation.

But the code cannot read the compiler's documentation ;-)

>
> What information about the builtin types do you find useful?  I
> can only think of sizeof.  I recently wrote a program that will
> generate typedefs based on the sizeof.  If sizeof(short)==2 and
> sizeof(int)==4, sizeof(long)==4, then assuming 1byte==8bit, the
> program prints this.  Note that there is a bug to fix!

The most interesting information is probably the existance.

Say you want to specialize a template to any integer type on the
platform. If you restrict yourself to the standard types, this
can be simplified with the nice trick Vlad Harchev showed:

#define INTEGRAL_TYPES(arg) \
  arg(char) arg(unsigned char) arg(signed char) \
  arg(short) arg(unsigned short) \
  arg(int) arg(unsigned int) \
  arg(long) arg(unsigned long)

template<class T> struct to_specialize { ... };

#define SPECIALIZE_ON(T) \
template<> struct to_specialize<T> { ... };

INTEGRAL_TYPES(SPECIALIZE_ON)

However, if this is in a library, this may be compiled on a compiler
which has non-standard type long long. Of course, in this case you
want to add that to the list of specialisations. Currently the only
way to do that is to anticipate any compiler on which the code might
be compiled, and then use #ifdef to set the correct variable for
the compiler (or, alternatively, use a tool like autoconf to check
for existance of certain types).

Indeed, I like the idea of such standard macros.

[...]


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: "Vlad Harchev" <vladhar@imimail.ssau.ru>
Date: 1998/08/28
Raw View

Siemel Naran writes ...
>The extra types supported should be documented in the compiler's
>documentation.


I meant the following:
   the programmer writes some library, which can use some extra types
provided by the compiler (if they are better than standard ones by some
criteria). If information about the additional types will be availble in
some way (may be that one i described), then programmer can write some
macros that will automatically browse those types. In that case  porting the
library to other compiler/platform (potentionally) will not require reading
the documenation of target compiler and modifing the code  - the library
(potentionally)  can be simply recompiled without any change.




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]