Re: Version number macros

  Philipp,

sorry for the delay in the answer: obviously you are right (I should
have read the C++ norm more
carefully).

Agreed with all you said.

Regards,

Jerome

On 9/15/2010 11:29 AM, Philipp A. Hartmann wrote:
> Jerome,
>
> according to the C++ standard (17.4.3.1.2 [lib.global.names]), "certain
> sets of names and function signatures are always reserved to the [C++]
> implementation":
>
> - Each name that contains a double underscore (__) or begins with an
> underscore followed by an upper-case letter (2.11) is reserved to
> the implementation for any use.
>
> So I would prefer to have a macro name like SYSTEMC_IEEE_VERSION, or
> SYSTEMC_IEEE_1666. SYSTEMC_VERSION should not be used, since this is
> already used in (some) existing implementations.
>
> Thanks,
> Philipp
>
> On 14/09/10 13:17, Jerome CORNET wrote:
>> On 9/10/2010 4:07 PM, john.aynsley@doulos.com wrote:
>>> Jerome,
>>>
>>> After process control extensions, the next priority on the list is
>>> version number macros.
>>>
>>> You wrote:
>>>
>>> "Speaking of macros, I don't know if this has been planned, but it
>>> would be great (and standard practice) to specify a way to retrieve
>>> the version number of the norm that an implementation is following.
>>> (In our case that would be either 2005 or 2010 for now).
>>> The ISO C standard defines a macro __STDC__VERSION__ whose value is
>>> 199901L (integer long) for C99.
>>> ISO C++ also defines a macro, __cplusplus with value 199711L."
>>>
>>> Would you like to make a specific proposal?
>>>
>> John, All, (sorry for the slight delay)
>>
>> to me the best way is to follow the other standards' previous decisions
>> unless
>> we've got strong reasons for changing.
>>
>> So I would propose a macro (to allow test in #if) like this:
>>
>> __SYSTEMC_IEEE_VERSION with value 201001L
>>
>>
>> with 2010 be for 1666-2010 and 01 being reserved for minor revisions (as
>> it is used for c++).
>>
>> If someone prefer a variations in the name (__SYSTEM_VERSION or
>> whatever), this is obviously
>> also ok for us.
>>
>>
>> Jerome
>>
>>
>>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.