And languages like Javascript or Rust have their own management tools like npm or cargo which are shipped with the language environment. CLion is good but is proprietary software.įor Java this is solved by having widespread support for simple and unified buildsystems like maven which are well thought through. Visual Studio or XCode are great, but only work on a single machine. License restrictions, personal preferences, and simply cross plattform availability. That said, there are C++ IDEs, but if you use them everyone in your team needs to use them (because a general buildsystem is of the table) which of course has other implications. So all you are left with is an editor that is configurable to your C++ project (like using clang-completion and stuff), and this already exists, Emacs, Vim, VSCode, there is nothing an IDE could do better than a good editor for such projects. the buildsystem and project configuration. So if you have an "IDE" it can't really integrate the most important part of your "Development Environment", i.e. But as your buildsystem is a literally a turing complete scripting language, this is simply computationally impossible, so long story short, such an IDE can not exist. So if you wanted to use an IDE, this IDE needs to be capable of parsing this buildsystem and somehow find out how you configured your project (search paths, defines, etc.) and also make smart changes to this when you configure your project. To handle this clusterfuck of a buildsystem you started of with makefiles but soon realized that this is not enough so you either write a configure script using Bash, generate one using Autoconf, or if you are a little less old fashioned use CMake. On Linux you might use GCC and GDB and for Apple you will use the Apple version of Clang with LLDB. For windows you use MSVC++ compiler and the corresponding debugger. Now let's say you have a C++ project for Windows, Linux and macOS. With using an IDE you are binding yourself to what this IDE can understand. C++ has by design some base complexity, so the rapid in RAD is already off the table.Īlso C and C++ have a "difficult" relationship with IDEs in general, because of the very different tooling available. The design of a language has profound implications on what it's strength and weaknesses are. For example, there is no concept of Method pointers in C++, there are only function pointers to this call functions. Not and Java which is why there are RAD tools available for these languages too.Ĭ is a language developed for one reason, kernel development, which is the pure opposite of RAD, looking at C++, there is QT with the QT-Creator, which tends more into the RAD direction, but as with C, the main niche C++ occupies is not rad development, which is somewhat understandable, because the language design of C++, it's strength and weaknesses, are not so well suited for RAD as for example C# or Pascal. Pascal as a language was steered into the RAD direction by borland, it also heavily inspired. Same is also true for example for Python. Simple, C++ is not used for RAD development, thats why there is no real RAD IDE for it. People always rant on this forum about delphi compatibility, but I think having an example that large groups of people looked up to was a really major, major factor (and TP compatibility before it)Īnd of course ONE whole Pascal RAD in 25 years might just be a statistical anomaly Some are that the free C/C++ compilers are tied to Unix, and thus are often tied to Unixy environments like cygwin and mingw on majority target Windows.Īnd Windows centric C++ users simply use free VS that allows you to deploy free GUI applications (contrary to Delphi that costs several thousands and the free version of which has license restrictions and is sometimes complex to get)Īnd to succeed you really need to keep all the noses pointed in the same direction. Some problems are inherently C++, like the need for complex project management since you need more than " CC mainfile" to compile a C++ project. I don't really know why there is not something equivalent. Many C++ IDEs exist, but the integration beyond code editing, navigation is usually poor, and design is even less, staying fancy editors and not much else. If that so, C++ users would stodgily refuse to use VIM because it is too advanced and gotten to bloated and stick to ED.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |