Why do people use Command-line instead of IDE? [closed] - c++

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Hi I am learning C++ and at the very beginning used a Command-line... then I started using Xcode (and since then couldn't switch back to command line) and was just wondering some specific reasons/situations to use Command-line instead of IDE...

More efficent for large systems -
Try opening a VS solution with a 100 projects and 10,000 files.
Simpler for a lot of tasks, you edit in one window, run make in another, have gdb in a third.
Easier to automate tasks, often easier to work in teams or cross-platform if everyone has gcc and vi (or emacs)

A big one for me is the editor. I really love vim, and it's pretty rare that an IDE has good vim emulation - especially since I use dvorak and have to remap a lot of the keys. For a lot of other people, they'd say the same thing except that they'd choose emacs.
Most IDE editors pale in comparison to the like of vim or emacs. There are features that you miss out on or are a lot harder to get to work well. For instance ctags definitely helps you be able to hop to the definitions of functions in vim, but it is nowhere near as good as a lot of IDEs can do since they actually understand the language. And of course, debugger integration and project management and the like aren't going to work as well in vim or emacs because they're not full-blown IDEs (though you can do a lot of that stuff with them). But often, the power of vim or emacs overshadows whatever the IDE has over them.
Also, as far as command-line editors go, they can be run on the command-line when you don't have access to an environment with a GUI, so there are plenty of situations where that flexibility is a big plus.
Of course, it would be great if you could combine all of the great features of vim or emacs with a full-blown IDE - and there are some attempts to do so - but there are always problems with it, and even the best attempts are far from perfect. So, you're often still stuck with the choice of vim or emacs and the features that they bring or an IDE with the features that it brings.
EDIT: Going into why vim or emacs is far more powerful in many respects than your typical IDE could get quite lengthy, and there are already several questions on SO which cover that.
This is a great answer on emacs: https://stackoverflow.com/questions/35809/why-are-vi-and-emacs-popular/35929#35929
This is a good article on vi that seems to get linked to frequently: http://www.viemu.com/a-why-vi-vim.html
For a quick attempt on my part to give some reasons why vim is more powerful:
Your typical IDE is basically a souped up notepad from a text-editing standpoint. You type in text and use your mouse to navigate around (which while sometimes quite useful, it can be quite a bit slower than just using your keyboard). They add code-specific features like code completion, automatic code indenting, the ability to jump to function definitions, refactoring tools, etc. (hence why IDEs can be so useful) But their basic text editing abilites are generally pretty poor. They might add some useful features like ctrl+d to delete a line, but what they add is generally very limited compared to what you'd get in vim or emacs.
Take deletion (a very basic operation) as an example. In vim, you can use the delete operation with any motion command, making for a potentially staggering number of ways to delete things.
dd Delete an entire line.
5dd Delete 5 lines.
dj Move the cursor up, deleting everything to the left on the current line and everything to the right on the line above.
dG Delete everything from here until the end of the file.
7dgg Delete everything between here and line 7.
d% Move to the brace or paren which matches the next paren or brace (whichever comes first) and delete everything between here and there, including the brace or paren that you jump to
dw Delete everything between here and the next beginning of a word
de Delete everything between here and the next end of a word
D Delete everything between here and the end of the line
d0 Delete everything between here and the beginning of the line
d^ Delete everything between here and the beginning of the first word on the line
dty Delete everything between here and the next occurrence of y on this line (or nothing if there are no y's between here and the end of the line)
The list goes on and on. And that's just for delete. The same goes for a whole list of other basic commands. And that's just basic commands. There are many, many more commands which are more advanced and quite powerful. Vim can do so much that most people who use it use only a fraction of what it's capable of.
Most IDEs don't even have a fraction of a fraction of such editing capabilities. They have many other programming-specific and language-specific features which vim and emacs either lack or in which they are much harder to get to work - such as good, context-sensitive code completion, refactoring tools, project management, etc. But as for text-editing capabalities, most IDEs just can't compare.

At least in UNIX, the command line tools are mature. The bugs I have to deal with are highly obscure at this point. vi, make, gcc, gdb - these tools are, in some cases, 20 years old or more. Tried, tested, proven.
Also, they are ubiquitous. Everyone has vi, make, gcc. I don't have to worry about not having my tool-du-joir. I can go to virtually anyones box, and no problem, I can compile, write, debug without any need to learn some fancy tool.

First, there's the increased choice. If you use an IDE, you use the tools that are specifically compatible with it, which may not be the tools you prefer. There are a lot of things that you can get in an integrated package or as components, and people go both ways.
Second, lots of developers got used to Unix tools, which are mature, very powerful, and meant to be used by themselves. There isn't a tradition like that on Microsoft Windows, and IDEs have ruled there since Turbo Pascal. (The big advantage Turbo Pascal had was that, in the days before any sort of multitasking, it wasn't necessary to start and stop the editor, then run the compiler and linker separately before running the test.)
Third, it's really, really easy to automate anything you'd do from a command line. It's harder to do such things in a GUI of any sort, both in that the tools are much harder to develop and in that they're harder to learn. Again, there's a culture gap here, as the Unix tradition is to deal with complicated procedures by automating them, and the Microsoft tradition is to build GUIs and wizards.
Fourth, for handling complicated systems, there's still no method clearly better than a human-readable text representation. The syntax of Unix makefiles is bad, but it would have avoided the issue I had recently, where the configuration of an after-build step in one setup of a Visual C++ project file was wrong in one case, and it was hard to spot. Using a makefile and vim, I can simply and reliably change how a given project will compile and build. It's a lot harder with Visual Studio.

You use command line when you want to automate your software builds. That's typically done when you are ready to release your software, and you need to do other things such as installer packaging in addition to software compilation before you can deliver the software to the users.
Beyond that you should always use an IDE for debugging, compiling and code editing purpose.

Commandline builds can be automated, and using standard tools such as CMake for your commandline builds make such builds cross-platform (note you can build an Xcode project from the commandline using xcodebuild, but that only works on Mac OS X with Xcode). Automation is incredibly important, because it allows you, for example, to create a "hook" for your version control system to build the project and reject code that doesn't compile or to have a continuous integration server periodically build your project, so that you can easily tell when breaking changes to the code have been made and fix them quickly.
In addition to portability and automation, the commandline is just faster. If you are using a Makefile project or something like the C++ Project Template which uses CMake but has a Makefile wrapper, then all it takes is the simple command "make" to build. The second time you build, you only have to hit the up arrow, and then hit ENTER for it to rerun "make". Although beginners with the commandline may be not be very fast and may find the GUI / IDE easier, once you have used the commandline for a while, it becomes much much faster than doing it with a GUI, and all those mouse movements and clicks seem slow and a waste of effort.

Related

As of 2011: Netbeans 7 or Eclipse Indigo for C++?

This is basically a duplicate of:
Netbeans or Eclipse for C++?
But, that question as 3+ years old, and a lot has changed since then.
I have a large code base with a custom (but Makefile based) build system. The areas I am specifically wondering about include:
Syntax highlighting
Code navigation.
Code hints.
"ReSharper style" code helpers.
Documentation integration.
Debugger UI and features.
Has anyone had the chance to evaluate both Netbeans and Eclipse?
EDIT: As a followup question, are any of the Netbeans users here concerned with its future given Oracle's recent bad history with "open" efforts? (Open Solaris, MySQL, Open Office)
Thank you
I cannot comment on eclipse, but on netbeans 7 I will say things that are very important for me and that work fine so far:
code completion, go to declarations
pkg-config automatic include management for parsing
stuff that sometimes works and sometimes don't
find usages, sometimes it might fail to find usages in other open projects
debugger sometimes gets confused with unittest-cpp macros and it will not go on the appropiate line
stuff that are not yet working and i care deeply:
C++0x syntax highlighting (auto, lambdas, enum class, variadic templates, none of them are recognized by the built-in parser)
stuff that is not quite working but i could not care less:
git integration. I enjoy using git from command-line so this is a non-issue
in all, the IDE is very usable. I hope to have a chance to try out latest cdt on Indigo Eclipse, but so far i haven't that much of a real reason to investigate
I cannot comment on Netbeans, but I can offer you information on Eclipse. I work with C++ on UNIX systems, and I have started to use Eclipse when exploring large code bases that I know little about. I don't use it to build, but it would be easy to integrate our build system with it as one only needs commands.
Eclipse has most of what you are looking for: (I'm speaking of Eclipse/CDT)
Not only can you completely customize your syntax highlighting, you can also have it format the code with templates. My company has a code standard for spacing, tabs and formatting of functions and conditional code, and with little effort I was able to modify an existing template to meet our code standards.
The navigation is not bad, if you highlight and hover over a variable, it shows you the definition in a small pop-up bubble. If you do the same for a type, it will you show you where the type is defined. For functions, it will show the first few lines of the implementation of the function, with an option to expand it and see the whole function. I find all of these nice for code discovery and navigation. You can also highlight a variable, and use a right-click menu option to jump to its declaration.
I suppose by code hints you are referring to something like intellisense? This is the main reason why I use Eclipse when looking over a large code base. Just hit the '.' or '->' and a second later you get your options.
The debugger UI is quite capable. You can launch gdb within the tool and it allows you to graphically move through your code just as you would in a tool like ddd or Visual C++. It offers standard features like viewing registers, memory, watching variables, etc.
That being said, I have found some weaknesses. The first is that it doesn't really strongly support revision control systems outside of CVS and SVN very easily (integrated into the GUI). I found a plug-in for the system we use at my company, but it spews XML and Unicode garbage. It was easier to just use the revision control on the command line. I suspect this is the plug-in's issue and not Eclipse. I wish there were better tool integration though.
The second complaint is that for each project I have to manually setup the include directories and library paths. Perhaps with an environment variable this could be circumvented? Or I may just do not know how to set things up correctly. Then again if it is not obvious to a developer how to do this, I consider that a weakness of the tool.
All in all I like working with Eclipse. It is not my main editing environment, but I appreciate it for working on large code bases.
I'm a huge fan of Netbeans. I am in a similar situation to yours, but creating the project was very easy. Just point Netbeans at where the code is checked out and it figures out most things for itself. I rarely have to do any configuration. One thing to note though, if your tree is very large, it can take some time to fully index - and while it does, memory and cpu will be hosed on the box.
The integration with cvs is awesome, and the Hudson integration is very cool for CB. I've not used Git myself, though I should imagine it's a no-brainer.
One thing that does irritate me no end is that it does not behave very well with code relying heavily on templates. i.e. shows lots of warnings and errors about types not being found etc.
I have not used the latest version of Eclipse, I tried the major release before the current one and gave up because it did not have the same smooth project integration with the makefiles etc. I find it's not as nice if you don't want to use it's make system - though I could be wrong.
I don't use any of the code formatting provided, I instead prefer something like AStyle instead. I know that NetBeans does a good job with Java - but have not used it for C++. CDT I seem to remember doing some odd stuff with indentation when formatting C++ code - esp. if templates are involved - but that was atleast two years ago.
Hope some of it helps - the best way to do this is to download and try for yourself and see what works for you. Anything we tell you is purely subjective.
I used to work with Netbeans with MinGW, I Just tried 7.0.1.
I currently use Eclipse Indigo with CDT and MinGW - It's better performance wise (less CPU & Memory).
Netbeans creates a makefile to compile all the time,
In Eclipse you can build directly with the CDT-Toolchain or use Makefile - Eclipse is more flexible.
Debugging: Netbeans might be better in Solaris/Linux.
I Personally rather eclipse over Netbeans, I think eclipse is more professional.
One particular issue that causes me quite a lot of grief with Netbeans 7.0 is that it tends to want to work with utf8 files, and not all of out c++ projects are utf8. It will issue a warning about opening such a file, and if you do open it, will corrupt said file, which is a pain.
I've not found out how to properly make netbeans handle this. Apparently the encoding can be changed, but for the entire project. So presumably changing it to us-acii would stop this problem, although non ascii characters wouldn't display properly.

Is there such a thing as a C++ interpreter? [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Have you used any of the C++ interpreters (not compilers)?
Hi,
I am currently learning C++ and a beginner in programming in general. I've been trying to write some code to a few programming problems from the book I'm using. What I find is that often I make mistakes in what I write and those mistakes come up when the program is run. Its usually quite obvious where in the program I've gone wrong when there is regular output. But in a long computation I'm often not sure why a particular code has acted a certain way. I've also looked at Python recently. Python works with an interpreter, which can take any piece of Python code and compute its output.
I was wondering if there was something similar for C++. Right now when I want to check a line or block of code I have to comment out a lot, save it, compile it, and then run it from a command line. And I have to do that many times for a single error until I've solved it. Is there a way to type code into an active terminal which would run code and show me output? What would be better still would be a way to select a block of code (like you select text) or multiple blocks (to see how a function is being handled) within the IDE and click run to run just that block of code and see its output without having comment out irrelevant lines or to save the file. The compiled code could just reside in memory.
CINT is a c & C++ interpretter that accepts nearly all valid C++. Unfortunately many Linux distros do not offer it, and you'll probably have to build it from source... and that is a non-trivial task.
Typically a debugger is used to step through code line by line, starting at a chosen breakpoint, and keep watch of all variables/values.
Unit testing is a technique to test smaller pieces of code.
A stepping debugger, as found in most IDEs will help you with this.
Here (for example) is a description of how to set the Execution point in In Visual Studio, which sounds like what you want to do.
For certain situations, the "Immediate Window" may be of use to you. It allows you to type in expressions to evaluate immediately.
Rather than just running individual lines independently, or relying on print statements to tell you the state of whatever variables you have decided to print, you can use the debugger to run to the point of interest (where you will have set a breakpoint), then you can examine the state of any in-scope variables, or even alter the normal flow of the program.
There are some solutions that try to do this - the ones I know are Ch and TextTransformer.
However, I doubt that this works very well. C++ is not at all designed to run as an interpreted language.
One of the problems is that C++ is very, very hard to parse. And this makes it very hard to provide certain types of tools that are usual for other languages. For example, I don't think there is any C++ refactoring tool that really works well.
C++ is a compiled language not like python. But there are few c/c++ interpreters out there but not sure about their features. Check these out: Ch interpreter and CINT
If you really want to learn c++ please do not use the c/c++ interpreters.
If you insist on using a interactive interpreter there is since a long time CINT which is the default interpreter used in the ROOT project. It got better over the years, but still has only limited capabilities when dealing with templates. Also, there is a move to replace it with a JIT compiling interpreter based on clang inside the ROOT project.
If I were you I would learn how to run compiler and an interactive debugger like suggested in some comments already.

How often will a programmer be asked to write a makefile file? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Is makefile an advanced problem or a general problem for a programmer?
For a C++ programmer, how often will he be asked to write a makefile file?
Nobody ever writes a Makefile. They take an existing Makefile and modify it.
Just be thankful you don't have to deal with IMakefile. (For those of you who were lucky enough to never deal with this, or who have managed to forget, IMakefile was a file that was sort of a meta-Makefile for X Window System based projects which would be used to generate a Makefile that knew where you'd installed all your X Windows libraries and binaries. Needless to say, it sucked.)
Setting up a meaningful build system is part of the craft. I'd expect any non-super-junior developer to be able to come up with a makefile.
As often as he is asked to start on a brand new project, which is not similar to an existing project whose builds scripts can be adapted. That is not a good answer I guess, but in my experience there has always been some code/resources/build scripts that I can adapt.
On a different note, for any C++ programmer, it is important to learn how his code is built. Makefiles, Ant scripts etc are just the implementation mechanism. So I think it is important enough to learn.
Programmers need to know how to build their projects. Typically (in my experience) the 'production build' is based on the original programmer's makefile. Many programmers go their entire careers just fumbling blindly when putting together their makefiles, but every programmer has to do it.
I have never thought of makefiles as problems, they are quite usefull...
The frequency would depend on the platform that you're using and your role.
For example, in some organizations there is a fairly fixed build file that doesn't often change, while in others there are frequent changes. Some organizations rely on the IDE to deal with the build, etc. You don't have to be the build engineer.
I think that most C/C++ developers should have at least some fundamental understanding of how makefiles work, though they don't have to be gurus. In my alma mater, that is part of first-year CS.
One thing to note is that, if the build system is set up in a modular way one practice isn't to build one huge makefile for the whole thing but makefiles for bits that can be called from the master makefile recursively. This is a great feature as it means different products (libraries?) can be built as separate units, often in parallel.
Makefiles are designed to automate the build process. Therefore, they are most definitely not a chore; they save you writing gcc -c *.c etc all the time. Not only that, but a properly written makefile has phonies for clean, rebuild etc. On most of my projects, make rebuild does exactly that - cleans everything and starts again.
Makefiles are really useful. I can't say that enough.
Even if you are using an IDE that deals with the details of building the project for you, makefiles can still be very useful. Occasionally you need to have some extra functionality as part of your build process, for instance to run a pre-processing step to generate a c++ file programmatically (if you use Qt then you may need to run moc on your header files or rcc on your resource files. You might need to process an .idl file to generate an implementation file), or as a post-build step to copy files to a destination. In these cases you typically have two choices:
run the scripts as pre- or post-build steps every time, which means the app will be rebuilt every time you build it
create a makefile to perform the action which will embody the dependency rule so that the step will only be invoked if the timestamp of the input file is newer than that of the output file. Building a project that is already up to date will do nothing
A C++ developer may go for many years without needing to create a Makefile if they're not working on Linux/Unix, but a decent developer will seek to understand how Makefiles work as they will probably improve part of your current workflow.
I suppose it depends...
Personally, I am quite mesmerized by the syntax of Makefiles. Doing any kind of even a simple operation on the paths of the object is ever so tricky.
On the other hand, being able to build is just necessary, and understanding the various arguments on the compile line is too. Though perhaps not for a junior.
I had to rewrite the build system of our application barely a year after I left school. I did it using scons and it worked great. Build time went from 1h30 to barely 10m because I was finally able to have parallel compilation and put an automatic local replication of the libraries used in place.
The morale is: if you ask someone to pick up a build mechanism, do not force Makefile on him. Let him pick a more recent tool.
A powerful part of make is the shell code that you can write in each rule.
So not only learning make is important, but understanding a shell language like bash and applying it to a project is very useful
It depends on the tools/libraries/frameworks you are using for your project. For my job I code using Qt so I never have to write a Makefile as qmake does it for me although I do have to know how to create a qmake project file instead.
I freely admit I probably couldn't write anything beyond the simplest Makefile without having to learn it all from scratch. I don't see that changing anytime soon as I would only learn it if I was forced to. Why learn something you may never need?
I haven't been asked to write a makefile in the last five years. Sometimes I could modify an existing makefile.
But when you have tools that make the job without the make program, it's not necessary to care for makefiles. Regarding your question, when a C++ programer has been asked for writing such a file: It depends.

How do I automatically clean up code in C++?

I'm working as a TA in an introductory programming class, and the students tend to submit their programs as either one line, or without any indentation. Is there any tool that allows me to insert indents and things like that automatically? (We're using C++ and VisualStudio)
You're after a pretty printer. I'd suggest Googling for C++ pretty printer, and looking for something that meets your requirements (price, platform).
As an aside, you may find that deducting marks for poorly formatted code will work just as well. Students need to learn that good code layout is an important part of writing maintainable code.
Rather than answering your question I will advise:
Don't let them do that.
Making their code readable for human beings is a part of programming, and you are fully justified in grading them on it. You might want to point them at the pretty printers listed in the other answers, however. Just to be nice.
Select the entire file (Ctrl-A) and then hit Ctrl-K Ctrl-F, which is essentially format the entire document.
EDIT: Of course in Visual Studio IDE
There is a gnu program called indent, usually shipped with linux but also available here (gnu indent) and available under Cygwin.
However, you are using VS, so you could use it to format code. They have hidden the feature just a bit: Edit -> Advanced -> Format Document, or Control/E, D.
If you need to do this in batch mode, try using astyle, also available in the Cygwin installer.
In Vim it's gg=G.

Autocompletion in Vim

In a nutshell, I'm searching for a working autocompletion feature for the Vim editor. I've argued before that Vim completely replaces an IDE under Linux and while that's certainly true, it lacks one important feature: autocompletion.
I know about Ctrl+N, Exuberant Ctags integration, Taglist, cppcomplete and OmniCppComplete. Alas, none of these fits my description of “working autocompletion:”
Ctrl+N works nicely (only) if you've forgotton how to spell class, or while. Oh well.
Ctags gives you the rudiments but has a lot of drawbacks.
Taglist is just a Ctags wrapper and as such, inherits most of its drawbacks (although it works well for listing declarations).
cppcomplete simply doesn't work as promised, and I can't figure out what I did wrong, or if it's “working” correctly and the limitations are by design.
OmniCppComplete seems to have the same problems as cppcomplete, i.e. auto-completion doesn't work properly. Additionally, the tags file once again needs to be updated manually.
I'm aware of the fact that not even modern, full-blown IDEs offer good C++ code completion. That's why I've accepted Vim's lack in this area until now. But I think a fundamental level of code completion isn't too much to ask, and is in fact required for productive usage. So I'm searching for something that can accomplish at least the following things.
Syntax awareness. cppcomplete promises (but doesn't deliver for me), correct, scope-aware auto-completion of the following:
variableName.abc
variableName->abc
typeName::abc
And really, anything else is completely useless.
Configurability. I need to specify (easily) where the source files are, and hence where the script gets its auto-completion information from. In fact, I've got a Makefile in my directory which specifies the required include paths. Eclipse can interpret the information found therein, why not a Vim script as well?
Up-to-dateness. As soon as I change something in my file, I want the auto-completion to reflect this. I do not want to manually trigger ctags (or something comparable). Also, changes should be incremental, i.e. when I've changed just one file it's completely unacceptable for ctags to re-parse the whole directory tree (which may be huge).
Did I forget anything? Feel free to update.
I'm comfortable with quite a lot of configuration and/or tinkering but I don't want to program a solution from scratch, and I'm not good at debugging Vim scripts.
A final note, I'd really like something similar for Java and C# but I guess that's too much to hope for: ctags only parses code files and both Java and C# have huge, precompiled frameworks that would need to be indexed. Unfortunately, developing .NET without an IDE is even more of a PITA than C++.
Try YouCompleteMe. It uses Clang through the libclang interface, offering semantic C/C++/Objective-C completion. It's much like clang_complete, but substantially faster and with fuzzy-matching.
In addition to the above, YCM also provides semantic completion for C#, Python, Go, TypeScript etc. It also provides non-semantic, identifier-based completion for languages for which it doesn't have semantic support.
There’s also clang_complete which uses the clang compiler to provide code completion for C++ projects. There’s another question with troubleshooting hints for this plugin.
The plugin seems to work fairly well as long as the project compiles, but is prohibitively slow for large projects (since it attempts a full compilation to generate the tags list).
as per requested, here is the comment I gave earlier:
have a look at this:
Vim integration to MonoDevelop
for .net stuff at least..
OmniCompletion
this link should help you if you want to use monodevelop on a MacOSX
Good luck and happy coding.
I've just found the project Eclim linked in another question. This looks quite promising, at least for Java integration.
I'm a bit late to the party but autocomplpop might be helpful.
is what you are looking for something like intellisense?
insevim seems to address the issue.
link to screenshots here
Did someone mention code_complete?
http://www.vim.org/scripts/script.php?script_id=1764
But you did not like ctags, so this is probably not what you are looking for...