Re: gnucap build with CMake on Windows
Christian Gagneraud <[email protected]>
| Newsgroups | gmane.comp.gnu.gnucap.devel |
|---|---|
| Message-ID | <CABxGUThnnc=_vdZSW3xO7BF1BNRfhqt2is_P0ExB7uqoKnFyxQ@mail.gmail.com> |
On Sat, 29 Jun 2019 at 06:44, Felix Salfelder <[email protected]> wrote: > > On Fri, Jun 28, 2019 at 03:36:30PM +0200, Patrick Mulder wrote: > > This can be solved by putting the dll in the same path as the modelgen.exe > > - so this works now > > Hi Patrick > > good you figured out this one, i think it requires some cmake skills to > fix this properly, if possible. > > > but running the diode compile i get an empty map in > > this constructor: > > what exactly do you mean? is it a compiler error? a warning is expected, > but the warning you get with (newer?) g++ can be safely ignored. > > could you quote the complete error, please? > > > class DISPATCHER_BASE { > > protected: > > std::map<std::string, CKT_BASE*> * _map; // (*) > > private: > > explicit DISPATCHER_BASE(DISPATCHER_BASE*) {unreachable();incomplete();} > > public: > > DISPATCHER_BASE() /*: _map(new std::map<std::string, CKT_BASE*>)*/ { > > if (!_map) { > > _map = new std::map<std::string, CKT_BASE*>; > > }else{unreachable(); > > puts("build error: link order: constructing dispatcher that already > > has contents\n"); > > } > > > > How does the map init to work? > > currently, all dispatcher instances are static. static objects are > initialised to zero (i.e. when they are copied to the stack). hence the No, that is not mandated by the C++ standard, relying on this is undefined behaviour... > map pointer (*) is NULL at the beginning. in the normal (intended) case, > you simply get a new map when the dispatcher is constructed. > > the other, unreachable, branch reports a linking problem. It happens on > some BSD(?), and afaik it should not show up on M$/mingw. Sometimes > things still seem to work properly, in case you see the error message. > the code looks a bit weird because it tries to handle this gracefully. ... and that's why you're seeing this problem only under some circumstances. You should either: explicitly initialise the member when declaring it, eg std::map<X, Y> *m_map = nullptr; or even better, do not use pointer to map, just use map. But i guess you tried and it didn't work. The reason it doesn't work (reliably) is because you're relying on another undefined behaviour, static initialisation order. See https://isocpp.org/wiki/faq/ctors#static-init-order If you build your code with -fsanitize=address,undefined (both in compiler and linker flags), all these problems will be reported at runtime. These sanitizers produce 0 false positive. https://github.com/google/sanitizers/wiki Chris > > hth > felix > > _______________________________________________ > Gnucap-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnucap-devel _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel