This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Tue, 2004-08-31 at 06:17 -0400, Doctor Bill wrote: > Actually, this makes perfect sense. When you do SomeClass(), without > using the new operator, you are telling the compiler to create this > instance on the stack, and then when you do foo(SomeClass()) you are > telling the compiler to pass this class by value. To do so requires > creating a copy. No. You need to see the method signature to know if this is the case or not. As it happens the signature is void foo(SomeClass const &); > This would not solve your problem. If you are trying to pass the > class by value, a copy will still need to be made. And? there are two separate copy methods for classes: assignment operator and copy constructor. In this case the assignment operator is written and public, and the existing, working code has no copy constructor written. > BTW. I would discourage all of these examples. Why? Because I > firmly believe in using a smart pointer class, and making the actual > constructors private. i.e. These two things are orthogonal. Smart pointers are good, but making the constructors private forces the class to be foreign storage only, which can be an unnecessary burden. ... > If that was followed for all the code, then your original example would have > been written: > > foo.create(Something.create()); eek. Any decent smart pointer class will let you do foo(SomeClass()); Rob
Attachment:
signature.asc
Description: This is a digitally signed message part
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |