Sushrut Sardeshmukh schrieb:

>
> I have seen 'C' developers first C++ code where he had a huge file
> and **everything** in one class. He called it OO because there as a
> class keyword in it. He could have done such so called OO work in ANY
> language.

The blob anti-pattern ...

> Because of this incidence, I cant conclude that NO language
> support OO.

Agreed.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"K=F8i=B9tof =AEelechovski" <giecrilj@stegny.2a.pl> wrote in message=20
news:ek7d9b$2bnc$1@news2.ipartners.pl...
>
> U=BFytkownik ""Tony"" <rdnewsNOSPAM2006@sbcglobal.net> napisa=B3 w wiad=
omo=B6ci=20
> news:8l39h.14295$Sw1.3636@newssvr13.news.prodigy.com...
>>
>> "Mathias Gaunard" <loufoque@remove.gmail.com> wrote in message=20
>> news:456455ae$0$6241$426a34cc@news.free.fr...
>>> Koitof wrote:
>>>> 3.
>>>> The main reason the OO support in C++ is crippled
>>>> is that there is no builtin construct suspend the execution of a met=
hod=20
>>>> at a well-defined point inside.
>>
>> You're asking for a cooperative model rather than a preemptive one? Is=
n't
>> that strictly an OS issue rather than a language one?
>>
>
> I do not think
> the OS should be burdened with halting a recursive enumerator.
> And the same problem appears
> in a cooperative multitasking environment:
> the event handler cannot be recursive.
> And that is because of the language, not because of the OS.

Well I'm only concerned with program startup at this point (read: main()
"sucks").

Tony=20

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote
in message news:ekangb$bqv$1@kujawiak.man.lodz.pl...
> Dnia Fri, 24 Nov 2006 18:37:17 GMT, "Tony" skrobie:
>> >> rather than message
>> >> passing, since C++ doesn't have that concept and it (message
>> >> passing) is the popular higher level architecture paradigm for
>> >> event driven programs and network programs.
>> >
>> > The "message passing" term is rather taken from Smalltalk (which is not
>> > a
>> > base
>> > language for C++).
>
>> I realize that too. But still unappropriate in a C++ context. And, I
>> think
>> "message
>> passing" and "messaging" should be reserved in the general sense for the
>> higher
>> level context (unless of course one is posting in a Smalltalk group).
>
> The problem is that there is no "general sense" of "message passing" and
> if
> you want to connect it to OO, this matches only Smalltalk and other
> similar
> languages. The problem here is in inheritance.

That is to tangent off topic. Valid thought but it could make this thread
never
ending. (OK, so maybe I tangented a bit... let's get back on track).

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Sushrut Sardeshmukh wrote:
>
> I have seen 'C' developers first C++ code where he had a huge file
> and **everything** in one class. He called it OO because there as a
> class keyword in it. He could have done such so called OO work in ANY
> language. Because of this incidence, I cant conclude that NO language
> support OO.

I have seen plenty of Java programs that do the same.

Java classes full of static members (effectively not OO at all, just
free functions wrapped in a class). And long Java functions with switch
statements and lots of ifs instead of polymorphism to cover the
different possibilities.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Nov 20, 9:25 am, rdnewsNOSPAM2...@sbcglobal.net ("Tony") wrote:
>The point is that C++ doesn't support the OO style as much as it does the
> procedural style.
>
> Tony
>
> ---

The point is that OO is too high level to simply be mixed with low
level concepts that C handles.I am looking for something better but
choosing other existing languages means losing a lot of benefits.I
think the people who have suggested C++ for the first time have been
driving too fast.I feel that there is a need for a new language
suggesting NEW PARADIGMS but it should not be like C# .we must not lose
the flexibility provided by C++.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Uzytkownik "Mathias Gaunard" <loufoque@remove.gmail.com> napisal w
wiadomosci news:4564bbbe$0$1988$426a34cc@news.free.fr...
> Krzysztof Zelechowski wrote:
>
>> I wanted to throw for the sake of the OP who does not like main.
>> Do you want to say that I am not allowed to throw unless within the
>> lifetime of main?
>
> Exceptions should only be thrown when facing an exceptional situation and
> when the context isn't enough to handle it correctly, hence delegating
> this task to higher scopes.
>
> At least, that's how I understand them.

Tony's problem with main is an exceptional situation :-)

>> Encoded values are harder to process them than unencoded.  You have to
>> decode them first before you are able to process them.
>
> Not really.
> UTF-8 is made to be compatible with ASCII.
> Basic operations can be made without conversions, and sometimes require a
> few tricks.
> No need to convert the whole thing.

The tricks required to split the string into characters
are too tricky for my taste.
And such encoded characters are not first-class objects;
they are memory segments you cannot sizeof.

>
>> Why not use wchar_t?  It was introduced with that purpose in mind.
>
> wchar_t, according to the standard, is not related to unicode.
> Plus, implementations vary, and sometimes it is used to store UCS-2,
> UTF-16 or UCS-4/UTF-32.
>
> But even if it is UCS-4, there is not only a waste of memory but also it
> can't handle grapheme clusters, canonical equivalence, etc., not to
> mention case related operations and tailored behaviour.
> char_traits, also, can't possibly answer the unicode requirements.
>
> What we need is a more clever string type.

"operations" and "behaviour" do not require a new type,
you can have functions to perform operations and to exhibit behaviour.
I understand you want to enclose them in a class; perhaps.
However, I would like these operations
not to allocate data on the heap internally, unlike std::string.

Chris


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In message <Qc39h.14293$Sw1.9700@newssvr13.news.prodigy.com>, Tony
<rdnewsNOSPAM2006@sbcglobal.net> writes

  <snip>
>The above discussion points out that "entry point" may be nicer defined
>as "thread of control" rather than main() which implies SINGLE thread
>of control. But why have the "relic" main() anyway

>since most programs
>don't give a hoot about command line args?

Some Windows programs have extremely useful runtime parameters, Windows
Explorer for instance.

>Why make one function
>"special"? One could indicate any of a number of "entry points":
>
>entry_point MyProgram.Run():
>entry_point MyObject2;
>entry_point MyFunction("arg to my function");
  <snip>

Could you explain what created the MyProgram and MyObject2 objects,
ready for them to act as entry points ?

  John
--
John Harris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"John G Harris" <news0@nospam.demon.co.uk> wrote in message
news:I7REZPIZTgZFFwEf@jgharris.demon.co.uk.nospam.invalid...
> In message <Qc39h.14293$Sw1.9700@newssvr13.news.prodigy.com>, Tony
> <rdnewsNOSPAM2006@sbcglobal.net> writes
>
>  <snip>
>>The above discussion points out that "entry point" may be nicer defined
>>as "thread of control" rather than main() which implies SINGLE thread
>>of control. But why have the "relic" main() anyway
>
>>since most programs
>>don't give a hoot about command line args?
>
> Some Windows programs have extremely useful runtime parameters, Windows
> Explorer for instance.
>
>>Why make one function
>>"special"? One could indicate any of a number of "entry points":
>>
>>entry_point MyProgram.Run():
>>entry_point MyObject2;
>>entry_point MyFunction("arg to my function");
>  <snip>
>
> Could you explain what created the MyProgram and MyObject2 objects,
> ready for them to act as entry points ?

I had some problems thinking about MyObject2 after I posted it also, but it
could be made to work. I'll get to that in a moment.

MyProgram is a global singleton that gets initialized by some guarantee that
global objects will all be initialized before any entry point is "run". Of
course
even the guarantee could be eliminated by doing something similar to:

MyProgram& MyProgInst()
{
   // Use singleton techniques to clean up my_prog at prog end
   //
   static MyProgram* = new my_prog;
   return *my_prog;
}

entry_point MyProgramInst().Run();

Now for MyObject2. Well since this is C++ and C++ knows about
constructors:

entry_point MyClass MyObject2; // constructor called and is an entry point

So that was the intention with MyObject2, just the class type was left out.

These are just patterns off the top of my head remember and not evolved
concepts.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Kristof Zelechovski wrote:

> The tricks required to split the string into characters
> are too tricky for my taste.
> And such encoded characters are not first-class objects;
> they are memory segments you cannot sizeof.

Yes, but since we don't have those first-class objects anyway, better
work with something that can integrate well with what exists today.


> "operations" and "behaviour" do not require a new type,
> you can have functions to perform operations and to exhibit behaviour.

Not really.
When working with strings, what you must access is a sequence of characters.
If you have a sequence of units which forms characters together, it's
not a good string since you are allowed to access part of a character
and invalidate the actual format.

The actual representation should only be available inside the type.
(which would still provide explicit facilities to access it)
And since working with the actual representation is more efficient than
working with say, iterators, we would better make algorithms member
functions.


> I understand you want to enclose them in a class; perhaps.
> However, I would like these operations
> not to allocate data on the heap internally, unlike std::string.

That's an implementation detail.
But indeed, it would be good to be able to build a string on top of any
data structure.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

U   ytkownik ""Tony"" <rdnewsNOSPAM2006@sbcglobal.net> napisa    w wiadomo   ci
news:8l39h.14295$Sw1.3636@newssvr13.news.prodigy.com...
>
> "Mathias Gaunard" <loufoque@remove.gmail.com> wrote in message
> news:456455ae$0$6241$426a34cc@news.free.fr...
>> Koitof wrote:
>>> 3.
>>> The main reason the OO support in C++ is crippled
>>> is that there is no builtin construct suspend the execution of a method
>>> at a well-defined point inside.
>
> You're asking for a cooperative model rather than a preemptive one? Isn't
> that strictly an OS issue rather than a language one?
>

I do not think
the OS should be burdened with halting a recursive enumerator.
And the same problem appears
in a cooperative multitasking environment:
the event handler cannot be recursive.
And that is because of the language, not because of the OS.

Chris


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Dnia Fri, 24 Nov 2006 18:37:17 GMT, "Tony" skrobie:
> >> rather than message
> >> passing, since C++ doesn't have that concept and it (message
> >> passing) is the popular higher level architecture paradigm for
> >> event driven programs and network programs.
> >
> > The "message passing" term is rather taken from Smalltalk (which is not a
> > base
> > language for C++).

> I realize that too. But still unappropriate in a C++ context. And, I think
> "message
> passing" and "messaging" should be reserved in the general sense for the
> higher
> level context (unless of course one is posting in a Smalltalk group).

The problem is that there is no "general sense" of "message passing" and if
you want to connect it to OO, this matches only Smalltalk and other similar
languages. The problem here is in inheritance.

Say, an object is of class A, which derives from X. In Smalltalk, when a
message M is delivered to an object and class A does not supply its
definition, it is redirected to class X.

This cannot be said about C++ because in C++ the method definitions are
provided at compile time and at the place of calling a method everything is
already known. In C++ this is totally different direction of heritage: you use
the base class to provide some definitions to the derived class. Once
provided, they become definitions of this very class, not a set of definitions
in base class referred by a class, of which the main object is. That's why,
for example, in C++ multiple inheritance makes sens and in Smalltalk it does
not.


--
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Sektor van Skijlen wrote:
> Dnia Fri, 24 Nov 2006 18:37:17 GMT, "Tony" skrobie:
> The problem is that there is no "general sense" of "message passing" and if
> you want to connect it to OO, this matches only Smalltalk and other similar
> languages. The problem here is in inheritance.

    I tend to agree about the nomenclature.

    But that's not the real issue with "message passing". The
real issue is how we program multiple-CPU machines without shared
memory, where you have to do real message passing to get anything
done.  C++ offers no help in breaking up problems for machines like
that.  Hardware is definitely headed that way; shared-memory
multiprocessors with interlocked caches have been pushad about
as far as they can go.

    The model of concurrency the C++ committee is considering
represents what was needed for the hardware of a decade ago.
That's not going to be good enough.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Tony wrote:

> That's right. Because main() is such a UNIX-filter-like thing. It implies
> a program that runs sequentially (like a UNIX filter!). Nothing OO about
> that.
> But not that the goal is to just do OO for OO's sake. But that if one
> escapes
> the main() paradigm, that there may be a better approach. An OO approach
> as an alternative indeed seems particularly lucrative. Just to add another
> ingredient, maybe if in pondering the alternative approaches, what if
> threads
> were recognized first class citizens? Would that help "the/a" better
> solution
> emerge?

You're confusing object oriented programming with concurrent programming.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Nov 22, 12:28 am, "Tony" <rdnewsNOSPAM2...@sbcglobal.net> wrote:
> I tried that with a GUI program last night and it ran just fine: the message
> loop running in the constructor. I don't remember where/when/if WinMain
> wraps main(). I may try the same thing with a traditional non-GUI program
> tonight. I wonder what I'm NOT guaranteed by running everything outside
> of main. (?)
>

The standard stream objects (cout, cin, cerr) are only guaranteed to be
constructed once main has started (27.3/2), although you can force them
to be constructed earlier.

In practice, on all compilers/platforms I've worked with, all global
objects of user-defined type (excluding dynamically loaded libraries,
of course) are constructed before the program enters main. I don't
recommend relying on that.

If you're using a 3rd-party library which implements main for you (such
as Win32, where you are expected to provide WinMain, not main),
services provided by that library may not be available until the
official client entry point is hit. After all, that's the meaning of
'entry point'.


James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:
 Please quote appropriately and post replies in conventional form for this newsgroup after the material to which they respond.


===================================== END OF MODERATOR'S COMMENT
Wow, that was smart.  Can you publish the code?
Chris

Uzytkownik "John Nagle" <nagle@animats.com> napisal w wiadomosci
news:c7Q8h.17737$B31.6423@newssvr27.news.prodigy.net...
> James Kanze wrote:
>> One could, for example,
>> imagine a language in which you could write code outside of any
>> function, and in which the start-off routine called by the
>> system started a separate thread for each object file.  (I
>> rather doubt that one could write correct code for such a
>> system, but that's another question:-).)  One could also imagine
>> that instead of starting in multiple threads, the modules
>> executed one after another, with the linker doing a topological
>> sort over the dependancies---that's actually the way some
>> languages (e.g. Modula-2, and I think Modula-3) work, and there
>> is currently a proposal to add something similar to C++.  Even
>> today in C++, code doesn't start in main, but in the
>> initialization of static objects (and you don't necessarily have
>> control of the order).
>
>     Here's a way you could do something like that in the context
> of C++ as it exists today.
>
>     Provide a library with a function called, say, "threadstart()",
> which takes a pointer to a member function as an argument.  The
> intent is that one puts a call to "threadstart" in the constructors
> of static objects which need a thread of their own.  However, rather
> than starting immediately, the threads started via "threadstart()"
> all block on a lock during initalization.  This prevents
> problems with threads running before static initialization
> finishes.
>
>     "main" then becomes a function in the library containing
> "threadstart()".  When "main" runs, it releases the lock on
> all the initial threads, and waits (probably via pthread_join)
> for them to exit.  Then it exits, allowing the program to exit.
> This prevents problems with the "main" thread exiting before the
> other threads and shutting down the program prematurely.
>
>     That's a few pages of code, and would provide the functionality
> the original poster wanted.  No more main program; just objects
> with threads.
>
>     There's a certain elegance to this.  It encourages writing
> concurrent programs, where objects are active services, rather
> than passive data.  It's in some ways close to Alan Kay's original
> concept of objects in Smalltalk.  And it's easy to do.
>
> John Nagle
> Animats
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Uzytkownik "Mathias Gaunard" <loufoque@remove.gmail.com> napisal w
wiadomosci news:456455ae$0$6241$426a34cc@news.free.fr...
> Koitof wrote:
>
>> 1.
>> The fact that every program contains the function main
>> does not imply you have to use it for any purpose other than returning 0
>> - which is what you unfortunately have to do.
>> However, it is a false path to make main a static method; it would buy
>> you nothing.
>> You should do your work in the constructor of the global Program object.
>> If you want to disable main altogether, just throw at the end.
>> 2.
>> In fact, you can have many such objects.
>> If you decide throw, only the first of them will run; if you do not, all
>> of them will run.
>> If you group them all in one module, they will run in the order in which
>> you place them;
>> if you do not, the order is unspecified.
>> It would be interesting to see all of these constructors run in separate
>> threads
>> - but, alas, C++ does not support threads.  A suitable extension would be
>> welcome.
>> (The current situation is just the opposite: since threads are C-y
>> things;
>> if you spawn a thread in a constructor of a global object, all hell can
>> break loose).
>
> Why are you talking about throwing exceptions? It doesn't even seem to be
> valid cases for exception usage.

I wanted to throw for the sake of the OP who does not like main.
Do you want to say that I am not allowed to throw unless within the lifetime
of main?

>
> And what's the problem with constructors?
> It's not any more dangerous than using threads everywhere else.
>

Since threads are nonstandard, it may be a problem at my place and no
problem at your place.

>
>> 3.
>> The main reason the OO support in C++ is crippled
>> is that there is no builtin construct suspend the execution of a method
>> at a well-defined point inside.
>
> Such a functionality would be coroutines or continuations.
> You can actually get more or less the same things by storing state values
> as member variables.
>
> And I don't see how it's related to OO at all.
> OO is about dynamic message passing following inheritance.

I thought iterators were an important part of the concept.  I might be wrong
though.

>
>
>> Therefore you cannot construct recursive iterators easily.
>> (A recursive iterator is an iterator corresponding to a situation
>> where the enumerating function is irreducibly recursive).
>
> I'm afraid I don't see why it needs coroutines or even how coroutines
> would make it easier.

I do not know much about coroutines because C++ does not support them;
but, once the enumerating function reaches the next element, it could freeze
and have its state examined.  It can be asked to resume afterwards.
And no matter how many levels of recursive calls have been made.

>
>
>> 4.
>> The function main, as it is declared, is a dinosaur; who cares about
>> narrow character strings in the global village?
>> Oh yes, the Americans are an exception.
>
> Because wide character strings are better?
> I wouldn't ever want to use either for internationalization. And if I have
> to use one, I would rather use utf-8 inside of chars.
>

Encoded values are harder to process them than unencoded.  You have to
decode them first before you are able to process them.

>
>> Fortunately there are programming environments where you can safely pass
>> your name as an argument to main,
>> or whatever the function would actually be named.
>
> You can do it with any environment which has a locale that supports the
> characters for your name.
> And that should be the case of your environment, unless you chose to use
> something that doesn't care about your language.
> But still, being locale specific is usually not a good idea.

Sure, what happens if I have a guest from a different culture?  Or if I am a
guest?  BTW, my name is not Koitof.

>
> Better have unicode. But C++ has no good unicode support, and will not
> have before a long time.
> The first step is to have a good unicode string type.

Why not use wchar_t?  It was introduced with that purpose in mind.
The problem is not that we do not have the type, the problem is we are
unable to handle it correctly using the standard tools.

Chris


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Krzysztof Zelechowski wrote:

> I wanted to throw for the sake of the OP who does not like main.
> Do you want to say that I am not allowed to throw unless within the lifetime
> of main?

Exceptions should only be thrown when facing an exceptional situation
and when the context isn't enough to handle it correctly, hence
delegating this task to higher scopes.

At least, that's how I understand them.


> I do not know much about coroutines because C++ does not support them;

They can be implemented with setjmp/longjmp, which are part of the standard.
More efficient implementations can be done with POSIX functions like
setcontext.


> Encoded values are harder to process them than unencoded.  You have to
> decode them first before you are able to process them.

Not really.
UTF-8 is made to be compatible with ASCII.
Basic operations can be made without conversions, and sometimes require
a few tricks.
No need to convert the whole thing.

>
> BTW, my name is not Koitof.

It is what it looked like once I removed all the weird characters I
didn't know how to type.
For some reason my news client actually totally removed your name when I
chose to reply.

But that's a known bug: newsgroups mostly work with ISO-8859-1 only.

>
>> Better have unicode. But C++ has no good unicode support, and will not
>> have before a long time.
>> The first step is to have a good unicode string type.
>
> Why not use wchar_t?  It was introduced with that purpose in mind.

wchar_t, according to the standard, is not related to unicode.
Plus, implementations vary, and sometimes it is used to store UCS-2,
UTF-16 or UCS-4/UTF-32.

But even if it is UCS-4, there is not only a waste of memory but also it
can't handle grapheme clusters, canonical equivalence, etc., not to
mention case related operations and tailored behaviour.
char_traits, also, can't possibly answer the unicode requirements.

What we need is a more clever string type.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Mathias Gaunard" <loufoque@remove.gmail.com> wrote in message
news:456455ae$0$6241$426a34cc@news.free.fr...

> OO is about dynamic message passing following inheritance.

I'd say that OO is fundamentally combining data and behavior.
Inheritance is a furthering upon the lowest level foundation of
data + behavior. Also, given that we are talking about C++, I'd
say "inheritance via method overloading" rather than message
passing, since C++ doesn't have that concept and it (message
passing) is the popular higher level architecture paradigm for
event driven programs and network programs.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Mathias Gaunard" <loufoque@remove.gmail.com> wrote in message
news:456455ae$0$6241$426a34cc@news.free.fr...
> Koitof wrote:
>> 3.
>> The main reason the OO support in C++ is crippled
>> is that there is no builtin construct suspend the execution of a method
>> at a well-defined point inside.

You're asking for a cooperative model rather than a preemptive one? Isn't
that strictly an OS issue rather than a language one?

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Mathias Gaunard" <loufoque@remove.gmail.com> wrote in message
news:45645069$0$29628$426a34cc@news.free.fr...
> Tony wrote:
>
>> That's right. Because main() is such a UNIX-filter-like thing. It implies
>> a program that runs sequentially (like a UNIX filter!). Nothing OO about
>> that.
>> But not that the goal is to just do OO for OO's sake. But that if one
>> escapes
>> the main() paradigm, that there may be a better approach. An OO approach
>> as an alternative indeed seems particularly lucrative. Just to add
>> another
>> ingredient, maybe if in pondering the alternative approaches, what if
>> threads
>> were recognized first class citizens? Would that help "the/a" better
>> solution
>> emerge?
>
> You're confusing object oriented programming with concurrent programming.

No I'm not. I just offered more scope/design space for people to create in.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

""Krzysztof Zelechowski"" <krixel@qed.pl> wrote in message
news:ek1ia7$c52$1@kontener.atcom.net.pl...
>
> ===================================== MODERATOR'S COMMENT: Please quote
> appropriately and post replies in conventional form for this newsgroup
> after the material to which they respond.
>
>
> ===================================== END OF MODERATOR'S COMMENT
> Wow, that was smart.  Can you publish the code?
> Chris
>
> Uzytkownik "John Nagle" <nagle@animats.com> napisal w wiadomosci
> news:c7Q8h.17737$B31.6423@newssvr27.news.prodigy.net...
>> James Kanze wrote:
>>> One could, for example,
>>> imagine a language in which you could write code outside of any
>>> function, and in which the start-off routine called by the
>>> system started a separate thread for each object file.  (I
>>> rather doubt that one could write correct code for such a
>>> system, but that's another question:-).)  One could also imagine
>>> that instead of starting in multiple threads, the modules
>>> executed one after another, with the linker doing a topological
>>> sort over the dependancies---that's actually the way some
>>> languages (e.g. Modula-2, and I think Modula-3) work, and there
>>> is currently a proposal to add something similar to C++.  Even
>>> today in C++, code doesn't start in main, but in the
>>> initialization of static objects (and you don't necessarily have
>>> control of the order).
>>
>>     Here's a way you could do something like that in the context
>> of C++ as it exists today.
>>
>>     Provide a library with a function called, say, "threadstart()",
>> which takes a pointer to a member function as an argument.  The
>> intent is that one puts a call to "threadstart" in the constructors
>> of static objects which need a thread of their own.  However, rather
>> than starting immediately, the threads started via "threadstart()"
>> all block on a lock during initalization.  This prevents
>> problems with threads running before static initialization
>> finishes.
>>
>>     "main" then becomes a function in the library containing
>> "threadstart()".  When "main" runs, it releases the lock on
>> all the initial threads, and waits (probably via pthread_join)
>> for them to exit.  Then it exits, allowing the program to exit.
>> This prevents problems with the "main" thread exiting before the
>> other threads and shutting down the program prematurely.
>>
>>     That's a few pages of code, and would provide the functionality
>> the original poster wanted.  No more main program; just objects
>> with threads.
>>
>>     There's a certain elegance to this.  It encourages writing
>> concurrent programs, where objects are active services, rather
>> than passive data.  It's in some ways close to Alan Kay's original
>> concept of objects in Smalltalk.  And it's easy to do.

The above discussion points out that "entry point" may be nicer defined
as "thread of control" rather than main() which implies SINGLE thread
of control. But why have the "relic" main() anyway since most programs
don't give a hoot about command line args? Why make one function
"special"? One could indicate any of a number of "entry points":

entry_point MyProgram.Run():
entry_point MyObject2;
entry_point MyFunction("arg to my function");

That would make threads first class citizens recognized by C++ if
multiple "entry points" were allowed to be specified. Getting rid of
the "special" main() function and making all functions equal and
allowing object methods or even objects as shown above, may be
an improvement (or a start toward one actually) over the main() "relic".

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

<tasjaevan@gmail.com> wrote in message
news:1164196324.880032.205230@b28g2000cwb.googlegroups.com...
>
>
> On Nov 22, 12:28 am, "Tony" <rdnewsNOSPAM2...@sbcglobal.net> wrote:
>> I tried that with a GUI program last night and it ran just fine: the
>> message
>> loop running in the constructor. I don't remember where/when/if WinMain
>> wraps main(). I may try the same thing with a traditional non-GUI program
>> tonight. I wonder what I'm NOT guaranteed by running everything outside
>> of main. (?)
>>
>
> The standard stream objects (cout, cin, cerr) are only guaranteed to be
> constructed once main has started (27.3/2), although you can force them
> to be constructed earlier.

OK, no problem there then (unless one is using streams).

> In practice, on all compilers/platforms I've worked with, all global
> objects of user-defined type (excluding dynamically loaded libraries,
> of course) are constructed before the program enters main. I don't
> recommend relying on that.

OK, no problem there then either (don't rely on the "initialization before
main is entered" as it is error prone and hard to keep track of what's
going on and when).

> If you're using a 3rd-party library which implements main for you (such
> as Win32, where you are expected to provide WinMain, not main),
> services provided by that library may not be available until the
> official client entry point is hit. After all, that's the meaning of
> 'entry point'.

OK, that may be a problem, though my elementary test indicates plausibility
of not requiring a main() or WinMain(). Indeed, some other way to manage
initialization would emerge that could do away with the pesky "will be
initialized before main() is entered" bad-to-rely-on paradigm.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

""Tony"" <rdnewsNOSPAM2006@sbcglobal.net> wrote in message
news:Xh39h.14294$Sw1.1163@newssvr13.news.prodigy.com...
>
> "Mathias Gaunard" <loufoque@remove.gmail.com> wrote in message
> news:456455ae$0$6241$426a34cc@news.free.fr...
>
>> OO is about dynamic message passing following inheritance.
>
> I'd say that OO is fundamentally combining data and behavior.
> Inheritance is a furthering upon the lowest level foundation of
> data + behavior. Also, given that we are talking about C++, I'd
> say "inheritance via method overloading" rather than message
> passing, since C++ doesn't have that concept and it (message
> passing) is the popular higher level architecture paradigm for
> event driven programs and network programs.

"inheritance via method overloading" is wrong of course, but written
in a hurry. So, before everyone attacks, I'll correct it.

C++ enables inheritance of functionality via derivation and
polymorphism via overloading of virtual functions.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Mathias Gaunard wrote:
> Krzysztof Zelechowski wrote:
.
> > I do not know much about coroutines because C++ does not support them;
>
> They can be implemented with setjmp/longjmp, which are part of the standard.

Yes, but the restrictions placed on their use within C++ code render
them very difficult to use safely, except in code that avoids using
many of the features that make C++ different from C.

.
> wchar_t, according to the standard, is not related to unicode.

More precisely, the standard does not impose any connection between
wchar_t and unicode. However, it is the intent and expectation that on
many implementations, they would be closely related.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Tony wrote:

> I'd say that OO is fundamentally combining data and behavior.
> Inheritance is a furthering upon the lowest level foundation of
> data + behavior.

OO without inheritance is object based programming. Which is way
simpler, since it doesn't need dynamic typing, virtual functions,
polymorphism, etc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In message <t%L8h.22487$yl4.1572@newssvr12.news.prodigy.com>, Tony
<rdnewsNOSPAM2006@sbcglobal.net> writes
>
>"James Kanze" <james.kanze@gmail.com> wrote in message
>news:1164112352.865350.165030@h48g2000cwc.googlegroups.com...
>> Dave Harris wrote:
>>> rdnewsNOSPAM2006@sbcglobal.net ("Tony") wrote (abridged):
>>> > You must have jumped into the thread in the middle. The "issue" is that
>>> > main() shoehorns every program into a paradigmic view of what a
>>> > program is.
>>
>>    FWIW: I didn't jump in in the middle; the initial posting
>>    very definitely claimed that "If one desires to write a
>>    program using the OO "paradigm", they can only fake it."
>
>That's right. Because main() is such a UNIX-filter-like thing. It implies
>a program that runs sequentially (like a UNIX filter!). Nothing OO about
>that.
   <snip>

I disagree. main is the way to start up a program, with all its objects
made ready to go.

   John
--
John Harris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <Yd49h.2737$yf7.1360@newssvr21.news.prodigy.net>, Tony
<rdnewsNOSPAM2006@sbcglobal.net> writes
>C++ enables inheritance of functionality via derivation and
>polymorphism via overloading of virtual functions.
You still cannot get the terminology right which makes discussion with
you rather difficult. There are at least two forms of polymorphism:

1) Static polymorphism supported by function overloading and Templates
with template specialisations

2) Dynamic polymorphism which is supported by virtual member functions
and overriding.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Dnia Wed, 22 Nov 2006 21:46:13 GMT, "Tony" skrobie:

> "Mathias Gaunard" <loufoque@remove.gmail.com> wrote in message
> news:456455ae$0$6241$426a34cc@news.free.fr...

> > OO is about dynamic message passing following inheritance.

> I'd say that OO is fundamentally combining data and behavior.
> Inheritance is a furthering upon the lowest level foundation of
> data + behavior. Also, given that we are talking about C++, I'd
> say "inheritance via method overloading"

You wanted to say "overriding". Overloading is creating a new function
(including member) with the same name and different signature.

> rather than message
> passing, since C++ doesn't have that concept and it (message
> passing) is the popular higher level architecture paradigm for
> event driven programs and network programs.

The "message passing" term is rather taken from Smalltalk (which is not a base
language for C++). Which, again, has nothing to do with message passing in
event driven programs, where messages are collected in a queue and execution
relies on dispatching messages from the queue in a loop (although it is
usually possible to request immediate delivery of the message or postpone it
by putting it into a queue, like it is done with WinAPI functions SendMessage
and PostMessage respectively). The important thing about OO here is that this
message passing (immediate delivery, of course) is a thing characteristic for
dynamically typed languages (like Smalltalk), so this does not make sense in
statically typed languages, like C++.

--
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote
in message news:ek3ij9$sj2$1@kujawiak.man.lodz.pl...
> Dnia Wed, 22 Nov 2006 21:46:13 GMT, "Tony" skrobie:
>
>> "Mathias Gaunard" <loufoque@remove.gmail.com> wrote in message
>> news:456455ae$0$6241$426a34cc@news.free.fr...
>
>> > OO is about dynamic message passing following inheritance.
>
>> I'd say that OO is fundamentally combining data and behavior.
>> Inheritance is a furthering upon the lowest level foundation of
>> data + behavior. Also, given that we are talking about C++, I'd
>> say "inheritance via method overloading"
>
> You wanted to say "overriding". Overloading is creating a new function
> (including member) with the same name and different signature.

OK then, to pick nits. But the passage in quotes is wrong anyway. I
corrected
it in a followup to my own post.

>> rather than message
>> passing, since C++ doesn't have that concept and it (message
>> passing) is the popular higher level architecture paradigm for
>> event driven programs and network programs.
>
> The "message passing" term is rather taken from Smalltalk (which is not a
> base
> language for C++).

I realize that too. But still unappropriate in a C++ context. And, I think
"message
passing" and "messaging" should be reserved in the general sense for the
higher
level context (unless of course one is posting in a Smalltalk group).

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
news:ndUGZqLYRZZFFwTD@robinton.demon.co.uk...
> In article <Yd49h.2737$yf7.1360@newssvr21.news.prodigy.net>, Tony
> <rdnewsNOSPAM2006@sbcglobal.net> writes
>>C++ enables inheritance of functionality via derivation and
>>polymorphism via overloading of virtual functions.
> You still cannot get the terminology right which makes discussion with you
> rather difficult. There are at least two forms of polymorphism:
>
> 1) Static polymorphism supported by function overloading and Templates
> with template specialisations

I'm not a template fan. See my most recent post in the thread "The Future of
C++"
in clc++. So, your #1 above, for me is non-existent.

> 2) Dynamic polymorphism which is supported by virtual member functions and
> overriding.

Yep, that's what I was talking about.

Tony
(I'm a practicianer/user, not a "language lawyer"!)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

I do not see why you posted such a thing in that forum, but I will try
to answer your questions.

Tony wrote:

> If one desires to write a program using the OO "paradigm", they can
> only fake it in C++ because it has no inherent support for it from the
> onset

Indeed, support for OOP in C++ isn't as extensive as in other
programming languages.
The main problem being the memory management. For a pure OOP design, you
need garbage collection somewhere.
But since C++ aims to be efficient, it lets you handle memory yourself.


> C++ only supports the procedural technique of C which is main().

Is it the fact that the entry point of the program is a function and not
a member fonction of some obscure singleton what's troubling you?


> Various techniques of hiding this blemish have been concocted by
> frameworks over the years.

I don't know what you're talking about.


> You'd think that with all that desire to do
> something OO from the onset (program initiation), an alternative approach
> to handle program that would have been supported by now: a 'Program'
> class or something. Becauset here isn't something like a 'Program' class,
> it kinda says that OO/classes aren't as "good" (for some reason) as
> procedural C and functions.

There is no need to replace main with a program class or whatever.
If you want one, just write it yourself.
Stuff isn't added to the language unless it's actually useful.


> Is C++ saying that procedural is better than OO? It seems so.

C++ avoids to impose OOP.
You shouldn't pay for what you don't use.

As a general rule, genericity and object-based programming are often
preferable to OOP.

In C++, unlike Java, OOP is only used when needed and/or when it's relevant.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

My penny..

I write software for Investment banking companies. My core concern is
in business domain and not C++ /Java / OO / procedural.

> onset, C++ only supports the procedural technique of C which is main().
I am not clear how existence of main() function suggest that C++ does
not support OO.

> Various techniques of hiding this blemish have been concocted by
> frameworks over the years. You'd think that with all that desire to do
> something OO from the onset (program initiation), an alternative approach
> to handle program that would have been supported by now: a 'Program'
> class or something. Becauset here isn't something like a 'Program' class,
> it kinda says that OO/classes aren't as "good" (for some reason) as
> procedural C and functions.

I have seen 'C' developers first C++ code where he had a huge file
and **everything** in one class. He called it OO because there as a
class keyword in it. He could have done such so called OO work in ANY
language. Because of this incidence, I cant conclude that NO language
support OO.


> Is C++ saying that procedural is better than OO? It seems so.

IMHO, one should not be fanatic about OO.  OO is excellent paradigm but
is not solution to all the problems. There are many many many cases
where a good mix of OO and procedural does the trick.

C++ is just a tool to solve my business problem. It is NOT a solution.
C++ should not (does not) decide or suggest OO / Procedural or mix of
both.

There is no paradigm which is better than another. What ever suites the
requirement is the best.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tony" wrote:
> If one desires to write a program using the OO "paradigm", they can
> only fake it in C++ because it has no inherent support for it from the
> onset, C++ only supports the procedural technique of C which is main().
> Various techniques of hiding this blemish have been concocted by
> frameworks over the years. You'd think that with all that desire to do
> something OO from the onset (program initiation), an alternative approach
> to handle program that would have been supported by now: a 'Program'
> class or something. Becauset here isn't something like a 'Program' class,
> it kinda says that OO/classes aren't as "good" (for some reason) as
> procedural C and functions.
>
> Is C++ saying that procedural is better than OO? It seems so.

Historically, C++ started out as a modification of C; one of the key
goals in the design of C is to maintain a certain amount of backwards
compatiblity with C. No language with that goal can completely abandon
procedural approaches, but C++ has gone just about as far as it can to
embrace OO within that constraint. You can't go much further without
making it a very different language; and if you're going to do that,
there's not much point in calling it C++. If you want a language that
is pure OO from the very beginning, use one; C++ isn't, and can't be,
such a language.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In message <Vhr7h.11912$yl4.9799@newssvr12.news.prodigy.com>, Tony
<rdnewsNOSPAM2006@sbcglobal.net> writes
>If one desires to write a program using the OO "paradigm", they can
>only fake it in C++ because it has no inherent support for it from the
>onset, C++ only supports the procedural technique of C which is main().
>Various techniques of hiding this blemish have been concocted by
>frameworks over the years. You'd think that with all that desire to do
>something OO from the onset (program initiation), an alternative approach
>to handle program that would have been supported by now: a 'Program'
>class or something. Becauset here isn't something like a 'Program' class,
>it kinda says that OO/classes aren't as "good" (for some reason) as
>procedural C and functions.
>
>Is C++ saying that procedural is better than OO? It seems so.

I fail to see why the class *static* function MyClass.main (Java & C#)
would be somehow superior to the free function ::main (C++).

The programmer's code that must be run when the program starts execution
and when it finishes execution must be written somewhere. Wrapping it
inside a function definition is the tidy way to do it. Any additional
wrapping is much more to do with avoiding special cases in the compiler
than with OO or not OO.

  John
--
John Harris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

rdnewsNOSPAM2006@sbcglobal.net ("Tony") writes:

> So maybe the focus on behavior (functions) is putting the cart
> before the horse?

That's pretty funny.  So much code (even C++ code) is all OO
"framework goop" and no computation.  Ultimately, what do we want from
our programs?  Computation, I hope.  They have to *do* something.
Isn't that the horse?  Isn't the structure (OO) the cart?

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"David Abrahams" <dave@boost-consulting.com> wrote in message
news:8764dcb53n.fsf@pereiro.luannocracy.com...
> rdnewsNOSPAM2006@sbcglobal.net ("Tony") writes:
>
>> So maybe the focus on behavior (functions) is putting the cart
>> before the horse?
>
> That's pretty funny.  So much code (even C++ code) is all OO
> "framework goop" and no computation.  Ultimately, what do we want from
> our programs?  Computation, I hope.  They have to *do* something.
> Isn't that the horse?  Isn't the structure (OO) the cart?

I tend to think in terms of nouns before verbs is all I was saying. YMMV.
I think that working with functions first is more inductive rather than
deductive. Like when an analysis of some unfamiliar domain is done and
from that analysis the objects (data, structs, classes, whatever) emerge.
Maybe that's key. If one knows the domain, the noun-things are probably
easy to write down pronto, and their behavior evolves as necessary to
realize the solution. In functional development you obviously still have
the nouns, they're just not as pronounced without the formalism of classes.
But C++ evolved out of the best practice of using structs with functions
that manipulate them. I tend to ask what it is before I ask what it does.
Again, YMMV. Would someone say "it allows users to create and
manipulate graphics" etc., or would they say "it's a paint program"?
I like C++ and think it's orders of magnitude better than C. And I like
it better because it gives better constructs to develop in a less contrived
way (over C). YMMV.

So, yeah, I think in most cases C++
and classes, with focus first on the entities rather than their behavior, is
great and that doing it the C way was just a stepping stone until someone
figured out how to do it better (or at least for a lot of SW development).

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tony" wrote:
>
> So, yeah, I think in most cases C++
> and classes, with focus first on the entities rather than their
> behavior, is great and that doing it the C way was just a stepping
> stone until someone figured out how to do it better (or at least
> for a lot of SW development).

Interestingly, the concept of classes was around long before the C language.

http://en.wikipedia.org/wiki/Simula

So C wasn't designed the way it is because nobody knew better, but because
of the severe limitations of the mini computer system it was implemented on.
It had to be extra lean, beacuse there just wasn't room for anything else.


Later, when you no longer needed a mainframe for it, Bjarne was able to
combine the two ideas in "C with classes". He has the interesting background
of a CS degree from a Scandinavian university, where Simula was very strong,
and then working for Bell Labs, the home of C. Why not use the combination?


Bo Persson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <w1y7h.16546$B31.8921@newssvr27.news.prodigy.net>, Tony
<rdnewsNOSPAM2006@sbcglobal.net> writes
>That's a paradigm! One that doesn't seem consistent with OO. So, one can
>do procedural well with C++, but OO only half-baked. (?)

If you want pure OO use an OO language such as Smalltalk. C++ is and was
designed as a multi-paradigm language. If you choose to be as purely OO
as possible:


#include <universal_class.h>
int main
  universal_class program:
}

And, if you insist, everything else can be OO. Of course you will not
use much, if any, of the Standard Library but that will be your choice.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Tony wrote:
> "Carl Barron" <cbarron413@adelphia.net> wrote in message
> news:171120061941223232%cbarron413@adelphia.net...
>> In article <Vhr7h.11912$yl4.9799@newssvr12.news.prodigy.com>, Tony
>> <rdnewsNOSPAM2006@sbcglobal.net> wrote:
>>
>>> If one desires to write a program using the OO "paradigm", they can
>>> only fake it in C++ because it has no inherent support for it from the
>>> onset, C++ only supports the procedural technique of C which is main().
>>> Various techniques of hiding this blemish have been concocted by
>>> frameworks over the years. You'd think that with all that desire to do
>>> something OO from the onset (program initiation), an alternative approach
>>> to handle program that would have been supported by now: a 'Program'
>>> class or something. Becauset here isn't something like a 'Program' class,
>>> it kinda says that OO/classes aren't as "good" (for some reason) as
>>> procedural C and functions.
>>>
>>> Is C++ saying that procedural is better than OO? It seems so.
>>
>>   C++ says it does not care what paradigm [classical OO,procedural,
>> semi-functional, etc] but the lowest common denominator is a free
>> function which is historically called main().
>
> That's a paradigm! One that doesn't seem consistent with OO. So, one can
> do procedural well with C++, but OO only half-baked. (?)

Java is said to enforce its OO paradigm by requiring everything should
be inside classes, so even main() is a member function of a class.
Do you consider this to be a "full-baked" OO paradigm?
If yes, I don't think it's fundamentally different from the free
function main() in C++; you can code whatever you want in classes,
and all you have to do in main() is to call your entry point.
If no, how do you think things should be to be a "full-baked" OO
paradigm? How would the program work without even an entry point?

>> No matter how you slice it, you must be able to write procedural code
>> to access the inards of your OO classes, but you don't need classes to
>> solve every problem.
>
> I tend to think in terms of things before I think about what those things
> do.
> So maybe the focus on behavior (functions) is putting the cart before the
> horse?

Fine, but describing 'things' doesn't necessarily tell how the program
should work. C++ provides all the tools you need to describe things
(classes), and do you say the "focus" is on functions just because it
wants a single entry function from you? You still write functions even
in OO after all, don't you?

--
Seungbeom Kim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tony":

> If one desires to write a program using the OO "paradigm", they can
> only fake it in C++ because it has no inherent support for it from the
> onset, C++ only supports the procedural technique of C which is main().

[ We'll soon have to move this discussion to an unmoderated newsgroup --
comp.std.c++ is far too censored. ]

You strike me as the kind of person who has taken an OO overdose.

Here's a simple little function:

    double CalcCircleArea(double const r)
    {
        return r*r*3.14;
    }

Are you the kind of person who thinks this should become:

    class CircleAreaCalculator {
    private:

        double const r;

    public:

        CircleAreCalculator(double const arg) : r(arg) {}

        double Calc() const { return r*r*3.14; }
    }

I've seen more than one person whose mind has become completely enveloped
in the idea of OO, so much so that they can't make the right decision when
it comes to how to write a particular piece of code.

Let's say for a moment, that we were to change the entry-point from a
function called "main", to something like:

class Program {
public:

    static void Startup()
    {

    }
};


What exactly would we gain from this?

A program starts at one single point. What difference does it make if this
one single point is an ordinary function, or a static function of a class,
or a member function of a class, or a constructor?

--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tony" wrote:
> "Carl Barron" <cbarron413@adelphia.net> wrote in message
> news:171120061941223232%cbarron413@adelphia.net...
>> In article <Vhr7h.11912$yl4.9799@newssvr12.news.prodigy.com>, Tony
>> <rdnewsNOSPAM2006@sbcglobal.net> wrote:
>>
>>> If one desires to write a program using the OO "paradigm", they
>>> can only fake it in C++ because it has no inherent support for it
>>> from the onset, C++ only supports the procedural technique of C
>>> which is main(). Various techniques of hiding this blemish have
>>> been concocted by frameworks over the years. You'd think that
>>> with all that desire to do something OO from the onset (program
>>> initiation), an alternative approach to handle program that would
>>> have been supported by now: a 'Program' class or something.
>>> Becauset here isn't something like a 'Program' class, it kinda
>>> says that OO/classes aren't as "good" (for some reason) as
>>> procedural C and functions. Is C++ saying that procedural is better than
>>> OO? It seems so.
>>>
>>> Tony
>>>
>>   What has this to do with the standardization of C++. But...
>>
>>   C++ says it does not care what paradigm [classical OO,procedural,
>> semi-functional, etc] but the lowest common denominator is a free
>> function which is historically called main().
>
> That's a paradigm! One that doesn't seem consistent with OO. So,
> one can do procedural well with C++, but OO only half-baked. (?)
>

Yes, and C++ is multi-paradigm. You can do whatever you like. Is that a
problem?

If you want to be serious OO only, you can have the main() function
initialize your Program object, and take it from there. Does that hurt much?


Bo Persson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tony" wrote:
> "Carl Barron" <cbarron413@adelphia.net> wrote in message
> news:171120061941223232%cbarron413@adelphia.net...
> >   C++ says it does not care what paradigm [classical OO,procedural,
> > semi-functional, etc] but the lowest common denominator is a free
> > function which is historically called main().
>
> That's a paradigm! One that doesn't seem consistent with OO. So, one can
> do procedural well with C++, but OO only half-baked. (?)

OK, so if the presence of main() and the absence of a Program class
means OO is half-baked in C++, then it's a pretty good half-baked and
I'll take it. It doesn't seem to impede me from doing any OO things in
the language I want -- and the absence of main() and the presence of
Program wouldn't enable any significant new OO stuff anyway.

I don't see what problem you're describing. All I see is you attaching
a label that sounds bad.

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

<kuyper@wizard.net> wrote in message
news:1163853808.640197.56030@h48g2000cwc.googlegroups.com...
> "Tony" wrote:
>> If one desires to write a program using the OO "paradigm", they can
>> only fake it in C++ because it has no inherent support for it from the
>> onset, C++ only supports the procedural technique of C which is main().
>> Various techniques of hiding this blemish have been concocted by
>> frameworks over the years. You'd think that with all that desire to do
>> something OO from the onset (program initiation), an alternative approach
>> to handle program that would have been supported by now: a 'Program'
>> class or something. Becauset here isn't something like a 'Program' class,
>> it kinda says that OO/classes aren't as "good" (for some reason) as
>> procedural C and functions.
>>
>> Is C++ saying that procedural is better than OO? It seems so.
>
> Historically, C++ started out as a modification of C; one of the key
> goals in the design of C is to maintain a certain amount of backwards
> compatiblity with C. No language with that goal can completely abandon
> procedural approaches, but C++ has gone just about as far as it can to
> embrace OO within that constraint. You can't go much further without
> making it a very different language; and if you're going to do that,
> there's not much point in calling it C++. If you want a language that
> is pure OO from the very beginning, use one; C++ isn't, and can't be,
> such a language.

It doesn't have to be either/or to implement an alternative.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 2006-11-18 07:32, "Tony" wrote:
> "Carl Barron" <cbarron413@adelphia.net> wrote:
>> Tony <rdnewsNOSPAM2006@sbcglobal.net> wrote:
>>
>>> If one desires to write a program using the OO "paradigm", they can
>>> only fake it in C++ because it has no inherent support for it from the
>>> onset, C++ only supports the procedural technique of C which is main().
>>> Various techniques of hiding this blemish have been concocted by
>>> frameworks over the years. You'd think that with all that desire to do
>>> something OO from the onset (program initiation), an alternative approach
>>> to handle program that would have been supported by now: a 'Program'
>>> class or something. Becauset here isn't something like a 'Program' class,
>>> it kinda says that OO/classes aren't as "good" (for some reason) as
>>> procedural C and functions.
>>>
>>> Is C++ saying that procedural is better than OO? It seems so.
:
>>   C++ says it does not care what paradigm [classical OO,procedural,
>> semi-functional, etc] but the lowest common denominator is a free
>> function which is historically called main().
>
> That's a paradigm! One that doesn't seem consistent with OO. So, one
> can do procedural well with C++, but OO only half-baked. (?)

You can think of the whole program as an object (which was instantiated
by loading the program into memory and performing static initialization),
and free functions as its member functions, one of which is main(), and
global variables as its member variables. After this program object has
been instantiated, the runtime invokes its main() member function. Once
main() has returned, the program object is destroyed by invoking static
destructors and functions registered by atexit(), and finally freeing
OS memory and handles etc.

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Tony wrote:
> "David Abrahams" <dave@boost-consulting.com> wrote in message
> news:8764dcb53n.fsf@pereiro.luannocracy.com...
>
>>rdnewsNOSPAM2006@sbcglobal.net ("Tony") writes:
>>That's pretty funny.  So much code (even C++ code) is all OO
>>"framework goop" and no computation.  Ultimately, what do we want from
>>our programs?  Computation, I hope.  They have to *do* something.
>>Isn't that the horse?  Isn't the structure (OO) the cart?

    There's a good point in there.  C++ isn't very good at dealing with
"framework goop".  Frameworks have heavily interlinked "objects", and
the question of when control is "inside" an object becomes ambiguous
as control passes through the same object more than once.  The issues
of "who owns what" for allocation purposes, and, in concurrent
programs, "which lock locks what" dominate.  C and, as a consequence,
C++, provide little help in addressing those issues.

    The "inside" issue is an ongoing problem.  The original
concept of "objects" was that they were supposed to be in
some valid and internally consistent state when control was
not inside the object.  This model falls apart when a member
function of A calls B which calls a member function of A.
This happens all the time inside "framework goop" systems,
and is an common cause of intermittent failures.  It's a serious
problem, and one with which C++ offers no help.

    The Microsoft "Spec#" team is addressing this "inside/outside"
issue, and it's worth taking a look at what they're doing.
They know they have a "framework goop" problem, and are trying
to put some theory under it.

    This problem needs to be addressed if support for threads
is formalized, or the mess will get even worse.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Tony wrote:
> I tend to think in terms of nouns before verbs is all I was saying. YMMV.

I guess you came from Java land. If you need one-paradigm-fits-all
language , stick to what you know , but do not bother others about
presumed "blemishes" of C++ . If you want to explore multiparadigm realm
, learn first. There are good books on C++ style , eg. Jim Coplien, Herb
Sutter, Scott Meyers and others.


B.

--
Remove -trap- when replying. Usun -trap- gdy odpisujesz.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"John G Harris" <news0@nospam.demon.co.uk> wrote in message
news:B21kQJICr2XFFwUM@jgharris.demon.co.uk.nospam.invalid...
> In message <Vhr7h.11912$yl4.9799@newssvr12.news.prodigy.com>, Tony
> <rdnewsNOSPAM2006@sbcglobal.net> writes
>>If one desires to write a program using the OO "paradigm", they can
>>only fake it in C++ because it has no inherent support for it from the
>>onset, C++ only supports the procedural technique of C which is main().
>>Various techniques of hiding this blemish have been concocted by
>>frameworks over the years. You'd think that with all that desire to do
>>something OO from the onset (program initiation), an alternative approach
>>to handle program that would have been supported by now: a 'Program'
>>class or something. Becauset here isn't something like a 'Program' class,
>>it kinda says that OO/classes aren't as "good" (for some reason) as
>>procedural C and functions.
>>
>>Is C++ saying that procedural is better than OO? It seems so.
>
> I fail to see why the class *static* function MyClass.main (Java & C#)
> would be somehow superior to the free function ::main (C++).

Me too.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kuyper@wizard.net writes:

> No language with that goal can completely abandon procedural
> approaches, but C++ has gone just about as far as it can to embrace
> OO within that constraint.

I don't see how that's a constraint on how far you can go with OO.
"OO" isn't the opposite of "procedural."  In fact, every "OO language"
I know of (with the possible exception of outliers like common lisp
and OCaml) is a procedural language.  The opposite of "procedural" is
"functional" or "declarative."

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Sushrut Sardeshmukh" <bestbrain@gmail.com> wrote in message
news:1163862709.421990.10200@e3g2000cwe.googlegroups.com...
>
> My penny..
>
> I write software for Investment banking companies. My core concern is
> in business domain and not C++ /Java / OO / procedural.
>
>> onset, C++ only supports the procedural technique of C which is main().
> I am not clear how existence of main() function suggest that C++ does
> not support OO.

Why read more into it than what was said? No on said that C++ does not
support OO.

> C++ is just a tool to solve my business problem. It is NOT a solution.
> C++ should not (does not) decide or suggest OO / Procedural or mix of
> both.
>
> There is no paradigm which is better than another. What ever suites the
> requirement is the best.

The point is that C++ doesn't support the OO style as much as it does the
procedural style.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Seungbeom Kim" <musiphil@bawi.org> wrote in message
news:ejnfuk$2tf$1@news.Stanford.EDU...

> and all you have to do in main() is to call your entry point.
> If no, how do you think things should be to be a "full-baked" OO
> paradigm? How would the program work without even an entry point?

I was hoping that those who have thought about that and similar issues
and were qualified to address it would chime in. What possibilities emerge
when one throws the main() paradigm away?

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Niklas Matthies" <usenet-nospam@nmhq.net> wrote in message
news:slrnelunli.2ims.usenet-nospam@nmhq.net...
> On 2006-11-18 07:32, "Tony" wrote:
>> "Carl Barron" <cbarron413@adelphia.net> wrote:
>>> Tony <rdnewsNOSPAM2006@sbcglobal.net> wrote:
>>>
>>>> If one desires to write a program using the OO "paradigm", they can
>>>> only fake it in C++ because it has no inherent support for it from the
>>>> onset, C++ only supports the procedural technique of C which is main().
>>>> Various techniques of hiding this blemish have been concocted by
>>>> frameworks over the years. You'd think that with all that desire to do
>>>> something OO from the onset (program initiation), an alternative
>>>> approach
>>>> to handle program that would have been supported by now: a 'Program'
>>>> class or something. Becauset here isn't something like a 'Program'
>>>> class,
>>>> it kinda says that OO/classes aren't as "good" (for some reason) as
>>>> procedural C and functions.
>>>>
>>>> Is C++ saying that procedural is better than OO? It seems so.
> :
>>>   C++ says it does not care what paradigm [classical OO,procedural,
>>> semi-functional, etc] but the lowest common denominator is a free
>>> function which is historically called main().
>>
>> That's a paradigm! One that doesn't seem consistent with OO. So, one
>> can do procedural well with C++, but OO only half-baked. (?)
>
> You can think of the whole program as an object (which was instantiated
> by loading the program into memory and performing static initialization),
> and free functions as its member functions, one of which is main(), and
> global variables as its member variables. After this program object has
> been instantiated, the runtime invokes its main() member function. Once
> main() has returned, the program object is destroyed by invoking static
> destructors and functions registered by atexit(), and finally freeing
> OS memory and handles etc.

And that's exactly how I do think about it. But maybe something is ripe for
picking in all that. Any creative ideas?

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Frederick Gotham" <fgothamNO@SPAM.com> wrote in message
news:BOG7h.16141$j7.333805@news.indigo.ie...
> "Tony":
>
>> If one desires to write a program using the OO "paradigm", they can
>> only fake it in C++ because it has no inherent support for it from the
>> onset, C++ only supports the procedural technique of C which is main().
>
> [ We'll soon have to move this discussion to an unmoderated newsgroup --
> comp.std.c++ is far too censored. ]
>
> You strike me as the kind of person who has taken an OO overdose.

Actually, I'm probably a minimalist, as I like to keep things "easily
digestible"
for future maintenance.

> Let's say for a moment, that we were to change the entry-point from a
> function called "main", to something like:
>
> class Program {
> public:
>
>    static void Startup()
>    {
>
>    }
> };
>
>
> What exactly would we gain from this?

Nothing. It's exactly the same (especially since you included 'static'). I'd
like
to hear peoples' ideas/concepts/thoughts about the whole program
initiation, startup etc. ball of wax, but especially in regards to "OO-ing"
it.
If it's "like an object", maybe it should be one. Maybe not (but doesn't
that
make classes second class citizens?).

> A program starts at one single point.

Maybe that's a paradigm in any of a number of ways.

Tony

(I learned the term 'paradigm' in the 80's while going through quality
management
training. The definition of 'paradigm' that sticks in my mind goes something
like:
"a prevailing view that blinds one to other possibilities". A lot of times I
use the
term more loosely for lack of knowing a better word that means something
more
like "design" or "style". At other times, indeed I do use it as "inside the
box"
thinking).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tony" wrote:

> If one desires to write a program using the OO "paradigm", they can
> only fake it in C++ because it has no inherent support for it from the
> onset,

Are you kidding.  C++'s support for OO is better than that of
many languages which claim to be "pure" OO.  (Java, for example,
lacks multiple inheritance, which is necessary for staticly
typed OO.)

> C++ only supports the procedural technique of C which is main().

C++ requires that the program start with the function main.
Sort of; it actually calls constructors for static objects
before.  So?  The program has to start somewhere.

> Various techniques of hiding this blemish have been concocted by
> frameworks over the years.

Have they?  I've yet to encounter anyone who considered it a
blemish.

> You'd think that with all that desire to do
> something OO from the onset (program initiation), an alternative approach
> to handle program that would have been supported by now: a 'Program'
> class or something.

What does this buy us?

> Because there isn't something like a 'Program' class,
> it kinda says that OO/classes aren't as "good" (for some reason) as
> procedural C and functions.

How does it say that?  It says that there's no point in
requiring an artificial object whose purpose we don't know.
Which sounds like very sound OO thinking to me: sound OO
thinking certainly shouldn't encourage objects without any
purpose.

> Is C++ saying that procedural is better than OO? It seems so.

Not to me.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

David Abrahams wrote:
> kuyper@wizard.net writes:
>
> > No language with that goal can completely abandon procedural
> > approaches, but C++ has gone just about as far as it can to embrace
> > OO within that constraint.
>
> I don't see how that's a constraint on how far you can go with OO.
> "OO" isn't the opposite of "procedural."  In fact, every "OO language"
> I know of (with the possible exception of outliers like common lisp
> and OCaml) is a procedural language.  The opposite of "procedural" is
> "functional" or "declarative."

I agree; I don't see it as a constraint. I'm merely responding to a
complaint which implies that it is a constraint. Even more oddly, he
identifies main() as the key problem, when every single member function
in C++ is just as procedural as main().

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

David Abrahams wrote:
> rdnewsNOSPAM2006@sbcglobal.net ("Tony") writes:

> > So maybe the focus on behavior (functions) is putting the cart
> > before the horse?

> That's pretty funny.  So much code (even C++ code) is all OO
> "framework goop" and no computation.  Ultimately, what do we want from
> our programs?  Computation, I hope.

For a very loose definition of computation, I hope.  Most of my
programs don't "compute" anything, in the classical sense of
"compute".  They manage things: stock market orders, dynamic IP
addresses, etc.  And those things are represented by classes.
All very OO.

I'll admit, however, that I don't quite understand what all this
has to do with the fact that main() is a function.  In order to
manage things, I first have to create them: in the beginning,
there is code, and the code says, let there be these things.
You can play funny games, of course, and say that there is this
miraculous object (whose characteristics we can't really define,
and which serves no useful purpose in the program)) which knows
how to create the other objects.  Or we can lie about it a
little, allow static functions (which are members only with
regards to access rights), and require that main be a static
member of some class.  But I'm not into those sort of games.

> They have to *do* something.
> Isn't that the horse?  Isn't the structure (OO) the cart?

Not necessarilly from a design point of view.  First you decide
what things you need, and how they interact.  And only then do
you write the code to create them.  At least for some types of
applications.  (It's been the case for most of my applications.
But as I said, my applications don't really "calculate" much, in
the classical sense.  In my work, the French word
"ordinateur"---something which puts order into things---is far
more appropriate than "computer".)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Bo Persson" <bop@gmb.dk> wrote in message
news:4saqkqFum7i8U1@mid.individual.net...

>Why not use the combination?

Why dictate policy instead of providing mechanism?

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

""Bo Persson"" <bop@gmb.dk> wrote in message
news:4s86irFu1nu2U1@mid.individual.net...
> "Tony" wrote:
>> "Carl Barron" <cbarron413@adelphia.net> wrote in message
>> news:171120061941223232%cbarron413@adelphia.net...
>>> In article <Vhr7h.11912$yl4.9799@newssvr12.news.prodigy.com>, Tony
>>> <rdnewsNOSPAM2006@sbcglobal.net> wrote:
>>>
>>>> If one desires to write a program using the OO "paradigm", they
>>>> can only fake it in C++ because it has no inherent support for it
>>>> from the onset, C++ only supports the procedural technique of C
>>>> which is main(). Various techniques of hiding this blemish have
>>>> been concocted by frameworks over the years. You'd think that
>>>> with all that desire to do something OO from the onset (program
>>>> initiation), an alternative approach to handle program that would
>>>> have been supported by now: a 'Program' class or something.
>>>> Becauset here isn't something like a 'Program' class, it kinda
>>>> says that OO/classes aren't as "good" (for some reason) as
>>>> procedural C and functions. Is C++ saying that procedural is better
>>>> than OO? It seems so.
>>>>
>>>> Tony
>>>>
>>>   What has this to do with the standardization of C++. But...
>>>
>>>   C++ says it does not care what paradigm [classical OO,procedural,
>>> semi-functional, etc] but the lowest common denominator is a free
>>> function which is historically called main().
>>
>> That's a paradigm! One that doesn't seem consistent with OO. So,
>> one can do procedural well with C++, but OO only half-baked. (?)
>>
>
> Yes, and C++ is multi-paradigm. You can do whatever you like. Is that a
> problem?
>
> If you want to be serious OO only, you can have the main() function
> initialize your Program object, and take it from there. Does that hurt
> much?

I was hoping for the inventors of this stuff to look into the possibilities
and discuss them here (and enlighten us). (Read: this is not a simple
programming issue nor targeted at those without in depth knowledge
of compiler and language implementation and hardware/environment
issues).

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
news:ofklZCWjEsXFFwTU@robinton.demon.co.uk...
> In article <w1y7h.16546$B31.8921@newssvr27.news.prodigy.net>, Tony
> <rdnewsNOSPAM2006@sbcglobal.net> writes
>>That's a paradigm! One that doesn't seem consistent with OO. So, one can
>>do procedural well with C++, but OO only half-baked. (?)
>
> If you want pure OO use an OO language such as Smalltalk. C++ is and was
> designed as a multi-paradigm language.

That's misleading, since one can only do "half-baked" OO. The developer
doesn't
have the choice of doing OO without the "C baggage". But that's not really
issue.
But if one could actually persuade the language lawyers, scientists and
compiler
developers to actually think outside of the box a bit, maybe there's a
possibility
of inventing some really useful, perhaps pivotal things.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tony" wrote:
> <kuyper@wizard.net> wrote in message
> news:1163853808.640197.56030@h48g2000cwc.googlegroups.com...
> > "Tony" wrote:
.
> >> Is C++ saying that procedural is better than OO? It seems so.
> >
> > Historically, C++ started out as a modification of C; one of the key
> > goals in the design of C is to maintain a certain amount of backwards
> > compatiblity with C. No language with that goal can completely abandon
> > procedural approaches, but C++ has gone just about as far as it can to
> > embrace OO within that constraint. You can't go much further without
> > making it a very different language; and if you're going to do that,
> > there's not much point in calling it C++. If you want a language that
> > is pure OO from the very beginning, use one; C++ isn't, and can't be,
> > such a language.
>
> It doesn't have to be either/or to implement an alternative.

If it doesn't have to be either procedural or OO, but can be both, then
in what sense does C++ fall short? It provides all of the support for
procedural programming that C does, and pretty nearly as much support
for OO and generic programming as can reasonably be fit into a language
that has, as one of it's design objectives, backward compatibility with
C.

Don't answer in vague terms claiming that C++ favors procedural
programming. Please identify specific features that you consider to be
lacking that are needed to provide full support for OO, or features
that are present that need to be removed or modified to provide that
support. While you're at it, please identify how the problem you
percieve can be corrected without breaking backward compatibility, not
only with C, but also with current versions of C++.

So far the only specific feature you've mentioned is the procedural
nature of main(). If you find it so objectionable, you can do something
like the following:

#include "program.hpp"
int main(int argc, char *argv[])
{
    program p(argc, argv);
    return p.exit_status();
}

This brings whatever it is that you find so objectionable about main()
to an absolute minimum. Is that minimum really so thoroughly
objectionable? All I'm saying is that if you do find that unacceptable,
you have no choice but to embrace a language that will be incompatible
with all existing C and C++ code. If that's what you feel you have to
do, then there's no point in insisting that the language you embrace be
called C++; it isn't going to happen (and shouldn't, IMO).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tony" wrote:
> "Sushrut Sardeshmukh" <bestbrain@gmail.com> wrote in message
> news:1163862709.421990.10200@e3g2000cwe.googlegroups.com...
.
> Why read more into it than what was said? No on said that C++ does not
> support OO.

I'll just settle for reading what you did say; that's more than
sufficient to justify Sushrut's comments:

> If one desires to write a program using the OO "paradigm", they can
> only fake it in C++ because it has no inherent support for it from the
> onset, C++ only supports the procedural technique of C which is main().

By saying that OO can only be faked in C++, you ARE saying that C++
does not support true OO; you wouldn't need to fake it if the real
thing were supported. In context, your second sentence expresses the
idea that one of the things excluded by the word "only" is the OO
paradigm.

If you want to avoid suggesting that C++ does not support OO, I
strongly recommend against using sentences with this kind of content,
structure and phrasing.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Tony wrote:
> Niklas Matthies wrote:
>> You can think of the whole program as an object (which was instantiated
>> by loading the program into memory and performing static initialization),
>> and free functions as its member functions, one of which is main(), and
>> global variables as its member variables. After this program object has
>> been instantiated, the runtime invokes its main() member function. Once
>> main() has returned, the program object is destroyed by invoking static
>> destructors and functions registered by atexit(), and finally freeing
>> OS memory and handles etc.
>
> And that's exactly how I do think about it. But maybe something is ripe for
> picking in all that. Any creative ideas?

"Creative" idea:

 #define program

 int program::main()
 {
  return 0;
 }


--
Andrei Polushin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"James Kanze" <james.kanze@gmail.com> wrote in message
news:1164020633.069653.118060@m7g2000cwm.googlegroups.com...
> David Abrahams wrote:
>> rdnewsNOSPAM2006@sbcglobal.net ("Tony") writes:
>
>> > So maybe the focus on behavior (functions) is putting the cart
>> > before the horse?
>
>> That's pretty funny.  So much code (even C++ code) is all OO
>> "framework goop" and no computation.  Ultimately, what do we want from
>> our programs?  Computation, I hope.
>
> For a very loose definition of computation, I hope.  Most of my
> programs don't "compute" anything, in the classical sense of
> "compute".  They manage things: stock market orders, dynamic IP
> addresses, etc.  And those things are represented by classes.
> All very OO.
>
> I'll admit, however, that I don't quite understand what all this
> has to do with the fact that main() is a function.

main() may be just a relic from the days when every program was
viewed as one of those unix filters controlled by command line
parameters. I'm surprised no one brought that up yet. Maybe it's
not optimal to shoehorn every program into that paradigm.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Andrei Polushin" <polushin@gmail.com> wrote in message
news:1164043683.869385.262460@h54g2000cwb.googlegroups.com...
> Tony wrote:
>> Niklas Matthies wrote:
>>> You can think of the whole program as an object (which was instantiated
>>> by loading the program into memory and performing static
>>> initialization),
>>> and free functions as its member functions, one of which is main(), and
>>> global variables as its member variables. After this program object has
>>> been instantiated, the runtime invokes its main() member function. Once
>>> main() has returned, the program object is destroyed by invoking static
>>> destructors and functions registered by atexit(), and finally freeing
>>> OS memory and handles etc.
>>
>> And that's exactly how I do think about it. But maybe something is ripe
>> for
>> picking in all that. Any creative ideas?
>
> "Creative" idea:
>
> #define program
>
> int program::main()
> {
> return 0;
> }

 #define unix_filter

 int unix_filter::main(int argc, char *argv[])
 {
 return 0;
 }

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"James Kanze" <james.kanze@gmail.com> wrote in message
news:1164019934.857745.139940@h48g2000cwc.googlegroups.com...
> "Tony" wrote:
>
>> If one desires to write a program using the OO "paradigm", they can
>> only fake it in C++ because it has no inherent support for it from the
>> onset,
>
> Are you kidding.  C++'s support for OO is better than that of
> many languages which claim to be "pure" OO.  (Java, for example,
> lacks multiple inheritance, which is necessary for staticly
> typed OO.)

You must have jumped into the thread in the middle. The "issue" is that
main() shoehorns every program into a paradigmic view of what a
program is. One can argue that main() is a relic from the past and there
may be a "better" abstraction/paradigm and perhaps one that would
yield other beneficial possibilities, not the least of which is more
accessibility to the newbie programmer.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"James Kanze" <james.kanze@gmail.com> wrote in message
news:1164019934.857745.139940@h48g2000cwc.googlegroups.com...
> "Tony" wrote:

>> Various techniques of hiding this blemish have been concocted by
>> frameworks over the years.
>
> Have they?  I've yet to encounter anyone who considered it a
> blemish.

'relic' would have been better than 'blemish'. I didn't mean to enflame.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 2006-11-20 16:18, "Tony" wrote:
> "Niklas Matthies" <usenet-nospam@nmhq.net> wrote:
:
>> You can think of the whole program as an object (which was instantiated
>> by loading the program into memory and performing static initialization),
>> and free functions as its member functions, one of which is main(), and
>> global variables as its member variables. After this program object has
>> been instantiated, the runtime invokes its main() member function. Once
>> main() has returned, the program object is destroyed by invoking static
>> destructors and functions registered by atexit(), and finally freeing
>> OS memory and handles etc.
>
> And that's exactly how I do think about it.

If you do, then how is C++ (which does what I described) anti-OO in
that respect?

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andrei Polushin:

> "Creative" idea:
>
>      #define program
>
>      int program::main()
>      {
>           return 0;
>      }
>


This I like, seems to satisfy everyone.

--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

<kuyper@wizard.net> wrote in message
news:1164023649.612750.36860@m73g2000cwd.googlegroups.com...
> "Tony" wrote:
>> <kuyper@wizard.net> wrote in message
>> news:1163853808.640197.56030@h48g2000cwc.googlegroups.com...
>> > "Tony" wrote:
> .
>> >> Is C++ saying that procedural is better than OO? It seems so.
>> >
>> > Historically, C++ started out as a modification of C; one of the key
>> > goals in the design of C is to maintain a certain amount of backwards
>> > compatiblity with C. No language with that goal can completely abandon
>> > procedural approaches, but C++ has gone just about as far as it can to
>> > embrace OO within that constraint. You can't go much further without
>> > making it a very different language; and if you're going to do that,
>> > there's not much point in calling it C++. If you want a language that
>> > is pure OO from the very beginning, use one; C++ isn't, and can't be,
>> > such a language.
>>
>> It doesn't have to be either/or to implement an alternative.
>
> If it doesn't have to be either procedural or OO, but can be both, then
> in what sense does C++ fall short?

What was meant that implementing an alternative (to the main() paradigm)
doesn't mean eliminating anything that already exists. 'Alternative' as in
'additional' (or "more evolved from what has been learned").

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"James Kanze" <james.kanze@gmail.com> wrote in message
news:1164019934.857745.139940@h48g2000cwc.googlegroups.com...
> "Tony" wrote:

>> You'd think that with all that desire to do
>> something OO from the onset (program initiation), an alternative approach
>> to handle program that would have been supported by now: a 'Program'
>> class or something.
>
> What does this buy us?

Well I was hoping to get the deepest of qualified thinkers to think about
exactly that. I'm all ears. (I mentioned more accessibility to newbie
programmers. But I didn't want to limit the discussion to just my one
Program class thing. ANY and ALL alternative ideas/concepts are valid.
The key of course being keeping an open mind and trying to avoid
paradigmic limitation).

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"James Kanze" <james.kanze@gmail.com> wrote in message
news:1164019934.857745.139940@h48g2000cwc.googlegroups.com...
> "Tony" wrote:

>> Because there isn't something like a 'Program' class,
>> it kinda says that OO/classes aren't as "good" (for some reason) as
>> procedural C and functions.
>
> How does it say that?  It says that there's no point in
> requiring an artificial object whose purpose we don't know.

The topic was started to see what the possibilities are. "whose
purpose we don't know" is indeed the area of research solicited
(but not that narrow of course, as it is only one potential starting
point).

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tony":

>> "Creative" idea:
>>
>> #define program
>>
>> int program::main()
>> {
>> return 0;
>> }
>
>  #define unix_filter
>
>  int unix_filter::main(int argc, char *argv[])
>  {
>  return 0;
>  }


I think Andrei's sarcasm is well placed. All you want to do is put a nice
frilly dress on "main" to make it look like something else (e.g. a member
function).

--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:

I'm approving this, but let's all make sure to be careful about tone here.
We want to make sure to avoid flame wars.

------=_Part_8909_7872375.1164061619890
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

approve<br>comment<br>I'm approving this, but let's all make sure to be careful about tone here. We want to make sure to avoid flame wars.<br>

------=_Part_8909_7872375.1164061619890--


===================================== END OF MODERATOR'S COMMENT
In message <O1d8h.8514$6t.2641@newssvr11.news.prodigy.com>, Tony
<rdnewsNOSPAM2006@sbcglobal.net> writes

   <snip>
>I was hoping for the inventors of this stuff to look into the possibilities
>and discuss them here (and enlighten us). (Read: this is not a simple
>programming issue nor targeted at those without in depth knowledge
>of compiler and language implementation and hardware/environment
>issues).

Well, thank you for dismissing my comments so thoroughly, and in advance
too.

Please tell us some of your thoughts :-

Who should create this program object of yours : the operating system,
the preamble code generated by the compiler, or some preamble code
written by the programmer ?

Where should your program object's class be defined : in the core
language, in the Standard Library, or user-defined ?

Must your program object be a singleton ?

   John

Your sig-separator is broken, by the way.
--
John Harris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

U=BFytkownik ""Tony"" <rdnewsNOSPAM2006@sbcglobal.net> napisa=B3 w wiadom=
o=B6ci=20
news:Vhr7h.11912$yl4.9799@newssvr12.news.prodigy.com...
> If one desires to write a program using the OO "paradigm", they can
> only fake it in C++ because it has no inherent support for it from the
> onset, C++ only supports the procedural technique of C which is main().
> Various techniques of hiding this blemish have been concocted by
> frameworks over the years. You'd think that with all that desire to do
> something OO from the onset (program initiation), an alternative approa=
ch
> to handle program that would have been supported by now: a 'Program'
> class or something. Becauset here isn't something like a 'Program' clas=
s,
> it kinda says that OO/classes aren't as "good" (for some reason) as
> procedural C and functions.
>
> Is C++ saying that procedural is better than OO? It seems so.
>
> Tony

Well, it seems I have finally grasped what it is all about.
My answer will refer to various posts that I am unable to quote
so I decided to attach the answer to the original post.
1.
The fact that every program contains the function main
does not imply you have to use it for any purpose other than returning 0
- which is what you unfortunately have to do.
However, it is a false path to make main a static method; it would buy yo=
u=20
nothing.
You should do your work in the constructor of the global Program object.
If you want to disable main altogether, just throw at the end.
2.
In fact, you can have many such objects.
If you decide throw, only the first of them will run; if you do not, all =
of=20
them will run.
If you group them all in one module, they will run in the order in which =
you=20
place them;
if you do not, the order is unspecified.
It would be interesting to see all of these constructors run in separate=20
threads
- but, alas, C++ does not support threads.  A suitable extension would be=
=20
welcome.
(The current situation is just the opposite: since threads are C-y things=
;
if you spawn a thread in a constructor of a global object, all hell can=20
break loose).
3.
The main reason the OO support in C++ is crippled
is that there is no builtin construct suspend the execution of a method a=
t a=20
well-defined point inside.
Therefore you cannot construct recursive iterators easily.
(A recursive iterator is an iterator corresponding to a situation
where the enumerating function is irreducibly recursive).
4.
The function main, as it is declared, is a dinosaur; who cares about narr=
ow=20
character strings in the global village?
Oh yes, the Americans are an exception.
But they fortunately have customers around the world and they had to lear=
n=20
those things anyway.
Fortunately there are programming environments where you can safely pass=20
your name as an argument to main,
or whatever the function would actually be named.
5.
When you talk about programming without main, you can also talk about=20
plugins.
Plugins are, alas, unsupported by the standard;
they are freestanding persistent objects you can provide to your customer=
 to=20
cooperate with.
The plugin can have one entry point, but it can also have several of them=
;=20
it is completely up to you;
but you have to agree with the customer to use the interface you provide.
The interface of the function main, having taken into account the=20
reservation of the previous paragraph,
is probably the easiest for the end users to call.
6.
A suggestion has been that a programme can be viewed as an object consist=
ing=20
of all its global data,
the function main being its sole method.  But this object is only a=20
hypothetical construct, and it is not well defined.
The reason is that its final shape is not known until the code has been=20
linked
and it contains members that are inaccessible to the programmer and are=20
nowhere declared.
It is not a proper object; no way.
Chris=20


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tony" wrote:
> <kuyper@wizard.net> wrote in message
> news:1164023649.612750.36860@m73g2000cwd.googlegroups.com...
.
> > If it doesn't have to be either procedural or OO, but can be both, then
> > in what sense does C++ fall short?
>
> What was meant that implementing an alternative (to the main() paradigm)
> doesn't mean eliminating anything that already exists. 'Alternative' as in
> 'additional' (or "more evolved from what has been learned").

Why is an alternative needed? Many people have shown you how to make
main() a formality, and do essentially all of your coding using an OO
paradigm. It takes only about 5 lines of code. What's so horrible about
having to define main() that justifies insisting that an alternative be
supported?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tony" wrote:
.
> Well I was hoping to get the deepest of qualified thinkers to think about
> exactly that. I'm all ears. (I mentioned more accessibility to newbie
> programmers. But I didn't want to limit the discussion to just my one
> Program class thing. ...

I think it's pretty clear at this point that there's not many people
participating in this discussion other than you who see this as a
problem. If you want to have a meaningful discussion about this, you
can't just propose a topic that no one else is interested in, and keep
your ears open. You've got to actually suggest an alternative, explain
what you see as it's benefits, and make it clear why you see the
absence of some such alternative as such a serious problem.

> ... ANY and ALL alternative ideas/concepts are valid.
> The key of course being keeping an open mind and trying to avoid
> paradigmic limitation).

Making a clear distinction between ideas and concepts that are valid,
and ones that are not, is essential to rational thought. Keeping an
open mind doesn't mean thinking that every idea is equally valid. It
means paying close attention to the evidence and arguments for a given
idea, and using those things to judge the idea's validity, rather than
simply automatically assuming that it's invalid because different from
what you thought before.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <kso8h.16210$j7.334100@news.indigo.ie>, Frederick Gotham
<fgothamNO@SPAM.com> writes
>I think Andrei's sarcasm is well placed. All you want to do is put a nice
>frilly dress on "main" to make it look like something else (e.g. a member
>function).


Actually there is another option:

class Program {
    Program() {/* the entry code */}
    ~Program(){/* the exit code */}
} program;

int main() {}


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <O1d8h.8515$6t.5829@newssvr11.news.prodigy.com>, Tony
<rdnewsNOSPAM2006@sbcglobal.net> writes
>I was hoping that those who have thought about that and similar issues
>and were qualified to address it would chime in. What possibilities emerge
>when one throws the main() paradigm away?


Well most of us have too much to do already tackling real world
problems. Tough problems like providing good, effective support for
parallel (not just multi-threaded) programming to make good use of
mult-core CPUs.

I obviously have a severe deficiency in the imagination department
because I cannot see what it is you are asking for and how it would
conceivably improve C++.

As I have already said, if you want pure OO use a pure OO language
(though there will be a good deal of procedural code once you get to a
low enough level), That parenthetical remark makes me wonder if there is
some pure OO language built on top of functional programming (probably
just highlights my ignorance)


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

rdnewsNOSPAM2006@sbcglobal.net ("Tony") wrote (abridged):
> You must have jumped into the thread in the middle. The "issue" is that
> main() shoehorns every program into a paradigmic view of what a
> program is.

I think it is the operating system which does that. Most operating systems
need a known entry point. Whether it is spelt program::main or just main
doesn't make much difference because there is no scope for dynamic
polymorphism or access control. Given the entry point you can create what
other objects you like.

There could be advantages from using a class. It would allow multiple
entry points, which could suit, for example, Microsoft Window's UI whereby
objects can be invoked with a variety of verbs (with names like "open",
"edit", "print" etc). A modern OO operating system could have a binary API
which reflected that UI directly. However, the C++ standard tries to be
portable and so aims at the highest common denominator. And Windows aims
to support programs written in languages other than C++.


In your original post you wrote:
> You'd think that with all that desire to do something OO from the
> onset (program initiation)

which I think misses that C++ does not, in fact, have a strong desire to
be OO from the onset. It aims to support a variety of paradigms well.
There is no particular reason for OO to be pre-eminent.

Mostly I think it's just seen as not very important. There are much bigger
problems that the standards committee needs to spend its time on. Just
write a main() which calls program::main() and move on.

-- Dave Harris, Nottingham, UK.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
news:TkQbXnEMWjYFFweQ@robinton.demon.co.uk...
> In article <O1d8h.8515$6t.5829@newssvr11.news.prodigy.com>, Tony
> <rdnewsNOSPAM2006@sbcglobal.net> writes
>>I was hoping that those who have thought about that and similar issues
>>and were qualified to address it would chime in. What possibilities emerge
>>when one throws the main() paradigm away?
>
>
> I obviously have a severe deficiency in the imagination department because
> I cannot see what it is you are asking for and how it would conceivably
> improve C++.

I don't know how to make it any more plain:

What possibilities emerge when one throws the main() paradigm away?

Pretend you know nothing of main() and then make it work a new way.
It's an open-ended question, feel free to take it to the limit: imagine you
had control of all other hardware and software design/engineering and
impose requirements on those if you wish. (Not that I personally wouldn't
prefer a practical solution though).

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
news:BE5fPRFqZjYFFw$L@robinton.demon.co.uk...
> In article <kso8h.16210$j7.334100@news.indigo.ie>, Frederick Gotham
> <fgothamNO@SPAM.com> writes
>>I think Andrei's sarcasm is well placed. All you want to do is put a nice
>>frilly dress on "main" to make it look like something else (e.g. a member
>>function).
>
>
> Actually there is another option:
>
> class Program {
>    Program() {/* the entry code */}
>    ~Program(){/* the exit code */}
> } program;
>
> int main() {}

(I've actually tried the above a long time ago in experimentation, but I
don't
remember what the result was. Maybe I'll try it again tonight just for fun.)

I think it was this thread (maybe the companion one in clc++) that I
mentioned
that in questioning the sanity of running an entire program in a
constructor. It
_seems_ fragile for some reason, or just not right. Why should one object be
more important than another? Maybe if one object should have more
importance,
that should be developer-defined. The fact that main() runs sequentially
from top
to bottom may be limiting: if you're writing a UNIX filter, fine, use main;
but
maybe an event-driven program could use some low-level support too. I think
comprehensively surveying existing technologies would probably be a good
starting point in researching this topic: what do other languages have? How
can programs be categorized? etc.

The above example probably helps to think about the purpose (or necessity,
if so)
of main() in bringing order to some of the startup chaos. Maybe just a bunch
of objects and "something else" would be simple and elegant. Maybe that
something else is something hidden from the programmer. There's a lot of
possibilities. One of those objects doesn't necessarily have to be an
instance
of a Program class (maybe that would be good, maybe not). Maybe "getting
rid of" (providing an alternative I mean) main() would lead to better
management
of the initialization process or the conceptualization (learning) of it.
Maybe there
is some kind of binder, maybe not. Maybe that is main(), but that seems
rather
far fetched (to me) after all this time that there aren't some better
organization
possibilities.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Tony wrote:
> "Seungbeom Kim" <musiphil@bawi.org> wrote in message
> news:ejnfuk$2tf$1@news.Stanford.EDU...
>
>> and all you have to do in main() is to call your entry point.
>> If no, how do you think things should be to be a "full-baked" OO
>> paradigm? How would the program work without even an entry point?
>
> I was hoping that those who have thought about that and similar issues
> and were qualified to address it would chime in. What possibilities emerge
> when one throws the main() paradigm away?

I feel so strange to see that all after having made a sensational
allegation without any convincing basis, you're now asking people
for the basis of your claim. The question you're asking is exactly
what you're supposed to answer to support your claim.

Some general rules for discussion:
- Don't make a claim if you cannot argue with enough bases.
- Don't attach labels that sound bad without any concrete bases.
- Listen to people and respond to their questions.
  In particular, repeating your claim is not a valid response.
- Be specific and concrete in what you claim.

--
Seungbeom Kim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Tony wrote:
> "Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
> news:TkQbXnEMWjYFFweQ@robinton.demon.co.uk...
>> In article <O1d8h.8515$6t.5829@newssvr11.news.prodigy.com>, Tony
>> <rdnewsNOSPAM2006@sbcglobal.net> writes
>>> I was hoping that those who have thought about that and similar issues
>>> and were qualified to address it would chime in. What possibilities emerge
>>> when one throws the main() paradigm away?
>>
>> I obviously have a severe deficiency in the imagination department because
>> I cannot see what it is you are asking for and how it would conceivably
>> improve C++.
>
> I don't know how to make it any more plain:
>
> What possibilities emerge when one throws the main() paradigm away?
>
> Pretend you know nothing of main() and then make it work a new way.
> It's an open-ended question, feel free to take it to the limit: imagine you
> had control of all other hardware and software design/engineering and
> impose requirements on those if you wish. (Not that I personally wouldn't
> prefer a practical solution though).

I'd keep main() and I'd add a function called upon program exit, called
maout().

Andrei

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tony" wrote:
> "Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
> news:TkQbXnEMWjYFFweQ@robinton.demon.co.uk...
> > I obviously have a severe deficiency in the imagination department because
> > I cannot see what it is you are asking for and how it would conceivably
> > improve C++.
>
> I don't know how to make it any more plain:
>
> What possibilities emerge when one throws the main() paradigm away?

I don't know how to make it any more plain either:

What problem are you trying to solve?

> Pretend you know nothing of main() and then make it work a new way.
> It's an open-ended question, feel free to take it to the limit: imagine you
> had control of all other hardware and software design/engineering and
> impose requirements on those if you wish. (Not that I personally wouldn't
> prefer a practical solution though).

I suppose if we wanted to we could pretend all sorts of things. I just
don't see the point, and you're not really doing anything to make it
clear.

Please explain why you think the "main() paradigm" should be done away
with.

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Dave Harris wrote:
> rdnewsNOSPAM2006@sbcglobal.net ("Tony") wrote (abridged):
> > You must have jumped into the thread in the middle. The "issue" is that
> > main() shoehorns every program into a paradigmic view of what a
> > program is.

    FWIW: I didn't jump in in the middle; the initial posting
    very definitely claimed that "If one desires to write a
    program using the OO "paradigm", they can only fake it."

> I think it is the operating system which does that. Most operating systems
> need a known entry point. Whether it is spelt program::main or just main
> doesn't make much difference because there is no scope for dynamic
> polymorphism or access control. Given the entry point you can create what
> other objects you like.

Technically speaking you're right.  Most operating systems start
each program as a single process with a single thread.  But
typically, you as a user don't see that: under Unix, for
example, the start-up point is typically in an object file
called crt0.o (crt here meaning C runtime, and not cathode ray
tube).  And it is not called main.  One could, for example,
imagine a language in which you could write code outside of any
function, and in which the start-off routine called by the
system started a separate thread for each object file.  (I
rather doubt that one could write correct code for such a
system, but that's another question:-).)  One could also imagine
that instead of starting in multiple threads, the modules
executed one after another, with the linker doing a topological
sort over the dependancies---that's actually the way some
languages (e.g. Modula-2, and I think Modula-3) work, and there
is currently a proposal to add something similar to C++.  Even
today in C++, code doesn't start in main, but in the
initialization of static objects (and you don't necessarily have
control of the order).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"James Kanze" <james.kanze@gmail.com> writes:

>> So much code (even C++ code) is all OO "framework goop" and no
>> computation.  Ultimately, what do we want from our programs?
>> Computation, I hope.
>
> For a very loose definition of computation, I hope.  Most of my
> programs don't "compute" anything, in the classical sense of
> "compute".  They manage things:

I note the word "manage" precedes "things."

> stock market orders, dynamic IP addresses, etc.  And those things
> are represented by classes.  All very OO.

I've got nothing against OO.  Properly applied, it's a wonderful
thing.

>> They have to *do* something.  Isn't that the horse?  Isn't the
>> structure (OO) the cart?
>
> Not necessarilly from a design point of view.  First you decide
> what things you need, and how they interact.
                            ^^^^^^^^^^^^^^^^^
Yeah, computation.

> And only then do you write the code to create them.

> At least for some types of applications.  (It's been the case for
> most of my applications.  But as I said, my applications don't
> really "calculate" much, in the classical sense.

I didn't say "calculate" and if I had I wouldn't have meant it in the
classical sense :)

> In my work, the French word "ordinateur"---something which puts
> order into things---is far more appropriate than "computer".)

Nice.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
news:BE5fPRFqZjYFFw$L@robinton.demon.co.uk...
> In article <kso8h.16210$j7.334100@news.indigo.ie>, Frederick Gotham
> <fgothamNO@SPAM.com> writes
>>I think Andrei's sarcasm is well placed. All you want to do is put a nice
>>frilly dress on "main" to make it look like something else (e.g. a member
>>function).
>
>
> Actually there is another option:
>
> class Program {
>    Program() {/* the entry code */}
>    ~Program(){/* the exit code */}
> } program;
>
> int main() {}

I tried that with a GUI program last night and it ran just fine: the message
loop running in the constructor. I don't remember where/when/if WinMain
wraps main(). I may try the same thing with a traditional non-GUI program
tonight. I wonder what I'm NOT guaranteed by running everything outside
of main. (?)

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Niklas Matthies wrote:
>>> You can think of the whole program as an object (which was instantiated
>>> by loading the program into memory and performing static initialization),
>>> and free functions as its member functions, one of which is main(), and
>>> global variables as its member variables. After this program object has
>>> been instantiated, the runtime invokes its main() member function. Once
>>> main() has returned, the program object is destroyed by invoking static
>>> destructors and functions registered by atexit(), and finally freeing
>>> OS memory and handles etc.
>> And that's exactly how I do think about it.
>
> If you do, then how is C++ (which does what I described) anti-OO in
> that respect?

it seems to be that Tony is simply unhappy with the concept of global
namespace; had C++ prohibited "things" being put in global namespace
(free functions, static objects etc.) and insisted on programmers using
some "wrapping" in a form of classes, he wouldn't have to imagine that
the whole program is an object; it would just *had* to be an object. Not
that I like it (because it's just fancy dress and more code to write
with no real meaning, except to satisfy some imagined "requirements")
but surely, we wouldn't have those pesky free functions that have no
place in real OOP world. Problem solved!

Now, can someone pls. hand me some Java textbook? I need to find
solution for few other problems lurking in C++ ...


B.



--
Remove -trap- when replying. Usun -trap- gdy odpisujesz.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"James Kanze" <james.kanze@gmail.com> wrote in message
news:1164112352.865350.165030@h48g2000cwc.googlegroups.com...
> Dave Harris wrote:
>> rdnewsNOSPAM2006@sbcglobal.net ("Tony") wrote (abridged):
>> > You must have jumped into the thread in the middle. The "issue" is that
>> > main() shoehorns every program into a paradigmic view of what a
>> > program is.
>
>    FWIW: I didn't jump in in the middle; the initial posting
>    very definitely claimed that "If one desires to write a
>    program using the OO "paradigm", they can only fake it."

That's right. Because main() is such a UNIX-filter-like thing. It implies
a program that runs sequentially (like a UNIX filter!). Nothing OO about
that.
But not that the goal is to just do OO for OO's sake. But that if one
escapes
the main() paradigm, that there may be a better approach. An OO approach
as an alternative indeed seems particularly lucrative. Just to add another
ingredient, maybe if in pondering the alternative approaches, what if
threads
were recognized first class citizens? Would that help "the/a" better
solution
emerge? There's a lot of ways of approaching the "problem" which seems to
be rather uninvestigated at this point as far as I can tell from the
responses
in this thread.

Yes, I believe main() heavily slants the perception of what a program is and
that the OO paradigm is relegated to "just something you can build on top of
lower level facilities" rather than having something from the start that is
OO and is even better than sequential main(). Of course, thinking that
abstractly
is going to frustrate some. Oh well.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
> One could, for example,
> imagine a language in which you could write code outside of any
> function, and in which the start-off routine called by the
> system started a separate thread for each object file.  (I
> rather doubt that one could write correct code for such a
> system, but that's another question:-).)  One could also imagine
> that instead of starting in multiple threads, the modules
> executed one after another, with the linker doing a topological
> sort over the dependancies---that's actually the way some
> languages (e.g. Modula-2, and I think Modula-3) work, and there
> is currently a proposal to add something similar to C++.  Even
> today in C++, code doesn't start in main, but in the
> initialization of static objects (and you don't necessarily have
> control of the order).

     Here's a way you could do something like that in the context
of C++ as it exists today.

     Provide a library with a function called, say, "threadstart()",
which takes a pointer to a member function as an argument.  The
intent is that one puts a call to "threadstart" in the constructors
of static objects which need a thread of their own.  However, rather
than starting immediately, the threads started via "threadstart()"
all block on a lock during initalization.  This prevents
problems with threads running before static initialization
finishes.

     "main" then becomes a function in the library containing
"threadstart()".  When "main" runs, it releases the lock on
all the initial threads, and waits (probably via pthread_join)
for them to exit.  Then it exits, allowing the program to exit.
This prevents problems with the "main" thread exiting before the
other threads and shutting down the program prematurely.

     That's a few pages of code, and would provide the functionality
the original poster wanted.  No more main program; just objects
with threads.

     There's a certain elegance to this.  It encourages writing
concurrent programs, where objects are active services, rather
than passive data.  It's in some ways close to Alan Kay's original
concept of objects in Smalltalk.  And it's easy to do.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Koitof wrote:

> 1.
> The fact that every program contains the function main
> does not imply you have to use it for any purpose other than returning 0
> - which is what you unfortunately have to do.
> However, it is a false path to make main a static method; it would buy you
> nothing.
> You should do your work in the constructor of the global Program object.
> If you want to disable main altogether, just throw at the end.
> 2.
> In fact, you can have many such objects.
> If you decide throw, only the first of them will run; if you do not, all of
> them will run.
> If you group them all in one module, they will run in the order in which you
> place them;
> if you do not, the order is unspecified.
> It would be interesting to see all of these constructors run in separate
> threads
> - but, alas, C++ does not support threads.  A suitable extension would be
> welcome.
> (The current situation is just the opposite: since threads are C-y things;
> if you spawn a thread in a constructor of a global object, all hell can
> break loose).

Why are you talking about throwing exceptions? It doesn't even seem to
be valid cases for exception usage.

And what's the problem with constructors?
It's not any more dangerous than using threads everywhere else.


> 3.
> The main reason the OO support in C++ is crippled
> is that there is no builtin construct suspend the execution of a method at a
> well-defined point inside.

Such a functionality would be coroutines or continuations.
You can actually get more or less the same things by storing state
values as member variables.

And I don't see how it's related to OO at all.
OO is about dynamic message passing following inheritance.


> Therefore you cannot construct recursive iterators easily.
> (A recursive iterator is an iterator corresponding to a situation
> where the enumerating function is irreducibly recursive).

I'm afraid I don't see why it needs coroutines or even how coroutines
would make it easier.


> 4.
> The function main, as it is declared, is a dinosaur; who cares about narrow
> character strings in the global village?
> Oh yes, the Americans are an exception.

Because wide character strings are better?
I wouldn't ever want to use either for internationalization. And if I
have to use one, I would rather use utf-8 inside of chars.


> Fortunately there are programming environments where you can safely pass
> your name as an argument to main,
> or whatever the function would actually be named.

You can do it with any environment which has a locale that supports the
characters for your name.
And that should be the case of your environment, unless you chose to use
something that doesn't care about your language.
But still, being locale specific is usually not a good idea.

Better have unicode. But C++ has no good unicode support, and will not
have before a long time.
The first step is to have a good unicode string type.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

If one desires to write a program using the OO "paradigm", they can
only fake it in C++ because it has no inherent support for it from the
onset, C++ only supports the procedural technique of C which is main().
Various techniques of hiding this blemish have been concocted by
frameworks over the years. You'd think that with all that desire to do
something OO from the onset (program initiation), an alternative approach
to handle program that would have been supported by now: a 'Program'
class or something. Becauset here isn't something like a 'Program' class,
it kinda says that OO/classes aren't as "good" (for some reason) as
procedural C and functions.

Is C++ saying that procedural is better than OO? It seems so.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

* Tony:
>
> Is C++ saying that procedural is better than OO?

I may be blind, but I fail to see the connection to the C++ standard.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <Vhr7h.11912$yl4.9799@newssvr12.news.prodigy.com>, Tony
<rdnewsNOSPAM2006@sbcglobal.net> wrote:

> If one desires to write a program using the OO "paradigm", they can
> only fake it in C++ because it has no inherent support for it from the
> onset, C++ only supports the procedural technique of C which is main().
> Various techniques of hiding this blemish have been concocted by
> frameworks over the years. You'd think that with all that desire to do
> something OO from the onset (program initiation), an alternative approach
> to handle program that would have been supported by now: a 'Program'
> class or something. Becauset here isn't something like a 'Program' class,
> it kinda says that OO/classes aren't as "good" (for some reason) as
> procedural C and functions.
>
> Is C++ saying that procedural is better than OO? It seems so.
>
> Tony
>
   What has this to do with the standardization of C++. But...

   C++ says it does not care what paradigm [classical OO,procedural,
semi-functional, etc] but the lowest common denominator is a free
function which is historically called main().

No matter how you slice it, you must be able to write procedural code
to access the inards of your OO classes, but you don't need classes to
solve every problem.

Not every car is a Ford, but every car has an engine :)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Carl Barron" <cbarron413@adelphia.net> wrote in message
news:171120061941223232%cbarron413@adelphia.net...
> In article <Vhr7h.11912$yl4.9799@newssvr12.news.prodigy.com>, Tony
> <rdnewsNOSPAM2006@sbcglobal.net> wrote:
>
>> If one desires to write a program using the OO "paradigm", they can
>> only fake it in C++ because it has no inherent support for it from the
>> onset, C++ only supports the procedural technique of C which is main().
>> Various techniques of hiding this blemish have been concocted by
>> frameworks over the years. You'd think that with all that desire to do
>> something OO from the onset (program initiation), an alternative approach
>> to handle program that would have been supported by now: a 'Program'
>> class or something. Becauset here isn't something like a 'Program' class,
>> it kinda says that OO/classes aren't as "good" (for some reason) as
>> procedural C and functions.
>>
>> Is C++ saying that procedural is better than OO? It seems so.
>>
>> Tony
>>
>   What has this to do with the standardization of C++. But...
>
>   C++ says it does not care what paradigm [classical OO,procedural,
> semi-functional, etc] but the lowest common denominator is a free
> function which is historically called main().

That's a paradigm! One that doesn't seem consistent with OO. So, one can
do procedural well with C++, but OO only half-baked. (?)

>
> No matter how you slice it, you must be able to write procedural code
> to access the inards of your OO classes, but you don't need classes to
> solve every problem.

I tend to think in terms of things before I think about what those things
do.
So maybe the focus on behavior (functions) is putting the cart before the
horse?

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

""Alf P. Steinbach"" <alfps@start.no> wrote in message
news:4s70jeFu0gm3U1@mid.individual.net...
>* Tony:
>>
>> Is C++ saying that procedural is better than OO?
>
> I may be blind, but I fail to see the connection to the C++ standard.

It's directly related: why is it like it is? How can it be better? Can it
be better? To where will it evolve? Will it stagnate in its tracks for its
attachment to backward compatibility (C)? What are the possibilities
if some stuff is rethought, rearchitected or jettisoned?

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]