C++ Looking for a functioning IDE for C++

Crivens said:
+1 for kdevelop.
There is also devel/codelite and devel/codeblocks which I had uses over the years.
Click to expand...

There is also Ultimate++ but the woe of these is reliance on internal or 'simple' GUI libraries that tend to not look well on high resolution high DPI displays. I've already been disproven in my generalizations but where I come from, developers tend to use at least two big screens.

Kdevelop is Qt/KDE so will always 'scale' with the graphics stack well.

I also fear those tools would not be able to resolve huge CMake projects that KDevelop does fine.

Btw. does anyone remember Bloodshed Dev-C++? Easy, batteries included IDE for windows, even had a package manager.
 
Zare said:
developers tend to use at least two big screens.
Click to expand...
This is a great point. I run a laptop connected to a 4K monitor. I end up running juci++ on the laptop display with everything else on the 4K monitor because the font is too small in 4K. The font size can be increased but so far I just drag the window to the smaller monitor out of laziness.
 
I'm in a mood for a morning rant and eclipse makes a good target. As much as I've tried over the years to embrace eclipse/cdt for c/c++ development over the years I just end up getting angry and needing high velocity projectile range therapy. My problems with it are

1) it's always been buggy as hell. I cannot tell you how many times I've had to recreate projects because their obfuscated JAVAesque project metadata got corrupted. Updates to the core IDE often break a well working feature at the expense of fixing something different. This leads to a flip flop of ongoing bugs that never seem to get totally fixed.

2) Have you ever actually tried to get good technical help from the eclipse foundation? The question is rhetorical. Their support venues suck to the nth degree. I used to participate in the eclipse forums and then they migrated away from the forums and onto github discussions. I washed my hands of any contact with them at that point.

3) Too many semiconductor manufacturers became enamored with eclipse and use it as the "workflow environment" for their products. STmicro comes to mind as an example. The problem is that it continues to be buggy, which means producing code for the products becomes a major hassle...and I've never enjoyed working in environments that force a specific workflow, but instead prefer to have a bunch of atomic tools that I can mix and match to meet my needs. Many times I've used the STmicro STCube environment in an out-of-order fashion and broke many days work by corrupting a project and I cannot easily recover because of eclipse's hiding and obfuscation of project metadata. A big no-no in the STmicro environment...DONT TRY TO RENAME COMPONENTS! refactoring is inviting armagedon. In the end I had to abandon eclipse and only use the STM32CubeMX app to setup the micro-controller I/O and features, then resort to a safe GUI editor to write the main code.

4) I guess there is only so much you can do effectively with JAVA...not that I have anything specific against it. It just covers a part of comp-sci that I avoid...I mean come on now, JAVA is effectively the 21st century replacement for COBOL. Too many times I've evaluated or had to use tools that were written in JAVA and been disappointed by the bloat and amateurish nature of the tools. eclipse does nothing to invalidate my bias in that regard.

So the question is "why is eclipse so bad?" I've got some opinions on that...imagine that, LOL

1) it suffers from project bloat without a clear authoritative mandate and direction. I think most FOSS projects suffer a similar disadvantage and the well run ones are run by professionals who maintain control and direction for the project.

2) As I've already said, it's JAVA based...it suffers an incredible resource bloat problem

3) the plugin nature of eclipse makes it incredibly hard to thoroughly test and validate the interactions between components and I suspect the attitude is the all too common "our users are our testers"

4) It tries to be all things to all people, so fails to do anything well.

Anyway, I'm guessing I've triggered at least one lurker so have at it and rip apart my arguments. LOL
 
Well Kent I have nothing to add to that. It used to be OKish 15 years ago.

elephant said:
This is a great point. I run a laptop connected to a 4K monitor. I end up running juci++ on the laptop display with everything else on the 4K monitor because the font is too small in 4K. The font size can be increased but so far I just drag the window to the smaller monitor out of laziness.
Click to expand...

There is also issue with looking at streams e.g. screen shares, if most people in the team use big desktops.
 
Alain De Vos said:
I liked borland text based gui editor & Delphi.
Click to expand...
I was eyeballs deep into every Borland product they ever sold from the the very beginning.
I remain on Delphi 7 to this day.
It does everything I need, except 64 bit code, which I don't need.

I also use "The Semware Editor" for the last 40 years.
Back in the 80s it was called QEdit for DOS, and worked great.
Today it is TSE and runs great as a Win32 app.
It does block and column operations easily, and handles any size of source material.
For those so inclined, it is extensible by user written macros.

I skipped Delphi after Embarcadero bought it, due to price and a very buggy 64-bit environment.
Today, Embarcadero offers a freebie Delphi version which is SO feature laden and complex, I turned away.
I don't care for the IDE in Visual Studio, either.

I also have Lazarus installed, both 32 and 64 bit versions.
It suffers similar to Embarcadero, in its complexity and level of features.

But it is a freebie, just in case I need 64 bit code, but will have to tweak my huge library to be Lazarus compatible.
No thanks, at least for now.

I couldn't imagine working today with a single screen.

I don't need a fancy swing set with gold plated poles and mink lined seats.
A simple rope and tire do just fine, and is very stable.
 
bgavin Since we're talking about Windows development for a moment ...

In between writing code in Turbo C and MFC, I was knee deep in Delphi / Object Pascal. At that time, Borland's tools - which were made to compete with Microsoft's Visual Basic - were better quality. Somewhere around the time VC5 MS's C++ tooling became usable is when I stopped seeing gigs asking for Delphi experience. I never saw much demand for Borland's OWL. I eventually dropped MFC in favor of ATL/WTL before demand for .NET took over.

Microsoft has been moving to a subscription model for everything. I don't mind a one-time payment for something but "renting" software that runs on my own hardware makes no sense to me.

visualstudio.microsoft.com

Visual Studio Pricing: Compare Subscription Plans & Costs

Professional developer tools subscription & licenses. See our Visual Studio Professional, Enterprise, Test Professional, & MSDN Platforms pricing today.
visualstudio.microsoft.com visualstudio.microsoft.com

Enterprise standard​

  • Visual Studio Enterprise
  • Azure DevOps (Basic + Test plan)
  • $150 Azure credit per month
  • Premium dev/test software
  • Extended training and support
  • Power BI Pro
  • and more
Starting at

$499.92user/mo*
Renewal rate $214.09 user/mo* (after first year)
Pricing varies by eligible subscription.

*One-time annual payment
Click to expand...

No thank you.
 
kpedersen said:
I think Embarcadero tried to revive that a number of years back.
Click to expand...

Didn't Embarcadero buy Borland's compiler range?
The late 00 versions of Borland's C++ Builder brought Linux support into the libraries. I remember Kylix being the name for the Linux version - googled it now, and yup Embarcadero bought that.

Dev-C++ was a light, freeware stuff. It had the same level of UI as 16-bit Windows Borland/Microsoft suites.
 
Yes, Embarcadero bought out Borland.
After many, many iterations, I understand the current 64-bit Delphi is free of the elemental bugs.

I recently grabbed their freebie offering and found it the same as Lazarus: too many moving parts.
So I stick with Delphi 7 and remain a happy coder.
I'm retired, so I write for private clients and my own amazement.
 
elephant said:
In between writing code in Turbo C and MFC, I was knee deep in Delphi / Object Pascal. At that time, Borland's tools - which were made to compete with Microsoft's Visual Basic - were better quality.
Click to expand...

Ha, I haven't seen your post before mentioning the Borland tools above.
I've used C++ Builder extensively throughout the 00s, as I come from C background.
I've always wondered why Microsoft did not equip VC++ with a true WYSIWYG form editor alike Visual Basic, yet Borland did it.

The tools are now moving away from form designs to HTML based, reactive frontend stuff. Like Qt QML.
What I don't like about it - the form design is a domain in itself, requiring expertise and all the rest of it. But anyone can draw out a simple fixed-width form, or work with basic resizable layouts. The point of these tools is to aid a programmer in designing a form. The new stuff doesn't have that. You need to get yourself deep into HTML/JS alike shit to be able to wrap your mind on how a simple hello world with a button form works.

Not to mention, the new design patterns yield quite functional but very bland, ugly designs.
 
Zare said:
Didn't Embarcadero buy Borland's compiler range?
Click to expand...
Yeah. Borland sold to CodeGear and then Embarcadero bought that if I recall.

Since C++Builder 6, they bloated it up considerably though. (Actually C++Builder 5 was the peak in my opinion...)

Borland Kylix was cool in theory but I never quite got it to work. What was quite interesting about it was that the underlying technology was just Wine. It was probably one of the largest commercial softwares using Wine technology at the time.

Zare said:
Dev-C++ was a light, freeware stuff. It had the same level of UI as 16-bit Windows Borland/Microsoft suites.
Click to expand...
Ah, here it is. It is still around, Embarcadero's maintained fork of Dev-C++:

https://www.embarcadero.com/free-tools/dev-cpp
 
elephant said:
Microsoft has been moving to a subscription model for everything. I don't mind a one-time payment for something but "renting" software that runs on my own hardware makes no sense to me.
Click to expand...
Isn't Visual Studio Code free of charge? Last I checked, it supports nearly every conceivable language via free plugins. And lots of tools, too - pretty much a complete toolchain, if you know how to set it up.

Other than that, I agree, renting software that runs on my own hardware makes no sense. Access to cloud services - yeah, renting makes sense. Stuff on my own hardware - nuh-huh, I'm not renting any software.
 
astyle said:
Isn't Visual Studio Code free of charge? Last I checked, it supports nearly every conceivable language via free plugins. And lots of tools, too - pretty much a complete toolchain, if you know how to set it up.
Click to expand...
For the sake of clarity. I'm sure astyle knows - VSCode != Visual Studio. I interviewed a contractor once who claimed to know Visual Studio. We hired him for a gig. I ended up coaching him over the phone on how to use VS.2017. He honestly thought they were the same thing. A bit like thinking Java and Javascript are the same thing.

For FreeBSD, I'd be okay with using VSCode if I could figure out the extensions to make it useable. Four years ago I used VSCode with Rust but really I was working in a shell window captured in the IDE. I don't know if this is still true today, but you could install VS but not activate it with a license key and still have access to all the command line tools. This was useful for CI/CD workflows. I should make a trial run of VSCode on Windows. Muscle memory will make that a bit painful.
 
elephant said:
I'm sure astyle knows - VSCode != Visual Studio.
Click to expand...
Yeah, I do know that. Tried both, BTW. Not only is VSCode slimmer than Visual Studio, the former is also a bit easier to get started with.

As for interviewing for a programming gig - I do continue to be flabbergasted at how people get cushy salaries just for throwing dust into the people's eyes, and can get away with just pretending to know something when they actually don't. That pretense eventually bites everybody when it comes to getting anything of substance actually done.
 
Ctags does not understand a Makefile, therefore it doesn't know what exactly is included from where.
What these IDEs do is index the project using LSP client with the definition of right include paths deduced from a Makefile.

Can you do that on a CLI setup, possibly, I don't know. I think there is a tool missing, that parses Makefiles into command line options for the code indexing tool.

Sometimes, scratch that, most of the times in commercial C/C++ dev capacity one works on an already set project. You might get a nice Makefile or autotools project that relies simply on having system packages for deps, sometimes you will get a very fat Conan/CMake/Ninja "modern C++" thing. Whoever worked with Conan knows it is not a simple thing to configure IDE's static include paths config against that abomination, let alone configure different files/modules against various deps in there. And they will change when the package update happens.

Right tool for the right job applies here too.
 
Zare fair point, but the few different IDEs I've used would let you specify include paths for a project and the $WORK stuff had code in a tree, so it had all the includes and "code" in it. Just start at the top and recurse down.
Standard system level includes, I've never found them interesting enough to include.

My biggest issues with every IDE I've used are:
Force you to lay out code in specific manner. This is fine if you are starting from zero and you take advantage of templating, but if you are picking up a project with thousands of files you spend more time setting things up.
Indexing. Yes, this has to be done, but I've had significant lags when it kicked in as a background task.
And if you are using git, anytime you do a pull to update tree, you trigger indexing.
 
mer said:
My biggest issues with every IDE I've used are:
Click to expand...
I can't really agree to that. Indexing, for example the complete RTEMS code base, takes not that long to start with. KDevelop knows what a makefile is and offers the build targets to be made in the IDE, also the project gets imported from a raw directory. The indexer can take some time, but it is multi threaded and works in the background. And it indexes files which are changed, not the whole set.

But it can be a problem, sure. I once wrote a program to set up project files and workspaces for codelite from a source tree, because that thing really does not do that right.
 
JohnK and mer , it is not about specifying an include path. I am depicting a scenario where there is no joint, correct, include path. The .c files have respective -I set, with different values. The LSP is configured with compiler execution arguments per each file.

E.g. you #include <stuff.h> in things.c, but depend on the build system to pass in the proper -Iinclude/amd64 for things.c as you have stuff.h in multiple directories.

From my own experience, using manual indexers on large projects, and I've used many, is going to be a half solution. First of all, I really need to say here, I don't need indexers for small to medium sized libraries. I can do that on my own, I need it for large stuff. From my real world example, Intel DPDK library. Go on, try to index it with ctags, cscope, SourceNavigator-NG, Sourcetrail, whatever. You will only get partial code resolve out of it, and when you go forward on the symbols - stuff.h - you will have to manually pick up the one of many directories, yet the code is already deterministically configured to use one.

Kdevelop and other C++ ides do not force you to structure your code. Even Qt Creator can be used for generic projects.

Best way to use Kdevelop is to manually set up your "hello world" via Makefiles or CMake. And then import it to Kdevelop.
When you work in the IDE and right click to add a file in the source, the file is not added to the build. You do that manually.
The Kdevelop's "responsiveness" needs some work, the parse errors tend to linger on, sometimes it sends the line to LSP while I'm typing, etc.

It takes Kdevelop about 5 to 10 minutes to parse serveral GB of sources the project I'm working for on $dayjob.
 
Crivens said:
I can't really agree to that. Indexing, for example the complete RTEMS code base, takes not that long to start with. KDevelop knows what a makefile is and offers the build targets to be made in the IDE, also the project gets imported from a raw directory. The indexer can take some time, but it is multi threaded and works in the background. And it indexes files which are changed, not the whole set.

But it can be a problem, sure. I once wrote a program to set up project files and workspaces for codelite from a source tree, because that thing really does not do that right.
Click to expand...
Now my issue with indexing could be related to the "time frame" roughly 1o to 15 yrs ago and the state of hardware $WORK had given me and the IDE maybe wasn't that smart about it.

anyway, if using a specific IDE makes someone more productive/work better/less stress, that's fine. I've learned, that for me, I'm more productive with a few term windows, emacs or vi and grep.
 
The big problem I have with OPC (other people’s code) is the crappy formatting that makes it hard to follow.

I spend so much time cleaning up this tripe that it takes a long time before I get anything done.

There is no reason to not write readable and commented code. The compiler does not care.
 
You must log in or register to reply here.
Back
Top