initialize strings in class

Hello

Suppose I have some class:

Code:

---

class someclass {
public:
  someclass() : m_id(0) { }

private:
  int m_id;
  std::string m_str1;
  std::string m_str2;
};

---

Is it sensible to initialize strings in this constructor (when no arguments are passed) like : m_id(0), m_str1(""), m_str2("") , etc.. or just leave as it is?

Thanks for help

A string is by it's own constructor initialized to empty string, so you don't NEED to do it. It's of course nothing wrong with initializing it anyways [except it adds extra code].

--
Mats

Thanks!

It might be better to initialize them using the default constructor: m_id(0), m_str1(), m_str2()

Somebody on this forum indicated that they prefer to always initialize everything in the initializer list, even those that only require a call to the default constructor. This documents that such an initialization was intended and not an oversight.

Quote:

---

Originally Posted by Daved

Somebody on this forum indicated that they prefer to always initialize everything in the initializer list, even those that only require a call to the default constructor. This documents that such an initialization was intended and not an oversight.

---

Yes, there's truth to that - you KNOW that the value is initialized. And my comment that "it adds extra code" is probably a little bit exaggerated, as the default constructor will be called ANYWAYS for all members that are classes. So you're not really adding any extra calls.

--
Mats

You're just adding a lot of extra work in typing that call to the default constructor that usually gets called by default ;)

Quote:

---

Originally Posted by Elysia

You're just adding a lot of extra work in typing that call to the default constructor that usually gets called by default ;)

---

Yes, but also clarifying to any casual reader that the content is initialized (and to what).

--
Mats

It's another matter if you need to initialize it to something else than "empty," but otherwise there's no big gain in doing so.

Quote:

---

Originally Posted by Elysia

It's another matter if you need to initialize it to something else than "empty," but otherwise there's no big gain in doing so.

---

Yes, but even in the "empty"/"default" value case, you clarify that you INTEND this to be empty/have default value, rather than "forgot to set it to something".

Again, I'm not saying that you HAVE to do it either direction - but the REASON for having explicitly assigned the members in a class is that you indicate that "I know that this should be empty" rather than "it's empty because it hasn't been set yet" - those are two different cases. Have you ever had a function/class that didn't work because you forgot to set a member variable at some point or another? I find that highly likely.

--
Mats

Probably there is, but I can't think of such a time, of course.
Unless I have to initialize something to a value other than "empty," I never call the constructor explicitly. Every class should have a default constructor that initializes the class to "empty" IMO.

Unless there is no "empty" or "zero" state, in which case it shouldn't have a default constructor.

> Yes, but even in the "empty"/"default" value case, you clarify that you INTEND this to be empty/have default
> value, rather than "forgot to set it to something".

I understand the desire to convince the reader that the writer knows what he's doing, but this sort of thing can backfire. If the reader knows the language at least as well as the writer does, and notices that the writer did something explicitly, even though the default does the right thing, then he may start to wonder whether the writer even knew this, and start second-guessing everything else in the code. My philosophy is that if doing nothing is guaranteed to do the right thing, then it's safer to do nothing, and it's the reader's responsibility to know the language well enough to know the difference between whether the writer forgot something, or was just being concise.

Yes, it's only meaningful to do implicit initialization explicitly if EVERYONE working on that code understands that it's done that way - e.g. in coding standards or such.

--
Mats

Quote:

---

Originally Posted by robatino

> Yes, but even in the "empty"/"default" value case, you clarify that you INTEND this to be empty/have default
> value, rather than "forgot to set it to something".

I understand the desire to convince the reader that the writer knows what he's doing, but this sort of thing can backfire. If the reader knows the language at least as well as the writer does, and notices that the writer did something explicitly, even though the default does the right thing, then he may start to wonder whether the writer even knew this, and start second-guessing everything else in the code. My philosophy is that if doing nothing is guaranteed to do the right thing, then it's safer to do nothing, and it's the reader's responsibility to know the language well enough to know the difference between whether the writer forgot something, or was just being concise.

---

I agree with this. Keep It Simple.
It's not worth trying to cater for every person that might not know one language feature or another.