constructor

问题 I have always been a good boy when writing my classes, prefixing all member variables with m_: class Test { int m_int1; int m_int2; public: Test(int int1, int int2) : m_int1(int1), m_int2(int2) {} }; int main() { Test t(10, 20); // Just an example } However, recently I forgot to do that and ended up writing: class Test { int int1; int int2; public: // Very questionable, but of course I meant to assign ::int1 to this->int1! Test(int int1, int int2) : int1(int1), int2(int2) {} }; Believe it or

问题 At work we have a class with an expensive constructor so we would like it to be called as few times as possible. We looked through the uses of it and tried to make the code more RVO friendly so to say. However we found a quirk in the g++ compiler where we didn't understand what happened. Please consider the two implementations of operator+ const Imaginary Imaginary::operator+(const Imaginary& rhs) const { Imaginary tmp(*this); tmp.append(rhs); return tmp; } and const Imaginary Imaginary:

问题 I was surprised to find out that the parameter-less constructor of my base class is called any time I call any constructor in a derived class. I thought that is what : base() was for, to explicitly call the base constructor if and when I want to. How can I prevent the base constructor from being called when I instantiate a derived class? using System; namespace TestConstru22323 { class Program { static void Main(string[] args) { Customer customer = new Customer("Jim", "Smith"); Customer c =

问题 public class test { test(double[] a) { System.out.println("in double"); } test(Object a) { System.out.println("in object"); } public static void main(String args[]) { new test(null); } } In the above code, I pass null as the constructor argument. As null can be anything, the above code compiles fine. When I run the code I expected it to print in object but it prints in double What is the reason behind this? NOTE the linked question may not be duplicate because this question is related with

问题 Some of us know that there are several constructors possible for C++ object, C1 and C2. But GCC sources says that there is can be third variant of constructor, the C3 "complete object allocating constructor" (check gcc-4.8/gcc/cp/mangle.c file just before write_special_name_constructor function): http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/mangle.c;h=10c2e2beb0c422e4f56e17e7659fbeb4ab3ee31b;hb=refs/tags/gcc-4_8_1-release#l1644 1645 /* Handle constructor productions of non-terminal

问题 I understand the concept of constructors in OOP languages like C++. However, I am not entirely sure when to use a constructor in REACT. I do understand that JavaScript is object oriented, but I am not sure what the constructor is actually 'constructing'. When rendering a child component, do you need a constructor in the child component? For example: class App extends React.Component { constructor(props) { super(props); this.state = { items: [], error: null } } render () { return ( <React

问题 # type foo = Foo of int * int # let t = (1, 2) # Foo t Error: The constructor Foo expects 2 argument(s), but is applied here to 1 argument(s) How is it that I must do Foo (1, 2) to avoid that error even t has the appropriate type? 回答1: This is one of the troubling parts of OCaml syntax, in my opinion. Despite the way it looks, the constructor Foo doesn't require a 2-tuple as its argument. It requires, syntactically, two values in parentheses--but they aren't a tuple. So it's simply the case

问题 Let's say you have a class class C { int * i; public: C(int * v):i(v) {}; void method() const; //this method does not change i void method(); //this method changes i } Now you may want to define const instance of this class const int * k = whatever; const C c1(k); //this will fail but this will fail because of non-const int C's constructor C(int * v) so you define a const int constructor C(const int * v):i(v) {}; //this will fail also But this will fail also since C's member "int * i" is non

问题 For standard copy constructors and assignment operators, I always think about implementing them or delete ing the defaults out of existence, if my class implements a destructor. For the new move constructor and move operator , what is the right way to think about whether or not an implementation is necessary? As a first pass of transitioning a system from pre-C++0x, could I just delete the default move constructor and move operator or should I leave them alone? 回答1: You don't have to worry

问题 I am working on some code, where I encountered a situation similar to this one: struct Bar; struct Foo{ friend struct Bar; private: Foo(){} void f(){} void g(){} }; struct Bar { Foo* f; Bar() { f = new Foo();} ~Bar() { delete f;} }; int main(){ Bar b; } I would prefer to have Bar not as friend of Foo , because besides Foo s constructor Bar does not need access to any of Foo s private methods (and thus should not have access). Is there a way to allow only Bar to create Foo s without making