error C3867: function call missing argument list; for a cli thread calling function

Hi all,

I searched the web for error: c3867 and most discussion were murky or obscure.
My code excerpt is:

#pragma once
#include <stdlib.h>
#include <process.h>

void PutUpfrmIO(void *);

namespace WordParsor {
using namespace System;
public ref class Form1 : public System::Windows::Forms::Form
{
// Blah Blah Blah….

System::Void Test_Click(System::Object^ sender, System::EventArgs^ e)
{
_beginthread( PutUpfrmIO, 0, NULL );
// Blah Blah Blah….
}

void PutUpfrmIO(void *param)
{
// Blah Blah Blah….
}
};
}

I get the generic error message:

error C3867: 'WordParsor::Form1::PutUpfrmIO': function call missing argument list; use '&WordParsor::Form1::PutUpfrmIO' to create a pointer to member; and the suggested fix just causes a new error.

One person suggested using the gcroot<> class, but I do not know how to declare the function or its arguments.

I do not know if it matters, but the calling function thread is within the parent class.

If you can specify a simple illustration, I would greatly appreciate that.

King

Well, your primary misconception may actually not have been that CodeGuru has a C++/CLI section (as mentioned over there in the VC++ section), but rather missing that you're writing a C++/CLI program in the first place.

It's generally not recommended to use native library routines (here: _beginthread()) in a managed environment without a real need to do so, but can become particularly problematic if multithreading is involved. For multithreading the real .NET way, have a look at the System::Threading namespace.

Thanks Eri523, I will look at the System::Threading namespace... and the usage of native code only.

A long time ago, I programmed in C++, but more recently I programmed in ASP.NET/C#.

I like C# and .NET, however, most well established numerical and graphics libraries are in C++. I also own such libraies.
So, I thought: C++/CLI was a good compromising environment for general development.

But I'm learning as you stated: without a real need to do so, mixes enviroments can become particularly problematic if multithreading is involved.
This is specially true since C++/CLI lacks demostrational code illustrating language syntax and usage.

With a C# background you're probably rather familiar with the .NET framework already, making that even more attractive here.

You're right, C++/CLI is the preferable language when it comes to integrating native libraries into .NET apps (and the other way 'round, but that's far less common) but the "contact surface" between the two worlds should preferably kept small, minimizing the frequency of rather expensive managed/native transitions.

There are quite some threads around here discussing library wrappers used in this kind of integration scenarios, which may at least give you some first impression of what that's about.

Thanks Eri523,

I recall working with managed threads but it requires defining a working thread class. But the simplicity of calling an asynchronous function in native code is attractive. So, if you can suggest some good key phases for searching, per wrapper integration scenarios, I wound be greatly appreciative.

King

I'm not really sure what you're referring to. :ehh: Of course there's no need to create an extra class for the sole purpose of providing a thread worker function. You just need to create a delegate of type ThreadStart or ParameterizedThreadStart that you pass to the Thread constructor. Then you call Start() on the thread object. And one of the IMO nice things about that is, that it's just a minor syntactic difference whether the delegate refers to a static or instance member function, which is quite convenient compared to "conventional" multithreading.

Sorry, poor chioce of words.

Specify, I has thinking of the "BackgroundWorker" thread Object and the "assigning of events delegates" to it.
And I notices with the native scenario... only a header file was necessary. Worker thread objects are probably the coventional approach.


However, you're right, I can simply create a thread object and then call the Start method.
Or use the Disspathcher Method: buttionObj.Dispathcher.Begin(DispacherPriority.Normal, afunction);

In your reply, I thought you were referring to manage and unmanaded wrapper integration scenarios.
But a second look a the Threading Class... It's really simple too!

Thanks for your help -- and it's greatly appreciated.

King

Ok, the BackgroundWorker class is nicely convenient when used as a form class member since it can be added and set up using Forms Designer, and automatically marshals its event invocations back to the GUI thread, so their handlers can directly manipulate GUI elements. However, the price for that convenience is a certain design rigidity, which, in a context not directly related to a form instance, can be rather counter-productive.

As you mention the Button::Dispatcher property, are you writing a WPF app? In case you don't, System::Windows::Forms::Control fearures similar methods, just a bit less flexible. Note, however, that they are not for starting worker threads, but rather for marshalling calls from a worker thread back to the GUI thread (unlike the methods with the same names provided by delegates, which are for invoking a method on a thread pool worker thread, and, depending on the scenario, can be much more convenient than a Thread object). And I'd bet that BackgroundWorker uses these very methods for its marshalling.

And, well, although it may look like that to some developrs, not everything in C++/CLI is about managed/native interop. :)

Thanks,

You gave me good insight it my erroneous thinking. I'm in the process of rediscovering C++. Although, CLI expand C++ to the .NET world... the best practice is not to unnecessary (or blindly) mix the two heap references on the function stack. Ideally, you should only mix the two moderns within a class or function for interop interface purposes. C++/CLI offer a lot , but “‘contact surface’ between the two worlds should preferably kept small”, not willy nilly. Care is needed in a mixed environment.

Your conclusions are fundamentally correct, but let me add some words of clarification: Avoiding an unnecessary mix of managed and native code is not restricted to heap models, not even to storage models in general. Imagine you get hands on a fantastic native library that allows you to add two ordinary 32-bit integers much faster than your .NET code could. (That's really fantastic, since it's technically impossible. And in fact that's why I chose this example.) That wouldn't require any non-local native object to be instantiated at all. Integrating that library into your .NET code is quite useless, though, since already the overhead of the interop call would take longer than the .NET code doing the addition on its own. The central lecture here is that interop is rather expensive (not only at runtime but also at development time) and should only be used if the reward is really cool.

The only real reason to use introp is to integrate a library from "the other world" (in both directions) that can do things that otherwise would require much more effort or wouldn't be possible at all. However, it may be needed to interpret the term "library" in a somewhat broader sense here. In particular it may include, for instance, the Win32 API, as can be seen in http://forums.codeguru.com/showthrea...pture-a-window

Yes, as long as you are processing local variables (not a heap referenced objects) or not using preexisting code… interop migation offers no advantageous. Currently, I’m experimenting with two large native libraries (Numerical Recipes in C++ and Opengl/C++) and I thought: I would use the .NET libraries in place of MFC… in order to obtain a GUI interface. These two libraries normally assume a win32 console app environment and I want to improve on aesthetics. I’m struggling with: relearning MFC (a native code GUI, but also, VS2010 MFC code wizard has great template setups) verse .NET interop concerns?

So, I’m wandering: is it best to place emphasis on MFC or .NET for future C++ development? Is the .NET platform still Microsoft developmental future?

If these two native libraries are the central aspect of your upcoming app, using MFC to build the app around them would be the natural and IMO preferable choice if MFC is available, i.e. you're not using the Express Edition of VC++. Relearning MFC may well be considerably less effort than acquiring decent knowledge of all that interop stuff.

OTOH, if your numeric library (think I've already heard the name but don't know any details) is of the numbercrunching kind, i.e. you give it large data sets on which it performs some extensive work and returns the results to you many, many CPU clock ticks later, it may be a pretty good candidate for interop integration, since you'd probably just require a low frequency of managed/native transitions and the library wouldn't directly interact with the GUI at all. The data structures used to interact with a library of this sort may require some degree of custom marshaling, though, increasing the integration effort.

I was surprised I didn't find any OpenGL API implentation for .NET, but, admittedly, my search for it wasn't really intense. I'm rather sure I've seen an interop-based OpenGL/.NET integration sample on http://www.codeproject.com sometime, but don't have a concrete link at hand.

The fundamental question you should ask yourself is: What are your important reasons to use .NET for that app?

C++/CLI has never been a mainstream .NET language and probably will never be. The mainstream .NET language is C#. I just happen to be decently fluid in both native C++ and C++/CLI (my MFC is a bit rusty, though), so I can easily use C++/CLI as a general purpose language in app development. Yet this use is quite uncommon considering the overall .NET development scene. So I don't think it's not really the question whether .NET is the future of C++ development. I consider it highly unlikely that MS will abandon Win32 on midterm (though that may mutate into some sort of "Win64"), so it's still on the list, along with MFC. And, as being a standard language on a vast lot of platforms, MS certainly won't give up C++ as a Windows language. And then there's WinRT which was introduced with Windows 8. Admittedly my knowledge about that is quite sparse. AFAIK it's used with native C++, so maybe it can be the base of some sort of "MFC - the next generation". I'm not quite sure whether it may only be usd for these "modern style" Windows 8 apps.