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

From: Mark A. Gibbs (x_gibbsmark_at_rogers.com_x)
Date: 04/13/04 

Date: Tue, 13 Apr 2004 02:07:50 GMT

Steven T. Hatton wrote:

> No, I am not warping what Stroustrup said. I am addressing the reasoning
> behind the guideline. The reason is that he believes it is bad to have the
> potential for binding helper functions unnecessarily to the
> representation(private and protected data).

Given your odd "associated" access specifier, I can see how you think
this supports your position. As I've made quite clear, I refuse to
discuss extending the language with you. Not only am I not enough of an
expert to do so properly - and I don't believe you are, either - this is
not a forum for discussing changing the standard, it is a forum for
discussing using it. I tend to believe that Stroustrup's statement was
also not intended to support adding another access specifier when it is
not necessary, but I'll let him speak for himself on that one.

So, given that we are actually discussing C++ in comp.lang.c++, I see no
rational interpretation of that point that does not support free functions.

Besides, given:

class A {};
class B {};

void helper(A, B);

Where does helper() go?

>>Frankly, I agree. Putting those helper functions in the class simply
>>bloats the class, making it more difficult to maintain.
>
>
> It is specifically an issue of preventing unnecessary dependencies between
> the functions and the representation.

In your mind. A maintennance programmer would balk at needlessly
expanding classes, access specifier or no.

>>And you haven't taken a single step further in your support of your
>>position.
>
>
> I'm not really sure what you are talking about. If it's the proposition
> regarding an /associated/ access specifier I don't believe you understand
> the situation well enough to judge.

I find it odd that you are so confident of your "couple months of real
C++ experience" that you so casually write of my several years' worth. I
find it quite bizarre, and more than slightly arrogant, that you believe
a "couple months of real C++ experience" endows you with enough wisdom
and practice to begin proposing extensions to the core of the language.
I am not amused by this unwarranted condenscention from one who finds it
necessary to slip crib notes on properly accessing struct members via a
pointer in his signature.

I was not talking about any mythical "associated" access specifier, I
was - remarkably enough - talking about C++ and the hypothetical
benefits and concerns of putting all program code into classes (except
main), which are - even more remarkably - the topics of this forum, and
this thread specifically. And, as I mentioned, you have not even come
close to a reasonable defense of your position.

> Ease of use and IDE support are inseparable for all intents and purposes.

Bull***. Language simplicity may be correlated to IDE coolness, but not
ease of use. Java is a very simple language. It is also very hard to use
in some cases - for example, RAII. Ease of use does not necessarily
equal simplicity.

C++ is a very complex language, and it can be very difficult to use - or
it can be a snap, depending on what you want to do.

Forcing all functions to be in classes offers some kind of simplicity to
the language, but it does not improve its ease of use - after all, how
can you increase something's ease of use when you take functionality
away? Denying programmers a tool does not help them. If the tool is
problematic, then they can be cautioned to not use it unless absolutely
necessary. I am growing old waiting to hear how free functions are
problematic.

>>That goes without saying, but the STL is a special case. You're not
>>going to be rewriting it, so it's design is hardly relevant, except,
>>perhaps, as a curiosity.
>
>
> The design of the STL is not ideal from an ease of use perspective, and it
> sets a very bad precedent IMO. The reason it is the way it is, probably
> his historical, and reflects so kind of early limitation. I hope it is
> changed in C++0X.

The hell part of "it's design is hardly relevant, except, perhaps, as a
curiosity" did you not understand?

>>All of this is irrelevant to the discussion. I ask again (and again, and
>>again) - and each time I have to make the request more pedantically
>>clear, so here is the next step - given a reasonably intelligently
>>designed class and namespace hierarcy (or class and package hierarchy if
>>you prefer), what are the concrete advantages of taking all the free
>>functions from their requisite namespaces (in my version) and putting
>>them into non-instantiable classes as class-static functions?
>
>
> Yes, you understand the question I asked. Answering that question was the
> goal of posing the hypothetical proposition.

Is this a joke? After me begging and pleading and damn near demanding
that you provide *some* kind of answer, all you can say is "yes, you're
right, an answer is needed"? This is downright surreal.

> Since I've already acknowledged that helper functions present a problem, the
> exercise of putting them in another class is not something I would
> consider, unless it happened to be a base class of the classes being
> operated on. But I haven't thought the consequences of that proposition
> through, so it is not intended as anything more than a speculation.

You claimed it was a problem without backing it up at all. That may work
in politics and religion, but not in science.

And I have invited you repeatedly to think more on your proposition. To
date, as noted elsewhere, nothing.

>>Before I say anything else, let me point out that this has nothing to do
>>with your thesis.
>>
>>But, for the record. Standard C++ does not allow for multiple entry
>>points.
>
> Yes, I know that. It is specified in Clause 3.6.1 of ISO/IEC 14882-2003(E)
> which I have sitting right here in my lap. As I said.

[snip]

>>HOWEVER. If you wanted you could have as many entry points as you needed
>>in your program. It's not hard, and it's not unheard of. Virtually
>>everything I do in windows ends up as a bunch of .dll's with at least
>>one .exe. Usually I have one entry point - one main - in the standard
>>startup exe, and another entry point - another main - in a "debug mode"
>>startup exe. Most of the time the debug's main calls the standard main
>>after setting some stuff up.
>
>
> [basic.start.main] 3.6.1 Main function

[snip]

So after I stated that the information posted was not really relevant to
the discussion, AND that it was not standard C++, you post almost 50
lines of standard text that you could have summed up in less than five
(including directing me to the relevant sections, of course).

I posted that outline to be instructive, to demonstrate the flexibility
that is possible. So you know, at no point - ANYWHERE - do I violate the
letter of the standard (ie, any of the 50-odd lines you posted) in
achieving this flexibility insofar as it applies to having multiple
mains (of course, I do so by using DLL's, but they are not technically
necessary). That's right, I have more than one main, I can start the
program with any of them - determined at run time even - and I can do
all this without even bending standard law. I don't even NEED windows to
do it, but the windows solution is closer in spirit to the Java one,
which is why I mentioned it.

It's not magic, it's just knowing the language. And knowing the language
is a wise step to take before criticising it.

Curious as to how to do it? Well, I'd love to tell you, but...

> Now I have to leave this thread and get back to reading informed texts on
> the subject of C++.

Ah well. So much for learning anything here.

I hope they teach you more than I got out of this chat. Otherwise, I
hope you didn't pay much for them.

mark