> - Splitting a program into more than one source file opens up a whole new 
> world of pain. (Especially if you don't have the benefit of automake.)

You don't have to do this, and for tiny programs it's probably not needed. 
For larger programs I cannot begin to imagine how inefficient it would be to 
have it all in one file, let alone when I want to reuse an existing class in 
another project.

You sound like you need to get a decent book on C++ (NOT C) and get a modern 
IDE (Visuall C++ Express will let you do standard C++ without any .net stuff 
and is free).

Of course if you're stuck writing a whole program in one C file in notepad 
things are gonna suck big time.

Post a reply to this message

scott wrote:
>> - Splitting a program into more than one source file opens up a whole 
>> new world of pain. (Especially if you don't have the benefit of 
>> automake.)
> 
> You don't have to do this, and for tiny programs it's probably not 
> needed. For larger programs I cannot begin to imagine how inefficient it 
> would be to have it all in one file, let alone when I want to reuse an 
> existing class in another project.

The point is, as soon as you have more than one source file, you have to 
manually write header files, manually keep them synchronised with the 
source files, manually figure out the dependency tree, manually compile 
everything one at a time, manually recompile stuff as needed, and 
manually link it all at the end. Get any single step wrong, and at best 
you'll get an incomprehensible linker error; at worst you'll get a 
segfault. Good luck every figuring out why.

If you have automake, a few of those tasks become automated. But 
seriously, I'm used to having a language where you say "compiler my 
stuff" and it hands you a runnable program.

> You sound like you need to get a decent book on C++ (NOT C) and get a 
> modern IDE (Visuall C++ Express will let you do standard C++ without any 
> .net stuff and is free).

I've seen more adverts for C than for C++ (although there certainly seem 
to be quite a few for C++ as well). I think I might still have VS 
installed on my PC at home. I guess it's just finding the motivation to 
use a language which is over-complicated, unsafe and difficult when I 
could instead use one which is clean, simple and easy...

> Of course if you're stuck writing a whole program in one C file in 
> notepad things are gonna suck big time.

Actually, Borland's TurboC for DOS IDE. (Or, alternatively, Vim under 
Linux.)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> The point is, as soon as you have more than one source file, you have to 
> manually write header files, manually keep them synchronised with the 
> source files, manually figure out the dependency tree, manually compile 
> everything one at a time, manually recompile stuff as needed, and 
> manually link it all at the end. Get any single step wrong, and at best 
> you'll get an incomprehensible linker error; at worst you'll get a 
> segfault. Good luck every figuring out why.

  Do you honestly think that an IDE like Visual Studio is not going to
automatically create project dependencies for you?

  In the Unix side of the world knowing a bit of makefile syntax gets you
a long way. It's even possible to create a makefile (at least when using
gnu make) which automates mostly everything, including resolving dependencies.

  And for a small project a simple "g++ *.cc -o myprogram" will do just fine.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Oh, I have a far bigger "problem" than that: C is the number one 
> language requested in job adverts. :-(

  I feel your pain because I hate C (but for different reasons than you).
See http://warp.povusers.org/grrr/HateC.html

  Your problem is that you project your C prejudices onto C++ as well,
and simply refuse to learn the tools C++ offers to make your life easier.
In a past thread I tried to teach you a few things about C++ which make
it a lot easier to write small programs quickly, and for a moment I thought
that you had actually learned something. Then some time after that you wrote
a new thread where you showed your attempts at writing something and it
seemed like you forgot or ignored *everything* that I had tried to teach you.
At that point I completely lost hope.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Do you honestly think that an IDE like Visual Studio is not going to
> automatically create project dependencies for you?

It's not entirely clear to me that the source code alone actually 
provides enough information to do this.

Presumably it's simple enough to figure out which source files depend on 
which header files. Not sure how you proceed from there though.

Post a reply to this message

> If you have automake, a few of those tasks become automated. But 
> seriously, I'm used to having a language where you say "compiler my stuff" 
> and it hands you a runnable program.

VS does most of that for you too (you just press F5 and it compiles and 
links the lot, automatically only compiling files that have changed since 
the last build), and you don't need to have separate header files if you 
don't want to.  A lot of people just find it makes more sense to have one 
file that neatly shows the interfaces and another to actually contain the 
implementation code.

> I guess it's just finding the motivation to use a language which is 
> over-complicated, unsafe and difficult when I could instead use one which 
> is clean, simple and easy...

From my point of view Haskell looks over-complicated, difficult and slow, 
but I suspect that's just because I haven't bothered to learn much about it.

Anyway, the motivation for you is all those job adverts you say you keep 
seeing...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:

> >   Do you honestly think that an IDE like Visual Studio is not going to
> > automatically create project dependencies for you?

> It's not entirely clear to me that the source code alone actually 
> provides enough information to do this.

  Why wouldn't it? If a source code file needs another source code file,
it will #include it, and the IDE sees that and creates a dependency.

  If you don't #include another source code file then there is no dependency
between those two files.

-- 
                                                          - Warp

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> From my point of view Haskell looks over-complicated, difficult and slow, 
> but I suspect that's just because I haven't bothered to learn much about it.

  My problem with Haskell is that it's hard to learn. It's like it's 1% of
syntax and 99% of "clever" tricks which you just have to learn from somewhere
(often by word of mouth). And these tricks are often rather exotic and
unintuitive to an imperative/OO programmer.

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
>> If you have automake, a few of those tasks become automated. But 
>> seriously, I'm used to having a language where you say "compiler my 
>> stuff" and it hands you a runnable program.
> 
> VS does most of that for you too (you just press F5 and it compiles and 
> links the lot, automatically only compiling files that have changed 
> since the last build), and you don't need to have separate header files 
> if you don't want to.  A lot of people just find it makes more sense to 
> have one file that neatly shows the interfaces and another to actually 
> contain the implementation code.

Now that's interesting.

1. How does it know which files depend on which other files?

2. A header file is what defines what can be accessed from outside a 
given source file. Without a header file, how do you determine what's 
supposed to be public and what isn't?

>  From my point of view Haskell looks over-complicated, difficult and 
> slow, but I suspect that's just because I haven't bothered to learn much 
> about it.

To use Haskell, you need to learn something like half a dozen basic 
principles. After that it's just figuring out "OK, how the hell do I 
perform task X?" Learning C++ it just seems like learning feature after 
feature after feature, seemingly without end. (C is a lot simpler, it's 
just astonishingly easy to shoot yourself in the foot with it.)

> Anyway, the motivation for you is all those job adverts you say you keep 
> seeing...

Yeah, but let's think about this. I could spend a few months failing to 
learn C++. Hell, maybe I could even write a small program that actually 
works. But I'm up against people who have coded in nothing but C++ since 
they were 9 years old. I don't really stand much of a chance here...

Post a reply to this message

Warp wrote:

>   My problem with Haskell is that it's hard to learn. It's like it's 1% of
> syntax and 99% of "clever" tricks which you just have to learn from somewhere
> (often by word of mouth). And these tricks are often rather exotic and
> unintuitive to an imperative/OO programmer.

I must concurr with Warp here on the "not written down anywhere" part. 
People are doing a lot of very cool stuff with Haskell, but it can be 
maddeningly hard to find answers.

(E.g., somebody implemented a Doom clone in Haskell, and wrote a paper 
explaining how they did it. Except that the paper is utterly 
incomprehensible. It makes no sense at all. It's so badly explained that 
I just can't follow any of it.)

Actually, I think Warp's assessment of Haskell is about right. Haskell 
is like Go. The "rules" are simple, but the "game" is not.

Post a reply to this message