Some of your requests will never happen, and with good reasons, I'll explain:

e) Fix the macro language so it is type safe

The macro language is not part of the c++ language. As far as I know, Bjarne would have loved to get rid of it entirely, but it was kept to help maximize C compatibility.

g) Deprecate and REMOVE that stupid 'short', 'long', 'double' crap from the language

Why? Sometimes the user wants to use types which are relative to the CPU word width, but don't want to be tied to a specific bit width. Remember, not everyone who codes in c++ uses an Intel CPU.

h) Provide PROPER 16-bit, 24-bit, and 32-bit characters

16/32 characters are fully supported in c++11, see char16_t and char32_t. I could be wrong, but I don't think I've seen a language which has 24-bit characters. It would likely be inefficient to support anyway since I'm not aware of any architectures which 24-bit access is properly aligned.

i) Fix the darn grammar so that compilers accept UNICODE source

Many compilers already do support UTF-8 in source code. But I do agree that this should just be standardized across the board.

j) Fix the darn grammar so that compilers RECOGNIZE identifiers WITH Unicode characters

Why? So you can have a function named () instead of pi()? This strikes me as something which would just make it harder to read.

k) Add a proper exponent operator

Won't and Can't do this efficiently. Not all CPUs have an intrinsic way to do exponention. This is specifically why it's a library function so it is obvious that it is potentially a non-trivial operation. Once again, not everyone uses an Intel CPU.

m) Add proper multiple return types

This would be nothing more than syntactic sugar. Why is using a struct such a big deal?

n) Fix all the times the spec says "undefined" or "implementation dependent". The point of a spec is to SPECIFY what the operations do, NOT to be ambiguous because in some idiotic universe 'char' is not exactly 8-bits.

NO. You will probably disagree, but this is part of the *strength* of both C and C++. By allowing something to be undefined or implementation dependent. The standard is allowing the compiler to choose the most efficient code to emit. If the standard were more specific in these places, we'd have a "one size fits all" solution which would be optimal for some architectures and very much sub-optimal for others. Better to let the compiler writers who know the arch best to decide these things.

q) Add a proper rotate-left and rotate-right bit shifts

See the answer to exponent operations. Simply put, not all CPUs have this. I would however welcome a standard library function for this like pow for exponents. Which the compiler could inline to a single instruction if the CPU supports it.

When is C++ going to add reflection support?

It probably won't because it's not well suited for how things work in the language. Here's (part of) the problem. With templates and optimizations, often there can be 100's of types created during compilation which are independent but get optimized away to literally nothing when finished. Should the compiler waste time and space generating reflection information for types which simply don't exist at runtime? Should the compiler emit reflection information for each and every template instantiation of std::vector that your program uses? You can't do one set of reflection's for each template, because different specializations can have different members! It spirals out of control really fast. Personally, I would not be apposed to an opt-in reflection system. You use some special syntax, let's say:

reflect class T { };

or something like that. Which would then add extra stuff to the std::typeinfo object associated with that type. So that way you could in theory do something like this:

typeof(T).methods(); to get a list of methods for T, IF you have opted in. But I don't think that will happen.

I am a big fan of C++, but I must admit, you make an interesting point. But pretty much the first half of your post really boils down to you not liking "constructors and destructors". That is the discriminating factor here. Sure, if you somehow create an object that is initialized with garbage, when the desconstructor runs, literally anything should happen. It can in fact run arbitrary code in your application. So, yes, there is no arguing that that is a danger which must be avoided.

Fortunately, it's been a VERY long time since I've seen any compiler not complain about a missing return, even with no extra warnings enabled. So that case should be visible to the most inept of programmers. And the other ways of accomplishing similar, honestly require more skill to pull off (I'm thinking of the case of allocating raw memory (not initialized), casting it to have the type of an object, and then doing something like trying to copy that junk object).

However, like most ANY tool that can be misused, constructors/destructors are more useful that I can adequately describe in one post. smart resource management itself does tremendous things with regard to increasing code correctness, clarity and brevity. Done in a way, which is simply not possible without the concept of destructors. Being able to write code that I KNOW will always release a mutex, regardless of how it exits the function is a godsend. Knowing that I won't have file descriptors accidentally left open, knowing that I won't have dangling pointers if I simply use smart pointers... the list goes on.

It was mentioned in a later post that "If every programmer should compile with certain flags, then they should be part of the standard". I would disagree, this removes flexibility from the compiler writes (remember, unlike things like C#, D, etc, the C and C++ committees write language specs, not compilers). I would love the see compilers default to "-ansi -pedantic", since it does nothing but improve code quality. But requiring diagnostics for certain *runtime* errors would introduce undo burden on the compiler writers. For example, the "no return" scenario is often not as obvious as you present, all possible code paths must be evaluated, which for most compilers means that a certain level of optimizations must be enabled to have that information. Additionally, sometimes, it can't be known. Sometimes the code path that has no return is impossible to reach because of constraints elsewhere. Sure we could target the easy ones, but you'd still be able to point at some case where it isn't caught.

Like I said, you made a good point. C++ introduces new tools, which have new pitfalls, but you are not required to use them. And frankly, modern compilers with appropriate warnings enabled will catch pretty much all of the obvious ones.

You are right about software bloat, but I wouldn't blame OOP.

OOP doesn't have to be less efficient (though admittedly, it is in some ways easier to write less efficient code in OOP languages). For example. There should be absolutely no difference in the the performance between these to snippets (as long as no virtual functions are involved):

C code:

void some_function(struct some_struct *p) { /* do whatever */
}

some_function(&thing);

C++ code:

void Thing::some_function() { /* do whatever */
}

thing.some_function();

In fact, they should in principle end up being identical machine code.

**properly** written C++ code can and should be made as efficient as its C counterparts. In fact, due to templates which have nothing to do with OOP, some C++ code can even exceed the C implementation's speed.

Abstractions can sometimes be **more efficient**, if they can convey to the compiler what is needed better. A trivial example of this is something like: std::swap, when you see this in the code, you know that it is swapping two variables. Because of templates the compiler has extra type information available, and in theory could have specialized implementations which do the swap particularly efficiently. Imagine when swapping two integers if the compiler has enough information to say "hey, that could just be a single xchg instruction. That higher level of abstraction just increased the expressiveness of the language and let the compiler implement more efficient code!

I think a more fair thing to blame is the current mentality of the development world in general. There seems to be a (IMO misguided) consensus that it's OK to write things in an inefficient way if it works, because the hardware is "fast enough". While I can agree that "premature optimization is the root of all evil", I also feel that people should default to writing code in a well designed way, which happens to often overlap with the efficient way. The pervasiveness of scripting languages (JavaScript, Python, PHP, Ruby, etc) continue this trend and I feel it's only a matter of time before this crappy, bloated, inefficient code can no longer be outweighed by the power of our CPUs.

Well designed code needs to make a comeback!

While what you suggest is hypothetically true, it is a terribly impractical stance. For a couple of reasons.

First of all, living in all of these exotic environments would be an extraordinary costly endeavor and would therefore probably only be accessible to the super wealthy.

Secondly, while living in oceans, other planets, etc is an interesting option, they are remarkably impractical. Building long term, large structures for large populations in under sea environments is not something we've done. At the very least there are several issues which have very difficult solutions. Air, Food, Water Pressure, etc. Heck, we can't even get a damn bio-dome to work sustainably above ground, I love the idea, but it just doesn't work yet (as far as I know, there may have been some success stories). But you know what, I'll even let you have that. After all, BioShock was an awesome game...

However, we can toy with colonizing mars and such, but it isn't exactly the most hospitable place. Sending resources there would take 6 months at best. It is even more resource constrained than the oceans. Terra forming may be a valid approach, but since that depends on green house gases warming the planet, it doesn't exist to the average conservative :-P. Joking aside, I like the idea of terra forming, but we have little to no experience making it actually work. And we don't know if it would work as expected until we actually tried. It may just end up being a multi-trillion dollar waste of time.

If we are to seriously consider planets in other solar systems (as you imply), then we would need to disconver some method of space travel that would get to other stars MUCH faster than anything we've ever considered. According to NASA, conventional rockets are nowhere near efficient enough. At a maximum speed of about 17,600 mph (about 28,300 kph), it would take the space shuttle, for example, about 165,000 years to reach Alpha Centauri.Currently. And that's assuming we are even capable of bringing enough Fuel!

The bottom line is that the options you present are good ideas, but effectively inaccessible. It's not that I don't think that "it would be enough" (the universe is *really* big), it's that the universe is almost entirely out of reach. Even our "galactic neighborhood" isn't practical. Since it is not currently possible to do something like colonize mars, let alone other further planets, they are not part of the economy in terms of land and/or other resources. As far as wealth is concerned, they don't exist (yet).

Even if we discuss things like mining the moon or asteroids, etc. The cost would probably outweigh any gain in wealth. Making it not a viable option outside of science fiction.

Certainly, it is inarguable, that the amount of living space/resources/other things of value we have now, and could conceivably use in the foreseeable future is very much finite. At the very least, we are (currently) limited to what's on earth (and maybe the moon, but i don't think the math makes it a win).

You seem to have ignored when I said "but this applies to any form of economy". Sure, I agree completely that wealth != money. It is simply one type of wealth. But all types of wealth are finite.

To use your own example, having a large amount of land only adds to your wealth *because* there is a finite amount of land. If everyone could have as much land as they wanted, then it wouldn't matter how you have, it would have no value, because it wouldn't be rare.

How is there not a finite amount of wealth to be had? Let's use money as an example (but this applies to any form of economy).

At any point in time, there is a finite amount of money in the world (like every other resource). For example, if we look at http://www.federalreserve.gov/faqs/currency_12773.htm, they say:

. Other countries certainly have an equally finite amount of money. The wealth of any individual is directly related to what percentage of that amount they have.

To put it simply, if I have $200,000, I have .00000001% of the total wealth to be had. Meanwhile, a billionaire has 0.0009% still a small number but *clearly* a much larger portion of the pie than I have. He has more "wealth" than I do. Even if we shrink the numbers to be more manageable, it's the percentage of the whole that establishes my wealth in the system.

Sure, we can print more money. And that could go two ways, both of which are bad. If it gets over time evenly distributed across the population, then everyone's relative wealth stayed the same, even though there bank accounts went up, the percentage stayed the same. The dollar has simply been devalued.

Or, more realistically. If the majority ends up in the hands of the already wealthy (let's face it, if a rich person invests $5 in something, they expect to get at least > $5 back... otherwise it isn't an investment), then the rich get richer and the poor get poorer AND the value of the individual dollar is devalued.

In the end, it is most certainly a "zero sum" game. For me to have something, that means someone else can't have it. Even for simple things like me going out and buying an xbox, my total worth has gone down (I can't reasonably sell a used xbox and full retail price, so it's a net loss) and someone else's has gone up. Sure, I've decided that this trade is "worth it" to me because I am willing to trade some wealth for entertainment. But I'm certainly slightly less rich.

Economies are *driven* by the fact that resources are limited. The more limited a resource, the more value it has. If wealth were infinite, then it would be effectively equally accessible to everyone, meaning that money would have no value (since infinite things are certainly *not* rare by any definition).

Certainly ABI changes can be difficult to deal with, but personally I think it is better than keeping old code around like many close sourced systems end up having to do for compatibility purposes.

I've found that a good (not perfect) solution is to write an thin abstraction layer between the module and the kernel. The module pretty much only deals with the kernel through this layer, so if the kernel changes, you have a central place to apply updates (nvidia does this and it has worked very well).

In the end, it's a trade off and you can rest assured that distros will likely build with the BKL enabled for a few releases before phasing it out to avoid compatibility issues.

It's a fairly simple idea. In any place that two threads of execution (be them real threads or interrupts or whatever) could possibly access the same resource at the same time, locking must be used to ensure data integrity and proper operation of the code. The "Big Kernel Lock" is a system wide "stop the world" lock. This is a very easy way to make the code "correct" in the sense that it will work and not corrupt data. But the downside is that while this lock is held... everything else must wait. So you better not hold it for very long and while it is easy to get correct, it has pretty bad performance implications.

A better solution is a fine grained lock just for that resource, so the only threads of execution which need to wait are ones that are actually contending for that resource. The downside here is that it is much more complicated to get correct. So when implementing this, you have to be *very* careful that you got it right.

The BLK has been in the process of being removed and has been phased out of the vast majority of the kernel for a while, this change is simply enabling a build in which it doesn't even exist if you don't build any of the older drivers which don't use more fine grained locking.

Well the purpose for making Richard immortal was because Jacob wanted someone to be the middle man between him and normal people. Jacob asked Richard what he wanted, and Richard said "I want my wife back". Jacob said "I can't do that". Then Richard said "Then I want to never go to hell" (or something to that effect). Jacob still couldn't do that. So Richard finally said "Then I don't want to die!" Jacob said "I can do that". That's the why. The purpose was to give Richard what he wanted in exchange for his help. The only thing left is the "how" as in, what is the mechanism used to do it. Well, that's magic, no point in explaining such things. Adds nothing. If I told you, Jacob was a Genie, would that change the story at all? Probably not.

As for the polar bears. Sure there is a bit of unanswered questions as to why they were brought there. Do you think that knowing why the Dharma initiative brought them there would help the story? To be honest, at first I thought Walt created them because he has some special abilities on the island to make reality what he wants (simplest example is always winning backgammon) and he was reading a comic with a polar bear. The writers chose to make them come from the Dharma initiative. In the end, they were in like maybe 4 episodes. I know they were there because of Dharma. I honestly don't care why Dharma wanted them there. It doesn't add to the story.

Yes the Dharma initiative exist in the real world. Eloise Hawking worked in the "Lamp Post" Dharma station which she used to get the "Oceanic Six" back to the island.

Dharma Seal? probably something as simple as "they found it, marked it, maybe did some experiments, moved on." Not a whole lot of meaningful mystery here.

The whispers are explains in this last season *completely*. People who have done wrong are doomed to have there souls roam the island, whispering to the people. Michael directly says to Hurley that he is "stuck on the island and not allowed to leave" and that he was the whispering they'd be hearing recently. In an after show interview, the guy who plays Michael confirmed that.

Pregnancy, a true mystery. The only thing we know is that it must be related the event (the nuke or the release of energy) that caused the hatch to to be built. Since pregnancy was just fine before that event.

As for Ben, I don't know what to tell you. Everyone has a back story and Ben's involved working under Jacob's orders. Not really a mystery. It is another thing if you dislike that story.

Like I said, you just need to pay attention :-P.

There are plenty of unresolved mysteries, but you aren't picking many of them! Here's some truly unsolved mysteries:

- why does traveling to/from the island on certain heading cause time shifting?

- when returning to the island, why was the group split up through time. How did some of them get "teleported" off the plane?

- When and under what circumstances did Eloise leave the Island?

- How did she end up running the Lamp Post? I don't care, just curious.

- How did she know about Desmond's future events in 1996, as well as the man wearing red shoes' destiny?

There are MANY more. But like I said, the ones you are asking about HAVE been answered to a degree that satisfies the story. If you got some hocus-pocus explanation of how these things happened, most people would pick those apart and still be unsatisfied.

Some of the things on your list have been answered:

-Richard immortality: Jacob did that, we don't know how he did it, but do you really what the show to try to "explain magic"?
-Dharma initiative: just a bunch of scientists who found the island doing experiments because the island has some weird properties.
-Polar Bears: related to the dharma initiative. They were originally in the cages on the second island that kate and sawer were kept in. They eventually escaped or were let out. Remember, polar bears can swim...
-Egiptian Iconology: No answer, but it's spelled "Egyptian". I think this was simply a reference to how long ago the story being told began. But that's just my take, this was never really answered, but I feel an answer would have helped the story here.
-Original people (Jacob's mother people)/Jacob's stepmother: Jacob's mother drew black rock to the island (remember she said "there was only supposed to be one" meaning she was expecting a pregnant woman to have a baby, just not twins). Presumably she was looking for a replacement (she said "thank you" to the man in black when he killed her). We don't know how long she has been guarding the island, or if she is the first guardian. But how far back do we need to go? The story may have a bit of a recursive property to it (same story over and over again in different times and such). But I feel that they went back far enough to explain the story as far as it effects the main characters.

Some of the other stuff on your list falls into the category of "it was a way to tell the story". This is TV, not real life, so it's ok for the story to be fantastical or improbable. people having ESP, Jacob having "magic" powers, etc. All of these things really don't need to be answered to tell the story. Besides, if they did answer them, it would lead to one of 2 conclusions. 1) There would be more questions, since we talking about fiction, that could go on indefinitely. 2) The answers would be perceived as ridiculous. I think it's better to not explain things like this, just say they are special, have some abilities and tell the STORY.

Certainly there are plenty of unanswered questions in the story. And it is a little frustrating, but I would say you didn't do the greatest job of paying attention, since a 3rd of your list was trivial answered.

The answer is probably that hardware virtualization is simply easier to implement. MS wanted to get the feature out of the door and to customers. They probably expect that a large number of Windows 7 users are on newer hardware likely to have VT. Then later updated the software to support software based virtualization in order to allow it to function for more people.

Adding features (in this case software virtualization support) through updates is hardly newsworthy...

Why compromise and have the installer have a checkbox for "advanced tools?" 99% of people will blindly click next without checking it, they won't get it, the other 1% will actually read what is being asked of them and possibly install it.

Seems like it would be simple to include it without bloating things at all.