Hypothetical: All code in classes but main()

[Steven T. Hatton]

This is a purely *hypothetical* question. That means, it's /pretend/,
CP. ;-)

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)?

BTW, yes, I /do/ favor this approach.
--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Juha Kettunen]

Re: Hypothetical: All code in classes but main()


"Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote in message
news:gJ6dnWSYdt J5G-rdRVn-tw@speakeasy.ne t...[color=blue]
> This is a purely *hypothetical* question. That means, it's /pretend/,
> CP. ;-)
>
> If you were forced at gunpoint to put all your code in classes, rather[/color]
than[color=blue]
> in namespace scope (obviously classes themselves are an exception to[/color]
this),[color=blue]
> 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)?
>
> BTW, yes, I /do/ favor this approach.[/color]

wow, finally I meet somebody who likes (c++) classes like me :). I am "with
you" ... I never really liked that c-style programming, if you can do the
same thing with classes, but this just my opinion and taste - I am not
saying, that I have the truth in this issue. Maybe its like that somebody
likes tea, but somebody else might hate tea but like coffee :).

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?

[Juha Kettunen]

Re: Hypothetical: All code in classes but main()


"Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote in message
news:gJ6dnWSYdt J5G-rdRVn-tw@speakeasy.ne t...[color=blue]
> This is a purely *hypothetical* question. That means, it's /pretend/,
> CP. ;-)
>
> If you were forced at gunpoint to put all your code in classes, rather[/color]
than[color=blue]
> in namespace scope (obviously classes themselves are an exception to[/color]
this),[color=blue]
> 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)?
>
> BTW, yes, I /do/ favor this approach.[/color]

wow, finally I meet somebody who likes (c++) classes like me :). I am "with
you" ... I never really liked that c-style programming, if you can do the
same thing with classes, but this just my opinion and taste - I am not
saying, that I have the truth in this issue. Maybe its like that somebody
likes tea, but somebody else might hate tea but like coffee :).

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?

[Jeff Schwab]

Re: Hypothetical: All code in classes but main()

Steven T. Hatton wrote:[color=blue]
> This is a purely *hypothetical* question. That means, it's /pretend/,
> CP. ;-)
>
> 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)?
>
> BTW, yes, I /do/ favor this approach.[/color]

I almost always have a single object to represent the whole application,
and use main() only as an entry point. That said, forcing _everything_
into classes seems to disallow use of some of my favorite C++ features
and programming styles. For example, many operator overloads belong
outside the class.

template< typename T >
int add_one( T const& t )
{
return 1 + t; // If T is a UDT, where is operator + defined?
}

[Jeff Schwab]

Re: Hypothetical: All code in classes but main()

Steven T. Hatton wrote:[color=blue]
> This is a purely *hypothetical* question. That means, it's /pretend/,
> CP. ;-)
>
> 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)?
>
> BTW, yes, I /do/ favor this approach.[/color]

I almost always have a single object to represent the whole application,
and use main() only as an entry point. That said, forcing _everything_
into classes seems to disallow use of some of my favorite C++ features
and programming styles. For example, many operator overloads belong
outside the class.

template< typename T >
int add_one( T const& t )
{
return 1 + t; // If T is a UDT, where is operator + defined?
}

[Mark A. Gibbs]

Re: Hypothetical: All code in classes but main()


I normally don't jump into hypothetical discussions like this, but parts
of this just rankled me.

Juha Kettunen wrote:
[color=blue]
> "Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote in message
> news:gJ6dnWSYdt J5G-rdRVn-tw@speakeasy.ne t...[/color]

[snip]
[color=blue][color=green]
>>If you were forced at gunpoint to put all your code in classes, rather[/color]
>
> than
>[color=green]
>>in namespace scope (obviously classes themselves are an exception to[/color]
>
> this),
>[color=green]
>>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)?[/color][/color]

Personally, I can see no practical functional limitations or benefits.

[snip]
[color=blue]
> 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?[/color]

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

[Mark A. Gibbs]

Re: Hypothetical: All code in classes but main()


I normally don't jump into hypothetical discussions like this, but parts
of this just rankled me.

Juha Kettunen wrote:
[color=blue]
> "Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote in message
> news:gJ6dnWSYdt J5G-rdRVn-tw@speakeasy.ne t...[/color]

[snip]
[color=blue][color=green]
>>If you were forced at gunpoint to put all your code in classes, rather[/color]
>
> than
>[color=green]
>>in namespace scope (obviously classes themselves are an exception to[/color]
>
> this),
>[color=green]
>>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)?[/color][/color]

Personally, I can see no practical functional limitations or benefits.

[snip]
[color=blue]
> 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?[/color]

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

[Steven T. Hatton]

Re: Hypothetical: All code in classes but main()

Jeff Schwab wrote:
[color=blue]
> Steven T. Hatton wrote:[color=green]
>> This is a purely *hypothetical* question. That means, it's /pretend/,
>> CP. ;-)
>>
>> 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)?
>>
>> BTW, yes, I /do/ favor this approach.[/color]
>
> I almost always have a single object to represent the whole application,
> and use main() only as an entry point. That said, forcing _everything_
> into classes seems to disallow use of some of my favorite C++ features
> and programming styles. For example, many operator overloads belong
> outside the class.
>
> template< typename T >
> int add_one( T const& t )
> {
> return 1 + t; // If T is a UDT, where is operator + defined?
> }[/color]

I believe there is actually a technical limitation met when binary operators
(ones that take two arguments) are forced to be class members. I need to
review the section, but I believe there are some symmetries that are lost.
IOW A@B works but B@A doesn't for cases such as '+' and '*'. Another
problem is the fact that functions which were external to a class now gain
access to member data and potentially become bound to it. This is the
argument Stroustrup gives for having helper functions at namespace scope.

I actually proposed another access specifier in addition to private,
protected, public and firend. I suggested /associated/ which would allow a
function to be a member, but it would only have access to public members of
its own class.
--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Steven T. Hatton]

Re: Hypothetical: All code in classes but main()

Jeff Schwab wrote:
[color=blue]
> Steven T. Hatton wrote:[color=green]
>> This is a purely *hypothetical* question. That means, it's /pretend/,
>> CP. ;-)
>>
>> 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)?
>>
>> BTW, yes, I /do/ favor this approach.[/color]
>
> I almost always have a single object to represent the whole application,
> and use main() only as an entry point. That said, forcing _everything_
> into classes seems to disallow use of some of my favorite C++ features
> and programming styles. For example, many operator overloads belong
> outside the class.
>
> template< typename T >
> int add_one( T const& t )
> {
> return 1 + t; // If T is a UDT, where is operator + defined?
> }[/color]

I believe there is actually a technical limitation met when binary operators
(ones that take two arguments) are forced to be class members. I need to
review the section, but I believe there are some symmetries that are lost.
IOW A@B works but B@A doesn't for cases such as '+' and '*'. Another
problem is the fact that functions which were external to a class now gain
access to member data and potentially become bound to it. This is the
argument Stroustrup gives for having helper functions at namespace scope.

I actually proposed another access specifier in addition to private,
protected, public and firend. I suggested /associated/ which would allow a
function to be a member, but it would only have access to public members of
its own class.
--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Steven T. Hatton]

Re: Hypothetical: All code in classes but main()

Mark A. Gibbs wrote:
[color=blue]
>
> I normally don't jump into hypothetical discussions like this, but parts
> of this just rankled me.
>
> Juha Kettunen wrote:[/color]
[snip][color=blue]
>
> Personally, I can see no practical functional limitations or benefits.[/color]

I believe there actually are two. I already mentioned them in another post
in this thread.
[color=blue]
> 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.[/color]

As you correctly pointed out below, virtual function calls have some
overhead beyond static calls. A static call to a member should be just as
fast as a global 'C'-style call, as far as I know.
[color=blue]
> 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?[/color]

One argument would be for the sake of uniformity. But I guess that's just
the soldier in me talking.
[color=blue]
> int larger = Math::max(1, 2);
>
> Only Java programmers could find the latter more legible.[/color]

There are advantages to having the static Math class in Java. It provides
for an easy point of reference. It's kind of like having a directory
structure and using it to organize your data. Personally, the following is
my idea of what a more complete set of mathematical operators looks like in
a programming language. But MMA is a specialized language:

http://documents.wolfram.com/v5/TheMathematicaBook/MathematicaReferenceGuide/InputSyntax/A.2.7.html

[color=blue]
> 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.[/color]

Other than the fact that people tend to be sloppy with namespaces.
[color=blue]
> What it is, is a design issue. What you're telling me is that there are
> such things as "Math" objects.[/color]

No. It's saying there are mathematical operators which can be classified as
such.
[color=blue]
> 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.[/color]

You don't instantiate Math. It is a utilities class.
[color=blue]
> 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.[/color]

And how does this differ from Java's use of a class where you use a
namespace?
[color=blue]
> Doesn't the latter just make more sense?[/color]

It depends how it's managed. Java takes the functional operator approach to
mathematical syntax, whereas C++ allows for infix notation. I find that
far more significant in terms of how it 'feels' to use. An interesting
parallel to this is found in Misner, Thorne and Wheeler's _Gravitation_
where three notational forms are used in parallel through out the text:

http://www.reviewcentre.com/review57645.html

[color=blue]
> 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.[/color]

Actually, this was a hypothetical proposition. One reason for putting
everything in classes is that it usually makes refactoring easier (with the
possible exception of helper functions), and also makes reuse easier.

--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Steven T. Hatton]

Re: Hypothetical: All code in classes but main()

Mark A. Gibbs wrote:
[color=blue]
>
> I normally don't jump into hypothetical discussions like this, but parts
> of this just rankled me.
>
> Juha Kettunen wrote:[/color]
[snip][color=blue]
>
> Personally, I can see no practical functional limitations or benefits.[/color]

I believe there actually are two. I already mentioned them in another post
in this thread.
[color=blue]
> 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.[/color]

As you correctly pointed out below, virtual function calls have some
overhead beyond static calls. A static call to a member should be just as
fast as a global 'C'-style call, as far as I know.
[color=blue]
> 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?[/color]

One argument would be for the sake of uniformity. But I guess that's just
the soldier in me talking.
[color=blue]
> int larger = Math::max(1, 2);
>
> Only Java programmers could find the latter more legible.[/color]

There are advantages to having the static Math class in Java. It provides
for an easy point of reference. It's kind of like having a directory
structure and using it to organize your data. Personally, the following is
my idea of what a more complete set of mathematical operators looks like in
a programming language. But MMA is a specialized language:

http://documents.wolfram.com/v5/TheMathematicaBook/MathematicaReferenceGuide/InputSyntax/A.2.7.html

[color=blue]
> 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.[/color]

Other than the fact that people tend to be sloppy with namespaces.
[color=blue]
> What it is, is a design issue. What you're telling me is that there are
> such things as "Math" objects.[/color]

No. It's saying there are mathematical operators which can be classified as
such.
[color=blue]
> 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.[/color]

You don't instantiate Math. It is a utilities class.
[color=blue]
> 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.[/color]

And how does this differ from Java's use of a class where you use a
namespace?
[color=blue]
> Doesn't the latter just make more sense?[/color]

It depends how it's managed. Java takes the functional operator approach to
mathematical syntax, whereas C++ allows for infix notation. I find that
far more significant in terms of how it 'feels' to use. An interesting
parallel to this is found in Misner, Thorne and Wheeler's _Gravitation_
where three notational forms are used in parallel through out the text:

http://www.reviewcentre.com/review57645.html

[color=blue]
> 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.[/color]

Actually, this was a hypothetical proposition. One reason for putting
everything in classes is that it usually makes refactoring easier (with the
possible exception of helper functions), and also makes reuse easier.

--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Mark A. Gibbs]

Re: Hypothetical: All code in classes but main()


Steven T. Hatton wrote:[color=blue]
> Mark A. Gibbs wrote:
>[color=green]
>>Personally, I can see no practical functional limitations or benefits.[/color]
>
>
> I believe there actually are two. I already mentioned them in another post
> in this thread.[/color]

Two what? Limitations or benefits? Are you referring to your comments on
assymetrical binary operations? That is not a design issue, that's an
implementation issue. If you want an operation a @ b to be valid for
objects of type A and B in any order you either have to define
operator@(A) in B and operator@(B) in A (thus coupling the two), or
define operator@(B) in A and operator@(A,B) globally (still coupling the
two), or define operator@(A,B) and operator@(B,A) globally (leaving the
classes uncoupled). To me, this *supports* non-class functions.

But whatever you decide out of the above options, you are limited by the
language. you could write add(A,B) and add(B,A) as class members (of
either class) with no problems. If you are talking about limitations of
possible implementations due to constraints of the language, count me
out. I have no intention of discussing alterations to the language. I
was talking about limitations on possible designs and program structures.

Your second argument, if I understood it, makes no sense. "Another
problem is the fact that functions which were external to a class now
gain access to member data and potentially become bound to it. This is
the argument Stroustrup gives for having helper functions at namespace
scope." So does that support your argument or not?

If a function requires access to member data, then by all means make it
a member function. But static functions can't access member data, now
can they? If they require access to static data, well that's different.
But if you have a function that does not require instance-specific data,
and does not require a class-global data (such as max()), you can choose
to use either a static member function or a non-class function without
concern.
[color=blue][color=green]
>>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.[/color]
>
>
> As you correctly pointed out below, virtual function calls have some
> overhead beyond static calls. A static call to a member should be just as
> fast as a global 'C'-style call, as far as I know.[/color]

That is the idea. It is possible for a theoretical implementation to do
something different, I suppose, but for all practical purposes it is
safe to assume that the only functional difference between a global
function and a class static function is that that the class static
function has access to private and protected class static data and
functions.

So in the context of this discussion, there are no performance differences.
[color=blue][color=green]
>>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?[/color]
>
>
> One argument would be for the sake of uniformity. But I guess that's just
> the soldier in me talking.[/color]

Being a former soldier myself, I should point out that while uniformity
is generally a good thing, there are many different types of soldiers,
some specializing in airborne drops, some specializing in beach
landings, not to mention the wildly varying trades like pilots,
artillery, armoured, mechanized infantry etc. etc. etc.

By all means, be uniform, but if the job calls for artillery, don't send
in the infantry.
[color=blue][color=green]
>>int larger = Math::max(1, 2);
>>
>>Only Java programmers could find the latter more legible.[/color]
>
>
> There are advantages to having the static Math class in Java. It provides
> for an easy point of reference. It's kind of like having a directory
> structure and using it to organize your data. Personally, the following is[/color]

?

You could replace "static Math class in Java" with "Math namespace in
C++" in your statement, and it would still be valid. The *only* reason
there is a static Math class in Java (as opposed to a Math namespace) is
that Java does not support free functions.

Given that C++ has the option, what are the advantages here?
[color=blue][color=green]
>>Both can run just as fast (if you inline the former; the latter is
>>intrinsical ly inlined), so it's not a speed issue. Namespace Math::max
>>provides (essentially) the same amount of collision protection and
>>encapsulati on as class Math::max, so it's not a maintennance issue.[/color]
>
>
> Other than the fact that people tend to be sloppy with namespaces.[/color]

People can be just as sloppy with anything in C++, and it's usually the
same people. Is there any emperical evidence that people tend to
sloppiness when namespaces are introduced?

But let me give the benefit of the doubt and ask sloppy in what way?
[color=blue][color=green]
>>What it is, is a design issue. What you're telling me is that there are
>>such things as "Math" objects.[/color]
>
>
> No. It's saying there are mathematical operators which can be classified as
> such.[/color]

Yes, but there are many ways of doing this in C++. You could use a
"Math" class, or you could use a "Math" namespace, or you could prefix
global functions with "Math_". Each of these methods groups certain
operations together, and each tell me different things about that
grouping. The class tells me that "Math"'s are things, ie, objects -
it's not called object-oriented programming for giggles - just like
class Student, class smart_ptr_polic y or class ifstream. The namespace
tells me that these functions are conceptually grouped in some way, but
otherwise gives me no further indications of how - which is fine, all I
really need to understand is that they are all "Math" functions.

The last? I guess it just tells me that someone's a rotten programmer,
unless they have a better excuse.
[color=blue][color=green]
>>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.[/color]
>
>
> You don't instantiate Math. It is a utilities class.[/color]

Of course I understand that, it was my argument after all. But a class
describes a (surprise, surprise) class of objects. The ONLY valid
reasons I can think of for having a non-instantiable (static) class is
when that body of operations MUST NOT be extended, and/or they all make
use of some kind of private data/algorithms that MUST NOT be visible to
the rest of the program. There are plenty of situations that satisfy
those constraints. I don't believe max() (or sin(), or round() etc.)
does. Explain to me why you do.
[color=blue][color=green]
>>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.[/color]
>
>
> And how does this differ from Java's use of a class where you use a
> namespace?[/color]

? what do you mean "Java's use of a class where you use a namespace"?

[Taking a guess at what you meant]

As I mentioned before, Java has no choice but to do max() with static
class members. You have a choice in C++.

Let me make this absolutely clear. I believe there is no difference
between designs that use non-class-functions and those that do in terms
of functionality, efficiency and maintainability . If anyone disagrees,
let me know. As far as I'm concerned this discussion is over the
benefits of Class::function () vs. Namespace::func tion(), and nothing more.

So to answer what I think your question was: it doesn't. It's the same
damn thing. There are no functional benefits either way.

But to me at least, you are making a statement when you create a class
vs. a namespace. A class describes a "thing", an object. A namespace
describes a group. To me, mathematical operations can be grouped. But a
"Math" doesn't have a "cosh()" capability. This is the basis of my
argument for putting these functions in namespaces as opposed to classes.

On the other hand, if I were to create a MemoryManager that was static
(non-instantiable), that's a different story. A "MemoryMana ger" is a
thing, an object. By making it a static class, I am making clear that
there is only one MemoryManager available, and you are not responsible
for creating or destroying it. Likewise, you are not to add functions to
it (make your own damn MemoryManager). It is a single, global interface
to some hidden memory system that needs managing. The static functions
in that class provide some operation or functionality of this monolithic
MemoryManager thing. Things like allocate(), get_free_memory (). That is
the language of objects.

Do not try to bend the Math into an object. That is impossible. Instead,
try to remember the truth.

There is no Math.
[color=blue][color=green]
>>Doesn't the latter just make more sense?[/color]
>
>
> It depends how it's managed. Java takes the functional operator approach to
> mathematical syntax, whereas C++ allows for infix notation. I find that
> far more significant in terms of how it 'feels' to use. An interesting
> parallel to this is found in Misner, Thorne and Wheeler's _Gravitation_
> where three notational forms are used in parallel through out the text:
>
> http://www.reviewcentre.com/review57645.html[/color]

wha?

[Attempting to decode]

If you prefer to use functional notation as opposed to operators, go
nuts. I think a + b is more understandable than operator+(a, b), but
hey, that's me.

But how is any of that relevant to keeping all the code in classes?
[color=blue][color=green]
>>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
>>maintennanc e problems, use them.[/color]
>
>
> Actually, this was a hypothetical proposition. One reason for putting
> everything in classes is that it usually makes refactoring easier (with the
> possible exception of helper functions), and also makes reuse easier.[/color]

I understand that it was hypothetical, so was my proposed "morse coding
standard". I am learning here, too. If you can convince me that
class-only design is better in some way than using global functions, I
may change my evil ways. But so far, all I have seen are wishy-washy
pseudo-statements like "the 'fact' that people *tend* to be *sloppy*
with namespace" or "putting everything in classes is that it *usually*
makes refactoring *easier*" (emphasis added in all cases), or assertions
to the tune of "that's how Java does it, so it must be good".

So tell me what you mean by "easier" refactoring or reuse, and how a
collection of static class functions makes this possible over a namespace.

For the record, Java is designed to run in distributed and network
environments. Because of the constraints of this environment, everything
*has* to be a class. They didn't make class Math cause it was a good
idea. They did it cause they needed the functions and had no other way
to make them.

But is it a good idea? I don't know, but I don't think so. Explain to me
why I might be wrong.

mark

[Mark A. Gibbs]

Re: Hypothetical: All code in classes but main()


Steven T. Hatton wrote:[color=blue]
> Mark A. Gibbs wrote:
>[color=green]
>>Personally, I can see no practical functional limitations or benefits.[/color]
>
>
> I believe there actually are two. I already mentioned them in another post
> in this thread.[/color]

Two what? Limitations or benefits? Are you referring to your comments on
assymetrical binary operations? That is not a design issue, that's an
implementation issue. If you want an operation a @ b to be valid for
objects of type A and B in any order you either have to define
operator@(A) in B and operator@(B) in A (thus coupling the two), or
define operator@(B) in A and operator@(A,B) globally (still coupling the
two), or define operator@(A,B) and operator@(B,A) globally (leaving the
classes uncoupled). To me, this *supports* non-class functions.

But whatever you decide out of the above options, you are limited by the
language. you could write add(A,B) and add(B,A) as class members (of
either class) with no problems. If you are talking about limitations of
possible implementations due to constraints of the language, count me
out. I have no intention of discussing alterations to the language. I
was talking about limitations on possible designs and program structures.

Your second argument, if I understood it, makes no sense. "Another
problem is the fact that functions which were external to a class now
gain access to member data and potentially become bound to it. This is
the argument Stroustrup gives for having helper functions at namespace
scope." So does that support your argument or not?

If a function requires access to member data, then by all means make it
a member function. But static functions can't access member data, now
can they? If they require access to static data, well that's different.
But if you have a function that does not require instance-specific data,
and does not require a class-global data (such as max()), you can choose
to use either a static member function or a non-class function without
concern.
[color=blue][color=green]
>>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.[/color]
>
>
> As you correctly pointed out below, virtual function calls have some
> overhead beyond static calls. A static call to a member should be just as
> fast as a global 'C'-style call, as far as I know.[/color]

That is the idea. It is possible for a theoretical implementation to do
something different, I suppose, but for all practical purposes it is
safe to assume that the only functional difference between a global
function and a class static function is that that the class static
function has access to private and protected class static data and
functions.

So in the context of this discussion, there are no performance differences.
[color=blue][color=green]
>>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?[/color]
>
>
> One argument would be for the sake of uniformity. But I guess that's just
> the soldier in me talking.[/color]

Being a former soldier myself, I should point out that while uniformity
is generally a good thing, there are many different types of soldiers,
some specializing in airborne drops, some specializing in beach
landings, not to mention the wildly varying trades like pilots,
artillery, armoured, mechanized infantry etc. etc. etc.

By all means, be uniform, but if the job calls for artillery, don't send
in the infantry.
[color=blue][color=green]
>>int larger = Math::max(1, 2);
>>
>>Only Java programmers could find the latter more legible.[/color]
>
>
> There are advantages to having the static Math class in Java. It provides
> for an easy point of reference. It's kind of like having a directory
> structure and using it to organize your data. Personally, the following is[/color]

?

You could replace "static Math class in Java" with "Math namespace in
C++" in your statement, and it would still be valid. The *only* reason
there is a static Math class in Java (as opposed to a Math namespace) is
that Java does not support free functions.

Given that C++ has the option, what are the advantages here?
[color=blue][color=green]
>>Both can run just as fast (if you inline the former; the latter is
>>intrinsical ly inlined), so it's not a speed issue. Namespace Math::max
>>provides (essentially) the same amount of collision protection and
>>encapsulati on as class Math::max, so it's not a maintennance issue.[/color]
>
>
> Other than the fact that people tend to be sloppy with namespaces.[/color]

People can be just as sloppy with anything in C++, and it's usually the
same people. Is there any emperical evidence that people tend to
sloppiness when namespaces are introduced?

But let me give the benefit of the doubt and ask sloppy in what way?
[color=blue][color=green]
>>What it is, is a design issue. What you're telling me is that there are
>>such things as "Math" objects.[/color]
>
>
> No. It's saying there are mathematical operators which can be classified as
> such.[/color]

Yes, but there are many ways of doing this in C++. You could use a
"Math" class, or you could use a "Math" namespace, or you could prefix
global functions with "Math_". Each of these methods groups certain
operations together, and each tell me different things about that
grouping. The class tells me that "Math"'s are things, ie, objects -
it's not called object-oriented programming for giggles - just like
class Student, class smart_ptr_polic y or class ifstream. The namespace
tells me that these functions are conceptually grouped in some way, but
otherwise gives me no further indications of how - which is fine, all I
really need to understand is that they are all "Math" functions.

The last? I guess it just tells me that someone's a rotten programmer,
unless they have a better excuse.
[color=blue][color=green]
>>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.[/color]
>
>
> You don't instantiate Math. It is a utilities class.[/color]

Of course I understand that, it was my argument after all. But a class
describes a (surprise, surprise) class of objects. The ONLY valid
reasons I can think of for having a non-instantiable (static) class is
when that body of operations MUST NOT be extended, and/or they all make
use of some kind of private data/algorithms that MUST NOT be visible to
the rest of the program. There are plenty of situations that satisfy
those constraints. I don't believe max() (or sin(), or round() etc.)
does. Explain to me why you do.
[color=blue][color=green]
>>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.[/color]
>
>
> And how does this differ from Java's use of a class where you use a
> namespace?[/color]

? what do you mean "Java's use of a class where you use a namespace"?

[Taking a guess at what you meant]

As I mentioned before, Java has no choice but to do max() with static
class members. You have a choice in C++.

Let me make this absolutely clear. I believe there is no difference
between designs that use non-class-functions and those that do in terms
of functionality, efficiency and maintainability . If anyone disagrees,
let me know. As far as I'm concerned this discussion is over the
benefits of Class::function () vs. Namespace::func tion(), and nothing more.

So to answer what I think your question was: it doesn't. It's the same
damn thing. There are no functional benefits either way.

But to me at least, you are making a statement when you create a class
vs. a namespace. A class describes a "thing", an object. A namespace
describes a group. To me, mathematical operations can be grouped. But a
"Math" doesn't have a "cosh()" capability. This is the basis of my
argument for putting these functions in namespaces as opposed to classes.

On the other hand, if I were to create a MemoryManager that was static
(non-instantiable), that's a different story. A "MemoryMana ger" is a
thing, an object. By making it a static class, I am making clear that
there is only one MemoryManager available, and you are not responsible
for creating or destroying it. Likewise, you are not to add functions to
it (make your own damn MemoryManager). It is a single, global interface
to some hidden memory system that needs managing. The static functions
in that class provide some operation or functionality of this monolithic
MemoryManager thing. Things like allocate(), get_free_memory (). That is
the language of objects.

Do not try to bend the Math into an object. That is impossible. Instead,
try to remember the truth.

There is no Math.
[color=blue][color=green]
>>Doesn't the latter just make more sense?[/color]
>
>
> It depends how it's managed. Java takes the functional operator approach to
> mathematical syntax, whereas C++ allows for infix notation. I find that
> far more significant in terms of how it 'feels' to use. An interesting
> parallel to this is found in Misner, Thorne and Wheeler's _Gravitation_
> where three notational forms are used in parallel through out the text:
>
> http://www.reviewcentre.com/review57645.html[/color]

wha?

[Attempting to decode]

If you prefer to use functional notation as opposed to operators, go
nuts. I think a + b is more understandable than operator+(a, b), but
hey, that's me.

But how is any of that relevant to keeping all the code in classes?
[color=blue][color=green]
>>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
>>maintennanc e problems, use them.[/color]
>
>
> Actually, this was a hypothetical proposition. One reason for putting
> everything in classes is that it usually makes refactoring easier (with the
> possible exception of helper functions), and also makes reuse easier.[/color]

I understand that it was hypothetical, so was my proposed "morse coding
standard". I am learning here, too. If you can convince me that
class-only design is better in some way than using global functions, I
may change my evil ways. But so far, all I have seen are wishy-washy
pseudo-statements like "the 'fact' that people *tend* to be *sloppy*
with namespace" or "putting everything in classes is that it *usually*
makes refactoring *easier*" (emphasis added in all cases), or assertions
to the tune of "that's how Java does it, so it must be good".

So tell me what you mean by "easier" refactoring or reuse, and how a
collection of static class functions makes this possible over a namespace.

For the record, Java is designed to run in distributed and network
environments. Because of the constraints of this environment, everything
*has* to be a class. They didn't make class Math cause it was a good
idea. They did it cause they needed the functions and had no other way
to make them.

But is it a good idea? I don't know, but I don't think so. Explain to me
why I might be wrong.

mark

[Jeff Schwab]

Re: Hypothetical: All code in classes but main()

Steven T. Hatton wrote:
[color=blue]
> I actually proposed another access specifier in addition to private,
> protected, public and firend. I suggested /associated/ which would allow a
> function to be a member, but it would only have access to public members of
> its own class.[/color]

What purpose would that serve?

[Jeff Schwab]

Re: Hypothetical: All code in classes but main()

Steven T. Hatton wrote:
[color=blue]
> I actually proposed another access specifier in addition to private,
> protected, public and firend. I suggested /associated/ which would allow a
> function to be a member, but it would only have access to public members of
> its own class.[/color]

What purpose would that serve?