Re: compilation error with direct-initialization
On Aug 10, 1:05 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* SG:
On 10 Aug., 10:31, "subramanian10...@yahoo.com, India" wrote:
Suppose 'Test' is class with the default ctor and copy ctor
defined
Then the line
Test obj(Test);
declares obj to be a function taking 'Test' class object as
parameter and returns a 'Test' class object. Am I correct ?
Now consider the line
Test obj(Test());
Here, I thought, Test() would return a temporary 'Test'
class object which would be the argument to copy ctor, that
will create 'obj'.
The other interpretation would be that it's equivalent to
Test obj(Test(*)());
which decalres a function obj that takes a function pointer.
Kindly explain me where I am misunderstanding. What is the
difference between the above two declarations ?
See
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=439
I would write
Test obj = Test();
instead for improved clarity and expect compilers to elide
unnecessary copies.
Which, of course, doesn't work if the object type doesn't
support copy. (In the particular case where the argument is
Test(), of course, the above doesn't work either if copy isn't
supported. And the above would normally be written just:
Test obj ;
..)
I agree, but just to not let some avenue be unexplored I just
now tried replacing all such in the code I'm working on (it's
a small hobby project, so far some 7K lines) with
Test obj (( value ));
I wasn't sure whether this notation is supported by formal
argument default initialization; it turned out that it's not.
It's probably the most general solution (since it works even for
objects which don't support copy). It's the one I usually use.
Nor is it supported by the possible declarations in 'if' and
loop heads.
No. You can't use objects which don't support copy in
conditionals. (The possibility of such declarations a
misfeature anyway, only useful for obfuscation.)
You can use direct initialization for the loop control variable
in the first part of a for statement, i.e.:
for ( Test obj( (value) ) ; // ...
I also discovered that, not counting for loop control
variables, I have *very* few local variables (and no global
ones), perhaps one per 20th routine.
Really:-). (Function parameters are "local variables":-).)
And this notation, as an adopted convention, sucketh a little
for multi-argument constructor, then necessitating something
like
Test obj (( Test( a, b ) ));
What's wrong with:
Test obj( (a), (b) ) ;
although there was only one such declaration in the code.
I have a couple. Mostly initialization of standard containers,
e.g.:
std::vector< Line > v( (std::istream_iterator< Line >( in )),
(std::istream_iterator< Line >()) ) ;
or
std::map< std::string, std::string > const
m( (begin( initTable )), (end( initTable )) ) ;
(where initTable is defined as:
struct InitMap
{
typedef std::map< std::string, std::string >::value_type
ValueType ;
char const* key ;
char const* value ;
operator ValueType() const
{
return ValueType( key, value ) ;
}
} ;
InitMap cosnt initTable[] =
{
{ "firstEntry" , "firstValue" },
{ "secondEntry", "secondValue" },
// ...
} ;
and begin and end in the usual way.)
Note that this is the only way (at least that I know) to create
a const instance of the container which isn't empty. (And no,
the extra parentheses aren't necessary for the example with
std::map, because begin and end aren't types. I don't usually
use it, but since I think you were talking about doing something
systematically.) In my code base, I've got a couple of cases
where I use const std::map.
But I think, for those who adopt the direct initialization
notation as default convention, as reportedly Francis
Glasborrow does in his books, then (( ... )) would be a nice
convention for that, avoiding the "most vexing parse" problem
and reinstating some of the ease of visual recognition that
"=" notation has.
Yes. I tend to favor direct initialization for class types; I'm
a lot less rigorous about it for other types. The main reason
is because it isn't assignment, and the = looks so much like an
assignment operator. (And the reason I'm less concerned about
this distinction with non-class types is because it doesn't
really exist for non-class types.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34