I've been working on some new software code at my current job and I keep getting this error:

 error C2059: syntax error : 'constant'

I looked up the error code on MSDN and got this explanation:

 To determine the cause, examine not only the line listed in the error message, but also the lines above it. 

... 

If examining the lines yields no clue to what the problem might be, try commenting out the line listed in the error message and possibly several lines above it.

 

Here is the link. 

I just find it odd that the documentation doesn't really explain what the error is, but how to fix it. It seems like they don't even know what it is.  

I'm not sure if this is a WTF, but it's certainly frustrating. 

С2059 is a generic syntax error. It means something like "this (constant) just can't be there!". So you are right, VS doesn't now what's messed up, only that something is.

constant as in a const; is that what you're trying to do?

What I really hate about VS (VC++, actually) is how a code that compiles with no warnings whatsoever (with /Wall) will give you a linker error.

OK, I may be trying to do my homework (or help with someone else's) without learning all of those fancy namespace/overloading/template rules, but a compiler unable to link my own damn
function is a WTF!

aib:

What I really hate about VS (VC++, actually) is how a code that compiles with no warnings whatsoever (with /Wall) will give you a linker error.

OK, I may be trying to do my homework (or help with someone else's) without learning all of those fancy namespace/overloading/template rules, but a compiler unable to link my own damn
function is a WTF!

How exactly do you imagine a toolset that can link whatever you give it? A code like this is doomed to compile, but not link:

int not_defined_anywhere(void);
int main() { return not_defined_anywhere(); }

aib:

What I really hate about VS (VC++, actually) is how a code that compiles with no warnings whatsoever (with /Wall) will give you a linker error.

OK, I may be trying to do my homework (or help with someone else's) without learning all of those fancy namespace/overloading/template rules, but a compiler unable to link my own damn
function is a WTF!

You obviously do not understand the purpose of a linker.  The linker is pulling in method definitions from elsewhere to use in your code where you just left method contracts.  If the compiler did what you want then there would be no need for a linker, and the compiler would do everything.  Which would mean that you would have to have all the source code.  Which basically means saying goodbye to most libraries.

Err OK, I knew I'd need to clear some things up. Sorry for not taking the time in my previous post.

First of all, I know what a linker is, thankyouverymuch. And of course I wouldn't expect it to link a nonexistent function. What I meant was more along the lines of:

int somefunction(void);

int main(void) { ... somefunction(); ... }

int somefunction(void) { ... }

And THEN you have something along the lines of "could not find function 'somefunction' "

 

Although I've seen quite a few examples (people I've tried to help being unfamiliar with the intricacies of C++, just like myself) in homeworks, etc., I can't find any at the moment. However, rest assured, it would be something along the lines of a class calling a method of another class, all quite properly defined. Because of what I'm guessing some namespace/scope and object code function name generation weirdings, you'd get something like:

LNKXXX: Unresolved reference to function_name_$$$@@@HASH@@@$$$_wouldreturntypebehere__(__stdio_std::IStream param1, param2, etc.) **

Sometimes, moving the "using namespace std;" lines around, or even recreating the project with the exact same source files would get rid of the error(s). Mind you, none of the default projects settings would have been modified in the first place.

 

Call me weird, but I expect proper* code that compiles cleanly to link cleanly.

*: e.g. one that has all the definitions of all prototyped functions
**: From what I could gather, the reported name of the missing function would match the name and parameters of the function defined in the sources. For example, function_name() would be able to use param1 without any problems (so we know its type is properly defined). The calling function would not have any problems either; i.e. copy-pasting the contents of function_name() inside the calling function would also work. However, they would just not link.

Any ideas? 

You lack understanding of how C++ name mangling interacts with the linker. It is normal for this sort of problem to be revealed by the linker rather than the compiler.

asuffield:

You lack understanding of how C++ name mangling interacts with the linker. It is normal for this sort of problem to be revealed by the linker rather than the compiler.

...among many other things. Any pointers?

I still think it should be the compiler's job to warn me. I mean, both the caller and the function definition itself have the same prototype from the class header?

From my lacking point of view; I'm either calling a function without a prototype, or I have a prototype without a definition and a definition without a prototype -- both of which should generate a warning.

aib:

asuffield:

You lack understanding of how C++ name mangling interacts with the linker. It is normal for this sort of problem to be revealed by the linker rather than the compiler.

...among many other things. Any pointers?

It's not something that gets documented. There's no real way to grasp the details other than implementing a C++ compiler.

I still think it should be the compiler's job to warn me. I mean, both the caller and the function definition itself have the same prototype from the class header?

 

There's probably a variation in their context. The same sequence of characters can generate a different type in a different context, and as far as C++ is concerned, two functions with different types are unrelated, even if they have the same identifier. The most common scenario is some variation in one of the argument types between the header as included in the definition, and the header as included in the call site, due to inconsistencies in the headers which were included before that point.

asuffield:

It's not something that gets documented. There's no real way to grasp the details other than implementing a C++ compiler.

 I thought maybe I could read up on the namespace thing and the scope issues associated with it. (I feel a comment about "any good C++ book" and/or google is on the way; I'll just google it.)

asuffield:

There's probably a variation in their context. The same sequence of characters can generate a different type in a different context, and as far as C++ is concerned, two functions with different types are unrelated, even if they have the same identifier. The most common scenario is some variation in one of the argument types between the header as included in the definition, and the header as included in the call site, due to inconsistencies in the headers which were included before that point.

Yeah that's what I thought it was :/. It was probably due to the IStream/OStream (or their combined class; forgot its name) and something to do with the 'std' namespace. Still, it's freakish when just recreating the project solves the problem.

Of course, the real WTF is that we had some course/book utility code where .h files included .cpp files...

aib:

Still, it's freakish when just recreating the project solves the problem.

That's the critical piece of information - what you have is a busted build system (Visual something? It's badly broken), combined with ABI drift. At some point since the last build of the affected files, the relevant types were altered in the source. Only one of the two significant compilation units was recompiled (either implementation or call-site), and the other's out of date, so it failed to link.

To determine the cause, examine not only the line listed in the error message, but also the lines above it.

That's classic :P. To me it sounds like "Even though we're saying the error is on this line, it could actually be anywhere above this point. Good luck finding it!"

Sounds a lot like the Parse error: unexpected $end error in PHP, which most commonly occurs when you forget a closing brace on an if statement or something. The line number it gives you is the very last line of the PHP code, which makes it rather hard to find where the error actually is (you need to check that all brackets and braces are not mismatched)

asuffield:

aib:

Still, it's freakish when just recreating the project solves the problem.

That's the critical piece of information - what you have is a busted build system (Visual something? It's badly broken), combined with ABI drift. At some point since the last build of the affected files, the relevant types were altered in the source. Only one of the two significant compilation units was recompiled (either implementation or call-site), and the other's out of date, so it failed to link.

I'm hoping I was stupid enough to forget to clean & rebuild from scratch. Visual C/C++/Studio does that to you...