Visual C++/CLI : .h vs .cpp file & more

Question

5.00/5 (1 vote)

See more:

Hi all,

I have programmed in native C++ and visual C#, but this is the first time I have tried Visual C++. I have read several articles describing C++/CLI and how it has grown from managed C++. Excited, I decided to try to write my own practice application. (Actually, my own class library in C++/CLI which I will use from a separate C# application.)

However, I have quickly become stuck on a few really basic things and I was hoping someone could help me out. (I'm more experienced than I am about to sound LOL) Here's my questions:

1. When I created the class library (VS2010, File->New Project-> Other languages->Visual C++->CLR->Class Library), I noticed a MyLibrary.h file and a MyLibrary.cpp file. Looking inside the MyLibrary.cpp file, all that was there is:

C++

// This is the main DLL file.

#include "stdafx.h"

#include "MLibrary.h"

That seems awfully basic. If I then go into the class view, right-click the class and add function, I notice it gets added to the .h file. So, what is the point of the .cpp file and how to use it? I obviously get why a .cpp file is important in native C++, but not so much for C++/CLI. For instance, I can't add a function prototype to the .H file and implement it in the .cpp file - it will complain of a class type redefinition.

2. What I want is basically the following use case:
C# application calls C++/CLR class library.
CLR class library calls CoCreateInstance to receive a COM interface and use it.

How can I expose a function in the library that would do this, without it being in the .h file? (Why don't I want it to be in the .h file? Well, I'd like to keep the #include it is going to need out of the .h file. I'm also just accustomed to putting code in .cpp files)

3. Finally, why does it say:
IntelliSense: 'Unavailable for C++/CLI'
I mean, what the heck? Is this seriously true? This could be a dealbreaker as I like to hit control space like a junkie - it helps me know what variables & functions I have, and see others I might not have known about.

Basically, my original problem is I found out that C# cannot call a particular Windows method (due to permissions) but native C++ could. I didn't want to have to create a native C++ library because then all the dllexport functions would have to be static, and I would have to marshal data from managed to unmanaged code, and if I had a managed C++ (C++/CLI) code library instead, then all I would have to do is add a reference to it and all of the functions would immediately be exposed. I wouldn't have to add a bunch of PInvoke lines for each function. All in all, C++/CLI started to sound attractive but the above questions have me worried (esp. about the IntelliSense, for which I fear there is no solution).

Thanks for the insight and help!!

Posted 8-Mar-12 18:04pm

unpocoloco

Add a Solution

3 solutions

Solution 1

This is a bunch of mixed and convoluted problem. Perhaps you should not try to solve them at once. I cannot promise you to answer them all at once. I just want to give you one simple idea (also about not addressing all things at once): at first, try not to mix C++/CLI code with C++ which you are doing already. If you know C++ reasonable well, start with C++. Don't use COM and other legacy stuff (why, be the way?).

You should develop C++/CLI code pretty much the same way you do it with C#. For a fist step, perhaps forget about .h files. They are the artifact of C++, which I don't like, but unfortunately, you will really need it, but a bit later. To start and understand the basics, start with having all members of a "ref" class or a structure inline. Please understand, .NET referencing between assemblies do not use anything like H files, it uses meta-data, exactly as in C#. The .h files is the internal feature of C++/CLI used to link together different .cpp files if you reference one class in another. Use only "ref" C++/CLI classes.

You goal is to use C++/CLI assemblies in C# projects. This is done in exact same way as referencing C# assemblies in C# project. Only with C++/CLI the parameters of all public method should be references ('^' types) or primitive types. C++/CLI can use value semantic, but don't use this feature outside C++/CLI assembly, as C# or VB.NET (F#, etc.) project would not be able to use them anyway.

In future, when you decide to mix C++ with C++/CLI, try to segregate files in four distinct classes: 1) pure C++/CLI, 2) pure native C++, 3) C++/CLI types using C++ types internally; 4) C++ types using C++/CLI type internally. In real life, you will hardly need to use both (3) and (4) in the same project. Also, in those mixed-mode files, avoid implementing any other functionality except collaboration between C++ and C++/CLI.

—SA

Posted 8-Mar-12 18:21pm

Sergey Alexandrovich Kryukov

Updated 8-Mar-12 19:27pm

v2

Comments

Lakamraju Raghuram 9-Mar-12 0:36am

Perfect. +5.
I feel that in C++ there are good reasons why we need a separate .h file (as the compiler can't simply peek into another unit - so using #include provides a means) and as C++/CLI evolved from c++, they have naturally extended this concept to it even the managed part never needs .h files

Sergey Alexandrovich Kryukov 9-Mar-12 0:41am

Thank you, Lakamraju.

I always was amazed by this: how it's possible to have such a rudimentary technology as #include in XXI century? Even though all those C/C++/PHP people asks "how else", the answer is obvious: when C++ already flourished, we had a many much wiser systems based on meta-data: Ada, Turbo Pascal (and its descendants), Modula and a lot more.

--SA

Lakamraju Raghuram 9-Mar-12 1:02am

Now as a hardcore fan of C++, I won't crib much on this. The reason is I feel, I have the control of what needs to be packed/refered by my unit, rather than leaving it platform (CLR or JVM ..) and this ability to peek into the meta-data easily calls for securing the core logic by alternative ways. But I agree the missing elegance

Sergey Alexandrovich Kryukov 9-Mar-12 1:23am

It's not just the elegance this is performance. And it's possible only include-based languages that the compiler shows you an error in some .h file you never wrote. The order of include becomes important in certain cases (very usual), and putting source code in different directories is difficult or needs thorough planning. I here you, but to me the whole idea is just wrong.
--SA

Solution 2

This is a nice query - basic but a good one.

Please find some nice arguments regarding this at:

1. http://stackoverflow.com/questions/1305947/why-does-c-need-a-separate-header-file[^]

2. http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/e08ce967-b5d8-4457-93a9-f549d37b1807[^]

Posted 8-Mar-12 18:31pm

Lakamraju Raghuram

Comments

Lakamraju Raghuram 9-Mar-12 0:41am

And to summarize, the Managed languages will not bother about .h files of C++/CLI projects.

Sergey Alexandrovich Kryukov 9-Mar-12 1:29am

Yes, but in practice they are needed if you have many files working together. Unfortunately.
Useful discussions references anyway, my 5.
--SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

unpocoloco · Accepted Answer · 2012-03-08T20:07:00

I think I may not have been clear. I understand why .h files are necessary in C or regular C++, but that's usually for function prototypes and inline's only. In my C++/CLI project, it's like the .cpp file is the one who isn't necessary anymore (btw, I've always felt the need for prototypes is dumb - the compiler should be able to figure it out, as in Java (or C#)). I'm wondering what the use of the .cpp is for therefore (if you try to create a Windows Forms CLI application, it doesn't even HAVE a .cpp file! All code goes in the .h). Also, it's easy to verify that by including a reference to the C++\CLI assembly in the c# project, that you can call the C++\CLI methods. So I'm good with that. It's just that I find it strange they are in .h files. If the implementation is in the .h file, and a prototype's unnecessary, then what good is the .cpp file?

Also, and about the Intellisense?

I need to use COM because I'm calling a Windows API that uses it almost exclusively. I was thinking, the nice thing about C++\CLI is that from C# app I could call into a method of a class, vs a static function in native C++.