I am developing a console program in Win32 using Borland C++ Builder 6 and Boost 1.33.1. I have a statically linked library that uses Boost tokenizer and regex. The main program uses Boost function and program_options. If my library is linked with the main program, the help output (generated by program_options) crashes with a null pointer access. This happens even if the library is not referenced in any way - it is enough just to link it in. Remove the library from the link list and the problem disappears. I'm fairly much out of ideas now so a bit of help would be very much appreciated. Ebbe
Ebbe Kristensen wrote:
I am developing a console program in Win32 using Borland C++ Builder 6 and Boost 1.33.1.
I have a statically linked library that uses Boost tokenizer and regex. The main program uses Boost function and program_options.
If my library is linked with the main program, the help output (generated by program_options) crashes with a null pointer access. This happens even if the library is not referenced in any way - it is enough just to link it in. Remove the library from the link list and the problem disappears.
I'm fairly much out of ideas now so a bit of help would be very much appreciated.
I know others disagree but my general suggestion is that if you have a statically linked library in your final EXE that all libraries should be statitically linked, else all libraries should be shared ( DLLs under Windows ). I have found over the years that mixing statically linked libraries and shared libraries is the biggest non-programming headache for programmers, outside of poor or missing documentation.
Edward Diener wrote:
I know others disagree but my general suggestion is that if you have a statically linked library in your final EXE that all libraries should be statitically linked, else all libraries should be shared ( DLLs under Windows ). I have found over the years that mixing statically linked libraries and shared libraries is the biggest non-programming headache for programmers, outside of poor or missing documentation.
It wasn't a library problem. I have now narrowed it down to a single .cpp file. If the condition in the following function is enabled, printing the help text crashes: void ParseParm() { string Something = "One,two,three"; typedef tokenizer< char_separator<char> > MyTokenizer; char_separator<char> sep( "," ); MyTokenizer tokens( Something, sep ); unsigned int Row = 0; MyTokenizer::iterator row_iter; #ifdef ENABLE_FAIL for( row_iter = tokens.begin(); row_iter != tokens.end(); ++row_iter, ++Row ) { } #endif } This function is *not* called anywhere in the program, its mere presence is enough to make the program fail. Seems like a Borland compiler/linker error to me but then I haven't tried this with other tool chains. Ebbe
participants (2)
-
Ebbe Kristensen -
Edward Diener