Other than VC++

[lallous]

Hello

I never compiled my code using any other compiler than MS's VC++

I know that if the code written is purely ISO C++ compatible, then it should
compile fine.

How, how to allow unicode as well?

In MSVC, we have TCHAR.H that maps:
1)
strcmp and wcscmp to _tcscmp, with something like:
#ifdef UNICODE
#define _tcscmp wcscmp
#else
#define _tcscmp strcmp
#endif

2)we also have the _T macro which conditionally defines strings either as
ASCII or as unicode as:
#ifdef UNICODE
#define _T(x) L ## x
#else
#define _T(x) x
#endif

3)
char and wchar_t to TCHAR

What are the equivalent features in other compilers?
Please share your thoughts.

Regards,
Elias

 

[fourfires.d]

I just search around google and find a article that might relevant:

http://www.sdconsult.no/linux/wine-doc/unicode.html

 

[loufoque]

lallous a écrit :

I know that if the code written is purely ISO C++ compatible, then it should
compile fine.

I think only Comeau supports the whole ISO C++ standard.
Anyway, if it runs on MSVC++ it should at least run on gcc.

How, how to allow unicode as well?

Standard C++ doesn't know what unicode is.

Your stuff is for code following the win32 api (which is C by the way
and not C++), which isn't elegant at all.
Anyway you should be able to use that with any win32 compiler I suppose.


If you want multiplatform Unicode support, you will have to use
something else (which wouldn't be a bad idea even if you only care about
win32)

 

[Pete Becker]

lallous a écrit :



I think only Comeau supports the whole ISO C++ standard.
Anyway, if it runs on MSVC++ it should at least run on gcc.

That hasn't been my experience in porting code. The two compilers have
different sets of language features and different sets of bugs.

 

[loufoque]

Pete Becker a écrit :

That hasn't been my experience in porting code. The two compilers have
different sets of language features and different sets of bugs.

I meant if it runs using the subset of the C++ standard MSVC++ provides,
it should run with gcc.
Of course, code relying on non-standard behaviours of MSVC++ may not work.

 

[Pete Becker]

Pete Becker a écrit :



I meant if it runs using the subset of the C++ standard MSVC++ provides,
it should run with gcc.
Of course, code relying on non-standard behaviours of MSVC++ may not work.

That hasn't been my experience in porting code. The two compilers have
different sets of language features and different sets of bugs. Porting
standard-conforming code to gcc is not as simple as you seem to think.

 

[red floyd]

That hasn't been my experience in porting code. The two compilers have
different sets of language features and different sets of bugs. Porting
standard-conforming code to gcc is not as simple as you seem to think.

I've found that when porting code from MSVC to gcc (3.2.x,3.3.x), the
issues were with non-compliant forms that MSVC (7.1) allowed (such as
passing a temp to non-const reference). Code that compiled cleanly on
gcc also compiled cleanly on VC7.1.

 

[yangc]

Right, look like gcc is more strict than MSVC.
I had tired to modify tchar.h from MSVC to gcc comply, and sadly found
there were lots of functions not existed in glibc. Too work should be
done for migrating unicode code.
I think the better way is define a good unicode schema before coding
for multiplatform.

 

[Ron Natalie]

Right, look like gcc is more strict than MSVC.
I had tired to modify tchar.h from MSVC to gcc comply, and sadly found
there were lots of functions not existed in glibc. Too work should be
done for migrating unicode code.
I think the better way is define a good unicode schema before coding
for multiplatform.

Depends which version of MSVC you are talking about. Even existing
VC 6 code gagged when we went to 2005. The thing is a lot less
lenient.

So far we've found (reportedly from my lead programmer, I haven't
verified it myself) one excruciatingly bad bug in iostreams on
2005.