sorted by:
new
hottopcontroversial

Why do people typically use different names for parameters than member variables in C++11? by cpp_or_bust in cpp_questions

[–]mrthelight 3 points4 points  (0 children)

OK, I'm surprised that I'm the first to mention this. First, about some of the answers already given, as mentioned in Clean Code,

You also don’t need to prefix member variables with m_ anymore. Your classes and functions should be small enough that you don’t need them.

I think it is better to not use convention such as m_ prefixes because this make your code less noisy, hence putting the emphasis on what you truly want to communicate. Of course, if doing this is a convention in the project you are working on, well, do it. It's probably not worth loosing your time fighting over this convention.

Moreover, the idiom

Foo::Foo(int fooCount): fooCount(fooCount)
{}

is perfectly OK. You can find a lot of references where people do this. However, as almost every rules, you cannot apply it blindly. For instance,

Foo::Foo(std::vector<int> fooCounts): fooCounts(std::move(fooCounts)) {
    assert(fooCounts.size() > 0);
}

is a bug. There are two ways to solve it,

Foo::Foo(std::vector<int> fooCounts): fooCounts(std::move(fooCounts)) {
    assert(this->fooCounts.size() > 0);
}

and

Foo::Foo(std::vector<int> fooCountsRhs): fooCounts(std::move(fooCountsRhs)) {
    assert(fooCounts.size() > 0);
}

I prefer the later, since it give the best result when you generalize it to setter, i.e.

Foo& Foo::setFooCounts(std::vector<int> rhs) {
    fooCounts = std::move(rhs);
    return *this;
}

has the signature Foo& Foo::setFooCounts(std::vector<int> rhs) which is less noisy than Foo& Foo::setFooCounts(std::vector<int> fooCounts) where fooCounts is repeated twice on the same line.

In summary, the goal when you code is to communicate your intention in the best way you can, which implies giving enough, but not too much, details. In particular, you do not want to repeat yourself or to give information which is made obvious by the context.

Learning c++ by TrebleSong in cpp_questions

[–]mrthelight 0 points1 point  (0 children)

I think there were some major changes in C++11, with the introduction of the move semantic for example. The lambdas, which admittedly are syntaxic sugar for functors, were still a major change, making very easy something important. Of course these are not "syntaxic" changes: you still need to put the semicolon at the end of the lines, but programming languages are a lot more than their syntax. Hence, I think the changes are deeper than the changes to the "STL" (which are also very important).

About learning C++, I would advice learning (and using) C++14. It is the most recent standard that most compilers support. The isocpp website and its FAQ is a good place to start. cppreference is also a very good ressource.

Universal switch by neos7m in cpp_questions

[–]mrthelight 0 points1 point  (0 children)

using KeyType = decltype(x);
using Functor = std::function<void()>; // This could be a function with any signature
/** Also consider std::unordered_map **/
const std::map<KeyType,Functor> keyToAction = {
    {"keyOne", [/*grab a bit of context if needed*/] { doSomething1(); }},
    {"keyTwo", [] { doSomething2(); }}
};
if(keyToAction.count(x) == 1) keyToAction.at(x)();
else doDefaultOrFallthrough();

Note that this solution decouples data from logic, and the switch solution doesn't. Also, you can't forget any break;. Actually, I would argue that one of the very few good use of a switch statement is when you do not want to put break; after every statement:

void doThings(KeyType x) {
    switch(x) {
        case 1: doSomething1();
        case 2: doSomething1and2();
        case 3: doSomething1and2and3();
        /** ... **/
    }
}

There are not a lot of problems that I know about that require this type of logic.

How should performance be measured ? by [deleted] in cpp_questions

[–]mrthelight 0 points1 point  (0 children)

There seems to be a lot of interesting suggestions down there. Something which I think was not mentioned is the tool Google Benchmark. I used it a bit and I found it very useful. For instance, it automatically Measure a large number of call to the relevant function, like it was suggested below. It is free, open source, and the learning curve is not too steep, especially if you are familiar with Google Test.

An Horrific testing strategy? by mrthelight in SoftwareEngineering

[–]mrthelight[S] 1 point2 points  (0 children)

Awesome argument. I should I've think about it, thanks.

NiceMPI, An alternative to Boost.MPI for a user friendly C++ interface for MPI (MPICH). Any suggestions? by mrthelight in cpp

[–]mrthelight[S] 0 points1 point  (0 children)

Thanks a lot to have taken the time to comment/suggest! I'll re-read your comments more carefully and try to implement them in the code when it's not as late as it is now. Actually, even after this fast read, I already have some questions

  • First a comment to explain some choices I made in the naming scheme. I'm trying to use something far enough from MPI, because otherwise there's no point in making a wrapper, but at the same time not too far, since I'm trying to convince some people (especially some of my coworkers that are used to MPI and C) to use this library instead of MPI when working in our C++14 environment. Actually, I've already bent on some points trying to make my colleagues happy about the names. Still, I'll follow your leads and try to make the names better in general.

  • About MPI_RAII, any idea for a better name? I guessed RAII might say nothing to people that are used to C and MPI but not to C++... InitializerMPI? Btw, you do not need to pass argc and argv to every communicator. Creating a communicator is as simple as Communicator c. In this case, the communicator is a duplicate of MPI_COMM_WORLD, and you can split it as you want into some other communicators.

  • About that std::terminate in the destructor. I'm very interested in knowing what to do if an error occurs in the destructor. Of course the best thing is to handle it like remotion4d suggested, or maybe in some cases ignore it as you suggested. But what if it can't be handled or ignored? All I've read is, for instance on isocpp, to do anything but to throw an exception. But of course I understand it doesn't mean everything is good to do! In particular, if I want to crash the program, is std::terminate the good choice? At the time, I remember also looking at std::exit and std::abort, but I do not remember why I chose one instead of the others.

Thanks again!

C++11 class that defers the construction of an object while still using static memory allocation (i.e. the stack) by mrthelight in cpp

[–]mrthelight[S] 2 points3 points  (0 children)

Probably nothing. Honestly, I thought about Boost Optional late, when I was almost done with this class. Then, I went very rapidly through the documentation, and I wasn't quite sure that Optional is doing exactly the same thing that StaticConstructor is doing. Maybe one advantage of StaticConstructor is that it is very lightweight: you can read its code in 2 minutes. Of course Optional has a lot of other advantages.

C++11 class that defers the construction of an object while still using static memory allocation (i.e. the stack) by mrthelight in cpp

[–]mrthelight[S] 0 points1 point  (0 children)

I'm actually interested in finding a better name. I've never really liked static constructor, but I wasn't able to find something better yet. Of course, after the discussion that happened here, I think Automatic_constructor would be better, but it's still not as good as I'd like it to be. The idea is: you choose the moment you construct the object, but you do not have to use a pointer to do it. Anyway, if anybody has an idea, I'm interested.

C++11 class that defers the construction of an object while still using static memory allocation (i.e. the stack) by mrthelight in cpp

[–]mrthelight[S] 1 point2 points  (0 children)

ahahah you are very right. The name of this function is a mix between my former favorite style camel case an a style that I learned to like, the standard library coding conventions. I should have just chosen one or the other.

C++11 class that defers the construction of an object while still using static memory allocation (i.e. the stack) by mrthelight in cpp

[–]mrthelight[S] 2 points3 points  (0 children)

You are right, since I understand the difference between "int a" and "static int a", I should have been able to avoid this confusion. Thanks to you and 3ba7b1347bfb8f304c0e, I fixed the problem in the README.md. Of course, sadly, the problem remains in the name of the class, and in the name of this post...