gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] gnucap build with CMake on Windows


From: Christian Gagneraud
Subject: Re: [Gnucap-devel] gnucap build with CMake on Windows
Date: Sat, 29 Jun 2019 15:28:29 +1200

On Sat, 29 Jun 2019 at 06:44, Felix Salfelder <address@hidden> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnucap-devel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]