afxstr and atlstr CString ambiguity

Compiling gets me with multiple

Code:

---

c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\include\afxwin.h(4722) :
error C2872: 'CString' : ambiguous symbol
        could be 'c:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\atlmfc\include\afxstr.h(97) : ATL::CStringT<BaseType,StringTraits> CString'
        with
        [
            BaseType=char,
            StringTraits=StrTraitMFC_DLL<char>
        ]
        or      'c:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\atlmfc\include\atlstr.h(975) : ATL::CString'

---

The problem is, that i am referencing an MFC-based library, but my application is a console-based application. The MFC-based lib has methods, which use CString, defined in afxstr.h, but i used CString defined in atlstr.h. Is there a way to face this problem? One solution is to do my application MFC-based, but i prefer to try something else first.


Thnx

Typically, if you use an MFC library, it's best to use MFC in your app too.
You can't use CString if you don't use MFC. So what's going on here?
Also include the same header or include MFC's main headers.

Quote:

---

You can't use CString if you don't use MFC. So what's going on here?

---

You can use CString and other MFC utlility functions without ever linking with the rest of MFC. If you are using MFC via shared DLLs you should have no problems. I have a book right here that has a chapter called Using MFC Utility Classes in Console Applications.

The utility classes are:

- CString
- CPoint
- CRect
- CSize
- CTime
- CTimeSpan

Project settings:
- Type: Win32 Console project
- Empty project (not MFC project)
- Settings: Check use MFC in a shared DLL (tells linker NOT to add all of MFC)
- Include: <afxwin.h>

Now when you use a portion of MFC that is not already linked in, it will link it in. So you can pick and choose which portions of MFC you want to use and those will be linked in for you.

News to me.
Though perhaps it's possible to wrap a header inside a namespace.
Such as

Code:

---

namespace MyMFC
{
        #include "MyMfcHeader.h"
}

---

IF it works, it could resolve ambiguity.

Code:

---

namespace TestSpace
{
        #include "Test.h"
}
using namespace std;

void Help()
{
        TestSpace::TestFnc2(0);
}

---

Test.h:

Code:

---

template<typename T> void TestFnc1(T p)
{
}

template<typename T> void TestFnc2(T p2)
{
        TestFnc1(p2);
}

---

It compiles fine, so... you could always try.
Unless it does ::SomeFnc, which I'm told MFC does.

Just include AFX.h

In MSVC 2003, right click on the project (in the class explorer window) and select 'Properties'.

In 'General' TAB make sure 'Use of MFC' is a 'static library' so you do not have to install/ship the MFC dlls with your app.

And that will bloat the app significantly.
No. Better to use use it in shared library. Runtime only has to be installed once, anyway. And with 2003, you can just copy all the files to win32\system32 and be done with it forevermore.

What exactly is the issue if your app is 25Kb or 250Kb?
(sure there are some reasons, but MFC is not the tool to use for those type of apps)

With broadband and massive amounts of memory (HD and RAM), the size of an exe is more about programmer pride than any real reason to create small exes.

I prefer to ship one exe file rather than an exe and multiple dlls (all to diff folders). Is much easier in secure/restricted systems.

Better than finding your app will not run on a VISTA, NT or 9x system because it is missing dlls (or crashes due to an incompatible version of the dll).

Well, I disagree. I hate bloat and I hate the usual do a static library just because you want to avoid the whole runtime problem.
Just in case, so say that each app will increase 10x -> 250 - 25 = 225 KB. So for each app, let's just say so ship 10 apps -> 225 * 10 = 2250 KB. Increase that figure that 100: 225 -> 100 = 22500. 22 MB. Whew.
See, that IS an incredible waste of space.
And let's be fair - not everyone has broadband; in USA people are stuck on 56K and even 26K!

Ship the libraries once, smack them into the win32\system32 dir and you never have to worry about it anymore.
And it's also very, very simple to write an installation to check if it's installed and install it if it isn't.