Do you use C++11

Pages: 1234... 8
AlitCandle wrote:
I also don't see why you should use constructor initializer lists. IIRC all they do is make sure those objects are constructed before the object that is being constructed. I'm pretty sure this doesn't make a difference when using primitive types like integers.


You do not recall correctly.

Constructor initializer lists allow you to initialize member objects and supply arguments to base class constructors. This happens before the body of the constructor is entered. If you do not use the initializer list those objects will be default-constructed prior to the body of the constructor being entered. In practical terms this means that if you make it a habit of assigning to members in your constructor body instead of using the initializer list, your code will be less efficient (requiring a default construction, then assignment) than if you used the initializer list (which only requires construction.)

[edit: quote attribution]
Last edited on
@cire
Oh ok, thanks.

@Fredbill

What is the point of Computer Science if nothing ever gets easier/changes? C++11 has added many nice shortcuts which is pretty much the entire point of high level programming language. You might as well go write everything yourself in assembly and never use any 3rd party libraries if you never want anything to get easier/change.
Last edited on
I use C++11 with clang++ -std=c++11 :)
I still don't understand why anyone would want to do that, even more why anyone would want to use C++ 11

Name the C++11 improvements that you don't like!

I would nominate move constructors and operators. In a language that is already too expert-friendly, these represent more bookkeeping tasks under the guise of microoptimizations.
I use it. I think it's a huge improvement. You now have hash tables, standard multithreading support, range based for loops, atomics, lambda's, and all kinds of other good stuff. C++ was/is poorly designed in many aspects. C++11 makes it possible to write better more elegant code than was possible before.
@Catfish4

Move constructors are not useless when pushing large objects into a container like a vector.

Instead of constantly copying and reassigning all the values you just change who owns the memory. There is no reason not to make one when making a class.

I don't understand what you mean by "expert friendly"
Last edited on
@Catfish4

Here is a small part of the book I am reading:

Before C++11, a swap() function could be implemented as follows. This example
uses templates, which are discussed in detail in Chapter 19.
1
2
3
4
5
6
7
template<typename T>
void swapCopy(T& a, T& b)
{
T temp(a);
a = b;
b = temp;
}

This implementation fi rst copies a to temp, then copies b to a and then copies temp to b. If type T
is expensive to copy, this swap implementation will hurt performance. With move semantics the
swap() function can avoid all copying:
1
2
3
4
5
6
7
template<typename T>
void swapMove(T& a, T& b)
{
T temp(std::move(a));
a = std::move(b);
b = std::move(temp);
}
Catfish4 wrote:
Name the C++11 improvements that you don't like!

I would nominate move constructors and operators. In a language that is already too expert-friendly, these represent more bookkeeping tasks under the guise of microoptimizations.
Considering that in many cases with properly designed code move constructors are implemented for you by the compiler, it can drastically speed up code and make expensive operations much cheaper. Move assignment operator is also useful, since we can now move streams (which, if you'll remember, were a pain in the ass because they were non-copyable).

While it is true that move constructors sort of circumvent the original flow of C++, I don't even think stroustrup is happy with the original flow of C++ and so he's trying to change it.
I just remembered that noexcept and throw lists were added in C++11. That definitely isn't useless.
closed account (N36fSL3A)
Alit I think you're going a bit too far with it. I never said I'd program with assembly, how do you get assembly from C++? Just because I don't see a large difference between 11 and 03?
AlitCandle wrote:
I just remembered that noexcept and throw lists were added in C++11. That definitely isn't useless.
Throw lists have been in C++ for a while, and not only that, they've been deprecated in C++11. Yes, deprecated. Because they're the same mistake as Java.
Because they're the same mistake as Java.


Can you elaborate?
Fredbill30, to your earlier question, why people would want to define constants in classes versus using #define... Well, #define does not take into account type. It is a direct replace of any instance of the word with what it is defined to be, regardless of what it is. This can cause a hell of a lot of issues. Constants in code, however, do not suffer from such limitations. Also, using #define can also cause issues outside of header files for a specific class if you need it to hold different values between classes (if you were to define the classes all in a single file, for example). Easy to do with constants, not so easy with #define, because constants have the benefit of being localized to wherever you stick them. #define is just a preprosser directive to replace all instances of one word with the value assigned, which... well, doesn't care where it is.
AlitCandle wrote:
> Because they're the same mistake as Java.

Can you elaborate?
Look up Java's Checked Exceptions thing, even RapidCoder has negative statements about it.
closed account (zb0S216C)
LB wrote:
"Considering that in many cases with properly designed code move constructors are implemented for you by the compiler"

GCC will, but the last time I checked, MSVC++ doesn't.

Catfish4 wrote:
"Name the C++11 improvements that you don't like!"

Lambdas, range-based "for"[1], smart-pointers[2], "::begin( )" and "::end( )"[3], and garbage collection[4].

[1]The new rage-based "for" is far more obscure (IMO) than the usual "for" variation.

[2]Smart-pointers are for lazy programmers. While most programmers would disagree with me on this, I think constructs such as "smart-pointers" encourage the "let the compiler do it; I can't be bothered" attitude.

[3]Useless. Plain and simple.

[4]While garbage collection is an optional feature, it introduces a horrid, slow and clunky construct to a language capable of producing fast programs. The last thing C++ programmers need is a program with a dead-weight dependency slowing it down.

Wazzak
Last edited on
closed account (N36fSL3A)
@Ispil Okay. So that means I have to change 95 percent of my #define s to constants. Lol.
@Framework
I don't mind garbage collection in other languages, but I don't think it belongs in C++, and actually I didn't know it was being added. As for the range-based for loop, I really like it, I use it a lot, but I think a foreach-in construct might have been more clear. I like smart pointers. Ordinary pointers are very C-like and garbage collection is very Java-like; smart pointers are very much the C++ solution: maximising high-level features while minimising overhead. Definitely the way-to-go IMO.

I don't know what you mean by
"::begin( )" and "::end( )"
Framework wrote:
GCC will, but the last time I checked, MSVC++ doesn't.
I don't consider MSVC to be useful for any C++11 projects. The things from C++11 it does support are hardly useful on their own. Please stop basing your opinion on a non-compliant compiler.

Framework wrote:
> Name the C++11 improvements that you don't like![/i]"
Lambdas, range-based "for"[1], smart-pointers[2], "::begin( )" and "::end( )"[3], and garbage collection[4].

[1]The new rage-based "for" is far more obscure (IMO) than the usual "for" variation.
Are you kidding? Regular for-loops look obfuscated, the range-based for loops display clear intent.
Framework wrote:
[2]Smart-pointers are for lazy programmers. While most programmers would disagree with me on this, I think constructs such as "smart-pointers" encourage the "let the compiler do it; I can't be bothered" attitude.
Please tell me you're being sarcastic. RAII is designed to prevent the programmer from being forgetful, not to let the programmer be lazy.
Framework wrote:
[3]Useless. Plain and simple.
Yes, generic code that works in all situations is indeed very useless. </Sarcasm!> Are you kidding? They're incredibly useful.
Framework wrote:
[4]While garbage collection is an optional feature, it introduces a horrid, slow and clunky construct to a language capable of producing fast programs. The last thing C++ programmers need is a program with a dead-weight dependency slowing it down.
I don't like GC in languages so I don't have a valid opinion here.

@chrisname: He forgot the "std" before them:
http://en.cppreference.com/w/cpp/iterator/begin
http://en.cppreference.com/w/cpp/iterator/end
Very useful :D
Last edited on
closed account (zb0S216C)
chrisname wrote:
"::begin( )" and "::end( )"

Sorry, I meant "std::begin( )" and "std::end( )".

LB wrote:
"Please stop basing your opinion on a non-compliant compiler."

I use the latest GCC compiler, so I don't know where you get "non-compliant compiler" from.

LB wrote:
"Regular for-loops look obfuscated, the range-based for loops display clear intent."

Err... no.

LB wrote:
"Please tell me you're being sarcastic."

Do you see any sarcasm tags in my last reply?

LB wrote:
"They're incredibly useful."

I disagree. Not once have I ever deemed their use valuable.

Wazzak
Last edited on
Pages: 1234... 8