[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
- [Gnucap-devel] gnucap build with CMake on Windows, Patrick Mulder, 2019/06/28
- Re: [Gnucap-devel] gnucap build with CMake on Windows, Patrick Mulder, 2019/06/28
- Re: [Gnucap-devel] gnucap build with CMake on Windows, Felix Salfelder, 2019/06/28
- Re: [Gnucap-devel] gnucap build with CMake on Windows,
Christian Gagneraud <=
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/29
- Re: [Gnucap-devel] link order, Christian Gagneraud, 2019/06/29
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/29
- Re: [Gnucap-devel] link order, Christian Gagneraud, 2019/06/29
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/29
- Message not available
- Re: [Gnucap-devel] link order, Patrick Mulder, 2019/06/29
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/29
- Message not available
- Message not available
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/30
- Message not available
- Message not available
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/30
- Message not available
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/29