Question concerning .NET 2003 and Namespaces

[Sean Quinn]

Recently I've come across an oddity in .NET, going back to a Managed
C++ implementation for GUIs since I never really learned how to code in
MFC.

Any way, I attempted to put some standard code I often re-use (like my
own random function) in its own namespace, lets call this namespace
"PersonalStd", and noticed that when I tried to reference the function
`random()' in the PersonalStd namespace from the project namespace it
was giving me a LNK2001 error despite everything being included in the
project.

It works fine with namespaces when compiled in unmanaged C++ compilers,
like MSVC6, unfortunately I haven't had a chance to test it on Linux
compilers, but I'm pretty certain it would work fine on those as well.

I think its a conflict with how managed C++ in .NET deals with
additional namespaces, because because when I took the PersonalStd
namespace out of the code, everything worked fine. I'm just wondering
if anyone else has run into this, or if anyone has insight or
suggestions into this?

Oh and as a side note; if anyone knows some really good MFC resources,
tutorials, or books, please let me know -- its sort of been something
that has been eluding me for a few years now that I just never really
tried to learn, but I feel like I should.

An example of what the code looked like with the namespaces is here:

--- PersonalStd.h

#pragma once
#ifndef PERSONAL_STANDARD
#define PERSONAL_STANDARD 1

namespace PersonalStd
{
int random(int, int);
}

#endif


--- PersonalStd.cpp

#include <algorithms>
#include <cmath>
#include "PersonalStd.h"

int random(int l, int h)
{
....
}


--- MainCode.h (where all the functions are in managed C++)

....

System::Void SomeFunction(...)
{
txtBox1->Text = PersonalStd::random(1,10);
}

 

[Victor Bazarov]

Recently I've come across an oddity in .NET, going back to a Managed
C++ implementation for GUIs since I never really learned how to code in
MFC.

This newsgroup has no dealings with .NET, Managed C++, or MFC. Just to
let you know...

Any way, I attempted to put some standard code I often re-use (like my
own random function) in its own namespace, lets call this namespace
"PersonalStd", and noticed that when I tried to reference the function
`random()' in the PersonalStd namespace from the project namespace it
was giving me a LNK2001 error despite everything being included in the
project.

Of course. You didn't define that function. See below.

It works fine with namespaces when compiled in unmanaged C++ compilers,

It does? I just tried to build this code:
------------------
namespace A {
int foo();
}

int foo() { return 42; }

int main() {
return A::foo();
}
-------------------
and A::foo was reported as unresolved external, as I expected.

like MSVC6,

MSVC6 is notoriously bad in many aspects. Upgrade your compiler.

> unfortunately I haven't had a chance to test it on Linux
compilers, but I'm pretty certain it would work fine on those as well.

I think its a conflict with how managed C++ in .NET deals with
additional namespaces [...]

If you need suggestions on "managed C++" or ".NET", you should consider
asking in a newsgroup whose name begins with "microsoft.public.".

Oh and as a side note; if anyone knows some really good MFC resources,
[...]

Somebody in an MFC newsgroup should be able to help you with that.

An example of what the code looked like with the namespaces is here:

--- PersonalStd.h

#pragma once
#ifndef PERSONAL_STANDARD
#define PERSONAL_STANDARD 1

namespace PersonalStd
{
int random(int, int);
}

#endif


--- PersonalStd.cpp

#include <algorithms>
#include <cmath>
#include "PersonalStd.h"

int random(int l, int h)

This declaration is not for the function in the namespace. It's for its
own function in the global namespace (AFA C++ is concerned). And that
means that 'PersonalStd::random' function has no definition, which is
against the ODR.

{
...
}

Surround this declaration/definition with the namespace and you will rid
yourself of the error, I believe.

--- MainCode.h (where all the functions are in managed C++)

...

System::Void SomeFunction(...)
{
txtBox1->Text = PersonalStd::random(1,10);
}

V

 

[Sean Quinn]

This newsgroup has no dealings with .NET, Managed C++, or MFC. Just to
let you know...

Thanks, for future questions I have on Managed, or MFC I will check
there, I appreciate your answers though, regardless!

Surround this declaration/definition with the namespace and you will rid
yourself of the error, I believe.

You're absolutely right, I don't know why I didn't catch that (I think
I've just been exhausted), thank you for pointing that out to me, its
so embarassing when one makes a mistake like that!

Thank you again!

 

[Ben Pope]

It works fine with namespaces when compiled in unmanaged C++ compilers,
like MSVC6, unfortunately I haven't had a chance to test it on Linux
compilers, but I'm pretty certain it would work fine on those as well.

VC .NET 2003 compiler can quite happily do unmanaged C++.

I suspect that your code is not compliant to the C++ standard, and that MSVC6 just didn't catch that (since it's not very compliant).

Oh and as a side note; if anyone knows some really good MFC resources,
tutorials, or books, please let me know -- its sort of been something
that has been eluding me for a few years now that I just never really
tried to learn, but I feel like I should.

Why don't you use the new fangled .NET GUI API rather than MFC?

Ben

 

[Sean Quinn]

VC .NET 2003 compiler can quite happily do unmanaged C++.

I suspect that your code is not compliant to the C++ standard, and that MSVC6 just didn't catch that (since it's not very compliant).

Yeah I know it can (I've done it before a while back, maybe 4 or 6
months ago, just haven't touched .NET recently and for some reason
became stupid in that time frame I think), but the real problem was
that I was giving hypothetical example code thus running into the same
problem that I was running into with the actual code I was writing.
Essentially forgetting to declare the namespace scope before the
function name, for some reason I was thinking "using namespace X" was
enough to define the scope, when in previous projects of mine, I knew
it wasn't. It was just a stupid moment. heh.

Why don't you use the new fangled .NET GUI API rather than MFC?

Its not that I don't want to use the .NET GUI (I love it actually, a
heck of a lot easier the MFC if I recall my struggles with MFC earlier
on correctly), but MFC has sort of been that elusive beast that I've
been trying to catch, and would like to at least become familiar with
it for that reason alone.