UB compiling = HELP!

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 13/12/2006 at 11:08, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   9.6 
Platform:    Mac  ;  Mac OSX  ; 
Language(s) :     C++  ;

---------
Hi,

ok, I have tried now to compile my plugin code with XCodes latest version with the 9.6 API. I followed exactly the instructions described in the SDK documentation but I get a massive amount of errors when trying to build.

I have 10000+ errors! It´s not that only my code has errors (weird errors!) but also general functions like op->GetPoint() for a point object give me an error saying that PointObject does not have a member named GetPoint() and similar. So, absolutely nonsense, the list is full of such things. This makes me think that the api libs are not yet built?

Anybody an idea what the problem may be? Maybe the API project must be build first? But how is that done? Sorry, I am still new to XCode and MAC. I thought this would be done automatically by XCode (prebuilding the dependencies if necessary). Or maybe it did already? I have no clue.

Any help appreciated. It´s weird!

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 13/12/2006 at 12:18, xxxxxxxx wrote:

What happens if you try to compile the SDK examples? Does it compile without error?

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/12/2006 at 07:37, xxxxxxxx wrote:

Hi Matthias,

no I haven´t compiled the SDK and I unfortunately have no time to do so. But it seems XCode is the problem. I am using a namespace and in VisualC++ and Codewarrior it compiles just fine!

I could reduce the error messages to only some, so the API is compiling fine and most of my files too but the namespace makes XCode go crazy.

My file pseudostructure is like this:

ownvector.h
ownmatrix.h
ownobjects.h
owncombiner.h
ownmaster.h

Each file uses the same namespace and each file has a class declared including template classes.

So, each class is of the form:

#headerdefine  
  
//forward declaration  
namespace XYZ  
{  
   class nameClass;  
}  
  
#include "necessary.h"  
  
namespace XYZ  
{  
    class nameClass  
    {  
        [...]  
    };  
}  
#endif

of course the template classes are accordingly defined.
However, some classes require the "master" class defined in "master.h" where all the calculations happen, so I am passing pointers of the master object to the according functions.

And here seems to be the problem. The compiler tells me that the master class is undefined. Which is nonsense. And they share the same namespace, so it should be known. Also forward declarations don´t help and including the header file doesn´t either!

It just tells me that this type is undefined. Hey, it´s a passed pointer, that´s a valid standard C++ operation. So, this is probably not really related to the SDK any longer but the compiler is.

I am sitting in front of this for days now and cannot find the bugger, so maybe someone has an idea in here what the problem may be.

I had this problem in Codewarrior once too, but I could fix the namespace collisions by simply using a

#include <iostream>
using namespace std;

instead of directly including <vector>.
Don´t ask me why this is, it makes no sense actually but that´s what MACs seem to be like. ArgH!

So any help, idea, suggestion is highly appreciated.

Thanks
Samir

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/12/2006 at 15:59, xxxxxxxx wrote:

Does this happen only with templates ? Some code with one of the error generating calls would be nice.

Perhaps it needs something like this
void NameClass::f( typename XYZ::Master &m; )

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/12/2006 at 18:10, xxxxxxxx wrote:

Hi Michael,

sorry, I have no clue which part I could put here as the errors are really arbitrary. I see no relation to any code I am actually using.

But I tried the typename declaration as you propose and also changed the template class accordingly. Makes no difference at all.

I rather think it´s a problem of my file structure.
You must think of it as this:

matrixclass.h (template class)
arrayclass.h (template class)
container.h (template class)
vectorclass.h
objectclass.h
master.h

the problem is this, the matrixclass is used within the container, but the matrixclass also needs/gets passed a pointer to the master and container.

the container is used within the master but also needs/gets passed a pointer to the master and uses the arrayclass.

the objectclass needs a container, master and matrix.

And so on, so it´s really a little chaotic. The master is a solver class and is actually the only class that creates all other objects (i.e. creates container and objects, container creates array etc.).

However, I cannot include the master.h in any of the other files as this would mean it includes itself as all other files are included in master.h.

Hmm, you see the problem? I am not absolutely sure if it´s the problem but it sounds plausible.

Any idea?

I try to narrow down the problem.
Btw. the SDK compiles just fine and my project without the part we are currently talking about compiles also just fine. So it´s really up to the namespace or the file structure I think. :-/

Samir

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 15/12/2006 at 03:26, xxxxxxxx wrote:

Hmm... i assume you have inline and template member function definition in header files. I think the compiler needs to know the full declaration of all types that appear there. If you have only forward declaration it probably generates an error.

Does it work when you put everything in a single .h file ?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 15/12/2006 at 07:30, xxxxxxxx wrote:

I will try a one file solutin (should work, but of course not desired). However, it´s not C++ Standard afaik that the compiler needs the full declaration. He only needs it when it needs to know how much memory the class requires, but for a pointer that´s not necessary as the compiler should think the class is properly defined.

Hmm, but he probably needs the declaration for member function calls of that instance...hmm, ok. that could be a problem.

btw. yes, all my class defintions are in header files, but also all members are declared and defined in the class body. So maybe I should move the function calls of the critical classes to a source file?! Man, why didn´t I think of that before? :-D

Thank you Michael! I will let you know if it worked out!
Best
Samir

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 18/12/2006 at 08:29, xxxxxxxx wrote:

I would like to know. Btw there is some helpfull info on template issues http://www.parashift.com/c++-faq-lite/

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 22/12/2006 at 16:24, xxxxxxxx wrote:

Thanks for the link Michael. I will have a look at that one!

For now I moved all the namespace class defintions into 1 header file and almost all implementations into source files.

This compiles fine in VC++ until it tries to link the libraries. I then get "unresolved external symbol". :-(
And this for template class definitions in a source file (implemented like below).

My header looks like this:

#ifndef _FLUID_HEADER_H_  
#define _FLUID_HEADER_H_  
  
#include "c4d.h"  
#include "../dpitlibraries/dpit_tools.h"  
#include "dpit_fluidobj.h"  
#include "dpit_fluidsim.h"  
#include <vector>  
  
// forward declaration  
namespace Fluid  
{  
     class xyzabcundco;  
}  
  
#include "fluidvector.h"  
  
namespace Fluid  
{  
        class xyzabcundco;  
}

and my cpp files look like this, with an example implementation of a template:

#include "fluid_header.h"  
using namespace Fluid;  
  
template <typename T>  
bool FSTGrid<T>::ValidPos(const int x, const int y, const int z) const  
{}

As I said, it compiles fine, but the final linking gives me the unresolved external symbol errors.

Any idea? Will look into that FAQ, maybe I find something.

From one error to the next, love it. :-)
Thanks!

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 22/12/2006 at 16:34, xxxxxxxx wrote:

Ha, ok, found a possible problem in that FAQ! Cool. Love the FAQ btw.. Very good overview for several issues. :)

Will report back when I retried.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 22/12/2006 at 16:50, xxxxxxxx wrote:

ok, so when it´s all in one header file, it compiles fine in VC++. Will now try if this compiles on MAC too, so I can at least compile a working version of my code.

Then will try another thing, because all the template implementations in one header file...phew, looks awful, especially when you have soooo much code, and looks even more terrible when I think I must work with them! :-(

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/01/2007 at 14:42, xxxxxxxx wrote:

Hey, just wanted to report. I have now put all the namespace class declarations into one header file. I define all template class members in the header file too. According to C++ it isn´t supported otherwise. non-template classes I still define in .cpp files.

And, swoop, that compiles! :-)

Anyway, having them within one header file is really annoying, but well, it compiles. That´s the most important thing currently.

So thanks again for the help to both of you!

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/01/2007 at 07:30, xxxxxxxx wrote:

Hi you're welcome and thanks for the info. Glad it finally works ;-)

Perhaps you could still split the header file into several. You just have to make a "super" header which includes all the parts in the right order. Not that great solution but maybe easier to work with..

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/01/2007 at 14:33, xxxxxxxx wrote:

thanks Michael. I will do so, once DPIT is released. I also think it´s easier to work with several files. :)