Re: Learning C++
"Rui Maciel" <rui.maciel@gmail.com>
How do you start a small command-line app project in your IDE of choice?
New project -> Console app -> 'A hello word application' -> Finish.
Then press F5 and it builds and runs.
I do it quite often.
Without an IDE you just open a text editor and write:
<code>
int main(void){ return 0; }
</code>
Done.
Extreme amoun of redundant typing if you ask me. Ok, I forgot from above to
state the name, but it is common in both versions.
You don't need to click through a set of wizards, you don't need to clean
up any cruft that was automatically generated. You just code away.
There are certainly options for 'empty project' fro those who like type
main. And you can make your own wizard if have a pattern in usual work.
The stock selection in VS IME covers about anything usually done from
scratch.
If you wish to automate your build process (which you probably want) then,
if
you wish to rely on plain old make and use a custom makefile then you only
need
to open a text editor and save the following in a file named Makefile:
<code>
all: myapp
myapp:
g++ main.c++ -o main
</code>
Done.
Is that supposed to win over 0 (as in zero) typing?
Please someone take a little time and finally explain me the vitue of that.
I understand the case where the project is a complex build or has some
special way of tuning, but these cases just beat me. Completely.
(Certainly without IDE a caring person would IMO probably have saved a first
such empty project, and merely unzip it on use, but whatever...)
And as you wish to have a finer control on your project, the IDE will
become more and more of a bloated nuisance than a solution.
Worked for me for the last ~20 years. And on my list of nuicances it is
hardly a contender. (btw all versions before the last had option to export
makefile, so there is not even a lock-in.
If something is a nuicance, solve it. Addressing the specific way. What is
the point of the preemptive strike, to tune the build system for what
believed for version 4.0, when you may never go beyond the first? And pay
up the price up front?
You will be
gradually pushed to hunt obscure options in a vast sea of bloated dialogs,
all
of which force you to only use the set the options that the people behind
the
IDE thought were reasonable, which could easily clash with what you intend
to
do.
You make this up, do you? ;-) If you know the option directly just insert
it in the special field, and it will be used -- and if has representation in
some dialog will appear there by itself.
And do you mean that the excess complexity you are discovering is
something that is genuinely present in beginner's projects, or it is tied
to the project you (as a seasoned expert) were summoned?
I believe it is easy to understand that all the options that the IDE's
interfaces push into the newbie's eyes are a terribly (and needlessly) big
source of confusion. Emphasis on the "needless".
Guess those are the kind not taking the Tutorial tour.
I recall doing over the Scribble sample set that explains creating a MFC
application (with fairly fophisticated features too), along with showing
most elements of the IDE used.
All in a very thoughtful, step-by-step way.
Sun's IDE also came with that Freeway sample and tutorial on how to use the
debugger to fix a multi-threaded application, fow to profile, etc
I also encountered very fine books from Wrox tuned for all kind of public.
If a beginner just sits down and expects the IDE magically fill his head
with knowledge, no wonder he gets confused -- I mean he started pretty deep
being that way.
So until someone comes out with
something better, we're stuck with make as the simplest
solution: the easiest to learn and use.
This sounds like your bunch of make experts could manage the build of a
project that was not fit an IDE's idea. And found it easier too -- that
is
hardly surprising.
But I don't see how actual easyness follow.
With an IDE you are firmly wedged into what the IDE imposes on you and
what the
project templates support.
What means if your project fits a template -- that it too often does, you're
ahead. Whjen it doesn't you are on the same square as in the alternative.
The empty project is always there. And you can download additional
templates if the case is at least so common -- or capture yours if done
once.
On the other hand, if you rely on a text editor to
write your code then you are perfectly free from those hindrances.
This resembles the argument on how much burden having a million dollar is
compared to being poor. ( Which btw have some ground, but i believe I could
deal with the expected problems ;)
You don't
have any weird workflow forced on you and if you need to perform a task
then you
are free to use whatever 3rd party app you wish to adopt and which lets
you
easily accomplish your task in your own terms.
weird workflow ===> prejudice.
While if the workflow of certain IDE does not match yours, simply chose one
which does, or forget it. Chosing the *fit* tool is part of the
development work.
More than that, if meanwhile you
opt to replace some tool then you are also free to do so. You don't have
anything bolted down and, in fact, you are free to fully use your system
to your
own advantage.
And you can write anything in assembly, why we bother with all the other
languages I wonder. ;-) Why accept restraints instead of having the
absolute freedom and power? O,O
IMO if you come to production, and any non-trivial project, managing the
build is an expert area in its own right.
If your experience is limited to what is offered by an IDE then it is only
natural that you perceive "managing the build" as being an "expert area in
its
own right".
I have a huge deal of experience on quite many platform and project sizes --
that statement applies to cases of big and non-trivial projects.
Also spet some time debugging the build -- it is about as easy as find the
real source of a random crash in a big C application (caused by a hidden
race condition or dangling pointer or overrun). Resembles mur black
magic than science ;-)