>>>>> On Fri, 27 Aug 1993 17:13:22 GMT, maxtal@physics.su.OZ.AU (John Max Skaller) said:

> Right. In particular, 'cin' and 'cout' and 'main' should be
> removed from the language specification because they are operating
> system dependent.

I can agree with cin and cout---they're part of a standard library,
not a part of the language---but main?

Using a particular function to start your program is the way that C,
and therefore C++ do things, and I think it is right and proper
(assuming that this is kept) that the standard should say what this
function should be called, and, for compatibility with C it should be
called main, at least by default.

> --
>         JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
>  Maxtal Pty Ltd,      CSERVE:10236.1703
>         6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
>         NSW 2131, AUSTRALIA
--
Bruce                    Institute for Advanced Scientific Computing
bruce@liverpool.ac.uk    University of Liverpool

Bruce Stephens (bruce@liverpool.ac.uk) wrote:
: >>>>> On Fri, 27 Aug 1993 17:13:22 GMT, maxtal@physics.su.OZ.AU (John Max Skaller) said:

: > Right. In particular, 'cin' and 'cout' and 'main' should be
: > removed from the language specification because they are operating
: > system dependent.

: I can agree with cin and cout---they're part of a standard library,
: not a part of the language---but main?

: Using a particular function to start your program is the way that C,
: and therefore C++ do things, and I think it is right and proper
: (assuming that this is kept) that the standard should say what this
: function should be called, and, for compatibility with C it should be
: called main, at least by default.

Just look at the standard "main" routine for MS Windows.
--

 JON WEYGANDT

 Lockheed Missiles and Space Co.
 Sunnyvale CA
 ciemjw@zuni.litc.lockheed.com

bruce@liverpool.ac.uk (Bruce Stephens) writes:

>>>>>> On Fri, 27 Aug 1993 17:13:22 GMT, maxtal@physics.su.OZ.AU (John Max Skaller) said:
>
>> Right. In particular, 'cin' and 'cout' and 'main' should be
>> removed from the language specification because they are operating
>> system dependent.

As is exit(), since the exit status is operating system dependant.

>I can agree with cin and cout---they're part of a standard library,
>not a part of the language---but main?
>
>Using a particular function to start your program is the way that C,
>and therefore C++ do things, and I think it is right and proper
>(assuming that this is kept) that the standard should say what this
>function should be called, and, for compatibility with C it should be
>called main, at least by default.

Agreed, but what about the parameters (argc, argv, env), and the return
value from main? If you want main() to be completely operating system
independant, it would have to be void main(void), and all interface
with the operating system would have to be through function calls
or global variables specified in some header file.

On the other hand, it's quite easy to implement a more standard int
main(int, char**) even on obscure operating systems, by simply passing
in an empty argument list and ignoring the return value.  Similarly
`cin' and `cout' can be made equivalent to /dev/null.
So there's not much advantage in removing these from the language
definition.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

In article <1993Aug31.202733.2752@butch.lmsc.lockheed.com> ciemjw@zuni.litc.lockheed.com (Jon B. Weygandt) writes:
>Bruce Stephens (bruce@liverpool.ac.uk) wrote:
>
>: Using a particular function to start your program is the way that C,
>: and therefore C++ do things, and I think it is right and proper
>: (assuming that this is kept) that the standard should say what this
>: function should be called, and, for compatibility with C it should be
>: called main, at least by default.
>
>Just look at the standard "main" routine for MS Windows.

Another poster mentioned the possibility of accessing the operating
system through global objects and functions.  Personally, I think
using this approach in MS Windows programming is much clearer,
cleaner, and more uniform than fiddling around with WinMain().  I'd
be interested to see someone come up with a library that implemented
WinMain, storing the variables passed in a global object, and then
calling main() as usual.  Then one would not have to pass these
variables to OO windows librarys (like Borland Applications
Frameworks), resulting in a simpler, more intuitive interface.

-Jonathan Aldrich

In article <1993Aug19.222917.3854@borland.com> pete@borland.com (Pete Becker) writes:
> In article <1993Aug19.160919.1376@euniice.canada.dg.com>,
> Allen B. Taylor <allen@eUNiiCE.canada.dg.com> wrote:
> >The answer is that the virtual function index syntax is a Borland extension to
> >the C++ language which is used in the OWL environment.  Many of those who
> >replied said that they don't mind using this proprietary language extension
> >since if you're using OWL, you must already be running Borland's C++ compiler.
>
>  DDVTs are not proprietary. We have no objection whatsoever to other
> vendors implementing them.

But they would be pretty crazy to do so. I don't see Borland proposing
them to the ANSI committee (and I think the likelihood of the committee
accepting such a kludge is about zero).

> >One other person who responded indicated that Microsoft solved the problem in a
> >slightly different manner, providing the same functionality yet using standard
> >C++ syntax.
>
>  I haven't looked at MFC 2, but version 1 relied on a couple of
> non-standard language constructs. Microsoft said they were ambiguities in the
> language specification. As far as I know, no other vendor had thought that
> the language definition was ambiguous in this area, nor had any other vendor
> interpreted the language definition in the way Microsoft did.

At least one other compiler vendor has licenced MFC (presumably MFC 2)
from Microsoft, and includes it with their latest announced product.

Can you say "industry standard" :-?

[The other compiler vendor is Symantec. My views on their treatment of the
once excellent Zortech compiler they took over are somewhat ambivalent. I
intend to see what other users say about their latest product before
buying a copy :-( ]


--
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.

In article <1993Aug23.180233.13704@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>In article <1993Aug19.160919.1376@eUNiiCE.canada.dg.com> allen@eUNiiCE.canada.dg.com (Allen B. Taylor) writes:
>>Now, I shall duck my head for the usually "my compiler/library's better than
>>yours" posts that are sure come.
>|---
>|Allen B. Taylor
>
>Naw, I'll try to resist the temptation.  Note from the "standards" point
>of view one should hardly expect a language to support features peculiar
>to one operating system [although C might argue against this point of view]
>What proprietory extensions a particular compiler vendor chooses to add
>to their compiler is basically their business -- as long as it doesn't
>interfere with the compilation of conforming programs.

 Right. In particular, 'cin' and 'cout' and 'main'
should be removed from the language specification because they
are operating system dependent.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

I've recently taken on the task of learning MS Windows programming in C++
using Borland's OWL (Object Windows Library).  The training materials document
a C++ syntax that I'm unfamiliar with.  I believe they call it a virtual
function index.  The syntax resembles that of a pure specifier, except the zero
is now an integer index in brackets.  Here's an example:

 virtual int funcname(type_spec,...) = [int_expression];

Does anyone know if this syntax is a proposed valid syntax or if it's some
invention of Borland's?  If it's a proposed ANSI syntax, I'd like to know more
about it.  I've read through the entire ARM and don't recall anything like it.
But, as always, things don't stand still very long and someone in some
committee somewhere might have decided this virtual function index was a good
idea.  Any info is appreciated.

BTW, please reply via e-mail or cross-post to comp.lang.c++ or comp.std.c++.  I
don't normally subscribe to the other groups I've posted this note to.  Thanks.
---
allen@eUNiiCE.canada.dg.com (Allen B. Taylor)
  -- or --
allen_taylor@dgc.ceo.dg.com

In article <1993Aug17.181814.17396@eUNiiCE.canada.dg.com>, allen@eUNiiCE.canada.dg.com (Allen B. Taylor) writes:
|> I've recently taken on the task of learning MS Windows programming in C++
|> using Borland's OWL (Object Windows Library).  The training materials document
|> a C++ syntax that I'm unfamiliar with.  I believe they call it a virtual
|> function index.  The syntax resembles that of a pure specifier, except the zero
|> is now an integer index in brackets.  Here's an example:
|>
|>  virtual int funcname(type_spec,...) = [int_expression];
|>
|> Does anyone know if this syntax is a proposed valid syntax or if it's some
|> invention of Borland's?  If it's a proposed ANSI syntax, I'd like to know more
|> about it.  I've read through the entire ARM and don't recall anything like it.
|> But, as always, things don't stand still very long and someone in some
|> committee somewhere might have decided this virtual function index was a good
|> idea.  Any info is appreciated.
|>

It's an invention of Borland, and a bloomin' useful one at that.  It allows the
compiler to map WM_xxxx and WM_COMMAND messages from MS windows directly to
a member function, i.e. all you do in your class derived from TWindowsObject is
specify something like

  classs MyWindow: public TWindowsObject
  {
  public:
    virtual void WMSize(RTMessage msg) = [WM_FIRST + WM_SIZE];
  };

and bingo, everytime your window is resized you'll end up in WMSize (by some magic
called DDVT, dynamic dispatch virtual tables).

It make writing Windows apps a snap, since each member function has a "this" pointer
to get access to class variables, and each member function can be kept nice
and small.  When your class grows to about 50 member functions you really see
the benefit compared with the huge switch-case statements needed in C.

I would really like to see something like this made into a part of the language,
and to be more general than just a binding to Windows, i.e. allow the user to
control the DDVT process, perhaps with hook routines called from within the runtime.
For example, you could (possibly) want to implement a real-time system where a
class member was bound to an interrupt.  Any other ideas?

Simon.

I have received many responses to my question regarding the virtual function
index.  Thank you for all your replies.

The answer is that the virtual function index syntax is a Borland extension to
the C++ language which is used in the OWL environment.  Many of those who
replied said that they don't mind using this proprietary language extension
since if you're using OWL, you must already be running Borland's C++ compiler.

One other person who responded indicated that Microsoft solved the problem in a
slightly different manner, providing the same functionality yet using standard
C++ syntax.  This person also indicated to me that Microsoft has licensed their
package - Microsoft Foundation Classes - to other compiler vendors.  This seems
to me to be the better route:  buy my compiler from the compiler vendor I like,
buy my class libraries from the vendor that makes most sense (MS Windows =
Microsoft = Microsoft Foundation Classes).  I can't speak to the quality, cost,
or whatever of MFC. I can say that I will be investigating it because of their
seemingly more standard approach.

Now, I shall duck my head for the usually "my compiler/library's better than
yours" posts that are sure come.
---
Allen B. Taylor
National Software Support Representative
Data General (Canada) Inc.
allen@euniice.canada.dg.com or
allen_taylor@dgc.ceo.dg.com

In article <1993Aug19.160919.1376@euniice.canada.dg.com>,
Allen B. Taylor <allen@eUNiiCE.canada.dg.com> wrote:
>I have received many responses to my question regarding the virtual function
>index.  Thank you for all your replies.
>
>The answer is that the virtual function index syntax is a Borland extension to
>the C++ language which is used in the OWL environment.  Many of those who
>replied said that they don't mind using this proprietary language extension
>since if you're using OWL, you must already be running Borland's C++ compiler.
>

 DDVTs are not proprietary. We have no objection whatsoever to other
vendors implementing them.

>One other person who responded indicated that Microsoft solved the problem in a
>slightly different manner, providing the same functionality yet using standard
>C++ syntax.

 I haven't looked at MFC 2, but version 1 relied on a couple of
non-standard language constructs. Microsoft said they were ambiguities in the
language specification. As far as I know, no other vendor had thought that
the language definition was ambiguous in this area, nor had any other vendor
interpreted the language definition in the way Microsoft did.

 -- Pete

hendrik@vedge.com (Hendrik Boom) writes:
: allen@eUNiiCE.canada.dg.com (Allen B. Taylor) writes:
: : I've recently taken on the task of learning MS Windows programming in C++
: : using Borland's OWL (Object Windows Library).  The training materials document
: : a C++ syntax that I'm unfamiliar with.  I believe they call it a virtual
: : function index.  The syntax resembles that of a pure specifier, except the zero
: : is now an integer index in brackets.  Here's an example:
: :
: :  virtual int funcname(type_spec,...) = [int_expression];
: :
: : Does anyone know if this syntax is a proposed valid syntax or if it's some
: : invention of Borland's?  If it's a proposed ANSI syntax, I'd like to know more
: : about it.  I've read through the entire ARM and don't recall anything like it.
: : But, as always, things don't stand still very long and someone in some
: : committee somewhere might have decided this virtual function index was a good
: : idea.  Any info is appreciated.
:
: It the int_expression is 0, it's in the ARM, and means that you
: have a pure function, which makes the class it's in abstract.

Whoops! Not quite! I missed the brackets around the integer, which
are NOT used in the definition of a pure function, but ARE used in the
Borland extension.
:
: If the expression is anything else, such as 2, or x-x, or such,
: it's a Borland extension.
:
: :
: : BTW, please reply via e-mail or cross-post to comp.lang.c++ or comp.std.c++.  I
: : don't normally subscribe to the other groups I've posted this note to.  Thanks.
: : ---
: : allen@eUNiiCE.canada.dg.com (Allen B. Taylor)
: :   -- or --
: : allen_taylor@dgc.ceo.dg.com
: --
: -------------------------------------------------------
: Try one or more of the following addresses to reply.
: at work: hendrik@vedge.com,  iros1!vedge!hendrik
: at home: uunet!ozrout!topoi!hendrik
--
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work: hendrik@vedge.com,  iros1!vedge!hendrik
at home: uunet!ozrout!topoi!hendrik

In article <1993Aug19.160919.1376@eUNiiCE.canada.dg.com> allen@eUNiiCE.canada.dg.com (Allen B. Taylor) writes:
>Now, I shall duck my head for the usually "my compiler/library's better than
>yours" posts that are sure come.
|---
|Allen B. Taylor

Naw, I'll try to resist the temptation.  Note from the "standards" point
of view one should hardly expect a language to support features peculiar
to one operating system [although C might argue against this point of view]
What proprietory extensions a particular compiler vendor chooses to add
to their compiler is basically their business -- as long as it doesn't
interfere with the compilation of conforming programs.

I will, however, express disappointment over C++'s very weak ability
to support message dispatches using methods other than the built-in
vtable approach.  Vtables are simply one extremely fast tradeoff in
a variety of speed/size tradeoffs available for message dispatch.  Also,
C++ programmers might want to implement dispatch schemes compatible with
other languages, or more flexible than C++'s dispatch scheme.
Unfortunately, C++ provides extremely weak support for any programmer
attempting to implement such alternate dispatch schemes.