A static library cannot use another static library. What exactly do you mean? Honestly VS is perfectly fine, it's, as almost always, the users... :laugh:

Ehm, that is simply not true. Unless you are targeting expertimental features from C++23 or similar there is very little left to complain about. What specifically are you missing?

I can't confirm that. Cross platform development work flawlessly once you start to use CMake amd vcpckg properly and work with generated solutions in Visual Studio. I write, test, debug and profile inside Visual Studio and run testsuites and benchmarks on other platforms in Docker. No problems at all. Everything is a breeze compared to other development platforms - which are close to masochism vim based editing.

I actually used it all the time. It was fast and didn't eat up the battery on my laptop like crazy.

40 yo manufacturing system...? I mean are you sure about the age, isn't it rather 25 yo? Then, you're a colleague of mine and they apparently assigned this task to two of us. No, seriously: take care of an architecture that allows you to plug in arbitrary data-backend and UI front end.

Sorry, but there was a bit of irony in my comment... C++ has no built in support for "plugins" of whatever kind. It's textual compilation model is pretty much the opposite of .Net component based model. Therefore my comment, if you don't mind...

This is the most exotic opinion I have heard lately...[]

That, sir, is really cool :cool: Also your Lego metaphor is completely right and puts everything to the point: building blocks of software that match each other like Lego blocks is of course always possible, but there are platforms which make things easy and others make things hard... Cheers, Paul

Well, yeah, XNA is a Microsoft specific technology which might change or go away. But this is a common problem with any vendor bound framework, so you always making a kind of bet. This is however still not a reason which would make me move away from the managed world. You will agree that a well-designed application can move dependencies on specific technologies to distinguished layers which can be replaced by some other implementation if a technology is not appropriate any more. In case of XNA I'd even give the various clones and ports a chance. I assume you know that software written for .Net is not bound to be executed on Microsoft's platforms... But that's not the point. I didn't tell that native C++ is "scary" (but it's not a bad attribute at all), it is just uhmm.. awkward to get certain things done. It's mainly because of the lack of (good and out-of-the-box available) high level libraries, but also due to limitations of deployment and compatibility models of C++. With C++11 you got another dimension of incompatibility between the various implementations and another one for the complexity. Things got quite better lately, with Boost growing strongly and getting integrated into standard fast, good libraries are being thrown to the public by Microsoft, Facebook and others, but still: for many kind of problems, doing certain things (e.g. those you have described in your post) remains awkward. Cheers, Paul P.S. I have to add that in my job I am a native C++ developer and have been for a very long time... I got so frustrated by certain awkward trivialities that I started to rewrite and publish the vex library which I am using to circumvent some really "vexing" parts of common developer's life...

Have a look at boost::optional, these things tend to be tricky in today's C++. I've a question to the thread author: You've apparently decided to rewrite a working piece of software, to "move away from Microsoft", if I may paraphrase... It appears to be more like "moving from managed to native", but why? This kind of thing is where the managed world offers you a fast, efficient and safe way to get your job done. Trying to rewrite this in native "bare metal" C++ is awkward, error prone and lengthy...

I reply to your message, although the answer applies to all comments. No, you can't. "C++" and ".NET Framework" are just not compatible terms to compare, therefore you can't "switch" from one to another. .NET Framework is an implementation of a specification which defines an Application Development Framework plus the humongous infrastructure which enables to run the framework itself plus applications written against it. C++ is a language specification consisting of 1250 pages of text (*) at least my copy does. Its up to vendors to implement this specification but here the parallels are over. I'd understand if somebody wrote "I am switching from .NET to Java" (which happens to be both language and AVR), or, to certain extent, "I am switching to native C++ development based on Qt". But in these cases, you are putting yourself in the similar position as before - you get dependent on somebody (**). Of course, you can write software based solely on C++ specification, but this is not really comparable to application development based on a infrastructure of the .NET Framework kind, not even comparable to writing software against an native C++ application development framework like Qt etc. (*) ...written by masochists (**) The "open source" arguments also apply to .NET specification for which an oss implementation exists

You may or may not like C++. But you can't just "turn away from .NET to C++". This is like you said "I am turning away from gasoline, since I do not want to depend on all of that oil stuff...". C++ is just a language, .NET is a eco-system of many languages, infrastructure, libraries, tools etc. If you rely on that, the language itself does not matter, but the presence of this infrastructure does.

Difficult to say from what you have shown. You can pin a handle to a managed object only temporarily, since a pin_ptr can only be created on the stack. Therefore, if you have something like this:

IntPtr YourClass::GetFuncPointer()
{
FuncDelegate^ fp = gcnew MessageFuncDelegate(this, &Handler);
pin_ptr pinnedFunctionPointer = &fp;
return ((ProcMessageFunc)pinnedFunctionPointer);
}

then you effectively have only pinned fp for the duration of this method call. A correct way to do this depends on your scenario. I'd recommend something along the lines of the following (I didn't compile it, but you get the idea):

public ref class ClientRegistrar abstract sealed {
static FuncDelegate^ s_ManagedReceiverList;

// ...
public static void RegisterClient(YourClient^ p\_Client)
{
    // thread safety for free
    s\_ManagedReceiverList += 
        gcnew MessageFuncDelegate(p\_Client, &YourClient::Handler);

    // here I assume that ::Receiver is an unmanaged global function which
    // takes a funtion pointer of type ProcMessageFunc. Don't know
    // if you need to deal with multiple registrations....
    ::Receiever((ProcMessageFunc)Marshal::GetFunctionPointerForDelegate(s\_ManagedReceiver));
}

public static void UnregisterClient(YourClient^ p\_Client)
{
    s\_ManagedReceiverList -=
        gcnew  MessageFuncDelegate(p\_Client, &YourClient::Handler);
    // use the same schema to unregister from the native receiver
}

}

Usage (C#):

YourClient tClient = new YourClient();
// ...
ClientRegistrar.RegisterClient(tClient);
// ...

s_ManagedReceiverList and any YourClient instance you register via RegisterClient will be kept alive as long as the current application domain will exist. Implement UnregisterClient if you need more fine grained control. A delegate does not need to be pinned, the CLR takes care of proper handling of that. It just needs to be kept alive. Cheers, Paul

What do you mean by "it does not work"?... The code as written just does not compile for a simple reason: Your second call to PrintBy does not match the signature of the called function. You either declare a second overload for PrintBy taking a proper pointer-to-method of Printer or (much better) you rely on standard library abilities:

#include #include template < typename TPrinter >
void PrintBy( std::string const & pString, TPrinter pPrinter )
{
pPrinter(pString);
}

// Your stuff ...

int main()
{
::PrintBy( "hi", Print );

::Printer p;

::PrintBy( "hi again", std::bind( &::Printer::Print, &p, std::placeholders::\_1 ) );

}

What exactly is meant by "WinC++"? I'd be interested into the background of this recommendation... In my (humble) opinion, the further away you get from Win32 APIs (assuming this is what you meant) the better off you might be in the future. Or did you mean the plain ANSI C++ as implemented by Microsoft?

This question can only be answered by looking at a specific OS. In general the OS starts the respective runtime which in turn calls into main after doing some initialization work. If you want to know the exact call stack for YOUR system, just hold on in the properly configured debugger at some point of the program and trace back to the roots... Use breakpoints on visible global objects with non-trivial constructors to see what's happening before the program enters main. At least on Windows you will be able to trace back the runtime-code as well. Cheers, Paul

Hm, not sure to whom this may concern, I always get confused by these hierarchies of threads... Anyway, the concept of a C++ reference is a subtle thing and it got even subtler with c++0x, as you might know. For good reasons this concept wasn't considered is what C# and other CLR targeting languages - and now we're back at OP's problem (at least as I see it...): in case of reference types (and in a verifiable program), you always deal with handles ("pointers") to instances. These handles can have two states: (a) pointing to valid object, (b) or "null". You can take a value of a "handle" by reference, by stating this intent explicitely at both call and target sites. However, this does not change the semantics of a handle, you just get access to the location of whatever the handle represents. So in C#, if you want to protect against handle pointing to "null", you either have to be explicit about that (code contracts are a great way to do that), or you rely on NullArgumentException handling (which is guaranteed to be thrown by the specs). The ref modifier mentioned somewhere in the thread does not help much:

void Bar(MyClass pParam) {
pParam.Member(); // guaranteed NullArgument exception if null
}

void Bar(ref MyClass pParam) {
pParam.Member(); // guaranteed NullArgument exception if null
pParam = new MyClass();
}

void Foo() {
MyClass tI1;
MyClass tI2 = null;
MyClass tI3 = new MyClass();

Bar(ref tI1); // error, tI1 uninitialized
Bar(ref tI2); // ok
Bar(ref tI3); // ok

Bar(tI1); // warning or error, not sure
Bar(tI2); // NullArgumentEx...
Bar(tI3); // ok

}

What you describe is Microsoft (implementation) specific version of "undefined behavior". The code in Foo is ill-formed and any assumptions about what happens after you took a reference to a "null" pointer are worthless...(the lang. spec. does not require an exception to be thrown.)

bob16972 wrote:

If the caller violates the standard definition of a reference, there is nothing I can do about it. I'm not even sure there is a way to check the reference for validity since the result of the action you described would be undefined (or at least, so it seems).

Exactly, with no need to further qualify the statement as you did in the second sentence. And no, there is no way to check a reference for validity, since it must be valid by definition. Otherwise, the caller has violated (a) the language specification of a valid C++ program and (b) the contract you have specified by defining the method signature that way... That's what I wrote in my post above (which was down-voted for some reason).

bob16972 wrote:

Someone please tell me there is a way to eliminate all these checks for null references in C# like I could in C++.

Hm, there is nothing like "null reference" in a C++ program. This would require dereferencing a null-pointer which immediately results in undefined behaviour of the rest of the program. If you pass an object by reference in C++, you implicitly state that this object cannot be a reference to null object by definition. In managed code you can use explicit code contracts. CCs allow you to make explicit assumptions about pre-, post- or state-conditions which are verifiable at compile- and run-time. You formulate contracts at metadata level so they get injected into IL in AOP manner:

[ContractClass(typeof(ISomethingContract))]
public interface ISomething {
public void DoSomething(AnotherClass pObject);
}

[ContractClassFor(typeof(ISomething))]
internal abstract class SomethingContract : ISomething {
public void DoSomething(AnotherClass pObject) {
Contract.Requires(pObject != null);
}
}
}