C# Naming Conventions

[TheoLogic]

How else would you use the initializer list? Not and just putting them in the constructor body? If this is the case, you are loosing performance. You will get a default initialization followed by an assignment! You should always initialize using the initializer list, always, no exceptions. Even if this means nullptr!

//h
class Foo
{
public:
Foo();

private:
int m_whatever;
MyObject* m_myObject;
};


//cpp
Foo::Foo()
:
m_whatever(0),
m_myObject(nullptr)
{
//Do some stuff so you can actually create m_myObject;
m_myObject = ...
}

 

This is the same discussion:

int blah = 0;
//vs
int blah(0);

 

Old compilers will not optimize the first one, and you'll get a default construction and an assignment. If you say premature optimization is the root of all evil, I agree. But this is sometimes faster, never slower so I don't consider this as an optimization...

 

But here is the good news, C++11 has a feature called "non-static datamember initialization". Once your compiler is updated, you can do:

class Foo
{
private:
int m_whatever = 0;
};

 

 

But wandering off-topic. Interesting things though

[Rick]

You should always initialize using the initializer list, always, no exceptions

 

I guess I'm a bad boy then because I never do that. Honestly I've never had any issues with not doing that. I've never seen any performance issues to worry about, and never had any strange bugs come up because of it. I feel like I'd need a more solid reason to make me change my ways with this. :/

[TheoLogic]

I guess I'm a bad boy then because I never do that. Honestly I've never had any issues with not doing that. I've never seen any performance issues to worry about, and never had any strange bugs come up because of it. I feel like I'd need a more solid reason to make me change my ways with this. :/

 

Using the language like it is supposed to? You should always initialize your variables, and you now do this in the constructor body yes?

If this is the case, why in hell wouldn't you do it in the way the language supports it? I don't see the overhead in initializer list vs constructor body.

[Rick]

I personally don't like the syntax, and don't care about the next to nothing savings you get, but also sounds like there are some caveats that come with this.

 

 

1) The items are not necessarily initialized in the order that they're listed in the initializer list. They're actually initialized in the order in which they're declared in the class.

 

 

class Foo
{
 vector<int> vec;
 int count;

public:
 Foo(int val)
 : count(val * 3),
   vec(count)                   // problem because count isn't what you think it is
 {
 }
};

 

2) They can complicate multiple ctors and produce a lot of redundant code. Say you have a class that has 20 members and 5 different ctors (most of which are initialized the same way for every ctor).

 

3) Sounded like arrays also can't be in there.

 

 

No need to get upset (the use of "why the hell" would lead me to believe your passion here) as it doesn't affect you in any way. Lots of people use things in which they weren't intended and the world still goes round I was just being honest in that I've been using C++ for 10 years and have never used initializer list. I'm not really heavy into C++ right now as I'm using lua more and to change my habits of 10 years most likely isn't going to happen

[TheoLogic]

I personally don't like the syntax, and don't care about the next to nothing savings you get, but also sounds like there are some caveats that come with this.

 

 

1) The items are not necessarily initialized in the order that they're listed in the initializer list. They're actually initialized in the order in which they're declared in the class.

 

 

class Foo
{
 vector<int> vec;
 int count;

public:
 Foo(int val)
 : count(val * 3),
   vec(count)                   // problem because count isn't what you think it is
 {
 }
};

 

2) They can complicate multiple ctors and produce a lot of redundant code. Say you have a class that has 20 members and 5 different ctors (most of which are initialized the same way for every ctor).

 

3) Sounded like arrays also can't be in there.

 

 

No need to get upset (the use of "why the hell" would lead me to believe your passion here) as it doesn't affect you in any way. Lots of people use things in which they weren't intended and the world still goes round I was just being honest in that I've been using C++ for 10 years and have never used initializer list. I'm not really heavy into C++ right now as I'm using lua more and to change my habits of 10 years most likely isn't going to happen

 

Fully agree, you must actually know C++ to use the initializer lists. Same applies for static's, inheritance, ...

I also agree that you will have redundant code on big classes (one of the reasons to keep them small and simple), that's why "non-static data member initialization" is introduced in C++11.

 

I'm not trying to change your habits. Even though I have a passion for C++, I find myself doing much more C# and python lately . But anyhow, I believe it's a best practice to use the language like it is supposed to. I find myself in the position where I have to maintain legacy C++ code written by COBOL developers, and you won't guess the amount of bugs I found due to uninitialized variables. Before I got here, they've spend 5 months on finding a buffer overflow in old-school C arrays. I refactored the code to use the STL, and it was fixed in 2 hours.

 

Bottom line, initialize your variables, initializer list or not can be a personal preference. I'll quit talking about this, they'll blame the C++ devs of hijacking threads .

[L B]

Oh lory, I thought I was in the C# forum, and now I'm assaulted with pointers. I must have gotten lost!