Re: link order

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 mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnucap-devel