constructor

问题 Pretty easy question, but anyway: is there any reason to override default constructor like this: public SomeObject(){ } It is public. It is does not have any logic. So, is there necessary? I didn't see the whole picture? Appreciate all your help. 回答1: One reason to define an empty no-arg constructor is if there is also a non-default constructor and the no-arg constructor is still desired to be accessible (public or protected). This is because any [other] constructor definition will prevent

问题 Pretty easy question, but anyway: is there any reason to override default constructor like this: public SomeObject(){ } It is public. It is does not have any logic. So, is there necessary? I didn't see the whole picture? Appreciate all your help. 回答1: One reason to define an empty no-arg constructor is if there is also a non-default constructor and the no-arg constructor is still desired to be accessible (public or protected). This is because any [other] constructor definition will prevent

问题 In D, I'm trying to create an enum whose members have members. I can better explain what I'm trying to do with an example, where s and i stand in for the sub-members I'm trying to create: In Python, I can do this: class Foo(enum.Enum): A = "A string", 0 B = "B string", 1 C = "C string", 2 def __init__(self, s, i): self.s = s self.i = i print(Foo.A.s) Java can do something like this: public enum Foo { A("A string", 0), B("B string", 1), C("C string", 2); private final String s; private final

问题 class A { private: int a; int b; int c; public: A() : b(2), a(1), c (3) { } }; As per C++ standard data members are constructed and initialized in the order they are declared, correct? But when using initalization list, we are changing the order of data members, now do they initialize in order of initialization list or the order of declaration? 回答1: In the order of declaration, the order in the initialization list does not matter. Some compilers will actually give you warning (gcc) telling

问题 I have the following class: class FixedByteStream { public: FixedByteStream() : size(0), address(NULL), existing(false) {} FixedByteStream(int length) : existing(false) { size = length; address = new char[length]; } FixedByteStream(int length, char* addr) : existing(true) { size = length; address = addr; } FixedByteStream(string* str, bool includeNull = false) : existing(true) { size = (*str).length(); address = const_cast<char*>((*str).c_str()); if (includeNull){ ++size; } } ~FixedByteStream

问题 In the following code, are pS and s.pS guaranteed to be equal in the final line? In other words, in the statement S s = S(); , can I be sure that a temporary S will not be constructed? #include <iostream> using namespace std; struct S { S() { pS = this; } S* pS; }; int main() { S s = S(); S* pS = &s; cout << pS << " " << s.pS << endl; } In every compiler I've tested this in pS == s.pS , but I'm not sufficiently familiar with the standard to be able to satisfy myself that this is guaranteed.

问题 I've defined multiple constructors, with some default argument values in all of them. Looks correct (I can't see any ambiguity), but Scala (2.8) compiler complains: multiple overloaded alternatives of constructor define default arguments Does it mean that I can't define default values for overloaded constructors at all? Let me illustrate the situation (primitivized, of course, but illustrative): class A(subject : Double, factor : Int = 1, doItRight : Boolean = true) { def this (subject : Int,

问题 I've defined multiple constructors, with some default argument values in all of them. Looks correct (I can't see any ambiguity), but Scala (2.8) compiler complains: multiple overloaded alternatives of constructor define default arguments Does it mean that I can't define default values for overloaded constructors at all? Let me illustrate the situation (primitivized, of course, but illustrative): class A(subject : Double, factor : Int = 1, doItRight : Boolean = true) { def this (subject : Int,

问题 VB6 classes have no parameterized constructors. What solution have you chosen for this? Using factory methods seems like the obvious choice, but surprise me! 回答1: I usually stick to factory methods, where I put the "constructors" for related classes in the same module (.BAS extension). Sadly, this is far from optimal since you can't really limit access to the normal object creation in VB6 - you just have to make a point of only creating your objects through the factory. What makes it worse is

问题 today I saw a snipped that looked really horrible to me, but unfortunetly I cannot simply change it, so I wonder if I can bypass this somehow. I have a class with a constructor that has an output-parameter for success. But that looks really ugly to me. And now when deriving from this class I have to take this param with me- if I want to or not. class ClassA { ClassA(out bool success) {...} } class B: ClassA { // call the constructor from ClassA but without the out-param } So I´d know if its