william.kempf@firstdatacorp.com wrote:
>
> Ok, I have a bit of a design problem I need some brain storming help on.  Say
> you've got a class with several functions that return a "string".  To be
> portable for internationalization you should be able to handle any "string"
> type, from char to wchar_t to something they'll dream up in the future.  Now
> the problem... how do you elegantly handle this in your class design.  Member
> templates might work, but are unwieldy.  The user of the class is going to get
> darn sick of typing something like "str = obj.get_name<char>()".

This syntax is illegal. Instead, you have to write (something more
sick:-))

  str = obj.template get_name<char>();

> Having to
> templatize your entire class just for string representation seems wrong, and
> won't handle the case where the user has to deal with multiple string types at
> once.
>

This is the easiest way I could think of. Since you are concerned about
internationalization, the situation of multiple string types won't be
frequent, IMHO.

Regards,
Biju Thomas



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I don't have a real good answer, but I followed Microsofts example,
something like:
#ifdef _UNICODE
#define tstring wstring
#else
#define tstring string
#endif

Then I used tstring.  It's a cludge, but not as *horrible* a cludge IMHO as
_T("somestring") is, so everything's relative.

william.kempf@firstdatacorp.com wrote in message
<70q7sf$iaf$1@nnrp1.dejanews.com>...
 >Ok, I have a bit of a design problem I need some brain storming help on.  Say
 >you've got a class with several functions that return a "string".  To be
 >portable for internationalization you should be able to handle any "string"
 >type, from char to wchar_t to something they'll dream up in the future.  Now
 >the problem... how do you elegantly handle this in your class design.  Member
 >templates might work, but are unwieldy.  The user of the class is going to get
 >darn sick of typing something like "str = obj.get_name<char>()".  Having to
 >templatize your entire class just for string representation seems wrong, and
 >won't handle the case where the user has to deal with multiple string types at
 >once.
 >
 >Even ignoring the possiblity of other types and limiting things to char and
 >wchar_t, it seems inneficient and combersome to declare both forms for every
 >function that should return a string (for example, get_name and
 >get_name_wide).
 >
 >Any other thoughts on this?

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jonathan H Lundquist wrote:
>
> william.kempf@firstdatacorp.com wrote in message
>
>  >Ok, I have a bit of a design problem I need some brain storming help on.  Say
>  >you've got a class with several functions that return a "string".  To be
>  >portable for internationalization you should be able to handle any "string"
>  >type, from char to wchar_t to something they'll dream up in the future.  Now
>  >the problem... how do you elegantly handle this in your class design.  Member
>  >templates might work, but are unwieldy.  The user of the class is going to get
>  >darn sick of typing something like "str = obj.get_name<char>()".  Having to
>  >templatize your entire class just for string representation seems wrong, and
>  >won't handle the case where the user has to deal with multiple string types at
>  >once.

I'm dealing with the very same problem at the moment.
Where your class/library has to handle both string
types (char/wchar_t) concurrently, you must provide
both interfaces.  You can of course do this as via
templates, but there's little or no gain (assuming that.  Better
to provide overloaded methods  - overload based on
a return arg, eg:

 void getName(std::string* pName) const;
 void getName(std::wstring* pName) const;


>  >(snip)
>  >
>  >Any other thoughts on this?
>
> I don't have a real good answer, but I followed Microsofts example,
> something like:
> #ifdef _UNICODE
> #define tstring wstring
> #else
> #define tstring string
> #endif
>
> Then I used tstring.  It's a cludge, but not as *horrible* a cludge IMHO as
> _T("somestring") is, so everything's relative.

Yes, where you just wish to provide either a char
or wchar_t version of a library, this is a workable
approach.  At my place of work a standard header
provides #define mappings for all the standard
library classes/objects that are templatized on
char/wchar_t.  We use '_t' as the prefix in line
with what's provided in <tchar.h>.
I attach the relevant section for information.

-----------------------------------------------
#ifdef _UNICODE
#define _tstring  std::wstring
#define _tcin   std::wcin
#define _tcout   std::wcout
#define _tcerr   std::wcerr
#define _tclog   std::wclog
#define _tios   std::wios
#define _tstreambuf  std::wstreambuf
#define _tistream  std::wistream
#define _tostream  std::wostream
#define _tiostream  std::wiostream
#define _tstringbuf  std::wstringbuf
#define _tistringstream  std::wistringstream
#define _tostringstream  std::wostringstream
#define _tstringstream  std::wstringstream
#define _tfilebuf  std::wfilebuf
#define _tifstream  std::wifstream
#define _tofstream  std::wofstream
#define _tfstream  std::wfstream
#else
#define _tstring  std::string
#define _tcin   std::cin
#define _tcout   std::cout
#define _tcerr   std::cerr
#define _tclog   std::clog
#define _tios   std::ios
#define _tstreambuf  std::streambuf
#define _tistream  std::istream
#define _tostream  std::ostream
#define _tiostream  std::iostream
#define _tstringbuf  std::stringbuf
#define _tistringstream  std::istringstream
#define _tostringstream  std::ostringstream
#define _tstringstream  std::stringstream
#define _tfilebuf  std::filebuf
#define _tifstream  std::ifstream
#define _tofstream  std::ofstream
#define _tfstream  std::fstream
#endif
-----------------------------------------------

--
+---------------------------------+
|         Paul Grealish           |
|       GEOPAK-TMS Limited        |
|       Cambridge, England        |
| paul.grealish@uk.geopak-tms.com |
+---------------------------------+


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jonathan H Lundquist wrote in message <70rbb9
    [snip]
>I don't have a real good answer, but I followed Microsofts example,
>something like:
>#ifdef _UNICODE
>#define tstring wstring
>#else
>#define tstring string
>#endif

In some cases, I agree that such preprocessor kludges are best.
However:

> >the problem... how do you elegantly handle this in your class design.  Member
> >templates might work, but are unwieldy.  The user of the class is going to get
> >darn sick of typing something like "str = obj.get_name<char>()".  Having to

I believe that obj.getName(str), where the type instantiating the member
template does not have to be explicitly specified, can be a superior
solution for this specific case -- yep, it might be nicer to return a string
value rather than taking a reference to one, but it's basically a "tradeoff
of syntactic-sugar forms" either way; and after all, what with such
existing standard functions as "std::getline(thestream,astring)", the
average user will probably be reasonably accustomed to passing
strings by reference rather than having them returned as values.


Alex




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ok, I have a bit of a design problem I need some brain storming help on.  Say
you've got a class with several functions that return a "string".  To be
portable for internationalization you should be able to handle any "string"
type, from char to wchar_t to something they'll dream up in the future.  Now
the problem... how do you elegantly handle this in your class design.  Member
templates might work, but are unwieldy.  The user of the class is going to get
darn sick of typing something like "str = obj.get_name<char>()".  Having to
templatize your entire class just for string representation seems wrong, and
won't handle the case where the user has to deal with multiple string types at
once.

Even ignoring the possiblity of other types and limiting things to char and
wchar_t, it seems inneficient and combersome to declare both forms for every
function that should return a string (for example, get_name and
get_name_wide).

Any other thoughts on this?

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]