I have downloaded some code to do DNP3 protocol and it is written in C and C++. It is going to require a little porting work as it was originally developed for a Unix system!!
I am trying to build the code just to see what sort of errors I am getting and exception handling is one I can't seem to get around.
I get this error
exception handling disabled, use -fexceptions to enable common.cpp dnp30 line 177 C/C++ Problem
You just use Project>Properties>C/C++Build>Settings>GNU C++ Compiler->Miscellaneous and uncheck the "No exceptions handling box. Keep in mind that turning on exception handling has costs (even if you never have an exception - or use a try/catch block). That is why it is off by default. When it is turned on the compiler adds overhead code for supporting automatic stack unwinding.
OK. With that help I got the library to compile with absolutely no errors which is pretty damned amazing.
The only issue is that now when I enable exceptions in my main project to allow this one to build, I get this error... actually a number of them in malloc.
C:\nburn\gcc-m68k\m68k-elf\include/malloc.h declaration of 'void _free_r(_reent*, void*)' throws different exceptions AX9000-DG line 50 C/C++ Problem
Does the netburner example compile and run? If so, look for differences in the basic calls, or maybe slowly add some code to that example similar to your library.
I've turned on exception handling in other projects and recompiled without problems. Are you on the latest tool chain? The error may be pointing you to the wrong place. The error is basically stating that in a .h file the declaration of a method has one exception specification but the implementation has another.
For example if the .h has
void MyFunction() throw (SomeException);
and.cpp has
void MyClass:: MyFunction() //need the same spec here ie throw(Some Exception)
{
}
Maybe even more common is when the throw signature is throw(), i.e. a promise not to throw. In my long C++ journey I once used exception specifications (to my eternal regret). My approach now is to NEVER use them. My advice is go through your library and try and remove them all. They really don't work the way most programmers expect. The biggest problem is that the enforcement can come at RUNTIME not compile time, the most typical enforcement of a violation is to terminate the program, not exactly what I consider graceful.
All the errors appear to be in the header files but I suspect it is the calls to them that are the issue. This library uses a lot of dynamic memory accesses.
In reference to removing them, that thought had crossed my mind.
As the software was originally developed to run on Linux the exception handling was probably a good way to go but on an embedded design it can cause headaches as you rightly say. There is no exit point with an embedded application so the error must be handled in a better way.
Looks like I have a bit of work ahead of me then!! Luckily there is only approx 40 source files so I better get started!!
Looking through this code I don't like the way it handles data ranges.
There is a lot of assert() calls in there. For me, this is not good programming style. Actually, these type of calls should only be used during initial debugging to catch programming errors and then removed.
Looks like a bit of work ahead for me. Considering the alternative is an $11,000 commercial version, this might have to be the only way forward just now.
While I agree that exceptions tend to be harder to use to one's advantage in embedded code I wasn't suggesting you remove the exceptions themselves. Just the "exception specification". That is in your library look at both the .h and .cpp files and see if they specify a "throw(xxx)" at the end of the method. Where xxx can be the name of an exception or blank (in that case it's a promise to not throw). You can remove all those specification portions ONLY. The code can still throw exceptions (and of course you'll want to catch them). Removing the specifications themselves should get rid of the compiler error you're seeing.
I have had a look again and I didn't find any reference to malloc or free in the code. It uses the C++ new and delete instead.
I back tracked all the code to the day before and this compiles (thank goodness for source control). I then entered the -fexceptions in the miscelaneous box and it came up with the same errors. I am not using malloc or free in my own code but I know that the LCD drivers do but that is simply a compiled library.
I have decided to abandon the DNP3 code as there is just not enough documentation for it and my lack of experience with it doesn't help.
I'll come back to the error later as I would like to find out what is causing it and may have a go with a sample project to see what triggers it.
