nullptr for VS2005 but what about VS2003?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi guys,
I'm using delegates to execute a group of methods using the BeginInvoke,
that works fine; I'm waiting for the asynch thread to return the response
using the EndInvoke, that works fine also. The point is, I didn't find the
way to pass a null value to the BeginInvoke method for the AsyncCallback and
object argument. I don't want to have unused code on my source code, but I
didn't find the way to avoid it.
Any thoughts?

return dDecrypt->EndInvoke(dDecrypt->BeginInvoke(Data,new
System::AsyncCallback(this,DelegateCallback),dDecrypt));
 
Charlie said:
Hi guys,
I'm using delegates to execute a group of methods using the BeginInvoke,
that works fine; I'm waiting for the asynch thread to return the response
using the EndInvoke, that works fine also. The point is, I didn't find
the
way to pass a null value to the BeginInvoke method for the AsyncCallback
and
object argument. I don't want to have unused code on my source code, but
I
didn't find the way to avoid it.
Any thoughts?

return dDecrypt->EndInvoke(dDecrypt->BeginInvoke(Data,new
System::AsyncCallback(this,DelegateCallback),dDecrypt));
Click to expand...

Well, to answer the question you asked in the subject line but left out of
the body, don't use Managed Extensions for C++. Not ever. It's buggy and
Microsoft will not be fixing it.

If you're just calling EndInvoke immediately, why are you using an
asynchronous call at all? It's just adding more overhead due to thread
synchronization and context switching.

Managed Extensions for C++ probably would have used "NULL" though, if it
wasn't too buggy to do anything reliably.
 
If you're just calling EndInvoke immediately, why are you using an
asynchronous call at all? It's just adding more overhead due to thread
synchronization and context switching.
Click to expand...

Good point, but the reason is that I need to execute the logic on a
different thread, since I'm consuming the C++ .Net Object from a complex ERP
(JDEdwards) thread and this particular thread has particular specifications
that force me to use a different thread to execute my logic.

Also, I found that I can't (I mean, I can but I shouldn't) execute the
EndInvoke immediately as I pasted on my first post, I have to wait for the
async thread to be completed to (them) call the EndInvoke.

//BeginInvoke()
while(!ar->IsCompleted)
{ar->AsyncWaitHandle->WaitOne(1, false);}
//EndInvoke()

For now my BeginInvoke Callback method is just a declaration (no code
inside)... but I just want to have a clean source code.

--
Carlos Redondo
..Net Developer


Ben Voigt said:
Charlie said:
Hi guys,
I'm using delegates to execute a group of methods using the BeginInvoke,
that works fine; I'm waiting for the asynch thread to return the response
using the EndInvoke, that works fine also. The point is, I didn't find
the
way to pass a null value to the BeginInvoke method for the AsyncCallback
and
object argument. I don't want to have unused code on my source code, but
I
didn't find the way to avoid it.
Any thoughts?

return dDecrypt->EndInvoke(dDecrypt->BeginInvoke(Data,new
System::AsyncCallback(this,DelegateCallback),dDecrypt));
Click to expand...

Well, to answer the question you asked in the subject line but left out of
the body, don't use Managed Extensions for C++. Not ever. It's buggy and
Microsoft will not be fixing it.

If you're just calling EndInvoke immediately, why are you using an
asynchronous call at all? It's just adding more overhead due to thread
synchronization and context switching.

Managed Extensions for C++ probably would have used "NULL" though, if it
wasn't too buggy to do anything reliably.
Click to expand...
 
Back
Top