Is it just me or just Microsoft?

[Ark Khasin]

Due to a peculiar need (code instrumentation) I came across unexpected
behavior of Visual Studio 6.0 and 2005 (doing the same thing):

#include <stdio.h>
#define CAT1(a,b) a ## b
#define CAT(a,b) CAT1(a,b)
#define MYNUM(n) CAT(n,__LINE__)
const int x = MYNUM(35); //OK
int z=MYNUM(78); //OK
int main(int argc)
{
static int y=MYNUM(21); //error!
//6.0: error C2064: term doesn't evaluate to a function
//2005 adds: taking 26451848 arguments.

printf("%d %d\n", x, y );
return 0;
}

Doesn't matter if I compile as C or as C++ (if I am not mistaken, the
preprocessor is the same).
No problem with another compiler (IAR for ARM)...
[Microsoft claims strict standard compliance in the C++ department]

Any suggestions?

Thank you,
Ark

 

[GeekBoy]

Due to a peculiar need (code instrumentation) I came across unexpected
behavior of Visual Studio 6.0 and 2005 (doing the same thing):

#include <stdio.h>
#define CAT1(a,b) a ## b
#define CAT(a,b) CAT1(a,b)
#define MYNUM(n) CAT(n,__LINE__)
const int x = MYNUM(35); //OK
int z=MYNUM(78); //OK
int main(int argc)
{
static int y=MYNUM(21); //error!
//6.0: error C2064: term doesn't evaluate to a function
//2005 adds: taking 26451848 arguments.

printf("%d %d\n", x, y );
return 0;
}

Doesn't matter if I compile as C or as C++ (if I am not mistaken, the
preprocessor is the same).
No problem with another compiler (IAR for ARM)...
[Microsoft claims strict standard compliance in the C++ department]

Any suggestions?

Yeah, buy a compiler that is ANSI/ISO compliant

 

[Ark Khasin]

Due to a peculiar need (code instrumentation) I came across unexpected
behavior of Visual Studio 6.0 and 2005 (doing the same thing):

#include <stdio.h>
#define CAT1(a,b) a ## b
#define CAT(a,b) CAT1(a,b)
#define MYNUM(n) CAT(n,__LINE__)
const int x = MYNUM(35); //OK
int z=MYNUM(78); //OK
int main(int argc)
{
static int y=MYNUM(21); //error!
//6.0: error C2064: term doesn't evaluate to a function
//2005 adds: taking 26451848 arguments.

printf("%d %d\n", x, y );
return 0;
}

Doesn't matter if I compile as C or as C++ (if I am not mistaken, the
preprocessor is the same).
No problem with another compiler (IAR for ARM)...
[Microsoft claims strict standard compliance in the C++ department]

Any suggestions?

Yeah, buy a compiler that is ANSI/ISO compliant

Thank you,
Ark

Easier said than done. Many people are bound to MS tools. I guess I
was asking for help with a workaround within MS if known.
- Ark

 

[Alf P. Steinbach]

* Ark Khasin:

Due to a peculiar need (code instrumentation) I came across unexpected
behavior of Visual Studio 6.0 and 2005 (doing the same thing):

#include <stdio.h>
#define CAT1(a,b) a ## b
#define CAT(a,b) CAT1(a,b)
#define MYNUM(n) CAT(n,__LINE__)
const int x = MYNUM(35); //OK
int z=MYNUM(78); //OK
int main(int argc)
{
static int y=MYNUM(21); //error!
//6.0: error C2064: term doesn't evaluate to a function
//2005 adds: taking 26451848 arguments.

printf("%d %d\n", x, y );
return 0;
}

Doesn't matter if I compile as C or as C++ (if I am not mistaken, the
preprocessor is the same).
No problem with another compiler (IAR for ARM)...
[Microsoft claims strict standard compliance in the C++ department]

Any suggestions?

Visual C++ __LINE__ is broken in many versions of that compiler, when
you compile with support for "Edit and Continue" (option /ZI), and that
may be what you're up against. As an alternative you can use
non-standard __COUNTER__. And the only thing that makes that compiler
specific information slightly on-topic here is that it's an issue with
Marginean's original scope guard (which is of general interest to the
C++ community), which needs to be modified for use with Visual C++.

 

[Dave Vandervies]

Due to a peculiar need (code instrumentation) I came across unexpected
behavior of Visual Studio 6.0 and 2005 (doing the same thing):

[...]

Any suggestions?

Yeah, buy a compiler that is ANSI/ISO compliant

MSVC6 complies to ISO 9899:1990 as well as any other compiler does when
it's invoked properly. Its C++ compiler pre-dates the last two versions
of the C++ standard and I don't have any experience with newer versions,
but I would be surprised if they don't at least closely approximate
compliance.

I'm unable to duplicate it with MSVC6, so it looks to me like it's
probably something specific to the OP's installation; but in any case
it's highly unlikely to be a deliberate non-compliance with the standard.


dave

 

[Ark Khasin]

Dave Vandervies wrote:

MSVC6 complies to ISO 9899:1990 as well as any other compiler does when
it's invoked properly.

<snip>

You must be kidding.
- Ark

 

[Dave Vandervies]

Dave Vandervies wrote:

<snip>

You must be kidding.
- Ark

No, I'm not. I have a lot of reasons to hate Microsoft, but their C
compiler isn't one of them.


dave

 

[Alf P. Steinbach]

* Alf P. Steinbach:

* Ark Khasin:

Due to a peculiar need (code instrumentation) I came across unexpected
behavior of Visual Studio 6.0 and 2005 (doing the same thing):

#include <stdio.h>
#define CAT1(a,b) a ## b
#define CAT(a,b) CAT1(a,b)
#define MYNUM(n) CAT(n,__LINE__)
const int x = MYNUM(35); //OK
int z=MYNUM(78); //OK
int main(int argc)
{
static int y=MYNUM(21); //error!
//6.0: error C2064: term doesn't evaluate to a function
//2005 adds: taking 26451848 arguments.

printf("%d %d\n", x, y );
return 0;
}

Doesn't matter if I compile as C or as C++ (if I am not mistaken, the
preprocessor is the same).
No problem with another compiler (IAR for ARM)...
[Microsoft claims strict standard compliance in the C++ department]

Any suggestions?

Visual C++ __LINE__ is broken in many versions of that compiler, when
you compile with support for "Edit and Continue" (option /ZI), and that
may be what you're up against. As an alternative you can use
non-standard __COUNTER__. And the only thing that makes that compiler
specific information slightly on-topic here is that it's an issue with
Marginean's original scope guard (which is of general interest to the
C++ community), which needs to be modified for use with Visual C++.

Just another suggestion: your "main" signature is incorrect.

 

[Ark Khasin]

* Ark Khasin:

Due to a peculiar need (code instrumentation) I came across unexpected
behavior of Visual Studio 6.0 and 2005 (doing the same thing):

#include <stdio.h>
#define CAT1(a,b) a ## b
#define CAT(a,b) CAT1(a,b)
#define MYNUM(n) CAT(n,__LINE__)
const int x = MYNUM(35); //OK
int z=MYNUM(78); //OK
int main(int argc)
{
static int y=MYNUM(21); //error!
//6.0: error C2064: term doesn't evaluate to a function
//2005 adds: taking 26451848 arguments.

printf("%d %d\n", x, y );
return 0;
}

Doesn't matter if I compile as C or as C++ (if I am not mistaken, the
preprocessor is the same).
No problem with another compiler (IAR for ARM)...
[Microsoft claims strict standard compliance in the C++ department]

Any suggestions?

Visual C++ __LINE__ is broken in many versions of that compiler, when
you compile with support for "Edit and Continue" (option /ZI), and that
may be what you're up against. As an alternative you can use
non-standard __COUNTER__. And the only thing that makes that compiler
specific information slightly on-topic here is that it's an issue with
Marginean's original scope guard (which is of general interest to the
C++ community), which needs to be modified for use with Visual C++.

Alas, __COUNTER__ is not defined in 6.0. The rest works as explained.
Thank you so very much!
- Ark

 

[Erik de Castro Lopo]

MSVC6 complies to ISO 9899:1990 as well as any other compiler does when
it's invoked properly.

Really? Do they have:

- New C99 math functions like lrint, lrintf, round etc ?
- A C99 compliant snprintf function?
- C99 variadic macros?

Erik
--

 

[red floyd]

Really? Do they have:

- New C99 math functions like lrint, lrintf, round etc ?
- A C99 compliant snprintf function?
- C99 variadic macros?

And what do C99 functions have to do with C90 (OP spec'ed 9899:1990)
compliance?

 

[Neelesh Bodas]

* Alf P. Steinbach:

[unnecessary stuff chopped off]

Just another suggestion: your "main" signature is incorrect.

Not really. The following code compiles well on comeau online:

int main(int argc)
{
return 1;
}

I guess the standard expects the implementations to support the two
"standard" signatures, but it also says that other signatures are
allowed as far as return type is int:

<quote>
3.6.1.2:
(main) function shall not be overloaded. It shall have a return type
of type int, but otherwise its type is implementation-defined. All
implementations shall allow both of the following efinitions of
main.....
</quote>

-N

 

[Default User]

I guess the standard expects the implementations to support the two
"standard" signatures, but it also says that other signatures are
allowed as far as return type is int:

So? That just makes it non-standard extension. It is incorrect within
the scope of either of these newsgroups.



Brian

 

[Martin Ambuhl]

Really? Do they have:

- New C99 math functions like lrint, lrintf, round etc ?
- A C99 compliant snprintf function?
- C99 variadic macros?

Only the truly perverse think that "complies to ISO 9899:1990" implies
the presence on C99 additions. In no way does their absence invalidate
Mr. Vandervies's claim.

 

[Richard Heathfield]

Neelesh Bodas said:

<quote>
3.6.1.2:
(main) function shall not be overloaded.

No, there is no section 3.6.1.2 in the Standard. There is a section
3.6(1), however, which says: "byte - addressable unit of data storage
large enough to hold any member of the basic character set of the
execution environment". I'm not sure how this is relevant to the fact
that your main declarator is broken.

 

[Bo Persson]

Erik de Castro Lopo wrote:
:: Dave Vandervies wrote:
::
::: MSVC6 complies to ISO 9899:1990 as well as any other compiler
::: does when it's invoked properly.
::
:: Really? Do they have:
::
:: - New C99 math functions like lrint, lrintf, round etc ?
:: - A C99 compliant snprintf function?
:: - C99 variadic macros?

That wasn't available in 1990, was it?


Bo Persson

 

[Bo Persson]

Dave Vandervies wrote:
:: In article <[email protected]>,
:::
::: :::: Due to a peculiar need (code instrumentation) I came across
:::: unexpected behavior of Visual Studio 6.0 and 2005 (doing the
:::: same thing):
::
:: [...]
::
:::: Any suggestions?
:::
::: Yeah, buy a compiler that is ANSI/ISO compliant
::
:: MSVC6 complies to ISO 9899:1990 as well as any other compiler does
:: when it's invoked properly. Its C++ compiler pre-dates the last
:: two versions
:: of the C++ standard and I don't have any experience with newer
:: versions, but I would be surprised if they don't at least closely
:: approximate compliance.

There are only two versions of the C++ standard, 1998 and 2003.

VC6 predates both of them, which you will notice if you try some
templated code, for example.


Bo Persson

 

[Rolf Magnus]

Really? Do they have:

- New C99 math functions like lrint, lrintf, round etc ?
- A C99 compliant snprintf function?
- C99 variadic macros?

What does this all have to do with C90 compliance?

 

[Rolf Magnus]

Neelesh Bodas said:



No, there is no section 3.6.1.2 in the Standard. There is a section
3.6(1), however, which says: "byte - addressable unit of data storage
large enough to hold any member of the basic character set of the
execution environment". I'm not sure how this is relevant to the fact
that your main declarator is broken.

It seems that both of you didn't notice that this thread goes to both
comp.lang.c and comp.lang.c++. It's likely that you are talking about
different standards.

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Really? Do they have:

- New C99 math functions like lrint, lrintf, round etc ?
- A C99 compliant snprintf function?
- C99 variadic macros?

Of course not, he said ISO 9899:1990, that's 9 years to early.