In article <OTFXb.12877$Ds7.10767@newssvr29.news.prodigy.com>, John
Nagle <nagle@animats.com> writes
>Francis Glassborow wrote:
>> In article <ur7wx3lxg.fsf@boost-consulting.com>, David Abrahams
>><dave@boost-consulting.com> writes
>>
>>> In contrast, a generalized GUI interface that's useful for more than
>>> toy programs is an incredibly difficult job.
>>   Yes, but we need to take account of the teachability of C++.
>>Without  some minimal Standard GUI it is far less attractive as a
>>language for  novices. Some argue that it does not matter, I happen to
>>think they are  mistaken. Even such a tiny thing as having raw access
>>to a keyboard and  a simple one button mouse + a dimensioned window
>>with plot and read  pixels makes a tremendous difference to the ,orale
>>of both teacher and  student.
>
>  There's always Tk.
>                               John Nagle
Those that teach novices will know that it is fairly important to avoid
such heavyweight added libraries. Something simple that the student (and
teacher) can model mentally without too much extra effort so they can
focus on programming rather than library complexity.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 15 Feb 2004 03:09:22 +0000 (UTC)
francis@robinton.demon.co.uk (Francis Glassborow) wrote:

> Yes, but we need to take account of the teachability of C++. Without
> some minimal Standard GUI it is far less attractive as a language for
> novices. Some argue that it does not matter, I happen to think they
> are mistaken. Even such a tiny thing as having raw access to a
> keyboard and a simple one button mouse + a dimensioned window with
> plot and read pixels makes a tremendous difference to the ,orale of
> both teacher and student.

Well wxWindows, Fox, FLTK and GTK is doing a good job, so why do we need
GUI support in standard C++? Most of the programs I write doesn't even
have a GUI or run on a system that does. Not having threads in C++ now
there is a problem.

br
db

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

francis@robinton.demon.co.uk (Francis Glassborow) writes:

> In article <ur7wx3lxg.fsf@boost-consulting.com>, David Abrahams
> <dave@boost-consulting.com> writes
>>In contrast, a generalized GUI interface that's useful for more than
>>toy programs is an incredibly difficult job.
>
> Yes, but we need to take account of the teachability of C++. Without
> some minimal Standard GUI it is far less attractive as a language for
> novices. Some argue that it does not matter, I happen to think they
> are mistaken. Even such a tiny thing as having raw access to a
> keyboard and a simple one button mouse + a dimensioned window with
> plot and read pixels makes a tremendous difference to the ,orale of
> both teacher and student.

I don't believe that needs to be standardized in order to be
available, and I really don't believe that standardizing a toy library
is a good idea: it'll eventually grow into a hacked-up monster.

--
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.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 15 Feb 2004 21:31:33 +0000, Kamil Burzynski wrote:

> If you are building soft for embedded machine which is low on space
> or e.g. filesystem is static and burned into eprom memory, then
> such 'eprom filesystem driver' which is likely to be written by hand
> may not support advanced filesystem facilities...

It doesn't imply that each system which does support directories should
use a different API. I often heard this absurd argument about possible
systems which can't support that...

A language standard doesn't have to define only the intersection of
language features across implementations. It should be closer to the
union, modulo parts which are either rare, or so differently handled that
it's impractical to force a unified API, or are likely to change in a few
years anyway.

Some parts of the standard might be marked as optional, or systems which
can't support them will just signal an error on all uses. But it would
allow to write programs portable across systems which do support these
features.

If you disagree, you could as well say that some embedded systems don't
have any files, or don't support floating point numbers, and thus C++
should not standarize these areas. Why are directories so different
from files?

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 16 Feb 2004 04:31:08 +0000 (UTC), "Marcin 'Qrczak' Kowalczyk" wrote:
> On Sun, 15 Feb 2004 21:31:33 +0000, Kamil Burzynski wrote:
>
>> If you are building soft for embedded machine which is low on space
>> or e.g. filesystem is static and burned into eprom memory, then
>> such 'eprom filesystem driver' which is likely to be written by hand
>> may not support advanced filesystem facilities...
>
> It doesn't imply that each system which does support directories should
> use a different API. I often heard this absurd argument about possible
> systems which can't support that...
>
> A language standard doesn't have to define only the intersection of
> language features across implementations. It should be closer to the
> union, modulo parts which are either rare, or so differently handled that
> it's impractical to force a unified API, or are likely to change in a few
> years anyway.

I agree - thats why I've wrote that case described by me is pathological
;)

Many computer systems/programs/designs/etc. are hurt by
overconcentration on unimportant extreme cases which in turn limit
usefullness of rest of cases.

--
Best regards from
Kamil Burzynski

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

dave@boost-consulting.com (David Abrahams) wrote in message news:<ur7wx3lxg.fsf@boost-consulting.com>...
> We've done the research at Boost; Beman has written a filesystem
> library that accounts for the commonality.  It was hard, but it works.
> Almost every language supports this functionality in some general way

I'm puzzled by your claim.  I don't recall using a single language
in a similar space to C++ (e.g. C, BCPL, Pascal, Algol 68, PL/1)
that has built-in support for directories.  How did you arrive at
your conclusion, if it is not mere hyperbole?

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 20 Feb 2004 17:15:07 +0000, Al Grant wrote:

>> We've done the research at Boost; Beman has written a filesystem
>> library that accounts for the commonality.  It was hard, but it works.
>> Almost every language supports this functionality in some general way
>
> I'm puzzled by your claim.  I don't recall using a single language
> in a similar space to C++ (e.g. C, BCPL, Pascal, Algol 68, PL/1)
> that has built-in support for directories.

Why are you only mentioning languages more than 30 years old?

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hi group

I have a few questions regarding the next release/version of C++.
I know nothing is desided, but I just want to know what the future
might bring.

When will the next release happen?

Which new things will be included/extented?
Support for:
 Threads
 Networking
 Printing
 Dynamic loading of libraries (for plugins)
 Garbage collector (hope not!)
 GUI (hope not!)
 More filesystem support like iteration over directories
 More?

If yes to some of these, will one of the current implementations
be selected? If yes which one?

br
db

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <20040212012059.13a688b7@main.trunet.dk>, db
<db@TruNet.dk-NOSPAM> writes
>Hi group
>
>I have a few questions regarding the next release/version of C++.
>I know nothing is desided, but I just want to know what the future
>might bring.
>
>When will the next release happen?
2008/9 but you will have a good idea what will be in it by 2006
>
>Which new things will be included/extented?
>Support for:
>       Threads
probably
>       Networking
possibly as a library facility
>       Printing
?? what do you want here? I completely fail to see what might be worth
providing considering that many perfectly reasonable platforms have no
direct printing facilities and that is ignoring the vast areas of
specialist embedded systems.

>       Dynamic loading of libraries (for plugins)

We are actively looking into that but there are severe problems because
two major general purpose platforms (Windows and Unix) do things very
differently.

>       Garbage collector (hope not!)

Why not, if we can come up with a formulation that allows it as an
option (extended C++ for CLI will likely have it)
>       GUI (hope not!)
Why not? At least in a simple form suitable for underpinning teaching of
C++ (I.e. as part of our target of making C++ more teachable)
>       More filesystem support like iteration over directories

Why assume that a target platform has directories? It is actually a
tough problem and one that exemplifies the advantages that might accrue
if we had a way to standardise optional APIs.

>       More?

Mostly cleaning up and providing better support for library and system
designers. Possibly providing a much cleaner set of tools for
meta-programming. Provide some scope concepts for the pre-processor.

>
>If yes to some of these, will one of the current implementations
>be selected? If yes which one?

Well we will know when we have given proper consideration to all the
issues. We do not try to predict the future.

>

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' 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.jamesd.demon.co.uk/csc/faq.html                       ]

db wrote:
> Hi group
>
> I have a few questions regarding the next release/version of C++.
> I know nothing is desided, but I just want to know what the future
> might bring.
>
> When will the next release happen?
>
> Which new things will be included/extented?
> Support for:
>  Threads
>  Networking
>  Printing
>  Dynamic loading of libraries (for plugins)
>  Garbage collector (hope not!)
>  GUI (hope not!)
>  More filesystem support like iteration over directories
>  More?
>
> If yes to some of these, will one of the current implementations
> be selected? If yes which one?

It's impossible to say at this time. Many things are being considered, nothing
has yet been rejected. A new standard takes years, and work on it has only just
started.

---
Steve Clamage, stephen.clamage@sun.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.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 12 Feb 2004 17:57:50 +0000 (UTC)
francis@robinton.demon.co.uk (Francis Glassborow) wrote:

> >       Printing
> ?? what do you want here? I completely fail to see what might be worth
> providing considering that many perfectly reasonable platforms have no
> direct printing facilities and that is ignoring the vast areas of
> specialist embedded systems.

This wasn't a list of requests (except threads and dynamic loading), so
it's not that I want printing support.

> >       Dynamic loading of libraries (for plugins)
>
> We are actively looking into that but there are severe problems
> because two major general purpose platforms (Windows and Unix) do
> things very differently.

Have you seen:
http://computing.ee.ethz.ch/sepp/libgtkmm-2.2.3-ke/reference/html/classGlib_1_1Module.html

I've never used it, but doesn't that solve the problem?

> >       Garbage collector (hope not!)
>
> Why not, if we can come up with a formulation that allows it as an
> option (extended C++ for CLI will likely have it)

If it is something that can be turned on and off then great :-)

> of C++ (I.e. as part of our target of making C++ more teachable)
> >       More filesystem support like iteration over directories
>
> Why assume that a target platform has directories? It is actually a
> tough problem and one that exemplifies the advantages that might
> accrue if we had a way to standardise optional APIs.

When you assume it has files, then why can't you assume it has
directories?

> >       More?
>
> Mostly cleaning up and providing better support for library and system
> designers. Possibly providing a much cleaner set of tools for
> meta-programming. Provide some scope concepts for the pre-processor.

Sounds good :-)

Thank you for your reply!

br
db

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On 12/2/04 5:57 pm, in article Q5WN6VBu21KAFw7v@robinton.demon.co.uk,
"Francis Glassborow" <francis@robinton.demon.co.uk> wrote:

>>       GUI (hope not!)
> Why not? At least in a simple form suitable for underpinning teaching of
> C++ (I.e. as part of our target of making C++ more teachable)

Why?. By your reasoning below, why assume that a target platform has a GUI?

>>       More filesystem support like iteration over directories
>
> Why assume that a target platform has directories? It is actually a
> tough problem and one that exemplifies the advantages that might accrue
> if we had a way to standardise optional APIs.
>


I do appreciate the difficulties in coming up with functionality to please
everybody! (Or, at least, most people!) :)

--
Regards,
Steve.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <BC518261.593A3%ng@spfweb.co.uk>, Steve Folly
<ng@spfweb.co.uk> writes
>On 12/2/04 5:57 pm, in article Q5WN6VBu21KAFw7v@robinton.demon.co.uk,
>"Francis Glassborow" <francis@robinton.demon.co.uk> wrote:
>
>>>       GUI (hope not!)
>> Why not? At least in a simple form suitable for underpinning teaching of
>> C++ (I.e. as part of our target of making C++ more teachable)
>
>Why?. By your reasoning below, why assume that a target platform has a GUI?

Perhaps because I see no great advantage to having a directory API for
teaching programming whilst I see a great deal of value in having a GUI
(to the extent of providing a very primitive one for the readers of my
book).

There are certain common primitives to all GUIs and in a teaching
environment we are not overly concerned with efficiency. OTOH what is
the commonality for directory structures? Be careful because this is an
area where many people are prone to assuming their experience
generalises.

>
>>>       More filesystem support like iteration over directories
>>
>> Why assume that a target platform has directories? It is actually a
>> tough problem and one that exemplifies the advantages that might accrue
>> if we had a way to standardise optional APIs.
>>
>
>
>I do appreciate the difficulties in coming up with functionality to please
>everybody! (Or, at least, most people!) :)

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' 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.jamesd.demon.co.uk/csc/faq.html                       ]

francis@robinton.demon.co.uk (Francis Glassborow) writes:

> In article <BC518261.593A3%ng@spfweb.co.uk>, Steve Folly
> <ng@spfweb.co.uk> writes
>>On 12/2/04 5:57 pm, in article Q5WN6VBu21KAFw7v@robinton.demon.co.uk,
>>"Francis Glassborow" <francis@robinton.demon.co.uk> wrote:
>>
>>>>       GUI (hope not!)
>>> Why not? At least in a simple form suitable for underpinning teaching of
>>> C++ (I.e. as part of our target of making C++ more teachable)
>>
>>Why?. By your reasoning below, why assume that a target platform has a GUI?
>
> Perhaps because I see no great advantage to having a directory API for
> teaching programming whilst I see a great deal of value in having a
> GUI (to the extent of providing a very primitive one for the readers
> of my book).
>
> There are certain common primitives to all GUIs and in a teaching
> environment we are not overly concerned with efficiency. OTOH what is
> the commonality for directory structures? Be careful because this is
> an area where many people are prone to assuming their experience
> generalises.

We've done the research at Boost; Beman has written a filesystem
library that accounts for the commonality.  It was hard, but it works.
Almost every language supports this functionality in some general way,
and not having it is not only a huge embarrassment, but a huge
inconvenience.

In contrast, a generalized GUI interface that's useful for more than
toy programs is an incredibly difficult job.

--
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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <ur7wx3lxg.fsf@boost-consulting.com>, David Abrahams
<dave@boost-consulting.com> writes
>In contrast, a generalized GUI interface that's useful for more than
>toy programs is an incredibly difficult job.

Yes, but we need to take account of the teachability of C++. Without
some minimal Standard GUI it is far less attractive as a language for
novices. Some argue that it does not matter, I happen to think they are
mistaken. Even such a tiny thing as having raw access to a keyboard and
a simple one button mouse + a dimensioned window with plot and read
pixels makes a tremendous difference to the ,orale of both teacher and
student.



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' 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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <ur7wx3lxg.fsf@boost-consulting.com>, David Abrahams
> <dave@boost-consulting.com> writes
>
>> In contrast, a generalized GUI interface that's useful for more than
>> toy programs is an incredibly difficult job.
>
>
> Yes, but we need to take account of the teachability of C++. Without
> some minimal Standard GUI it is far less attractive as a language for
> novices. Some argue that it does not matter, I happen to think they are
> mistaken. Even such a tiny thing as having raw access to a keyboard and
> a simple one button mouse + a dimensioned window with plot and read
> pixels makes a tremendous difference to the ,orale of both teacher and
> student.

   There's always Tk.

    John Nagle

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 13 Feb 2004 14:37:49 +0000 (UTC), db wrote:
> On Thu, 12 Feb 2004 17:57:50 +0000 (UTC)
> francis@robinton.demon.co.uk (Francis Glassborow) wrote:
>> Why assume that a target platform has directories? It is actually a
>> tough problem and one that exemplifies the advantages that might
>> accrue if we had a way to standardise optional APIs.
>
> When you assume it has files, then why can't you assume it has
> directories?

Ever seen TFTP protocol? It handles files, but not directories ;)

If you are building soft for embedded machine which is low on space
or e.g. filesystem is static and burned into eprom memory, then
such 'eprom filesystem driver' which is likely to be written by hand
may not support advanced filesystem facilities...

Yes, I know, this is pathological case, but it would be nice to
make language which does support such systems..

--
Best regards from
Kamil Burzynski

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

db wrote:
> On Thu, 12 Feb 2004 17:57:50 +0000 (UTC)
> francis@robinton.demon.co.uk (Francis Glassborow) wrote:
>
>>>      Dynamic loading of libraries (for plugins)
>>
>>We are actively looking into that but there are severe problems
>>because two major general purpose platforms (Windows and Unix) do
>>things very differently.
>
>
> Have you seen:
> http://computing.ee.ethz.ch/sepp/libgtkmm-2.2.3-ke/reference/html/classGlib_1_1Module.html
>
> I've never used it, but doesn't that solve the problem?

No. That library appears to solve the restricted problem of different APIs on
different platforms for access to dynamic libraries.

The problems we are trying to address are the semantics of dynamic libraries,
which are very different on different platforms. The default visibility of
symbols and what you can control about visibility of symbols is different. The
way duplicate symbol definitions are handled is different. The way
initialization and finalization occurs is different.

The problem is to find a useful functionality set that can be implemented across
a range of systems without breaking the conventions of major platforms.

---
Steve Clamage, stephen.clamage@sun.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.jamesd.demon.co.uk/csc/faq.html                       ]