Sign in to follow this  

Dev-C++ and .inl files (contained in OpenMesh)

This topic is 3706 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there! short version: How do I have to use .inl files in Dev-C++? They work in MSCV 2005, but I can't get them to work in Dev-C++. They are located in a framework and implement classes using templates in an inline way. If I want to use the funcions, the program crashes. Everything other of the program works well. Thanks! more elaborate version for people who aren't in hurry ;-): This is the first time, I can't find an answer to my problem on this website. For my diploma thesis (visualisiation of computer tomography data in 3d and calculation of elasticity) i use Dev-C++ 4.9.9.2 and OpenMesh 1.1 together wie IsoEx 0.2 (both of RWTH Aachen / www.openmesh.org). In OpenMesh there are three files called .inl containing the implementation of classes using templates. After adding all files (with and without the .inl files) I could compile OpenMesh with Dev-C++ and use the library. Using IsoEx I can generate a mesh in an OpenMesh format and display it. But if i want to use some import/functions the programm crashes at the point, it want to use the template functions in the .inl files. So i think they are not compiled with. The program works compiles without errors or warnings. Parts of the program not related to the template functions, work well. I would be very pleased about all help. Cheers.

Share this post


Link to post
Share on other sites
Normally, you would not need to compile .inl-files. You'd include them, just like you would with header files. So, in the files in which you'd want to use the templates in the .inl-files, make sure to #include these files.

However, not including these files should not crash your program, it should fail to compile. So I'm inclined to think that the problem is not the inclusion of the .inl-files, but the way gcc (the compiler used by Dev-C++) and MSVC handle the templates differently.
I think you should use a debugger to establish where the program crashes exactly.

Share this post


Link to post
Share on other sites
Thanks for your response.

Well, I think the program crashes in cause of the .inl files in cause of this:

It crashes when executing the method below, while exiting the method who started the operations with these things (so far as I can see, may be a destructor error?). Dev-C++ gives me a Segmentation Fault on this place (lines 321 and 322 in my stl_vector.h). The .inl files implement methods who are inherited from stl_vector.h.
I think the program tries to delete things that arent in there. I compared the program flow in Dev-C++ with the one in MSVC. The flow seems to be similar, but in Dev-C++ the mesh is returned empty - and in MSCV not.


//lines 321 and 322 in my stl_vector.h
/**
* Returns a read-only (constant) iterator that points to the
* first element in the %vector. Iteration is done in ordinary
* element order.
*/

const_iterator
begin() const { return const_iterator (this->_M_impl._M_start); }



The .inl files are included at the end of a header file, which provides some template methods on its own. One of the .inl files:


template <> struct binary< std::vector< std::string > >
{
// struct binary interface

typedef std::vector< std::string > value_type;
typedef value_type::value_type elem_type;

static const bool is_streamable = true;

// Helper

struct Sum
{
size_t operator() ( size_t _v1, const elem_type& _s2 )
{ return _v1 + binary<elem_type>::size_of(_s2); }
};

// struct binary interface

static size_t size_of(void) { return UnknownSize; }

static size_t size_of(const value_type& _v)
{ return std::accumulate( _v.begin(), _v.end(), 0u, Sum() ); }

static
size_t store(std::ostream& _os, const value_type& _v, bool _swap=false)
{
return std::accumulate( _v.begin(), _v.end(), 0,
FunctorStore<elem_type>(_os, _swap) );
}

static
size_t restore(std::istream& _is, value_type& _v, bool _swap=false)
{
return std::accumulate( _v.begin(), _v.end(), 0,
FunctorRestore<elem_type>(_is, _swap) );
}
};



I already thought about a pointer problem, but accoring to www.openmesh.org it's compatible to gcc. (Maybe not to MinGW?). And it's exactly the same code that works in MSVC 2005.

Cheers.

Share this post


Link to post
Share on other sites
Hello

The problem is solved. It wasn't a problem with the inl-Files. I added the following lines in the GNU-GCC part of the file compiler.h.

# if defined(__MINGW32__)
# define OM_STATIC_BUILD 1
# endif


I don't know, if this is a bug in OpenMesh. In OpenMesh it isn't defined for gcc, but at least for my MinGW version it has to be.

greetings

Share this post


Link to post
Share on other sites

This topic is 3706 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this