Need real source of error

Visual Studio 2008, Windows XP Pro, C++
I have a project that fetches data from one place, works it over, then sends to antother place. The entire project builds and rebuilds without error. Then in module C_IADS_TCP_Manager.h one line line is added:

Code:

---

#pragma once
#include "utServerSocket.hpp"
#include "Message_Constants.h"
#include "C_AR2_Messages.h"  // this line is added
...

---

After adding this one line, that .cpp file is compiled with the error message:
error 2143: syntax error : missing ';' before '*'

A double click on the error leads me to file C_AR2_Messages.h and this line

Code:

---

C_IADS_TCP_Manager *mp_IADS_TCP_Manager;

---

This line compiled just a minute ago before adding the include, so it does not have an error.
There are two classes here: C_IADS_TCP_MANAGER which handles the TCP calls between my application and another application. The other is C_AR2_Messages, when does all the work of processing messages. Each of them has a need to have a pointer to the other one.

Does anyone know how to trace this error down to its real source?

Thanks for your time.

This is a real source. Compiler does not know what C_IADS_TCP_Manager is.

Quote:

---

Originally Posted by bkelly

There are two classes here: C_IADS_TCP_MANAGER which handles the TCP calls ....

---

Code:

---

C_IADS_TCP_Manager *mp_IADS_TCP_Manager;

---

If the class is really called C_IADS_TCP_MANAGER ( all capitals ) that would explain the error message
Kurt

Quote:

---

Originally Posted by bkelly

After adding this one line, that .cpp file is compiled with the error message:
error 2143: syntax error : missing ';' before '*'

---

If you're using precompiled headers, then you need to compile stdafx.cpp first, to ensure your changes are seen by the compiler.

If you did, then how about a 1 line .cpp program to see how independent that header file is:

Code:

---

#include "C_AR2_Messages.h"  // this line is added

---

If you created a CPP file, and had that single line, does that CPP file compile with no errors? If not, then that single header requires other headers, and you have dependencies created.

Quote:

---

A double click on the error leads me to file C_AR2_Messages.h and this line

Code:

---

C_IADS_TCP_Manager *mp_IADS_TCP_Manager;

---

This line compiled just a minute ago before adding the include, so it does not have an error.

---

What you did doesn't really prove anything, and especially if that header will not compile by itself (requires other headers).

What if that new header now includes a file, which includes a file, which includes...etc.., and you wind up including that line of code you say is OK? Who knows what guantlet of #includes, #defines, #ifdef/#endif, etc. that were encountered on this new trip you're now taking by including this new header.

Regards,

Paul McKenzie

Hello,
The computer under question is isolated from the internet and I cannot copy and paste directly. Please forgive my typos. When I typed in C_IADS_TCP_MANAGER I left the caps key on and did not notice it.

Before I added the one #include line, the project compiled and ran as expected. That shows that file C_IADS_TCP_Manager.h is syntactically correct, and to a high degree of probability, logically correct. Cutting to the chase, I added the include line and the error popped up about expecting a ; before the *

The line in question is

Code:

---

C_IADS_TCP_Manager *mp_IADS_TCP_Manager;

---

I performed a Clean and Rebuild all before inserting the new include and after. That made no difference.

That line had just compiled successfully. It is declaring a pointer to a class and No, there should be no semicolon before the *. This is telling me that the compiler became confused somewhere else and output this error. That is why I wrote that the displayed error is not the real error. The displayed error is a side effect and I need to find the real error. That the compiler was looking for a semicolon there is a symptom, but not the cause. It should not have been looking for the ; there.

There are a couple of good ideas in the responses and I will be checking them at work tomorrow.
Thanks for taking the time to reply.

Most likely, the problem is as others have mentioned ... the compiler
does not kbow what C_IADS_TCP_Manager is yet.

Consider this simple program:

Code:

---

// a.h
struct A
{
        B *b;
};


// main.cpp

#include "a.h"

int main()
{
        return 0;
}

---

the error that I get is:

Quote:

---

1>a.h(3): error C2143: syntax error : missing ';' before '*'
1>a.h(3): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>a.h(3): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

---

You mentioned:

Quote:

---

Each of them has a need to have a pointer to the other one.

---

You need to use forward declaration ... do not include each others header file.

Quote:

---

Originally Posted by Paul McKenzie

If you're using precompiled headers, then you need to compile stdafx.cpp first, to ensure your changes are seen by the compiler.

---

The project is fully functional without that one line of code. stdafx.cpp is being compiled as part of the build and rebuild processes. None the less, I explicitly compiled it before a good build without the new line, no change. Then I added the new line, compiled stdafx.cpp, then did a build. Same error popped up.

Quote:

---

Originally Posted by Paul McKenzie

If you did, then how about a 1 line .cpp program to see how independent that header file is:

Code:

---

#include "C_AR2_Messages.h"  // this line is added

---

If you created a CPP file, and had that single line, does that CPP file compile with no errors? If not, then that single header requires other headers, and you have dependencies created.

---

That looks like a good idea, so I did it. I started with

Code:

---

#pragma once
#include "C_AR2_Messages

---

It compiled without error. One at a time I included each of the include files. No compile errors.

Quote:

---

Originally Posted by Paul McKenzie

What you did doesn't really prove anything, and especially if that header will not compile by itself (requires other headers).

---

I dissagree with that conclusion. It proves that every line of code in the project compiles without syntactical error. If there is an error in the include file, it should show up at other places in the build project. I do conceed that there could be some type of error, but by following your earlier instructions, that appears to show that the included file is OK.

The compiler wants a semicolon after naming a class in a header declaration. The previous line of code does have a proper semicolon end. I am not yet dissuaded from the thought that the compiler detected a problem somewhere else and that this error is erroneous.

Just in case: Windows XP, Visual Studio 2008

Thanks for taking the time to reply.

Edit: I expaned the test cpp file by including all the header files. No errors.

Quote:

---

Originally Posted by bkelly

The project is fully functional without that one line of code. stdafx.cpp is being compiled as part of the build and rebuild processes. None the less, I explicitly compiled it before a good build without the new line, no change. Then I added the new line, compiled stdafx.cpp, then did a build. Same error popped up.

---

You never showed where C_IADS_TCP_Manager is actually defined. With all you've shown us, you never showed us where this is defined. So as of right now, C_IADS_TCP_Manager doesn't exist to us and therefore the only conclusion that can be derived is that the compiler also doesn't know what a C_IADS_TCP_Manager is.

Secondly, to remove all doubt, go to the file where C_IADS_TCP_Manager is defined and do this:

Code:

---

#pragma message ("I am going to define C_IADS_TCP_Manager")
// This is where you defined C_IADS_TCP_Manager
class C_IADS_TCP_Manager
{
  // whatever
};

---

When you compile your code, if you don't see the message "I am going to define C_IADS_TCP_Manager" in the compiler output window before it gets to the point of the error, then the compiler has not encountered that definition. You then need to take a closer look as to why that definition is never encountered. The compiler doesn't lie.

There is also the /showIncludes command line option in Visual C++ that lists out what files are being included when the compilation occurs. Then you know the exact name of the file that is being included, meaning you get the full path name. Who knows, maybe you're including files that happen to have the same name, and some conflict is occurring.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

You never showed where C_IADS_TCP_Manager is actually defined. With all you've shown us, you never showed us where this is defined. So as of right now, C_IADS_TCP_Manager doesn't exist to us and therefore the only conclusion that can be derived is that the compiler also doesn't know what a C_IADS_TCP_Manager is.
...
Paul McKenzie

---

I do not understand why you are asking that question. In the OP I wrote:

Quote:

---

... Then in module C_IADS_TCP_Manager.h one line line is added: ...

---

The #include that starts the trouble is being added to C_IADS_TCP_Manager. If it is being added to that class, how could it not exist. (btw, just in case, that class manages the TCP/IP link between my program and another computer called IADS, Interactive Analysis and Display System.)

Following your request I inserted the pragma into a couple of H files and in the ouput window I do find:
[quote]
Declare C_AR2_Messages next
f:\....\c_ar2_messages.h(382) : error C2143: syntax error : missing ';' before '*'
...
Define C_IADS_TCP_Manager next
Build log was saved ....
[quote]

When C_AR2_Messages is compiled with ctl-F7, it compiles fine.
When C_IADS_TCP_Manager is compile with ctl_F7, it gets an error, but the error is not in C_IADS_TCP_Manager, it is in C_AR2_Messages.cpp. Well, I did not compile that file, why is the compiler giving me an error.

You can say it does not exist yet. I can reply, so what. That is why we have dot h files, so the compiler can determine the interfaces before the module is actually compiled.

Changing horses, and calling the two classes Messages and TCP:

The Messages class builds messages and contains the TCP class so it can send out messages via TCP. The messages class has a couple of functions to log status to a text file. Within the TCP class, if I have a pointer to the Messages class, I can use that pointer to write to the error log without writing more code.

In essense, both classes have a reference to the other class. To my knowledge, that should be ok. If it is, then my technique is wrong.

However, in the mean time, I extracted the logging code into another class and hand a pointer to the Logger to each class. Now the classes do not need to reference each other. But I still have the pesky #include that I can uncomment to test any replies.

As Philip Nicoletti suggested, you probaly need:

Quote:

---

Originally Posted by Philip Nicoletti

You need to use forward declaration ... do not include each others header file.

---

Did you try it?

Quote:

---

Originally Posted by bkelly

You can say it does not exist yet. I can reply, so what. That is why we have dot h files, so the compiler can determine the interfaces before the module is actually compiled.

---

Not entirely true. If your header file uses objects of a specific type, and you only provide forward declaration to the type, then you get a compiler error that the type is incomplete. Even though it seemingly looks like you can use the forward declared type, you are limited in its use.

The compiler is stating it doesn't know what that definition is at the point of the error. Well, the only conclusion is that the definition is not seen by the compiler. Maybe an #ifdef caused an issue, maybe a misplaced #define macro set something on/off, maybe you misspelled a class name or used the wrong casing (as someone earlier mentioned), who knows. Whatever it is, the compiler isn't lying to you. Don't shoot the messenger.

In addition, we have to work with the code you posted, and not what you claim you have written. So far, we have no idea what's in those files -- too many times we get posters saying "I did this and did that", but when we finally take a look at what they've done, they didn't do what they said they have done, or they did something incorrectly. The result -- a lot of wasted time. That's why I asked you to show where this is defined, so that we can clearly see for ourselves what is happening.

Secondly, the forward declaration can be used, to ensure that the compiler knows that definition (forward declares can be used only if the code that relies on the forward declaration uses pointers and references to the incomplete type, and not complete instances). I will try to use the example shown earlier in this thread:

Code:

---

// a.h
struct A
{
        B *b;
};

// main.cpp

#include "a.h"

int main()
{
        return 0;
}

---

This does not compile due to the usage of B without the compiler knowing what B is. To fix it:

Code:

---

// a.h
class B; // forward declaration
struct A
{
    B *b;
};

// main.cpp
#include "a.h"

int main()
{
    return 0;
}

---

This now compiles.

However, if you were now to do this, the code will no longer compile:

Code:

---

// a.h
class B;

struct A
{
  B *b;  // no error here since we forward declared B

  void DoSomethingWithB()
  {
      B theB;  // error here, even though we forward declared B
  }
};

// main.cpp
#include "a.h"

int main()
{
  return 0;
}

---

The code no longer compiles since in a.h, you're using B objects, and the compiler must know the complete type for B before it can use B objects.

Last, why not use the /showIncludes compiler option when you compile the module that is giving the issue? Then you will see the exact names and orders of the files that are being included. You can set this option in the project settings for that particular CPP module.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by bkelly

That is why we have dot h files, so the compiler can determine the interfaces before the module is actually compiled.

---

A very common mistake about header files a compiler to determine something from. Compiler works on every compile unit comprised of .c/.cpp/.cxx with all its inclusions in-lined and macros expanded, nothing more, nothing less. It never "determines" if a type is defined somewhere else, or already met before, instead it literally compiles the resultant compile unit code line by line. To compile, the resultant code must be consistent in order of type declaration appearance.

Quote:

---

Originally Posted by Igor Vartanov

A very common mistake about header files a compiler to determine something from. Compiler works on every compile unit comprised of .c/.cpp/.cxx with all its inclusions in-lined and macros expanded, nothing more, nothing less. It never "determines" if a type is defined somewhere else, or already met before, instead it literally compiles the resultant compile unit code line by line. To compile, the resultant code must be consistent in order of type declaration appearance.

---

All true. A header file has no hidden magic, special properties, etc. that retain information about the types defined, unlike other languages (for example, Java using the import or package keywords). It's just a text inclusion, nothing more, nothing less.

Also, the OP can specify to just preprocess the module and inspect the preprocessed file. Then it should be clear looking at the preprocessor output as to the exact code the compiler is using.

Regards,

Paul McKenzie

To All,
I participate in missions here at work that take prioirty over everything. There are a number of points made recently that I don't fully understand and need to think about for a while. I am not ignoring you and will get back to this soon. But I do want to say thanks for all the time you have devoted to helping me.
Be back soon,
Bryan

An important thing about header files that some new C++ programmers don't fully understand is that they are processed LINEARLY. If at any time during that linear processing some name is encountered that the compiler didn't see before, it'll spit out errors about it.

This is different from some programmign languages where ALL of the headers/sources are (pre)processed once to extract all the definitions and where you can "use" names before their formal definition in so far as that name eventually gets defined somewhere.