Re: Programmer knowledge
From: Malcolm (malcolm_at_55bank.freeserve.co.uk)
Date: 03/26/04
- Next message: Bill Godfrey: "Re: how to attract grades 7-10 to Computer Science?"
- Previous message: Malcolm: "Re: Programmer knowledge"
- In reply to: Gerry Quinn: "Re: Programmer knowledge"
- Next in thread: Gerry Quinn: "Re: Programmer knowledge"
- Reply: Gerry Quinn: "Re: Programmer knowledge"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 26 Mar 2004 22:43:49 -0000
"Gerry Quinn" <gerryq@indigo.ie> wrote in message
>
> The constructor is (correctly) lightweight and none of the serious
> initialisation takes place until you actually 'create' a window. This is
> good because if you have CWnd member variables you don't want
> them to be wasting time and memory performing significant
> initialisation in the constructor.
>
This is sort of reason why I prefer C to C++. If a constructor can't be used
to construct the object, then there's obviously something wrong somewhere. A
different object-oriented language might be able to fix this, maybe by
allowing dynamic class members. In C++ you can use a pointer to the
sub-object (a child window), which is set to zero on object construction and
later initialised, but this brings its own problems.
>
> Separating construction from initialisation is the correct paradigm in
> such cases.
>
> Nonsense. I'm using it for what I want it for. If you don't eat the
> peel are you eating a banana ineffectively?
>
If you consider that a banana is a piece of fruit to be used only for
dessert then, no, you're not using a banana very effectively. People from
Africa, who know all about bananas, fry them as a staple, make them into
banana liqueur, and generally make them work with other foods as an integral
part of a meal.
>
> The unnecessary use of template metaprogramming is a bad idea.
>
That's a separate issue. This is what the standard template library is
designed to do. Of course there are arguments against it.
>
> You have destroyed encapsulation of functionality, and you are
> assuming that salary() returns data of a numeric type irrespective of
> the class of the object.
>
salary() needs to return an object that a) can be divided by 12, and b) can
be serialised to a text output stream. If we declare a "monetary" class then
the function will work, as long as it fulfils these two reasonable
conditions.
>
> There's no reason for STL methodology to pervade 'normal' code,
> and generic functions like payroll() above are also things to be used
> only in very special cases.
>
There's an obvious case for generic programming general-purpose functions
like "sort". The question is, should a "payroll" function be written
generically so that it can work with any data structure of employees, and
can pay anything that has a name, a salary and a National Insurance number?
I think you can make a case that it is so powerful, and so flexible, that it
is easy to abuse it, for instance by extending to a non-British system (eg
Chinese) where the national insurance number is actually a tax code. This
will work for a while and then go horribly wrong as the system suddenly
starts demanding a contribution history from a Chinese employee.
>
> Every choice we make cuts off options. You are avoiding OO
> methodologies because you prefer C
>
I prefer C, partly because it is stable, partly because it is efficient, and
partly because it precludes OO methodologies.
>
> and spaghetti (generic functions are a form, or at least a congener,
> of spaghetti). I don't like either.
>
This is typical. People say they prefer C++, but then don't use all the
language, or don't use it to its full potential. Generic programming is at
the heart of STL, and STL has completely revolutionised C++.
- Next message: Bill Godfrey: "Re: how to attract grades 7-10 to Computer Science?"
- Previous message: Malcolm: "Re: Programmer knowledge"
- In reply to: Gerry Quinn: "Re: Programmer knowledge"
- Next in thread: Gerry Quinn: "Re: Programmer knowledge"
- Reply: Gerry Quinn: "Re: Programmer knowledge"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|