Fringe's token fifth and final season is now four of thirteen episodes down, with the fourth having aired just last night. Here's a spoiler-filled dump of my thoughts so far.
Don't read on if you don't want to be spoilt as to what we've seen so far.
Though it's wonderful to have more Fringe to watch each week, this time-jumped final arc is still making barely any sense to me.
Some thoughts on this week's logical holes:
- No way they escaped that blast radius in 25 seconds without being out of breath.
- The Observers can evidently still transport wherever they want but, because this would really make them undefeatable, most of the time they take lifts — except now when it suits the plot.
- We still don't know why they're keeping any humans around, and why they spent centuries "observing" first.
- Was Etta physically attached to the baton — I don't think so.
- Astrid never knew about that entire cold storage lab? In all those years? Never saw Walter keeping it? She never lost sight of him in four years.
And glossing over the parallel universe viewport was ridiculous. You could theoretically recruit the forces of an entire untouched world who are your friends and have experience in this kind of thing, not to mention advanced technology. Or at least you could find out whether the other universe is indeed untouched by the Observers. Or at least it would be really cool — the other universe was always the fan favourite of Fringe. I appreciate that they hung a lantern on the omission with Peter saying it would be pointless to go down that route, but this was actually just offensive since it so blatantly wouldn't be.
This is still more than anything a WW2 resistance story clone with characters and settings supplanted from a sci-fi show I used to watch. Only so many episodes left to go, and I still have no idea why the Observers are doing what they're doing, how they did it in the first place, why so many humans are being strung along, why the humans are kept around, and so on.
There's just no backstory to this season five tale and it's preventing me from investing in the plot at all.
Thank heavens for the character moments because that's all there is so far this season — these are important but they do not alone a great final season to a cult favourite TV series make. Hopefully still to come is an episode that lets us in on the motivations of the major players and the events that unravelled in the days and weeks of the initial invasion, something that I had been hoping for in an episode whose title alludes to a backstory.
It has begun:
There is no such thing as "an auto"!
See, this is why I disagreed with the proposal to add this syntactic sugar.
Last year I "left" Stack Overflow but, as predicted, recently found myself trickling back onto it for the fame and glory.
Then, this.
My question (which you won't be able to view live without sufficient rep):
NB: I'm sure someone will call this subjective, but I reckon it's fairly tangible.
C++11 gives us new basic_string types std::u16string and std::u32string, type aliases for std::basic_string and std::basic_string, respectively.
The use of the substrings "u16" and "u32" to me in this context rather implies "UTF-16" and "UTF-32", which would be silly since C++ of course has no concept of text encodings.
The names in fact reflect the character types char16_t and char32_t, but these seem misnamed. They are unsigned, due to the unsignedness of their underlying types:
[C++11: 3.9.1/5]: [..] Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively [..]
But then it seems to me that these names violate the convention that such unsigned types have names beginning 'u', and that the use of numbers like 16 unqualified by terms like least indicate fixed-width types.
My question, then, is this: am I imagining things, or are these names fundamentally flawed?
It was a polarising question, with as many upvotes as downvotes, and it was closed but managed to attract a string of re-open votes, not to mention a high-powered and professional debate in the comments. Admittedly, discussion is not supposed to take place in SO comments, but there we go.
I didn't mind it being closed, though of course I voted to re-open.
But the kicker is what moderator George Stocker did with it: after posting the following comment…
The problem with this question is the last sentence, "Are these names fundamentally flawed?" Let's imagine for a second that the answer is 'yes'. how does that 'yes' answer help us? It doesn't.
… he used his moderator powers to delete the question outright.
Now question deletion, in my day, was a power of last resort, reserved only for questions of such a clear lack of value that they amounted to nothing more than monkeys writing Shakespeare, or viagra spam. It overrides the open/close-voting that has made Stack Overflow such a powerful community-driven tool in the past.
But it would seem that during my time away, this has changed. Whether or not you agree with me that since the question was tagged language-lawyer the question is completely relevant (if the answer is "yes" then that helps us to rationalise about and hopefully improve the C++ language), is it not deeply disturbing that moderators are now seemingly running around Stack Overflow, deciding what should be forever deleted, on a whim?
I made a mistake that could have cost my application its stability. Learn from the error of my ways!
Cleaning up some code, I saw an opportunity for a forward declaration and I took it:
struct T2;
struct T1
{
std::auto_ptr obj;
};
Only by chance, some hours later, did I spot a diagnostic note from GCC hidden away in my build output:
note: neither the destructor nor the class-specific operator delete will be called, even if they are declared when the class is defined.
Deleting an object of an incomplete type yields undefined behaviour, and since obviously the standard library runtime implementing std::auto_ptr does not define my type T2, the destruction of an std::auto_ptr now invokes this UB.
I was lucky to spot this — I figure GCC should emit a warning rather than a note, since I'm trained to spot them from a mile away. In the meantime, that's one mystical shutdown-time segfault (that I'd shelved for later investigation, not considering that it could be linked to this code change) explained.
#include "T2.h"
struct T1
{
std::auto_ptr obj;
};
I lose my forward declaration, but at least my program is well-defined and will not open black holes. So there are kind of some pluses and minuses.
