On Sunday, November 18, 2012 2:54:58 AM UTC-8, Arthur Tchaikovsky wrote:
Your "is that English" remark was clearly directed at "Resource acquisition is initialization." Let's not pretend like you were talking about the acronym here.
At this stage it is purely academic, and so it follows, more or less pointless and useless but would you mind not telling me what I had in mind? Because when I was speaking about RAII as a non-English word while CADRE is English.
Then you should have made that more clear in your paragraph structure. Here is a direct quote: "It took me a while before I understood the meaning of "unfolded" so to speak mnemonic. Resource aquisition is initialization? What does it mean?!! Is this english?"
The most recent thing that "this" could be referring to is "Resource aquisition[sic] is initialization". That's what "it" referred to, so the obvious inference is that "this" and "it" are talking about the same thing.
You made a mistake in your paragraph structure, leading to a misunderstanding.
Â
I have heard alternative names for RAII, but I'd never heard of "CADRe" before
And your point is?
That you're not going to convince the rest of the world to adopt your language, just because you thought it up and think it's better. The decision on what to call this technique has been made; it was made years ago.
If you were Herb Sutter, Scott Meyers, and Bjarne Stroustrup all rolled into one, you might, might, be able to convince the rest of the world to adopt your terminology. But only by rewritting all of your books to excise the old term in favor of the new.
As it stands, you are a guy on a forum. The ship has sailed. The horse is out of the barn; trying to close the doors now isn't helping.
Oh, and again, this is not the place to discuss this. This is a place to discuss issues related to the Standard for Programming Language C++, which never mentions RAII at all. Please take it to some other forum where this would be on-topic.
Â
Discussion with you Nicol is pointless. Why? Because you contradict yourself from post to post. Example:
You stated in one of your post that recursion is no harder to iteration so there is no need for having a mechanism which would allow iteration over variadic templates.
No, I did not.
I stated that it had
not been demonstrated that recursion was harder than iteration. Because that was central to the argument, the argument that there was a need for iteration over variadic templates was
flawed.
It like this:
All fish live in the ocean.
All sharks are fish.
Therefore, all sharks live in the ocean.
The conclusion may be correct, but one of the premisses is factually inaccurate. It is possible to agree with a conclusion
without agreeing with the
reasoning that a person used to arrive at that conclusion. You can want iteration, but
not because it makes things easier.
Â
Yet, few post later, in another thread you are all heated up for static for? Why? Why would you like to have static for when you already can do what static for will do. You have recursion which according to you is no harder to iteration, so why would you waste time of everybody to have such a feature? Where is the consistency?
Because static for is not about ease of use; it's about being able to do what you couldn't do before. static for, particularly when applied to member variables and functions, now allows a std::tuple to be a standard-layout type (and possibly trivial), if its member types are standard layout/trivial. It allows std::tuple to have named members in addition to the `get<>` interface. It hooks into constexpr, allowing static iteration over a static numerical range. It may have many other uses in static reflection scenarios that have yet to be defined.
And yes, it also makes it easier to iterate over template parameter packs. But that's only one part of a much larger feature. It's a... fortunate consequence, not the primary designed purpose of the feature.
The difference between the original idea and his is that there was no original idea at all. There was just "Let's allow iteration over parameter packs... somehow." By providing an actual idea that is at least conceptually implementable, it went from being a limited feature that existed only to ostensibly satisfy people who can't figure out recursion, to a real feature with innumerable uses that also just so happens to satisfy people who can't figure out recursion.
See the difference? An actual idea is much better than "let's do this... somehow."