It should be noted that relying on static initialization as suggested in the article, while at times useful, can open a new set of problems until initialization order is well-defined (it's out of scope for the article, so I imagine the author is aware and just opting for brevity). Some compilers provide an explicit ordering mechanism (clang and GCC) and the there are proposals in the C++ standards at the moment, but until then relying on static initialization is something one should think about potentially solving differently. Depending on the architecture, there tends to also be well-defined hooks for functions to run pre and post-main which is another consistent model for initialization/shutdown.
I had a really good experience designing an RTOS initialization system that both depended on static initialization, but didn't have issues with ordering either (and in fact didn't even have a main, post init just went right into the idle thread).
Basically I only let children of one class be statically initialized (and enforced this with a tool that goes through the generated binary and type information). These 'subsystem' classes then gets callbacks after all of the static initializers have run which allows them to find the other subsystems they depend on, and then that dependency graph is walked to initialize the full system (the dependency graph has to be a DAG or the system faults). Combined with a code review rule that static initializations only happen in one compilation unit in an anonymous namespace, and nothing else can happen there, means that no one can really touch other subsystems before they've all been initialized, and therefore the order doesn't matter.
I was really happy with how it turned out, despite being completely off the wall compared to how C++ normally works.
The symmetrical Static Destruction Order Fiasco is also a very fun problem to deal with. The solution proposed for SIOF in the C++ FAQ does nothing to help you deal with this one, though.
Is the "static initialization order fiasco" a thing that can happen in go? The order of package level variable initialization is well defined in the spec and because go doesn't allow import cycles it seems like the issue mentioned in the linked page is not possible.
In embedded you can usually modify every step from boot to main. They are just pieces of code you can interact with and make them do whatever you want and initialize stuff in whatever order you want, providing you know what you do.
Deviating with a war story now, I once modified some startup code so it self-detected its boot location and initialized the ram data according to this location shift. It was fun, but debugging code you relocated is a pain because you need to somehow relocate the symbols as well.
Well, a bootloader and the self-detection was useful for the bootloader self-update. The update bootloader would be copied in a different section and on reset would start and copy itself over the original bootloader section.
I also wanted to maintain full functionality even at shifted location in case the self-copy process somehow failed. Never did fail, at least to my knowledge.
In the embedded software context, you typically do your own static initialization in a startup.S file or equivalent. There should be 0 ambiguity as to when your DATA section is copied to RAM.
There's generally a difference between "static initialization" copying .data from ROM to RAM, and running static initialization functions out of the table. That table doesn't really have ordering constraints generally.
> Depending on the architecture, there tends to also be well-defined hooks for functions to run pre and post-main which is another consistent model for initialization/shutdown.
Is atexit the post-main hook to which you were referring, or is that just the posix hook into a larger class of post-main hooks?
I agree with the clarification of the Miranda for youths who may not fully understand it as it is recited today.
From the article, "We put kids in jail and that could ruin their life, so we need to be really careful about when and how we do that.” This is a very important point and I hope they do not stop at clarifying Miranda rights. Extending the approach of helping youths lacking 'perspective and judgement', I'd hope for further investigation into the effects of reducing sentences of minor crimes for youths as well.
Correct. The Galapagos have many of these trees and all are marked on paths.
The article did not mention it, but the poison severity of the tree varies quite a bit with season. Once the fruit has all fallen, the milky irritant on the tree has dried or washed off. You should still avoid staying under them in the rain as mentioned above.
It's quite hard to take anything objective from this article. Unless I missed it, I don't see any link to the source material and there is no mention of what the specifics of the test were, or the sample (aside from the sample size). The three links provided on the article are links to mentioned universtiy landing pages or a link to another Telegraph article regarding a /different/ study.
It would be interesting to see the details of the study to determine if there is potentially more of a link to some other criteria (e.g. wealth) than the test questions themselves (which are never mentioned).
The actual questions will probably never be distributed publicly, if they are planning on actually using this for something. If people can see what the questions look like ahead of time, it can bias them and lead to inaccurate results, so it's standard practice in psychology to keep the details private.
But yeah, there isn't a lot of content here regardless.
What's the difference if it's EA, Ubisoft, Apple etc... Nothing is preventing a holiday price drop for bitongo which could be outweighed by the author's projected increased holiday sales. Further, a good app will rise above shovelware appropriately. Is this really a detrimental scenario for a start-up?
The problem is that EAs products are not shovelware, but actually worth the 7+ Dollars they usually sell for. Thats where the huge perceived value comes into play.
Edit: spelling