CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 23 of 23
  1. #16
    Join Date
    Jun 2015
    Posts
    208

    Re: CString class in non-MFC static library

    Quote Originally Posted by Arjay View Post
    I think if you are only targeting windows
    What do you mean by that?

    My advice is general. Always prefer standard C++.

  2. #17
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,490

    Re: CString class in non-MFC static library

    Quote Originally Posted by tiliavirga View Post
    What do you mean by that?

    My advice is general. Always prefer standard C++.
    What I mean if you are coding for Windows desktop applications (such as an MFC app) and never need to code for cross platform, then CString provides benefits over std::string or std::wstring.

  3. #18
    Join Date
    Feb 2003
    Location
    Iasi - Romania
    Posts
    8,234

    Re: CString class in non-MFC static library

    Quote Originally Posted by tiliavirga View Post
    [...]
    Only rely on third party libraries, like MFC and ATL, when you absolutely have to and then use them as little as you absolutely can.
    [...]
    "Third party"? Prefer saying MFC and ATL are C++ wrapper libraries over native Windows API.
    Quote Originally Posted by tiliavirga View Post
    [...]
    My advice is general. Always prefer standard C++.
    Probably, in a parallel world and a future life, we'll have a standard C++ supporting all native OS's stuff.
    Most of complex applications deal with native. E.g. the better way to keep settings in Windows is to use registry while Mac OS X applications use p-lists. User experience on Mac is pretty different to user experience on Windows. That means, prefer writing the GUI part for Windows using MFC/ATL/WTL and for Mac OSX using Cocoa framework.
    Of course, can and it's good to isolate a cross-platform part of the project (e.g. the communication module) which can be written in "pure" standard C++, completing with boost stuff where necessary.

    My advice based on some experience in desktop applications targeting multiple platforms is:
    1. write platform-independent part using cross-patform code (STL and boost);
    2. write platform-dependent part (user interface, system specific, etc) using native frameworks.
    3. isolate as much as possible the code from #1 and #2; do not mix them.


    Returning to our sheep and copleting what Arjay already said: once a given code uses MFC/ATL is preferable to use CString and not std::string/std::wstring inside it, as well as if uses Cocoa is preferable to deal with Cocoa's NSString.

    See also the quote from my signature.
    Last edited by ovidiucucu; November 14th, 2015 at 07:55 AM.
    Ovidiu
    "When in Rome, do as Romans do."
    My latest articles: https://codexpertro.wordpress.com/

  4. #19
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,620

    Re: CString class in non-MFC static library

    Quote Originally Posted by tiliavirga View Post
    My advice is general. Always prefer standard C++.
    I always am afraid of general advices. In their most those are useless.
    Best regards,
    Igor

  5. #20
    GCDEF is offline Elite Member Power Poster
    Join Date
    Nov 2003
    Location
    Florida
    Posts
    12,635

    Re: CString class in non-MFC static library

    Quote Originally Posted by tiliavirga View Post
    A much better solution is to always use standard C++ as much as possible.

    Only rely on third party libraries, like MFC and ATL, when you absolutely have to and then use them as little as you absolutely can.

    I know my suggestion comes too late for many who have already fallen into the honey trap and they may benefit from your suggestion of course.
    This is a Visual Studio forum and MFC is part of Visual Studio. I'd hate to have to write a Windows app without MFC. MFC has been around for 20 years or so, and is very reliable. For many of us, multi-platform or multi-character set code just isn't an issue that's ever going to come up.

  6. #21
    Join Date
    Jan 2009
    Posts
    399

    Thumbs up Re: CString class in non-MFC static library

    "MFC has been around for 20 years or so, and is very reliable".
    Totally agree !

  7. #22
    Join Date
    Nov 2015
    Posts
    12

    Re: CString class in non-MFC static library

    It turns out I celebrated too early, now I made my own expierence with it. The pitfall is that it works f you use it inside a data structure like
    struct MyStruct
    {
    CString cstr;
    }

    ...somewhere else:
    MyStruct ms;
    ms.cstr=_T("Hello");//OK

    but as soon as CString is used as a function parameter, then the linker suffers indigestion

    On the other hand I remembered, that I have an application (incomplete and frozen for a while) that uses CString exactly in this manner, so it may require further invistigation
    Last edited by Prandr; December 21st, 2015 at 04:17 PM.

  8. #23
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,620

    Re: CString class in non-MFC static library

    Quote Originally Posted by Prandr View Post
    but as soon as CString is used as a function parameter, then the linker suffers indigestion
    You may use CString inside your library, but you must not let it in or out of the one. Use LPCTSTR in function prototypes and take care of underlaying CString lifecycle.
    Attached Files Attached Files
    Last edited by Igor Vartanov; December 22nd, 2015 at 06:48 AM.
    Best regards,
    Igor

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured