Re: Learning C++
"Jorgen Grahn" <grahn+nntp@snipabacken.se>
What kind of fiddling was that? I use Emacs, Make, version control
and the Unix shell are my usual tools, so I have a hard time imagining
what those inefficiencies were.
In my terminology emacs is an IDE by most practical means...
When there are IDE-or-no-IDE discussions, the Emacs and Vim users tend
to be on one side and the IDE people on the other. But I see what you
mean -- you can drive Make and the debugger from inside Emacs.
I personally never learned to do that.
It really depends on the application. You can integgrate Emacs with other
tools, making it IDE. Or use VS as notepad...
If the editor does not soak up the build's error output one trivial source
of inefficiency is all the actions to navigate to look/edit the error
places. (All IDE's provide 1-key means of going through the list, and it is
a very common case in development).
(I should add that I *do* belive that one's editor must have a C++ mode.
People programming in Notepad or plain old vi *do* waste their time,
and also probably produce misindented code.)
LOL, especially as there is notepad2 that is suggested to replace the stock
notepad, is light, aware of many languages, pure joy...
When we talked 'normal editor' upstream I ormally associate with stuff like
that notepad2, the ones you mentioned are too deep WTFs to be worth arguing.
;-)
And the plain editor s okay for simple tasks, but as the project grow the
inefficiencies grow steeply.
As I mentioned upstream, using real browse info has a great edge compared to
just grep.
"fiddling" I mean extra time/effort spent on loading, reloading sources,
go
to desired locations (say where the compile error is), to watch related
code, etc. Also related documentation.
Never had any major problems with that in my environment. I also use
grep, Perl one-liners etc quite a lot on the command line -- I guess
IDEs only can offer some of those features.
To me IDE is just what the word means, integrated & environment. The point
is that you shall spend no ecess UI activity on feeding the external tools
and process their result.
Like navigating on all places of a certain function call is a 1-click
activity. Simple local or global find also has auto-pick text and history
for input and 1-click navigation. ('click' includes keypress not jsut
mouse)
Where using those requires extra actions, even as mnuch as copy/paste where
really avidable, I see inefficiency. But especially if all you get is a
textual list, and shall take actions to open the files and go to lines.
During all the usual cases -- primary code writing, review, raw-compile,
debug...
The Makefile can be an issue if you don't understand that it needs
to capture all dependencies (i.e. you have to have autogeneration
for them, using something like makedepend), or that you can rely on
the default *.cpp -> *.o rules. Once you have seen a decent
Makefile *once*, the problem is gone.
Pobably so -- but the alternative is to not have the whole problem set at
all.
You *do* pay a price for not using a C++-specific tool for building.
But you win the other things a Makefile offers, like building
documentation, running unit tests, installing ...
Whoever read me on this thread knows I'm in no way a bigot of one build
tool. :) Someone just recently wrote that you can integrate the other
translators without problem, so it is there, I once had .asm files, and
recall no problems to include them. but admit that the possibility is
there, and one may run into the case a built-in project manager handles
badly or not at all.
Then you have to deal with the problem of feeding back the build's
information. If that one solved, you're back to fine IDE, just with a
different build tool, aren't you? ;-)
If not, then it is a price. I'd probably look for solution to build the
renitent components separately. (As pre- and post build steps are
supposedly supported why not put the source generators and the dox/packaging
there, and keep the cpp compilation in? )
I wrote a lot more, but deleted it. I claim to have a good
command-line workflow, you claim to have a good IDE workflow. And
neither of us know what we're missing: I've never really used an IDE,
and to be frank I don't think your experience with MS-DOS is relevant
to a current Unix environment.
Well, I do have a deal od command-line experience, and spent like 3 years
recently on a big unix project -- many observations mentioned are right from
there. So I believe I can compare the things from both my personal work and
observations.
But if you have a good workflow and is content with the progress, the
results and the kind of activities you do, good for you. :)