[odb-users] Intermittent problems building solution

[Hugo.Mildenberger at web.de]

Boris,

I've seen such a situation with ODB quite often. It is certainly more a weakness of the c++ compiler than a problem of ODB, especially when it comes to diagnosing template related errors. However, when going through the list of files pointed out by the c++ error messages, I often stumbled upon a comment located within the umpteenth ODB header, hinting to a typical reason behind my specific situation. 

Yet I think there is a flexible solution for this problem: if one regards the stack of errors generated by the compiler as a pattern with a typical structure (with place holders for the variable elements), one should be able to write a filter which reduces the stack and outputs a clear message instead (much like those you've hitherto written into the ODB headers). Within an application program, I once used the pattern represented by a linked list of the caught and somehow transformed exceptions, combined with a very simplistic lookup of the fingerprint in a database table. This table was gradually amended whenever an unforeseen situation emerged. And that has worked very well, simply because the fingerprint generated by the linked list of exceptions represented the actual control flow within the program. So, whenever an ODB related fingerprint is not contained in the database, print the pattern and request the user to inform you about the circumstances. 

Kind regards

Hugo
 


On Thu, 18 Jul 2013 10:56:11 +0200
Boris Kolpackov <boris at codesynthesis.com> wrote:

> Hi Adam,
> 
> Adam Walters <adam at navigatesurgical.com> writes:
> 
> > Further examination showed it to be caused by a missing override in the
> > derived class
> 
> Ok, that explains it. What happens is this: because your derived class
> still has pure virtual functions, ODB treats it as abstract. And since
> a (reuse-) abstract class cannot be queried for, ODB doesn't generate
> any of the query machinery.
> 
> 
> > (this would normally cause a 'can't instantiate abstract class' error
> > message).
> 
> You would still get it if your code tried to instantiate the class.
> 
> 
> > The ODB compile doesn't complain that the derived class doesn't
> > implement all of the abstract base class methods;
> 
> ODB doesn't know your intentions: did you not override the functions
> on purpose (and therefore the class should be treated as abstract) or
> did you forget? ODB treats the class as abstract if it is abstract in
> C++ sense (i.e., has pure virtual functions) or is explicitly marked
> abstract.
> 
> The only way to fix this that I can see is to always require ODB-abstract
> classes to be explicitly marked with the pragma. This way the ODB compiler
> will be able to complain if it sees a C++-abstract class that is not
> explicitly marked.
> 
> 
> > At least I know what causes it now. Hopefully this will be of use
> > to others who encounter the same problem.
> 
> Yes, definitely. Thanks for sharing this!
> 
> Boris
>