Code::Blocks vs. VS Code

[tigerbeard]

When you search the forum with "CodeBlocks" and "Visual Studio" you quckly find those three.

Code

General (but related to Code::Blocks) / Code::Blocks vs Visual Studio
« by kinddavid on July 28, 2015, 04:11:44 am »

General (but related to Code::Blocks) / Code::Blocks vs. Visual Studio
« by pghtech on August 07, 2006, 11:22:45 pm »

General (but related to Code::Blocks) / Code::Blocks vs. Visual C++
« by ixfd64 on March 21, 2008, 10:52:18 pm »

The newest is 2015. I have not found anything about "VS Code"

A few days ago I did check out MS Code. Where for Visual Studio I have a sack full of arguments why I rather stick to Code::Blocks, for VS Code I realize that things are very different.

So to me it looks like with "MS Code" Microsoft now has
* a full open source cross-plattform IDE
* supporting almost all conceivable languages
* impressing online documentation (limited offline use)
* debugger and intellisense integration for many languages
* easy to install
* central addon repository. Automatic download & install from IDE

a bit unclear
* Suitability for larger projects? (no "project" concept, but "workspaces")
* Build management?

I am impressed to see what happens when massive manpower is directed into open source. MS built something very open and very flexible. Very unlike other MS stuff. Just looking at the wealth of 3rd party addons (called "extensions") shows that it seems already widely accepted and widely used. Looking at their own C++ extension I was instantly wondering where they plan to draw the line against their own VS Community edition over the next years.

I guess I will stay with CB which feels more suited to me for larger projects. Also I kind of love the non-fancy but very functional user interface. But I feel I am running short of real good arguments. Maybe it is mostly because its a long used tool I just comfortable to work with.
In fact, my last unsuccessful action in C:B got me the VS Code in the first place ( http://forums.codeblocks.org/index.php/topic,23035.msg156654.html#msg156654, "Plugin development/python plugin"). I was up and running Python with VS Code in a day, both for Linux and Windows. I still have my struggles with the modern GUI and with missing offline documentation but I guess even the strongest C::B supporter would give 100 points to MS Code here.

I think VS Code is a very interesting development and worth watching. Also worth a fact-based exchange of thoughts and experiences. I would be interested in

• When you are C:B user, what is your experience with that tool?
• What are your pros & cons? 
• Do you plan to stick with C::B, change or use both in the future?

[sodev]

My Situation is like this:

• I need a cross platform IDE (for me that means Windows and Linux). I don't want to learn to use two IDE's.
• I need a cross platform meta build system that can drive automated builds and the IDE. I need to apply identical configurations to many projects, need to easily update libraries, compiler, settings, i don't want to maintain two sets of build system configurations, one for automated build, one for the IDE.

For about the last 6-8 years my setup was a heavily modified PreMake 3.x and CodeBlocks. For the last 2 years i am looking for a replacement because mainly CodeBlocks doesn't fit my needs anymore. Using a lot of Modern C++ CodeBlocks is for me reduced to a Notepad++, pretty much most of its CC functions are dead for me.

My first shot was Eclipse, but it doesn't work on Windows for me because it's not usable with the MSVC compiler there (try to use the plugin and you will quickly figure out the problems). I am using Eclipse on the Linux side though, with handwritten project files to copy enough compiler configuration to get Codan running. A maintenance nightmare but usability is really great. I was quite interested about VS Code too, tried it, and dropped it pretty fast. Main reason is focus. It is focused around "modern" web-based "fancy" script-like languages, while it might be good in that area (sorry, im not that modern enough to justify ) it lacks in the "classic" native-code area. The project-less approach is weird and as soon as you need to configure something you end up writing "obscure" settings files. This is not very user friendly and smells like trouble for my second requirement.

From my Java work i know Gradle as a (meta-)buildsystem which fulfills my requirements for the Java side, it also gets improved support for native building but IMHO has the same problem like VS Code: its focus is Java. But now there is a very strong option for my C++ side: CMake. Yes i heard the stories about it, that was also the reason why i didn't pick it earlier, but now there is some nice improvement: native IDE support. CMake could generate projects for various IDE's previously, even some i would pick, but the results weren't that awesome. But now, since major IDE's can natively open CMake projets, the situation has changed. The results using this path looks better. Another point for CMake is that it is kind of the standard meta buildystem right now and you see increased support for it.

CodeBlocks was not bad, it was a good choice for me in the past, but i don't see a future for it for my work. It lacks some essential features and regarding the currently available manpower i doubt this will improve in the near future. For me the path is clear, get my stuff running with CMake and then use the IDE that supports this best.

[oBFusCATed]

... It lacks some essential features and regarding the currently available manpower i doubt this will improve in the near future...

Hehe, I'll try to prove you wrong, hopefully even this year. Getting good CC support these days is not that hard as it was 5 years ago.

[BlueHazzard]

You really need a killer argument against vs code? It is an electron application. Everything said ... The integration in the operating system is terrible, the resource usage is terrible, everything seems to be reinvented.... (just my two cents i will not argument anymore about this)

Hehe, I'll try to prove you wrong, hopefully even this year. Getting good CC support these days is not that hard as it was 5 years ago.

Have you any preview (probably language server?) ?

[oBFusCATed]

Have you any preview (probably language server?) ?

Nope, when I have something you'll see a topic. And yes it is language server based.

[Krice]

I think C::B is the only actual IDE in open source scene, that's why it's also the best one. When comparing, more accurate vs. is Visual Studio Essential (free version) and it's just better in my opinion. But C::B has "no installer" option which I think is great, you would be surprised how many people need that.

[pluto]

My needed opinion, because I've nothing better to do 

I've tried VS Code in the past, and the GUI simply sucks. I think it's the new trend of making inconsistent, nonsensical and unaccessible GUIs that for some people look cool. Good examples are Windows 8, and modern browsers. Maybe it comes in part from the forced GUIs of rich websites (instead of using protocols+custom clients) and smartphones.

Outside of the GUI, I haven't tried VS Code debugging, but in the traditional VS it's one of its strongest points. Here CB has regressed to the point that lately I've been trying CodeLite to be able to debug anything.

Also, I think the CC effort was a big waste of time. Why rewrite a parser when there are already open source implementations from compiler themselves? Not only it's a step closer to having continuous compilation, but it's implicitly consistent with how an actual compiler sees the code; plus, it requires less code maintaining with new language standards (see C++).

[oBFusCATed]

Outside of the GUI, I haven't tried VS Code debugging, but in the traditional VS it's one of its strongest points. Here CB has regressed to the point that lately I've been trying CodeLite to be able to debug anything.

What OS is this on? The debugging experience hasn't changed much in my opinion.

Also, I think the CC effort was a big waste of time.

What rewrite? CC hasn't changed much last 3-4 years. clangd is still not that usable for big projects.

[pluto]

What OS is this on? The debugging experience hasn't changed much in my opinion.

Windows 32bit with GDB
I've not used much CB in the last year, so pardon me if my info is not up to date, but let me see..
- the disasm window doesn't show anything anymore
- the pretty printing went away without any announcement, and suddenly I have to learn how to use GDB's ugly python crazyness, which was (still is?) not documented anywhere
- multithreaded debugging doesn't work
- breakpoints sometimes don't work
- the watch window doesn't remember anything
- pausing or stopping the slave, doesn't work anymore and sometimes stalls CB
- ...
is the GDB interface still the deprecated one?

What rewrite? CC hasn't changed much last 3-4 years.

Exactly, and it still crashes the IDE.

clangd is still not that usable for big projects.

Maybe it would have been more proficuous to help that project to make it more usable in the IDE, instead of starting from scratch?

Before anybody thinks I'm just an ungrateful random ranting, I'm not.
I'm grateful CB exists and that some people worked and are still working on it. I'm just pointing out some problems from my point of view.
As I wrote in the past, every single user of CB is a coder, which is very useful for code contribution, and an advantage that most open source projects don't have. The problem is that most of these users don't have time to dig into the entire codebase to understand it to contribute, so it would be very useful to document it a little, especially because CB already supports plugins, so that small patches can be provided easier and faster.

[oBFusCATed]

- the disasm window doesn't show anything anymore

This should be fixed now. Try a night build and report if it doesn't work. But you'll have to switch to 64bit gdb and your executable also should be 64bit.

- the pretty printing went away without any announcement, and suddenly I have to learn how to use GDB's ugly python crazyness, which was (still is?) not documented anywhere

The old thing never worked well. The python stuff is documented in GDB's documentation.

- multithreaded debugging doesn't work

Simple example which can be used to reproduce the problem? We know this is not very robust part of the debugger interface, but it works most of the times and if you're not too aggressive switching threads.

- breakpoints sometimes don't work

Example please.

- the watch window doesn't remember anything

Never did, so it is not a regression.

- pausing or stopping the slave, doesn't work anymore and sometimes stalls CB

Example? Are you debugging 64bit apps?

What rewrite? CC hasn't changed much last 3-4 years.

Exactly, and it still crashes the IDE.

Minimal example to reproduce the problem. If you've not disabled the symbol browser try to do it. It might save you some of the crashes.

Maybe it would have been more proficuous to help that project to make it more usable in the IDE, instead of starting from scratch?

Our parser is older than clangd and possibly clang. So there is no chance we've been able to help them.
And still using clangd with gcc or vc++ is not working 100% of the time, so it is a good solution only if you use clang as your compiler. But probably in the future we'll use clangd. I have an experimental plugin and when I find the time I'll finish it.

... so it would be very useful to document it a little...

What do you mean here? Which parts need better documentation? The codebase isn't really that big in the first place.

[pluto]

What do you mean here? Which parts need better documentation? The codebase isn't really that big in the first place.

Some intro document that at least explains the general architecture of the main parts, so it's easier to know where to look, and when somebody changes some code, it doesn't break something else (as confirmed by the numerous regressions that pop out (I've mentioned some of the debugging, but there are more I've noticed)).
More comments in the code wouldn't hurt, but that's usually the coder's style, so that's less important.

[oBFusCATed]

... (as confirmed by the numerous regressions that pop out (I've mentioned some of the debugging, but there are more I've noticed))...

Argh, I quit this argument. You win. Debugging experience has regressed beyond being usable. Argh. But if you think so, why don't you switch to an old version (both cb, gcc, gdb) which worked better?

[pluto]

Argh, I quit this argument. You win.

I wasn't debating. That's why I didn't reply to any of your quotes of me. You either take the feedback or not.

Debugging experience has regressed beyond being usable

Yes.

why don't you switch to an old version

I did.

[oBFusCATed]

I wasn't debating. That's why I didn't reply to any of your quotes of me. You either take the feedback or not.

Ah, so you're saying it is regressing, but you're not interested in helping out describe how it has regressed, so we have a chance to fix it?

And which version has a better debugger experience than the latest one?

[pluto]

Ah, so you're saying it is regressing, but you're not interested in helping out describe how it has regressed, so we have a chance to fix it?

I tried to report some bugs on SF, but the problem is that even when something gets fixed, something else breaks, hence the regressions I'm talking about. After a while, this trying a new build, rolling back, and then again, report, et cetera.. gets frustrating and I gave up (especially now that the win32 version is not released "nigthly" anymore).
So I decided I may be able to contribute, but I don't have the time to study the entire codebase.

Also, I can't give you examples of the debugging problems I reported in my previous post because I simply don't have any repro code right now with me. I've stopped using CB for months now. As I wrote before, I'm trying out CodeLite at the moment.

And which version has a better debugger experience than the latest one?

I honestly can't remember, but definitely not a recent one. Of course, that version lacked a lot of other fixes and new features..