[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] link order
From: |
Felix Salfelder |
Subject: |
Re: [Gnucap-devel] link order |
Date: |
Sat, 29 Jun 2019 14:37:10 +0200 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
On Sun, Jun 30, 2019 at 12:12:47AM +1200, Christian Gagneraud wrote:
> The evidence is the very existence of this thread. It obviously does
> happen, b/c you're observing it right now.
> I have explained the reason why.
no, we havent seen the full error message yet. I don't even know if it
is about a compiler, a linker or a runtime error. You explained
something, but I also did ask for evience of your claims (especially the
zero initialisation).
> What is static is just an object, this object is created (read: memory
> allocation+initialisation) using the default constructor.
> The default constructor doesn't inilialise _map.
> There is no guarentee as to what the value of _map is.
the default constructor is ran *after* _map is initialised to _zero.
> Sorry, i don't have a link to share, this is basic C++ rules.
i found a copy of the C++17 draft [1]. this quote under "11.6
Initializers", from page 222 might be of interest to you.
"""
10 [ Note: Every object of static storage duration is zero-initialized
at program startup before any other initialization takes place.
In some cases, additional initialization is done later. — end note ]
"""
this applies to the dispatcher instance (which is static), hence _map is zero
at the start. essentially what I claimed earlier about ANSI-C.
in my understanding, this asserts that (unless the link and object order
is wrong), the link order error message is not shown. this is the
intended behaviour -- other cases remain undefined.
> Concerning the "on the stack" aspect, resizing the stack is as easy as
> incrementing a pointer, the pointed to memory doesn't have to be
> initialised AFAIK.
Yes is could be implemented either way. I hope it now became more clear
that the standard requires zero initialisation in that case.
> Please don't attempt to control the link order, my (real) example was
> an example of what you shouldn't do.
initialisation to zero doesn't have anything to do with link order.
if there's something i shouldn't do, then please explain what i should do
instead. controlling the link order seems problematic indeed, which is the only
reason why the error handler is there.
thanks
felix
[1] https://wg21.link/std17, obtained just now,
sha1 01e634f42f0e285426e627260d05ac9e3c48dff1
- [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, 2019/06/28
- 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 <=
- 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