Re: Hypothetical: All code in classes but main()
From: Mark A. Gibbs (x_gibbsmark_at_rogers.com_x)
Date: 04/10/04
- Next message: vishnu mahendra: "Queries about strstream.h"
- Previous message: John Harrison: "Re: Cast from (long double*) to (const double*)"
- In reply to: Juha Kettunen: "Re: Hypothetical: All code in classes but main()"
- Next in thread: Steven T. Hatton: "Re: Hypothetical: All code in classes but main()"
- Reply: Steven T. Hatton: "Re: Hypothetical: All code in classes but main()"
- Reply: David Harmon: "Re: Hypothetical: All code in classes but main()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 10 Apr 2004 17:47:46 GMT
I normally don't jump into hypothetical discussions like this, but parts
of this just rankled me.
Juha Kettunen wrote:
> "Steven T. Hatton" <susudata@setidava.kushan.aa> wrote in message
> news:gJ6dnWSYdtJ5G-rdRVn-tw@speakeasy.net...
[snip]
>>If you were forced at gunpoint to put all your code in classes, rather
>
> than
>
>>in namespace scope (obviously classes themselves are an exception to
>
> this),
>
>>and 'bootstrap' your program by instantiating a single application object
>>in main(), would that place any limitations on what you could accomplish
>>with your program? Are there any benefits to doing things that way (other
>>than survival)?
Personally, I can see no practical functional limitations or benefits.
[snip]
> I dont see eny limitations in "normal programming" - I would defenitely
> choose class route if possible . I was jus thinking, that some very critical
> fast code might need pure c-code because of efficiency. For example in chess
> game programming you calculate 2 000 000 moves per second, so classes might
> not be suitable in all programming because they might be a little bit too
> slow ... but to be honest with you, I am not sure of this ... Does somebody
> know if this is true or not?
Where this whole thing starts to spiral out of control is here. "C-code"
by itself is no slower or faster than the equivalent "C++-code" (ie,
class-based code). If you wanted to, you could write "slow" or "fast"
code in either. In fact, writing the theoretical "fastest" program is
possible in C and C++ - your compiler and your algorithm are what
determine how "fast" your code will run.
For the record, I make games, and I need "efficient" code to move big
chunks of data around very quickly. I use classes with impunity - the
things I usually watch for are polymorphism and virtual functions, and
hidden code (destructors and constructors that aren't immediately
obvious). And even these I use in some cases.
But being told to put all your code into classes is as illogical to me
as being told to use only words and phrases from Shakepeaean iambic
pentameter as variable names. Or, more practically but no less obtuse,
hungarian notation. Does it help anything? Not really. Does it hurt
anything? Not really. And if it does either it does them in equal
measure. So why insist on it?
I mean, compare the elegance of this:
int max(int a, int b) { return (a > b) ? a : b; }
int larger = max(1, 2);
To this:
class Math
{
public:
static int max(int a, int b) { return (a > b) ? a : b; }
};
int larger = Math::max(1, 2);
Only Java programmers could find the latter more legible.
Both can run just as fast (if you inline the former; the latter is
intrinsically inlined), so it's not a speed issue. Namespace Math::max
provides (essentially) the same amount of collision protection and
encapsulation as class Math::max, so it's not a maintennance issue.
What it is, is a design issue. What you're telling me is that there are
such things as "Math" objects. In order to find the max of two numbers,
I have to go get a "Math" and use the "Math"'s "max" operation. Or, in
the static case, that "Math"'s have a behaviour or mechanism that is not
specific to any one "Math", but is nonetheless "Math" object-specific
behaviour.
On the other hand, the free function tells me that "max" is an operation
in category (ie, namespace) "Math". In other words, "max" is a "Math"
operation.
Doesn't the latter just make more sense?
So in conclusion, what the hell are the benefits of such arbitrary
constraints? Write your program so that it makes logical sense and
models the problem it is trying to solve as closely as possible. If the
language has the tools, and if they don't lead to bad design and
maintennance problems, use them.
If you really feel the need to apply arbitrary constraints, why not
write your code in morse code ( http://www.ioccc.org/1986/hague.c )?
mark
- Next message: vishnu mahendra: "Queries about strstream.h"
- Previous message: John Harrison: "Re: Cast from (long double*) to (const double*)"
- In reply to: Juha Kettunen: "Re: Hypothetical: All code in classes but main()"
- Next in thread: Steven T. Hatton: "Re: Hypothetical: All code in classes but main()"
- Reply: Steven T. Hatton: "Re: Hypothetical: All code in classes but main()"
- Reply: David Harmon: "Re: Hypothetical: All code in classes but main()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
