> John Nagle wrote:
> >     There's a need for a clear distinction between a "pointer to an
> > object" (this ought to be called a "reference", but the word is
> > in use), and an iterator.  A pointer to an object can only point
> > to the beginning of an object.
>         Generally speaking, it's not the case. Consider the following code:
>
>  Base* b= ...
>  Derived* d=b;
>
> I.e. d can point into a Base subobject inside the whole object.
 Sorry, I mean:

 Derived* d= ...;
 Base* b=d;

..b can point into a Base subobject...
--
         With all respect, Sergey.               http://ders.angen.net/
         mailto : ders at skeptik.net

---
[ 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                       ]

John Nagle wrote:
>     In particular, seldom is C++ GUI code written for a highly concurrent
> model.  Arguably, it should be, but for historical reasons, most
> GUI systems are single-thread.
>
 Also there exist some good reasons to keep GUI single-threaded. Please, take
a look at "Multithreaded toolkits: A failed dream?"
http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html
 In particular:

The problem of input event processing is that it tends to run in the opposite
direction to most GUI activity. In general, GUI operations start at the top of
a stack of library abstractions and go "down". I am operating on an abstract
idea in my application that is expressed by some GUI objects, so I start off
in my application and call into high-level GUI abstractions, that call into
lower level GUI abstractions, that call into the ugly guts of the toolkit, and
thence into the OS. In contrast, input events start of at the OS layer and are
progressively dispatched "up" the abstraction layers, until they arrive in my
application code.

--
         With all respect, Sergey.               http://ders.angen.net/
         mailto : ders at skeptik.net

---
[ 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                       ]

Hans Boehm wrote:
> > a look at "Multithreaded toolkits: A failed dream?"
> > http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html
> >       In particular: ...
> >
> I'm not sure this is terribly relevant to this discussion.  But if we
> are talking about the needs for threads in general:
>
> Isn't there an important distinction here between applications that
> happen to have a GUI, and the GUI event processing per se?
>
 The point is that GUI toolkit itself doesn't have to be MT-safe. Application
is allowed to spawn any number of threads but only one thread at the time
shall touch the GUI.
--
         With all respect, Sergey.               http://ders.angen.net/
         mailto : ders at skeptik.net

---
[ 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                       ]

John Nagle wrote:
>     There's a need for a clear distinction between a "pointer to an
> object" (this ought to be called a "reference", but the word is
> in use), and an iterator.  A pointer to an object can only point
> to the beginning of an object.
 Generally speaking, it's not the case. Consider the following code:

 Base* b= ...
 Derived* d=b;

I.e. d can point into a Base subobject inside the whole object.
--
         With all respect, Sergey.               http://ders.angen.net/
         mailto : ders at skeptik.net

---
[ 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                       ]