5

I'm wondering how Visual Studio, other IDE's, and any other sort of circumstances (ie. no IDE at all) handle bringing in code from outside.
At first I thought #includes were the only way to do this, by either placing the assembly files in the designated directory for Visual Studio assembly files and then using the <> format to bring them in, or by putting the assembly files in the project directory and using the "" format to bring them in (that is, <> and "" respectively). But now I come up to the example at the end of this post with the #using directive (which, to note, is different than just the 'using' directive without the '#', for namespaces). Also I've come across adding assembly references in visual studio from within the 'configuration properties' dialogue.
So, would someone set me straight on all the in's and out's of adding assembly files and other code to a given project?

--The following is the example that has confused me--> I have this section in my book that states:

"...The figure combines C++ 2008 code with legacy C and native C++ code. It also presents the two assembly reference files you'll use most often with C++ 2008, along with their associated namespaces. Unlike when you use Visual Studio to develop a project, the assembly reference files aren't included by default when you code a single source file. Because of that, you must code #using directives for these files. ..."

#include <stdio.h>
#include <iostream>
#using   <system.dll>
#using   <system.windows.forms.dll>

// Associated namespace directives

using namespace std;
using namespace System;
using namespace System::Windows::Forms;

void main()
{
    printf(            "Hello, Earth\n");  // from stdio.h
    cout <<            "Hello, Mars\n";    // from iostream
    Console::WriteLine("Hello, Jupiter");  // from system.dll
    MessageBox::Show  ("Hello, Saturn");   // from system.windows.forms.dll
}
jww
  • 97,681
  • 90
  • 411
  • 885
Evan Sevy
  • 659
  • 1
  • 13
  • 25
  • What the f**k is C++ 2008 ? This is C++/CLI, period. Whatever this book is (perhaps one other of those crappy "Visual C++ 2008" or whatever), you shouldn't read it. Learn standard C++, or learn C#. C++/CLI's only sensible use case is when you want to expose standard C++ code to .NET. – Alexandre C. May 23 '11 at 18:49
  • I'D BE INTERESTED IN THE OPINIONS OF OTHER DEVELOPERS ON THIS POINT-- WHETHER C++/CLI IS WORTHWHILE? (lol, first time I've found a use for 'yelling characters') – Evan Sevy May 23 '11 at 19:03
  • 1
    C++/CLI is a great tool for doing interop between C++ and the .NET world. You may have many reasons for doing this, particularly leveraging a legacy C++ codebase with .NET, or sometimes, when C++ is the best tool available for a particular task, but the finished product must use .NET. However, I am sincerely convinced that C++/CLI is not a good production language. There is far more support and momentum towards C#, either from Microsoft or from the community. – Alexandre C. May 23 '11 at 19:38
  • This is a great question. It answered a simpler question that was incredibly tough for me today. This was the 5th article I found. How can I include `System` in a C++/CLI source module. (The compiler was telling me that using does not work with System or something) I could have looked back at the program I wrote, but I didn't want to cheat on something I always have trouble remembering. – ebyrob Oct 09 '18 at 15:36

1 Answers1

6

This is not native C++ (usually just referred to as C++), but C++/CLI, which is actually a .NET language designed to ease interacting between native and managed code, and as such can use both. It is, however, definitely not C++, despite an intentionally strong resemblance. Assemblies are .NET managed code repositories. You use the #using command to use them. #include is for native C++ headers. You should also be able to add managed references (that is, #using but done throughout for you) from the project's properties.

In native C++, then you must #include headers, and if appropriate, link to .lib files (or use GetProcAddress manually), and Visual Studio also offers #import for COM libraries. C++/CLI also offers #using for bringing in managed assemblies.

void main()
{
    printf(            "Hello, Earth\n");  // C native code
    cout <<            "Hello, Mars\n";    // C++/CLI's wrapper on C++ Standard
    Console::WriteLine("Hello, Jupiter");  // .NET managed code
    MessageBox::Show  ("Hello, Saturn");   // A thin wrapper on WinAPI
}

If you don't already know both C++ and .NET code, and/or you're not trying to link the two together, it's not recommended to use C++/CLI.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • Ok, so; 1) #using is only for C++/CLI (.NET) assemblies. 2) #include is only for header files. 3) Adding references from the projects properties is the same as #using, only its implemented in the background. – Evan Sevy May 23 '11 at 18:07
  • 2 Quick questions: Are .dll files only for .NET? -- this StackOverflow post says nothing of it being .NET only: http://stackoverflow.com/questions/913691/dll-and-lib-files-what-and-why . And just to make sure, dll's are assembly files, right? – Evan Sevy May 23 '11 at 18:18
  • @Gjera: `.dll` is a run-time library. Some are .NET assemblies, some are native code. – Puppy May 23 '11 at 18:46