2003 to 2005 upgrade - function pointer syntax issues

[Todd R. Jacobs]

Hi group,

I had this with VS2003 Managed C++

pro-to-types:

===================================
TimeHandler.h

class TimeHandler
{
public:
TimeHandler(void);
virtual ~TimeHandler(void);
// Adjust time span
static bool AdjTime(TimeSpan *tsLogSpan);
};
===================================
TimeHandler.cpp

// Adjust time span
bool TimeHandler::AdjTime(TimeSpan* tsStatusLogSpan)
{
// Adjust TimeSpan here
// ...
}
===================================
Form1.h

#include "TimeHandler.h"

nanespace MyForm
{
public __gc class Form1 : public System::Windows::Forms::Form
{
static TimeSpan tsSpan = 0;
// ...

private: System::Void ShowTimeSpan_Click(System::Object * sender,
System::EventArgs * e)
{
Pass in a pointer to our TimeSpan
AdjTime ( &tsSpan );
// Display adjusted TimeSpan ...
}
};
}
===================================

And now I am trying to do the same with 2005 /clr:pure

===================================
TimeHandler.h
TimeHandler.cpp
SAME AS BEFORE
===================================
Form1.h

#include "TimeHandler.h"

namespace MyForm
{
public ref class Form1 : public System::Windows::Forms::Form
{
static TimeSpan tsStatusLogSpan = TimeSpan(0);
// ...
#pragma region Windows Form Designer generated code
/// ...
#pragma endregion
private: System::Void ShowTime_Click(System::Object^ sender,
System::EventArgs^ e)
{
Pass in a pointer to our TimeSpan
AdjTime ( &tsSpan );
// Display adjusted TimeSpan ...
}
};
}

I am getting the C2664 Error: cannot convert 'cli::interior_ptr<Type>' to
'System::TimeSpan *'
which after looking at the docs would be expected. But I still haven't found
where it shows how to fix it.

Can anyone show me what I need to change?

TIA,
Todd

[Carl Daniel [VC++ MVP]]

Todd R. Jacobs wrote:

I am getting the C2664 Error: cannot convert
'cli::interior_ptr<Type>' to 'System::TimeSpan *'
which after looking at the docs would be expected. But I still
haven't found where it shows how to fix it.

Can anyone show me what I need to change?

I don't have time to try it, but I believe you need to change the type of
the paramer to AdjTime to TimeSpan% instead of TimeSpan*.

-cd

[Todd R. Jacobs]

Carl,

Thank you for your response.

This just arrived today
C++/CLI in Action - Using interior and pinning pointers
By Nishant Sivakumar.
http://www.codeproject.com/books/Cpp...tionCh4Ex1.asp

As described in the above article.

Changing the function definition
From:
static bool AdjTime(TimeSpan *tsLogSpan);
To:
static bool AdjTime(interior_ptr<TimeSpantsLogSpan);

Allowed the use of the native pointer &tsSpan parameter.

Is this what you were inferring?

Thanks again,
Todd

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:uD**************@TK2MSFTNGP03.phx.gbl...

Todd R. Jacobs wrote:

>I am getting the C2664 Error: cannot convert
'cli::interior_ptr<Type>' to 'System::TimeSpan *'
which after looking at the docs would be expected. But I still
haven't found where it shows how to fix it.

Can anyone show me what I need to change?

I don't have time to try it, but I believe you need to change the type of
the paramer to AdjTime to TimeSpan% instead of TimeSpan*.

-cd

[Tamas Demjen]

Todd R. Jacobs wrote:

Changing the function definition
From:
static bool AdjTime(TimeSpan *tsLogSpan);
To:
static bool AdjTime(interior_ptr<TimeSpantsLogSpan);

Allowed the use of the native pointer &tsSpan parameter.

Is this what you were inferring?

It looks like interior_ptr<TimeSpanwould work, too. However, Carl
recommended

static bool AdjTime(TimeSpan% tsLogSpan);

and

AdjTime(tsSpan); // instead of AdjTime(&tsSpan);

I believe this is what you are looking for -- you should just try it,
and unless you experience problems, that's the way to go.

X% is a reference, similar to X& in unmanaged code. The compiler has
more room for optimization when it comes to references, because it can
simply substitute your variable with its reference; it's not possible
with pointers. A reference is also safer than a pointer, since it must
always be initialized. A reference can't accidentally point to a random
location, or to NULL.

The advantage of interior_ptr is that you can use pointer arithmetics on
it, which as

while(*source) *dest++ = *source++;

This is not possible with references. It may also come handy that an
interior_ptr can point to nowhere, and you can also reassign it to
something else. A reference can't be reassigned to a different object.

However, it doesn't look like you need these feature. If you don't need
pointer reassignment or pointer arithmetics, you should stick with the
reference syntax.

I believe that interior_ptr is considered unsafe, and can't be used with
verifiable assemblies (in other words, places where strong security is
required, such as inside a Web browser). You should really not restrict
your function unnecessarily. Unless you have a good reason to use
interior_ptr (such as very fast image processing algorithms), you should
stick with references.

Rule of thumb: If you can solve a problem with references, do it so,
otherwise use interior_ptr.

This is just an advice, it really depends on what you need to do.

Tom

[Todd R. Jacobs]

All,

Yes, that works, and I now have a better understanding of how it works
thanks too everyone's helpful advice

Thanks again,
Todd

"Tamas Demjen" <td*****@yahoo.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

Todd R. Jacobs wrote:

>Changing the function definition
From:
static bool AdjTime(TimeSpan *tsLogSpan);
To:
static bool AdjTime(interior_ptr<TimeSpantsLogSpan);

Allowed the use of the native pointer &tsSpan parameter.

Is this what you were inferring?

It looks like interior_ptr<TimeSpanwould work, too. However, Carl
recommended

static bool AdjTime(TimeSpan% tsLogSpan);

and

AdjTime(tsSpan); // instead of AdjTime(&tsSpan);

I believe this is what you are looking for -- you should just try it, and
unless you experience problems, that's the way to go.

X% is a reference, similar to X& in unmanaged code. The compiler has more
room for optimization when it comes to references, because it can simply
substitute your variable with its reference; it's not possible with
pointers. A reference is also safer than a pointer, since it must always
be initialized. A reference can't accidentally point to a random location,
or to NULL.

The advantage of interior_ptr is that you can use pointer arithmetics on
it, which as

while(*source) *dest++ = *source++;

This is not possible with references. It may also come handy that an
interior_ptr can point to nowhere, and you can also reassign it to
something else. A reference can't be reassigned to a different object.

However, it doesn't look like you need these feature. If you don't need
pointer reassignment or pointer arithmetics, you should stick with the
reference syntax.

I believe that interior_ptr is considered unsafe, and can't be used with
verifiable assemblies (in other words, places where strong security is
required, such as inside a Web browser). You should really not restrict
your function unnecessarily. Unless you have a good reason to use
interior_ptr (such as very fast image processing algorithms), you should
stick with references.

Rule of thumb: If you can solve a problem with references, do it so,
otherwise use interior_ptr.

This is just an advice, it really depends on what you need to do.

Tom