afxstr and atlstr CString ambiguity

This is a discussion on afxstr and atlstr CString ambiguity within the Windows Programming forums, part of the Platform Specific Boards category; 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 ...

  1. #1
    Registered User
    Join Date
    Dec 2007
    Posts
    19

    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

  2. #2
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,428
    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 Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,590
    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.
    Last edited by VirtualAce; 12-16-2007 at 10:20 AM.

  4. #4
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,428
    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.
    Last edited by Elysia; 12-16-2007 at 10:18 AM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,856
    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.
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

  6. #6
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,428
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #7
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,856
    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).
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

  8. #8
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,428
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21