I'm flaking out now. When shall we cross meet? http://va7kwx.skhit.in/
The Design of C++ (1994) [video]
51–60 of 63 posts
Re: The Design of C++ (1994) [video]
#52Here lonely girl looking for fun with the guys http://ifyhiu.skhit.in/
Re: The Design of C++ (1994) [video]
#53The language may seem complex to some, but so does math. It is the single most powerful programming tool the world has ever known. Sure, it may be hard to see that it is beautiful, but that is so only because it is a product of both intelligent design and evolution. The language structure is extremely logical, and there is very little that could be changed in it without the danger of destroying its finely tuned fabri…
Let's bring up some technical details to see whether there is a deliberate thought process behind the evolution of C++. Recent versions of C++ have the auto keyword. It's a cool new feature grafted onto C++ from other languages and meant to make the programmer's life easier. It lets you avoid typing things like
for (std::vector>::const_iterator it = v.begin(); it != v.end(); ++it) {
foo(*it);
}
for (int i = 0; i for (auto x : v) {
foo(x);
}
Let's put aside the fact that you can't explain the difference between "*", "&" and "&&" to a C programmer without them bursting out laughing. Why does auto have six different variants? Isn't this emblematic of how C++ is evolving?
Re: The Design of C++ (1994) [video]
#54Earlier quoted context omitted.
Is diamond inheritance really part of that fabric? Diamond inheritance isn't a problem in C++ as each inheritance path is followed separately. A small price to pay to enjoy the power of multiple inheritance. And NULL? NULL is deprecated since C++ 11 in favor of nullptr. C++ is old and has only accumulated, never lost. You may want to have a look at the latest standards.
> NULL is deprecated since C++ 11 in favor of nullptr Pedantically, it's discouraged, not deprecated. NULL is a preprocessor constant defined in so many places, often in contradictory ways. There's no practical way for the C++ standards to deprecate it. Compiler and analysis tools vendors could (and should) provide warnings when NULL is used when nullptr is more appropriate (which is always IMO).
Actually before nullptr was designed, the good practice in C++ was to use a plain 0, due to the way NULL is sometimes defined and how implicit conversions work.
Seeing C++ codebases using 0 for pointers instead of NULL was already a sign how up to date the respective programmers were with C++'s best practices.
Re: The Design of C++ (1994) [video]
#55The language may seem complex to some, but so does math. It is the single most powerful programming tool the world has ever known. Sure, it may be hard to see that it is beautiful, but that is so only because it is a product of both intelligent design and evolution. The language structure is extremely logical, and there is very little that could be changed in it without the danger of destroying its finely tuned fabri…
Let's bring up some technical details to see whether there is a deliberate thought process behind the evolution of C++. Recent versions of C++ have the auto keyword. It's a cool new feature grafted onto C++ from other languages and meant to make the programmer's life easier. It lets you avoid typing things like for (std::vector >::const_iterator it = v.begin(); it != v.end(); ++it) { foo(*it); } The above used to be…
At least C++ offers me tools to avoid leaking resources or corrupting memory, which cannot be said for C.
The fact that C11 made the security Annex optional, is a sign how much the C committee values writing safe code.
Re: The Design of C++ (1994) [video]
#56I finally figured how Dr. Stroustrup can always make C++ seem like not only a reasonable thing, but probably the best possible one. He has chosen a number of goals that, while being reasonable and desirable individually, each tend to complicate the realization of all the others. Consequently, for any of the complications of the language, he can pick a couple of goals and show that they make the complication unavoidab…
We will now call this "Stroustrupping": choosing a large number of incompatible goals and using a subset to defend any argument while ignoring the fact this subset conflicts with many of the other goals, such as the subset used to defend the previous argument.
Re: The Design of C++ (1994) [video]
#57Earlier quoted context omitted.
> They had a golden opportunity to fix it, but even with C++17 and the expression "a(b(), c());", it is still left indeterminate whether b() or c() will be invoked first. If the order of b() and c() matter, then they shouldn't be in the same statement. That is an abomination. What you little you gain in terseness, you more than make up for in future headaches.
That is not an abomination. Turning this: int val = a(b(c(), d()), e(f(), g())); Into this: auto _1 = c(); auto _2 = d(); auto _3 = b(_1, _2); auto _4 = f(); auto _5 = g(); auto _6 = e(_4, _5); int val = a(_6); Is the abomination. Expecting every programmer to know that a(b(), c()); may call b() first or may call c() first is an abomination. Having a programmer's app work fine on most PCs, and then suddenly having a…
>int val = a(b(c(), d()), e(f(), g()));
I'll stick by my original assertion. If the order of those invocations matter, then they shouldn't be on the same line, regardless of whether the actual behavior is well-defined or not. Just one example of what can go wrong: parameter reordering is often done automatically by tools, or manually by someone who is not intimately familiar with the code, such as six-months-in-the-future you.
Six operations with side effects--especially conflicting side-effects--belong on six lines. Six lines on your screen is not worth the days potentially spent searching for a future bug.
Re: The Design of C++ (1994) [video]
#58The language may seem complex to some, but so does math. It is the single most powerful programming tool the world has ever known. Sure, it may be hard to see that it is beautiful, but that is so only because it is a product of both intelligent design and evolution. The language structure is extremely logical, and there is very little that could be changed in it without the danger of destroying its finely tuned fabri…
Let's bring up some technical details to see whether there is a deliberate thought process behind the evolution of C++. Recent versions of C++ have the auto keyword. It's a cool new feature grafted onto C++ from other languages and meant to make the programmer's life easier. It lets you avoid typing things like for (std::vector >::const_iterator it = v.begin(); it != v.end(); ++it) { foo(*it); } The above used to be…
for (auto x : v) {
usually you'd use for(const auto& : v) though
Re: The Design of C++ (1994) [video]
#59Earlier quoted context omitted.
The sort of puppy-dog C++ style on Arduinos - a sort of pedomorphic variation on "'C' with classes", chock full of singletons and the inability of constructors to operate unless they're called in A Certain Place - pretty much works. What's less attractive is Dogmatic Bikeshedding C++ OO Fundamentalism.
its actually the full gcc compiler on arduino.... not that they advertise that.
They were pretty upfront about it being gcc/g++ - the "Arduino" part are the built-in things like Serial.
Re: The Design of C++ (1994) [video]
#60I finally figured how Dr. Stroustrup can always make C++ seem like not only a reasonable thing, but probably the best possible one. He has chosen a number of goals that, while being reasonable and desirable individually, each tend to complicate the realization of all the others. Consequently, for any of the complications of the language, he can pick a couple of goals and show that they make the complication unavoidab…
We will now call this "Stroustrupping": choosing a large number of incompatible goals and using a subset to defend any argument while ignoring the fact this subset conflicts with many of the other goals, such as the subset used to defend the previous argument.
To be clear, I am not suggesting that Stroustrup is being misleading in any way. I think the complexity is inevitable, given the goals, and I came to this view from asking whether there is one thing about C++ that leads to this complexity. Perhaps the closest thing to a single cause was the decision to make C++ a superset of C, which in turn leads to the use of naked pointers, arrays that do not know their dimensions, and to accessing arrays through pointers. Another issue may be separate compilation, which seems to complicate templates and polymorphism.