I suggest using an IDE capable of attaching a debugger, and not insist on going cross platform from the very start. -Makes life easy! :-)

If cross platforms must be supported, go with it from the start will SAVE your life unless you have already very rich cross platform experience.
The C++ code written only in VC most likely can't be compiled by GCC directly. And sometimes it's not trivial to port the code.
Of course it depends on what C++ features you use. If only using very basic features such as no templates, the porting may be easier.

[quote name='SuperVGA' timestamp='1331277625' post='4920604'] I suggest using an IDE capable of attaching a debugger, and not insist on going cross platform from the very start. -Makes life easy! :-)

If cross platforms must be supported, go with it from the start will SAVE your life unless you have already very rich cross platform experience. The C++ code written only in VC most likely can't be compiled by GCC directly. And sometimes it's not trivial to port the code. Of course it depends on what C++ features you use. If only using very basic features such as no templates, the porting may be easier. [/quote]

Yes and no.

If you stick to standard C++ you'll be mostly fine, and mostly-er fine as time goes on In the far reaches of C++ space, there are still areas where the major compilers do not have equivalent support, but those are either very new things, or rather esoteric things that you're not likely to encounter anyways. That said, a few of the more-common cases that you might run across are compiler extensions and inline assembly (gcc uses a different syntax than Microsoft's compiler, for example) -- however, if you're doing either of those then you're explicitly accepting that those portions of code are not strictly portable. Something like templates are pretty safe until you start wanting to do partial template specialization, or variadic template arguments, both of which only tend to come up in relatively "advanced" scenarios.

On the other hand, the availability of libraries on the target platforms is a great deal more important. A simple example is that you can't use DirectX on MacOS or Linux platforms. A more subtle example is Boost::ASIO which is implemented very differently on Windows than it is on *nix last I heard, due to differences in the underlying platform -- even though your client code will be the same or very similar, performance might be unacceptable on one or the other platform. In general you either have to find a common library, or roll your own abstraction. When I end up doing the latter, I find that it works best to develop two or more of the "most different" implementations in parallel, and then fill in any remaining implementations later. That way you can usually avoid painting yourself into a corner, without having so much to consider that you fall victim to analysis-paralysis.

Yes and no.

If you stick to standard C++ you'll be mostly fine, and mostly-er fine as time goes on

I think "standard" is not quite equivalent to portable or cross platform.
VC is quite popular compiler but it's far less standard than GCC.
For example, VC parses template in just one phase while standard requires two phases.
That means VC has loose syntax check on template. So some template code that compiled fine in VC may fail in GCC.
And I guess MS doesn't want to change it to standard because it will break a lot of VC-only code.

Just my opinion.

[quote name='Ravyne' timestamp='1331323575' post='4920751']
Yes and no.

If you stick to standard C++ you'll be mostly fine, and mostly-er fine as time goes on

I think "standard" is not quite equivalent to portable or cross platform.
VC is quite popular compiler but it's far less standard than GCC.
For example, VC parses template in just one phase while standard requires two phases.
That means VC has loose syntax check on template. So some template code that compiled fine in VC may fail in GCC.
And I guess MS doesn't want to change it to standard because it will break a lot of VC-only code.

Just my opinion.
[/quote]
I don't think it's a valid opinion.

In a huge proportion of cases code written in MSVC is perfectly capable of being compiled on other platforms without issue or error. It's a huge jump from a bunch of interdependent "might"s and "may"s to stating that "C++ code written only in VC most likely can't be compiled by GCC directly" - especially when there are many real-life projects out there that do exactly that, and plenty of real-life people in here who have also done exactly that and can attest that it does work.

It's not the code that's going to break things, it's the libraries.

I don't think you should use GCC/MinGW on Windows unless you absolutely have to. MSVC should always be the default choice.

I don't think it's a valid opinion.

In a huge proportion of cases code written in MSVC is perfectly capable of being compiled on other platforms without issue or error. It's a huge jump from a bunch of interdependent "might"s and "may"s to stating that "C++ code written only in VC most likely can't be compiled by GCC directly" - especially when there are many real-life projects out there that do exactly that, and plenty of real-life people in here who have also done exactly that and can attest that it does work.

It's not the code that's going to break things, it's the libraries.

Did you write heavily template based code in VC then port to GCC?
I did. And due to the non-standard one phase parsing in VC, I need to change some of the code to pass the two phases check in GCC.
Of course if your code has only classes, functions, no template, it's quite portable.
In this thread nobody said their code is only classes and functions.
So I assumed template is also used.
So my opinion is valid.
That's not only my opinion, but my experience. I experiment the port issue.

[quote name='mhagain' timestamp='1331403038' post='4920937']
I don't think it's a valid opinion.

In a huge proportion of cases code written in MSVC is perfectly capable of being compiled on other platforms without issue or error. It's a huge jump from a bunch of interdependent "might"s and "may"s to stating that "C++ code written only in VC most likely can't be compiled by GCC directly" - especially when there are many real-life projects out there that do exactly that, and plenty of real-life people in here who have also done exactly that and can attest that it does work.

It's not the code that's going to break things, it's the libraries.

Did you write heavily template based code in VC then port to GCC?
I did. And due to the non-standard one phase parsing in VC, I need to change some of the code to pass the two phases check in GCC.
Of course if your code has only classes, functions, no template, it's quite portable.
In this thread nobody said their code is only classes and functions.
So I assumed template is also used.
So my opinion is valid.
That's not only my opinion, but my experience. I experiment the port issue.
[/quote]
I don't doubt that you've found a case, but going from that to "C++ code written only in VC most likely can't be compiled by GCC directly" is stretching things a little, especially when there is plenty of code written in MSVC that can be compiled by GCC. One case does not make it a universal law. "I guess MS doesn't want to change it to standard because it will break a lot of VC-only code" is definitely going too far as well.

I don't doubt that you've found a case, but going from that to "C++ code written only in VC most likely can't be compiled by GCC directly" is stretching things a little,

It's not special case.
The one phase template parsing in VC can influence a lot of template code.
It's not trivial case.

especially when there is plenty of code written in MSVC that can be compiled by GCC.

Are you sure those code are not done with extra work to port to gcc?
Or the code writer has already a lot of experience with porting between VC and gcc?
Or are you sure those code using a lot of template? Or just some pure class library?

One case does not make it a universal law.

Did I say it's a universal law? Or did I say it's a law? Please quote if I said that.
As I said, the one phase parsing in VC is not trivial case.
And even it's a trivial case, I told others about the case so they can know it and won't waste time on it.
Why are you arguing so much on this? Or do you think we can only talk about universal law here?

"I guess MS doesn't want to change it to standard because it will break a lot of VC-only code" is definitely going too far as well.

Far from what?
If MS changes one phase parsing to two phases parsing, a lot of VC code heavily using template will definitely not compile.
Isn't it that true?

Finally, did you ever write a lot template code in VC then port to gcc? Did you have any problem?

For those who are not familiar with VC template parsing issue, here are two links,
http://stackoverflow...ithout-typename
http://stackoverflow...mplate-instanti

After reading the two pages, to avoid any more unnecessary arguing, I admit my phrase "one phase parsing problem" in VC is not appropriate. It should be better "incorrect two phases parsing" in VC.

For those who down voting me, please jump out to give your reason.
Down voting others anonymously with no reason is not something a man should do.
Thanks