468,491 Members | 2,079 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,491 developers. It's quick & easy.

Template parameter type constructor method call

How do I write a constructor mehtod call in this case

/*-----------*/
template<typename Tclass CObjectPoolImpl
{
public:

void smth(T* pObj)
{
if (pObj)
pObj->T::T(); // an attempt to call a constructor method of
class T
}

};

CObjectPoolImpl<mynamespace::CMyTypeCF;
CMyType mt;

CF.smth(&mt);
/*-----------*/

MS Visual C++ 7.1:
error C2039: 'T' : is not a member of 'mynamespace::CMyType'

There is a reason not to write 'new T' and not to explicitly write
constructor method name (type name). Default constructor method for
CMyType exists.

Oct 12 '06 #1
18 3394
AlexanderVX wrote:
How do I write a constructor mehtod call in this case
There is no "constructor method call" in C++. What is it you're
trying to accomplish?
>
/*-----------*/
template<typename Tclass CObjectPoolImpl
{
public:

void smth(T* pObj)
{
if (pObj)
pObj->T::T(); // an attempt to call a constructor method of
class T
I am guessing here, but you might want to do

new (pObj) T();
}

};

CObjectPoolImpl<mynamespace::CMyTypeCF;
CMyType mt;

CF.smth(&mt);
This will very likely cause the constructor to be called twice for the
same object. That has undefined behaviour, AFAICT. Why do you think
you need it? 'mt' is already a fully constructed object.
/*-----------*/

MS Visual C++ 7.1:
error C2039: 'T' : is not a member of 'mynamespace::CMyType'

There is a reason not to write 'new T' and not to explicitly write
constructor method name (type name). Default constructor method for
CMyType exists.
Read about "placement new".

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 12 '06 #2
AlexanderVX wrote:
How do I write a constructor mehtod call in this case

/*-----------*/
template<typename Tclass CObjectPoolImpl
{
public:

void smth(T* pObj)
{
if (pObj)
pObj->T::T(); // an attempt to call a constructor method of class T
new ( (void*) pObj ) T ();

or:

std::allocator<T>().construct( pObj, T() );
}

};

CObjectPoolImpl<mynamespace::CMyTypeCF;
CMyType mt;

CF.smth(&mt);
/*-----------*/

MS Visual C++ 7.1:
error C2039: 'T' : is not a member of 'mynamespace::CMyType'

There is a reason not to write 'new T' and not to explicitly write
constructor method name (type name). Default constructor method for
CMyType exists.
Note: probably, someonewill tell you that you cannot call a constructor and
that all that you can do is cause the implementation to invoke/call it.
That slogan refers to three facts: (a) constructor calls are not function
calls, (b) the standard, somewhat cryptically, states that constructors
have no names (hence they are not found through name lookup), and (c) the
standard uses the passive voice in talking about constructors being called.

Personally, I find it rather confusing to underscore the difference between
functions calls and constructor calls by taking the linguistic license to
say that we call functions but not taking the license to say that we call
constructors. (You take a linguistic license in either case since the
standard also uses the passive voice when talking about a function being
called: the standard is just not concerned with what programmers do. Also,
a function call according to the standard is just a certain form of
expression: all you do is to write such an expression in your program and
that causes the implementation to invoke the function in the course of
evaluating the expression.)
Best

Kai-Uwe Bux
Oct 12 '06 #3
This will very likely cause the constructor to be called twice for the
same object. That has undefined behaviour, AFAICT. Why do you think
you need it? 'mt' is already a fully constructed object.
You are right. This is just a sample. And the question was not about
it...
Read about "placement new".
I knew, but this kind of solution was not on the top of my head...

Oct 12 '06 #4
Kai-Uwe Bux, your philosophic remark helps understanding. Good I am not
on technical interview.

Oct 12 '06 #5
And I did it:
pObj = new ( (void*) pObj ) T ();

Guys, "placement new" solution results in

error C2059: syntax error : '('

I have an MFC project with a lot of headers included... What can cause
this?

Oct 12 '06 #6
AlexanderVX wrote:
And I did it:
pObj = new ( (void*) pObj ) T ();

Guys, "placement new" solution results in

error C2059: syntax error : '('

I have an MFC project with a lot of headers included... What can cause
this?
Probably not including <memory>

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 12 '06 #7
Probably not including <memory>

I am not quite sure why I should have included that STL header... BTW,
this no-good project include stuff even not allowing me to use none of
STL....

If I include <memoryor <listor whatever STL:

C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\xutility(341): error C2084: function
'std::_Scalar_ptr_iterator_tag std::_Ptr_cat(const std::_Bool
*,std::_Bool *)' already has a body
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\xutility(251) : see previous definition of '_Ptr_cat'
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\xutility(335): error C2084: function
'std::_Scalar_ptr_iterator_tag std::_Ptr_cat(std::_Bool *,std::_Bool
*)' already has a body
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\xutility(245) : see previous definition of '_Ptr_cat'
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\xutility(168): error C2766: explicit specialization;
'std::iterator_traits<std::_Bool>' has already been defined

And I am confused because it is not obvious what's causing it...

But now my question is why I cannot compile such a simple thing... This
requires include <memoryor something?

pObj = new ( (void*) pObj ) T ();

Oct 12 '06 #8
AlexanderVX wrote:
And I did it:
pObj = new ( (void*) pObj ) T ();
[snip]

Nope. Just

new ( (void*) pObj ) T ();

This is not allocating memory for you. The pointer pObj must already point
to the memory location where you want that object to be constructed.
Best

Kai-Uwe Bux
Oct 12 '06 #9
Kai-Uwe Bux, thanks, it removes unwanted assignment but compilation
error does not go away...

Oct 12 '06 #10
Victor Bazarov posted:
Probably not including <memory>
You sure you don't mean <new>?

--

Frederick Gotham
Oct 12 '06 #11
AlexanderVX wrote:
Kai-Uwe Bux, thanks, it removes unwanted assignment but compilation
error does not go away...
Well, the line is legal. I would guess that there is a syntax error
somewhere close. Please post a minimal complete example that shows the
problem.
Best

Kai-Uwe Bux
Oct 12 '06 #12
Frederick Gotham wrote:
Victor Bazarov posted:
>Probably not including <memory>

You sure you don't mean <new>?
Do we need any headers for placement new? I thought, <newjust provides
allocation and deallocation functions. Placement new shouldn't need those,
or would it?
Best

Kai-Uwe Bux
Oct 12 '06 #13
* Kai-Uwe Bux:
Frederick Gotham wrote:
>Victor Bazarov posted:
>>Probably not including <memory>
You sure you don't mean <new>?

Do we need any headers for placement new? I thought, <newjust provides
allocation and deallocation functions. Placement new shouldn't need those,
or would it?
There are infinitely many different placement new's, but /the/ placement
new, the one that constructs in place, requires the header <new>. It's
also a good idea to use '::'. This is because it's a library feature,
not a language feature (although those are strongly connected here).

But, but, but... I hear you say, the <newheader also defines the
standard global allocation function invoked by ordinary 'new', and we
don't need to include no flickin' <newheader to use ordinary 'new'?

Well, that's because the ordinary 'new' is made easy to use, while the
placement form is made less easy to use. It's specified by 5.3.4/11.
If the placement new syntax is used (and only then), overload resolution
is performed to determine the allocation function to call, which
allocation function, in the case of /the/ placement new, is supplied by
the <newheader.

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Oct 12 '06 #14
Kai-Uwe Bux wrote:
Frederick Gotham wrote:
>Victor Bazarov posted:
>>Probably not including <memory>

You sure you don't mean <new>?

Do we need any headers for placement new? I thought, <newjust
provides allocation and deallocation functions. Placement new
shouldn't need those, or would it?
He's right, <newis what's needed, not <memory>. Placement new
is declared in it. See 18.4 of the Standard.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 12 '06 #15
Victor Bazarov wrote:
Kai-Uwe Bux wrote:
>Frederick Gotham wrote:
>>Victor Bazarov posted:

Probably not including <memory>

You sure you don't mean <new>?

Do we need any headers for placement new? I thought, <newjust
provides allocation and deallocation functions. Placement new
shouldn't need those, or would it?

He's right, <newis what's needed, not <memory>. Placement new
is declared in it. See 18.4 of the Standard.
Thanks, now that I read it, I feel that the whole thing is a mess. Do I
understand this correctly:

1. Any call to new (placement or not) will call an allocation function and
construct the object.

2. For the usual placement new, we do not want to allocate memory; thus, we
provide a special allocation function that intentionally does nothing. When
allocation is a null-op we are just left with the construction of the
object that any call to new will perform.

3. To add insult to injury, we need to include the header <newbecause that
is where the 'allocation function that intentionally does nothing' is
declared.

Oh boy: I need to include the right header to get a function that does
nothing! Why does it have to be that weird? More and more, I come to think
that we should just be able to call constructors as we can call the
destructor.
Thanks again

Kai-Uwe Bux
Oct 13 '06 #16
Kai-Uwe Bux wrote:
[..] Do
I understand this correctly:

1. Any call to new (placement or not) will call an allocation
function and construct the object.

2. For the usual placement new, we do not want to allocate memory;
thus, we provide a special allocation function that intentionally
does nothing. When allocation is a null-op we are just left with the
construction of the object that any call to new will perform.

3. To add insult to injury, we need to include the header <new>
because that is where the 'allocation function that intentionally
does nothing' is declared.
I am not sure how you make this conclusion. The header <newdeclares
overloaded 'operator new' functions that take some special arguments
(along with the size). Those forms do not exist by themselves in the
language, they are part of the library. It really has nothing to do
whether the allocation function for placement new does anything.
>
Oh boy: I need to include the right header to get a function that does
nothing!
No, not at all. You need to include the right header for the right
'operator new' function declaration.
Why does it have to be that weird? More and more, I come to
think that we should just be able to call constructors as we can call
the destructor.
It's all in your head.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 13 '06 #17
Well, the line is legal. I would guess that there is a syntax error
somewhere close. Please post a minimal complete example that shows the
problem.
In headers I found this... Left by my predeccessor a million years
ago...

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

I removed it and the proposed "placement new" solution works!

Oct 13 '06 #18
Victor Bazarov wrote:
Kai-Uwe Bux wrote:
>[..] Do
I understand this correctly:

1. Any call to new (placement or not) will call an allocation
function and construct the object.

2. For the usual placement new, we do not want to allocate memory;
thus, we provide a special allocation function that intentionally
does nothing. When allocation is a null-op we are just left with the
construction of the object that any call to new will perform.

3. To add insult to injury, we need to include the header <new>
because that is where the 'allocation function that intentionally
does nothing' is declared.

I am not sure how you make this conclusion. The header <newdeclares
overloaded 'operator new' functions that take some special arguments
(along with the size). Those forms do not exist by themselves in the
language, they are part of the library. It really has nothing to do
whether the allocation function for placement new does anything.
I didn't (mean to) say that you need <new*only* to include functions that
don't do anything or that whether you have to include <newdepends on
whether the functions do something or not.

What I find strange is the round-about way of C++ to provide object
construction at a specified location. Here is what I figured from 5.3.4:

A placement new expression like

new ( some, args ) T ( some, other, args )

can be understood as performing two steps (given in pseudo-code):

1. void* pos = operator new( sizeof(T), some, args ).
2. construct T( some, other, args ) at pos.

Thus, placement new provides a hook to supply additional arguments to an
allocation function (5.3.4/11).

As a trick, for just constructing an object of a given location, the header
<newprovides the overload

void* operator new (std::size_t size, void* ptr) throw();

described in 18.4.1.3. And this operator new overload is deliberately
designed to just return ptr and perform no other action. Thus, if you do

new ( (void*) t_ptr ) T ( some, other args );

the above two steps translate to

1. void* pos = operator new( sizeof(T), (void*)t_ptr );
( equivalent to: void* pos = (void*) t_ptr; )
2. construct T( some, other, args ) at pos.

I consider that a pretty awkward way of going about construction of an
object. The compiler knows how to construct an object at a given location
anyway. This is nothing that is done by the operator new overload from
<new>; and in fact, one would expect (or hope) that step 1 in the above
sequence is optimized away. So, I find it strange that C++ does not offer a
way of constructing an object at a given location that does not involve an
allocation function to be imported from <new>.

It's like using delete with the deallocation function from 18.4.1.3/5-10 for
calling a destructor.

>Oh boy: I need to include the right header to get a function that does
nothing!

No, not at all. You need to include the right header for the right
'operator new' function declaration.
Yes, and 18.4.1.3/1-4 describes the right one for the line in question

new ( (void*) t_ptr ) T ( some, other args );

and this right one just returns its second argument and does nothing else.

>Why does it have to be that weird? More and more, I come to
think that we should just be able to call constructors as we can call
the destructor.

It's all in your head.
I would think, it was in the standard before it was in my head :-)
Best

Kai-Uwe Bux
Oct 14 '06 #19

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Alexander Stippler | last post: by
8 posts views Thread by Alexander Stippler | last post: by
14 posts views Thread by Bart Samwel | last post: by
8 posts views Thread by Tony Johansson | last post: by
12 posts views Thread by mlimber | last post: by
3 posts views Thread by gieforce | last post: by
reply views Thread by theflame83 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.