Build CodeBlocks using Microsoft Visual C++

[killerbot]

I have used both, and off course CB is better ;-)
But the debugging experience in Visual Studio is way better, honest is honest [better watches windows, more stable, structures in a watch or mouse over can expand, [the frontend, aka CB part] ... , and way better then GDB (the backend part)]. This is the one of the very little things on my list I would love to see on the same level in CB.

[ollydbg]

I have used both, and off course CB is better ;-)
But the debugging experience in Visual Studio is way better, honest is honest [better watches windows, more stable, structures in a watch or mouse over can expand, [the frontend, aka CB part] ... , and way better then GDB (the backend part)]. This is the one of the very little things on my list I would love to see on the same level in CB.

Visual studio's supply two versions of CRT libraries(release, debug). when debugging, the debugging CRT library give the debugger more information.(e.g. the debug CRT library can set the stack to 0xCC when entering a function, so VC debugger can easily catch some uninitialized variable, it can save some stack pointer address value, so it can check the value when the function returned).

but for gdb, it has no idea about this. I do not know whether MinGW CRT library has both release/debug CRT. So, sometimes, gdb try to resolve uninitialized memory(contains random value instead 0xcc), which mostly cause a gdb crash. So, I mostly hope a more stable debugging CRT library under MinGW to support gdb.

PS: GDB's python script can make debugging under GDB much better. MSVC as I know does not has this kind of script support.

[Loaden]

BTW: This will break translations IMHO, as the second part (now _T("")) will not appear in the translation tables. You should always use _("").

Bad news, And I can't fix this issue.

[Ceniza]

I have access to Visual Studio 2010 Professional and Intel C++ Studio XE, which means more tools that could be used to improve C::B if you manage to make it build with it.

I, on the other hand, think that Visual Studio 2010 SP1 + Visual Assist X + Intel C++ Studio XE is much better than C::B, at least from a Windows-only point of view. Price is quite a difference, but the company is paying for it.

[MortenMacFly]

Bad news, And I can't fix this issue.

Well, you'll need to do something like:
Old:

Code

_("text....\n"
   "more text...")

New:

Code

_("text....\nmore text...")

...or:

Code

wxString str = _("text....\n")
                 + _("more text...");

[oBFusCATed]

Ceniza:
You need Visual Assists in VS 2010, so they failed to make the CC work again?

It is normal for VS to be better, because it is 10+ developers working part time vs 10-20-100 working full time.
The remarkable thing is how close (and even better for some things) C::B is to VC in many aspects.

(I've not tried 2010, yet)

[Biplab]

My few cents!

First of all I'd like to say Thanks to Loaden for this effort.

I do agree VS debugger is better in some cases. I am also facing a similar issue with my 64 bit porting. GDB can't give me any meaningful reply on why C::B is crashing. So I think once C::B source can be compiled with VC, I may get some clue. Personally I am also working on patching C::B source to be compatible with VC (I have compiled upto SDK). But after Loaden's patch it will be easier for me.

I differ on some opinions expressed on using ifdefs. Personally my opinion is - as long as it doesn't affect officially supported compiler, ifdef's should be ok. They add bloat to the source; not to the binary. And with the code-folding feature in any modern IDE/Editor, it is not an issue anymore that source code will become unreadable.

Loaden & others - Keep up the good work! Cheers!

[oBFusCATed]

Biplab: debugging on 64bit is harder than 32bit in general and it is because of the way the processors work.
Have you tried to use -fno-omit-frame-pointer (inspect the manual for the correct option) (it is default on 64bit archs)?

[Ceniza]

Ceniza:
You need Visual Assists in VS 2010, so they failed to make the CC work again?

The integrated IntelliSense seems to be good (barely tried it), but Visual Assist X is just great. I had already got it before switching to VS 2010, and life is just not the same once you get used to it. The renewal is quite cheap also, and, once again, I am not the one paying for it.

I still do not get why you say 64 bits is harder to debug. You get more, and wider, registers, and the calling convention defaults to fastcall. Other than that it is pretty much the same as with 32 bits. Am I missing anything?

[oBFusCATed]

I was using VAssist and then stopped... now I'm using "find in files" or "thread search" ... and  I don't feel I've lost something in the functionality.

The backtraces have less info in them (there is a doc at work describing the problems) ...
Also http://www.rotateright.com/faq.html#UserInterface_2

[MortenMacFly]

They add bloat to the source; not to the binary. And with the code-folding feature in any modern IDE/Editor, it is not an issue anymore that source code will become unreadable.

I clearly disagree here. We are working 100% with the code, so cluttered code is bad. And we cannot selectively code-fold, just "all-or-nothing" as you know. In addition Thomas did a lot hard work to remove nasty #defines in the past which we should honor as this was our decision.

Furthermore we have SVN for exactly such trials. Such experiments should be done in a branch as it is not our overall-goal to support compilation with VC. IMHO for C::B being a cross-platform IDE it just causes more hassle than benefits. Look at the wxWidgets sources itself what hacks are in there just to support other compilers. It's OK if you need it or if it's a design decision, but both is not the case for us.

Edit: To make it clear: I don't want to stop the work, just do it in the right place. As e.g. Jens with the console branch.

[Biplab]

The backtraces have less info in them (there is a doc at work describing the problems) ...
Also http://www.rotateright.com/faq.html#UserInterface_2

Is this applicable on 64 bit Windows?

Edit: To make it clear: I don't want to stop the work, just do it in the right place. As e.g. Jens with the console branch.

If the direction is not to include such patches to trunk then it is not necessary to create a branch and then abandon it later. I'd rather keep my local copy in sync and dump the whole patched source somewhere in the web.

[MortenMacFly]

If the direction is not to include such patches to trunk then it is not necessary to create a branch and then abandon it later. I'd rather keep my local copy in sync and dump the whole patched source somewhere in the web.

I didn't mean to abandon. Its easy to keep the branch in sync with trunk. We did this so often in the past and have two active branches that do so just fine. It's an experiment in the end, needed for a special purpose from time-to-time. The main stream development has to be in MinGW/GCC.

So, whenever you need the branch make it in sync with trunk and use it. These are 3 mouse clicks in my SVN software. And once stabilised you wouldn't even cause conflicts as there won't be much changes. And if we come to design guidelines (e.g. never do something like:

Code

_("text....\n"
   "more text...")

)
...which we apply in trunk the differences will be minimised.

Why do you believe it would be better to

dump the whole patched source somewhere in the web.

then??? It will make it way harder to handle.

[Loaden]

Bad news, And I can't fix this issue.

Well, you'll need to do something like:
Old:

Code

_("text....\n"
   "more text...")

New:

Code

_("text....\nmore text...")

...or:

Code

wxString str = _("text....\n")
                 + _("more text...");

I know this, but it can't support multi-line, or lead broke the whole string.
Can someone have a better way?

[Loaden]

Hello everybody, now there is a very perplexing question: Why build CB use VC compiler will cause startup crash?
If the code is robust enough to write, then use a different compiler should be able to run.
But now I start again busy, so I can not continue.