Re: 3.0.1 Freeze

[Bo Thorsen <bo at sonofthor dot dk>]

On Tuesday 07 August 2001 10:39, Gabriel Dos Reis wrote:
> Bo Thorsen <bo@sonofthor.dk> writes:
> | On Tuesday 07 August 2001 02:21, Mark Mitchell wrote:
> | >   1. Build a generic std_limits.h that has a structure like:
> | >
> | >      #ifndef __glibcpp_int_bits
> | >      #define __glibcpp_int_bits 32
> | >      #endif
> | >
> | >      #if __glibcpp_int_bits == 32
> | >      #ifndef __glibcpp_int_max
> | >      #define __glibcpp_int_max <right value>
> | >      #endif
> | >      #ifndef __glibcpp_long_max
> | >      #define __glibcpp_long_max <right value>
> | >      #endif
> | >      ...
> | >      #elif __glibcpp_int_bits == 64
> | >      ...
> | >      #endif
> | >
> | >      <stuff involving __glibcpp_long_max>
> |
> | Why is it that most of you insist on macros instead of const ints? Afaik
> | gcc will generate the exact same code for:
>
> I'm not sure to fully undertand your question, but here is what will
> happen in effect:
>
> 	// #define goes here....
>
> 	template<>
> 	struct numeric_limits<int>  {
> 	  const bool is_specialized = true;
>
> 	  static const int digits = __glibcpp_int_digits;
> 	  //  and so on...
>
> -- Gaby

As I said, it's more of a general attitude towards macros. I consider them to 
be a necessary evil, but something that gcc has an obscene amount of. This 
was just one example where it would be pretty easy to change from a macro to 
a const int. The fact that the example macro is used to just copy the value 
to a const int makes no difference in my general point. Macros are bad for 
debugging and code understanding and they offer no optimization over inlined 
constants/functions anyway. The reason I took this example was that Mark was 
suggesting to introduce a set of macros here which is unnecessary. This issue 
is much about style of programming so there is no right or wrong in it. But I 
would like to see gcc (and most other gnu projects) shift away from macros 
where it makes sense.

Bo.