"kwikius" <andy@servocomm.freeserve.co.uk> wrote in message
news:1164724788.102215.311700@h54g2000cwb.googlegroups.com...
>
> Francis Glassborow wrote:
>> In article <ekd1ul$o3r$1@kujawiak.man.lodz.pl>, Sektor van Skijlen
>> <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes
>> >Stating GUI, as an example, with current approach to the standard,
>> >either the
>> >standard has GUI thus making compilers for embedded platforms
>> >nonstandard, or
>> >it doesn't have, which means that there is no "standard GUI" thus making
>> >a
>> >user learned in "Standard C++" useless for making GUI in favor of guys
>> >learned
>> >in C# or Java.
>>
>>
>> There is a far more fundamental problem. Try defining a portable GUI
>> that is efficient on all platforms that support a GUI concept.
>
> Provide a virtual platform and you remove the problem.
> hmm.... I wonder why no one has thought of that.... ;-)

In your view, how is a cross-platform GUI API different from a
"virtual platform"? That it implies that other cross-platform APIs
(such as threads, networking, files etc) aren't included?

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                      ]

Uzytkownik "Earl Purple" <earlpurple@gmail.com> napisal w wiadomosci
news:1164731078.745258.94860@h54g2000cwb.googlegroups.com...
>

> You have defined the mouse exactly, at least with regard to this
> situation, it can point and it can click.
>

But I have not defined the crocodile, and neither have you.
And, by the way, I have not defined all possible aspects of clicking.
For example, I have left the strength (intensiveness) of the click
undefined.

>
> There is no standard concept of an event-driven application, as such,
> in C++. That, perhaps, is the concept the OP was trying to aim at. And
> that, perhaps, is what might be standardised in such a way that any GUI
> could be implemented with regards to such.

You can build a general framework and plug the devices for your platform
into it
but you cannot expect the application to work in a different environment.
Because your applications expects a mouse click and what it gets is a
crocodile clasp.
That is the problem.

> And why, by the way, is there no such thing as C++ scripting language?

If you want to add scripting to your C++ application, you can use JavaScript
for that purpose.
I do not know of any other scripting language
that is available for every platform and ready to be plugged in,
but if there is one, it can probably be used as well.
I can see no point in fixing the choice in the C++ standard.
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                      ]

"Tony" wrote:
> "kwikius" <andy@servocomm.freeserve.co.uk> wrote in message
> news:1164724788.102215.311700@h54g2000cwb.googlegroups.com...
> >
> > Francis Glassborow wrote:
> >> In article <ekd1ul$o3r$1@kujawiak.man.lodz.pl>, Sektor van Skijlen
> >> <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes
> >> >Stating GUI, as an example, with current approach to the standard,
> >> >either the
> >> >standard has GUI thus making compilers for embedded platforms
> >> >nonstandard, or
> >> >it doesn't have, which means that there is no "standard GUI" thus making
> >> >a
> >> >user learned in "Standard C++" useless for making GUI in favor of guys
> >> >learned
> >> >in C# or Java.
> >>
> >>
> >> There is a far more fundamental problem. Try defining a portable GUI
> >> that is efficient on all platforms that support a GUI concept.
> >
> > Provide a virtual platform and you remove the problem.
> > hmm.... I wonder why no one has thought of that.... ;-)
>
> In your view, how is a cross-platform GUI API different from a
> "virtual platform"? That it implies that other cross-platform APIs
> (such as threads, networking, files etc) aren't included?

To answer that question would need a more definitive description of
what a virtual platform is. However one significant feature is that it
is as an abstraction independent as far as possible of a particular
API, and  API's should ideally be built or adapted to use it as it as a
common base layer.
I don't have a long time to go looking for suitable links, but here is
a random google search for some "int32" type. Some of these types are
the same, some have a tight spec and some have a loose spec, but the
int32 in each API has similar basic functionality and in many cases
resolves to the same C++ type but in many cases a particular API uses
its own naming conventions. A good virtual platform would of course
provide a detailed spec of the semantics of an int32. If  the virtual
platform cannot be implemented on a real platform then that real
platform simply doesnt meet the requirements to be considered as
implementing the virtual platform. Its that simple. In reality though
it might be sensible to work bottom up of course to write the spec to
get some chance of adoption, but that is down to the judgement of the
designers of the spec. A completely "anything goes" spec is as useless
as one that is too tight...

http://msdn2.microsoft.com/en-us/library/system.int32.aspx

http://tinyurl.com/y3vz7c

http://www.lispworks.com/documentation/lw445/LWRM/html/lwref-586.htm
http://tinyurl.com/y8ncn5

http://ftp.omnimark.com/documentation/concept/777.htm

http://developer.gnome.org/doc/API/2.0/glib/glib-Basic-Types.html

http://gtk-gnutella.sourceforge.net/doxygen/structdquery.html

The other way to look at a virtual platform is that is the logical
development from per API cross platform development.

Once you have such a specification you have removed a major hurdle to
cross platform development. Because C++ has no such spec cross platform
dvelopment results in each library duplicating this type of
functionality.

Various times I have heard it is hard to write the spec for such a
virtual platform, but nevertheless they exist for e.g Java and . Net.
Sure its hard, but it makes life much simpler for the user and library
developer.

regards
Andy Little

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

kwikius wrote:
>
> Various times I have heard it is hard to write the spec for such a
> virtual platform, but nevertheless they exist for e.g Java and .
> Net. Sure its hard, but it makes life much simpler for the user and
> library developer.
>

But it sometimes makes it incredibly hard and expensive for those that
happen not to exactly fit the spec.

I work on big iron machines like this

http://www-03.ibm.com/systems/z/hardware/

where it is necessary to add this kind of hardware extension to run Java
properly

http://www-03.ibm.com/systems/z/zaap/


I don't see that some advantage for a library developer is really worth the
$$$ invested here. I also hope that C++ never ever ends up there!


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                      ]

"Bo Persson" wrote:
> kwikius wrote:
> >
> > Various times I have heard it is hard to write the spec for such a
> > virtual platform, but nevertheless they exist for e.g Java and .
> > Net. Sure its hard, but it makes life much simpler for the user and
> > library developer.
> >
>
> But it sometimes makes it incredibly hard and expensive for those that
> happen not to exactly fit the spec.
>
> I work on big iron machines like this
>
> http://www-03.ibm.com/systems/z/hardware/
>
> where it is necessary to add this kind of hardware extension to run Java
> properly
>
> http://www-03.ibm.com/systems/z/zaap/
>
>
> I don't see that some advantage for a library developer is really worth the
> $$$ invested here. I also hope that C++ never ever ends up there!

I'm curious - what features of the Java Virtual Machine make it
difficult to emulate efficiently on that platform, without that
hardware extension? A quick look around those web sites didn't answer
that question for me.

---
[ 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" wrote:
> kwikius wrote:
> >
> > Various times I have heard it is hard to write the spec for such a
> > virtual platform, but nevertheless they exist for e.g Java and .
> > Net. Sure its hard, but it makes life much simpler for the user and
> > library developer.
> >
>
> But it sometimes makes it incredibly hard and expensive for those that
> happen not to exactly fit the spec.
>
> I work on big iron machines like this

Is the 'big iron' designed to do useful work or is it just designed to
be 'big iron'.?

AFAIKS somebody somewhere convinced somebody else with $$$ that
spending some $$$ was necessary to get 'big iron'  to work with Java
platform

Why did they do that? Are you saying that all that $$$ was wasted?

regards
Andy Little

---
[ 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 "kwikius" <andy@servocomm.freeserve.co.uk> napisal w wiadomosci
news:1164847979.127232.281180@l12g2000cwl.googlegroups.com...
>
> "Bo Persson" wrote:
>> kwikius wrote:
>> >
>> > Various times I have heard it is hard to write the spec for such a
>> > virtual platform, but nevertheless they exist for e.g Java and .
>> > Net. Sure its hard, but it makes life much simpler for the user and
>> > library developer.
>> >
>>
>> But it sometimes makes it incredibly hard and expensive for those that
>> happen not to exactly fit the spec.
>>
>> I work on big iron machines like this
>
> Is the 'big iron' designed to do useful work or is it just designed to
> be 'big iron'.?
>
> AFAIKS somebody somewhere convinced somebody else with $$$ that
> spending some $$$ was necessary to get 'big iron'  to work with Java
> platform
>
> Why did they do that? Are you saying that all that $$$ was wasted?
>

The description says that the coprocessor allows the virtual machine to run
without burdening the CPU.
It is commonplace to have specialized coprocessors to perform specialized
tasks.
There are coprocessors for floating point arithmetic,
for graphics, for sound (my regards to Lisa and Paula), for communication
line disciplines,
for moving pictures, even for networking, PostScript and Lisp.  Why
shouldn't there be a coprocessor for Java?
I imagine mainframe machines do not have much time to spare - they are too
expensive to stay idle.
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                      ]

kuyper@wizard.net wrote:
> "Bo Persson" wrote:
>
>>kwikius wrote:
(regarding IBM mainframes)
> I'm curious - what features of the Java Virtual Machine make it
> difficult to emulate efficiently on that platform, without that
> hardware extension? A quick look around those web sites didn't answer
> that question for me.

     Java requires IEEE Standard 754/854 floating point, and IBM
mainframes have a completely different floating point format.
See  "http://en.wikipedia.org/wiki/IBM_Floating_Point_Architecture"
The formats are so incompatible that trying to do IEEE floating
point in software on IBM mainframe hardware is painfully slow.
IBM used a base 16 exponent, instead of a base 2 exponent in
their floating point format, which, in 1960, seemed like a good
way to get more exponent range and better compete with
the 36-bit word machines.  In retrospect, it was a bad
design decision with wierd numerical implications.

    On a practical level, users of IEEE standard floating point
are guaranteed correct results on integer values stored in
floating point numbers, something today's Java programmers expect
(and some languages, notably Python, rely on).
That's not true of IBM's floating point.

    This is getting off topic.  Can we close out this thread?

    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                      ]

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

For what it's worth, I can't think of anything more on-topic than a
discussion of whether certain kinds of requirements in the standard would
make the standard unimplementable on important platforms.

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

approve<br>comment<br>For what it's worth, I can't think of anything more on-topic than a discussion of whether certain kinds of requirements in the standard would make the standard unimplementable on important platforms.<br>

------=_Part_49201_5158480.1164911750310--


===================================== END OF MODERATOR'S COMMENT
kuyper@wizard.net wrote:
> "Bo Persson" wrote:
>> kwikius wrote:
>>>
>>> Various times I have heard it is hard to write the spec for such a
>>> virtual platform, but nevertheless they exist for e.g Java and .
>>> Net. Sure its hard, but it makes life much simpler for the user
>>> and library developer.
>>>
>>
>> But it sometimes makes it incredibly hard and expensive for those
>> that happen not to exactly fit the spec.
>>
>> I work on big iron machines like this
>>
>> http://www-03.ibm.com/systems/z/hardware/
>>
>> where it is necessary to add this kind of hardware extension to
>> run Java properly
>>
>> http://www-03.ibm.com/systems/z/zaap/
>>
>>
>> I don't see that some advantage for a library developer is really
>> worth the $$$ invested here. I also hope that C++ never ever ends
>> up there!
>
> I'm curious - what features of the Java Virtual Machine make it
> difficult to emulate efficiently on that platform, without that
> hardware extension? A quick look around those web sites didn't
> answer that question for me.
>

Hope this is still on topic  :-)

I don't know really where the problems occur, but it seems like what could
be a single machine instruction in "implementation defined" C++, takes
several machine instructions in the Java VM. Running a webserver, this
happens often enough that 1 zAPP can do the work of 2-3 general purpose
CPUs.

Without the Java hardware, we have seen cases where WebSphere took as much
as 50% of the total capacity, leaving the rest to DB2 and the several
hundred other applications running on the machine.


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                      ]

kwikius wrote:
> "Bo Persson" wrote:
>> kwikius wrote:
>>>
>>> Various times I have heard it is hard to write the spec for such a
>>> virtual platform, but nevertheless they exist for e.g Java and .
>>> Net. Sure its hard, but it makes life much simpler for the user
>>> and library developer.
>>>
>>
>> But it sometimes makes it incredibly hard and expensive for those
>> that happen not to exactly fit the spec.
>>
>> I work on big iron machines like this
>
> Is the 'big iron' designed to do useful work or is it just designed
> to be 'big iron'.?

It does a lot of useful work, like hosting a DB2 database, several hundred
applications and serving abot 10000 terminals (PCs actually). It also runs a
webserver, based on Java applets.

Moving it all to the mainframe removed the communications bottleneck between
a room full of PC-server racks, with C++(!) applications, and the central
database. The only catch was converting all the C++ code to Java...

>
> AFAIKS somebody somewhere convinced somebody else with $$$ that
> spending some $$$ was necessary to get 'big iron'  to work with Java
> platform

Without the Java hardware, we were close to the "fully configured" system,
where you just cannot add more CPUs. Not fun, at all!

As some of the other software licenses are based on the machine
configuration, adding a bunch of CPUs isn't very fun anyway.

>
> Why did they do that? Are you saying that all that $$$ was wasted?

I'm saying that *if* Java had been a better fit for existing machines, or
allowed some "implementation defined" features, we could have saved a lot of
$$$. I hope the potential savings for the "library developers" make up for
this. It sure didn't help for any of our inhouse Java code...


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                      ]

John Nagle wrote:
> kuyper@wizard.net wrote:
> > "Bo Persson" wrote:
> >
> >>kwikius wrote:
> (regarding IBM mainframes)
> > I'm curious - what features of the Java Virtual Machine make it
> > difficult to emulate efficiently on that platform, without that
> > hardware extension? A quick look around those web sites didn't answer
> > that question for me.
>
>      Java requires IEEE Standard 754/854 floating point, and IBM
> mainframes have a completely different floating point format.
> See  "http://en.wikipedia.org/wiki/IBM_Floating_Point_Architecture"
> The formats are so incompatible that trying to do IEEE floating
> point in software on IBM mainframe hardware is painfully slow.
> IBM used a base 16 exponent, instead of a base 2 exponent in
> their floating point format, which, in 1960, seemed like a good
> way to get more exponent range and better compete with
> the 36-bit word machines.  In retrospect, it was a bad
> design decision with wierd numerical implications.
>
>     On a practical level, users of IEEE standard floating point
> are guaranteed correct results on integer values stored in
> floating point numbers, something today's Java programmers expect
> (and some languages, notably Python, rely on).
> That's not true of IBM's floating point.
>
>     This is getting off topic.  Can we close out this thread?

This is very definitely on-topic, though I may have failed to make that
clear. The things that make implementation of the Java Virtual Machine
difficult on some platforms, are precisely the things we should avoid
introducing into C++, and that's why I was interested.

---
[ 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:4t8m4bF12rhp3U1@mid.individual.net...
>
> ===================================== MODERATOR'S COMMENT:
> For what it's worth, I can't think of anything more on-topic than a
> discussion of whether certain kinds of requirements in the standard would
> make the standard unimplementable on important platforms.

On topic for the newsgroup but off topic for the thread.

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:
> "Bo Persson" <bop@gmb.dk> wrote in message
> news:4t8m4bF12rhp3U1@mid.individual.net...
> >
> > ===================================== MODERATOR'S COMMENT:
> > For what it's worth, I can't think of anything more on-topic than a
> > discussion of whether certain kinds of requirements in the standard would
> > make the standard unimplementable on important platforms.
>
> On topic for the newsgroup but off topic for the thread.

Thread drift happens. There's nothing inherently wrong with it, though
at some point it becomes appropriate to change the subject line on a
sub-thread That message did not drift significantly from the topic of
the message it was responding to.

---
[ 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 Sun, 26 Nov 2006 19:13:53 GMT, Dave Harris skrobie:
> giecrilj@stegny.2a.pl ("K?i?tof ?elechovski") wrote (abridged):
> > > However, the C++ standard tries to be portable and so aims at
> > > the highest common denominator.
> >
> > Lowest, if you please.

> Why would it aim to be lowest? Note the word "common". If some high
> feature is available on every platform, portability is not lost by
> exploiting it and we gain whatever facility it provides.

This is exactly the greates problem with current standard. That there are no
standard "modules", so the standard is "everything or nothing".

The consequence of this is that either the standard contains standard
solutions for most of users, making this way non-standard all compilers that
are not able to implement some libraries due to platform limitations, or you
make the standard weak and short, causing therefore that libraries userd by
many users will have to be created as 3rd party or by compiler vendors.

Stating GUI, as an example, with current approach to the standard, either the
standard has GUI thus making compilers for embedded platforms nonstandard, or
it doesn't have, which means that there is no "standard GUI" thus making a
user learned in "Standard C++" useless for making GUI in favor of guys learned
in C# or Java.

The problem is that the standard must cope with two opposite situations:
 - people need libraries for most required things (read: must have GUI)
 - some platforms don't allow to implement some of those libraries (read: no
   GUI possible)

So, there are the following choices:
 - select no GUI, leaving users that want to make GUI in C++ alone
 - select GUI, making non-standard almost all compilers for emb. systems
 - split the standard into modules and require the declaration for every C++
   implementation whether it supports particular modules

Modules, of course, would have to be selected according to what is possible
for particular platform and it may contain language core features with library
parts as well. This may be GUI, exceptions, dynamic-allocated memory, etc.

Having that, not only can you provide standard compilers for platforms that
are not able to implement all extended standard's needs, but you are also able
to provide everything that most people need.


--
//  _    ___         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:

> This is exactly the greates problem with current standard. That there are no
> standard "modules", so the standard is "everything or nothing".
>
> [...]
>
> The problem is that the standard must cope with two opposite situations:
>  - people need libraries for most required things (read: must have GUI)
>  - some platforms don't allow to implement some of those libraries (read: no
>    GUI possible)
>
> So, there are the following choices:
>  - select no GUI, leaving users that want to make GUI in C++ alone
>  - select GUI, making non-standard almost all compilers for emb. systems
>  - split the standard into modules and require the declaration for every C++
>    implementation whether it supports particular modules
>
> Modules, of course, would have to be selected according to what is possible
> for particular platform and it may contain language core features with library
> parts as well. This may be GUI, exceptions, dynamic-allocated memory, etc.

Not all implementations have standard input and output, but the C and
C++ standards have required printf/scanf family and iostreams anyway.
The same is for files. Does this mean those implementations haven't been
conforming? Or is there any special provision made by the standards?

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

ethouris@guess.if.gmail.com.is.valid.or.invalid (Sektor van Skijlen) wrote
(abridged):
> Stating GUI, as an example, with current approach to the standard,
> either the standard has GUI thus making compilers for embedded
> platforms nonstandard, or it doesn't have, which means that there
> is no "standard GUI" thus making a user learned in "Standard C++"
> useless for making GUI in favor of guys learned in C# or Java.

I don't think that's the problem. There wouldn't be a big issue with
making some standard components optional on platforms that obviously
couldn't support them. Something similar is already done for "printf" et
al on non-hosted platforms.

The real problem with GUI specifically is that it is hard to standardise
effectively. Personally I want my apps to have the very best GUI on my
chosen platform, without compromising it with considerations of other
platforms. So I don't think I'd use a standard GUI even if one was
available. It would at best be a starting point for platform-specific
widgets. At worst it would be an abstraction barrier that hid the details
I need to do my job.

A related problem is funding. To produce a plausible cross-platform GUI
would be an expensive effort.

In any event, I don't agree that a programmer learned in Standard C++ is
useless for making GUIs. Rather, they have to learn some non-standard
libraries in addition to the standard ones. I don't believe this is much
of a problem in the commercial world.

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

On 2006-11-26 19:13, Dave Harris wrote:
> giecrilj@stegny.2a.pl ("K?i?tof ?elechovski") wrote (abridged):
>> > However, the C++ standard tries to be portable and so aims at
>> > the highest common denominator.
>>
>> Lowest, if you please.
>
> Why would it aim to be lowest?

Because that's how denominators work: The lower the better. :)

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

In article <ekd1ul$o3r$1@kujawiak.man.lodz.pl>, Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> writes
>Stating GUI, as an example, with current approach to the standard, either the
>standard has GUI thus making compilers for embedded platforms nonstandard, or
>it doesn't have, which means that there is no "standard GUI" thus making a
>user learned in "Standard C++" useless for making GUI in favor of guys learned
>in C# or Java.


There is a far more fundamental problem. Try defining a portable GUI
that is efficient on all platforms that support a GUI concept.


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

Uzytkownik "Francis Glassborow" <francis@robinton.demon.co.uk> napisal w
wiadomosci news:UvvqlIS46taFFwvB@robinton.demon.co.uk...
> In article <ekd1ul$o3r$1@kujawiak.man.lodz.pl>, Sektor van Skijlen
> <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes
>>Stating GUI, as an example, with current approach to the standard, either
>>the
>>standard has GUI thus making compilers for embedded platforms nonstandard,
>>or
>>it doesn't have, which means that there is no "standard GUI" thus making a
>>user learned in "Standard C++" useless for making GUI in favor of guys
>>learned
>>in C# or Java.
>
>
> There is a far more fundamental problem. Try defining a portable GUI that
> is efficient on all platforms that support a GUI concept.
>

There is a far more fundamental problem.
GUI must support devices; and the number of input devices is potentially
infinite.
It would be unwise to define a standard input device
that any device driver should be able to emulate.
std::wcin is such a device; but std::wcin is not a GUI.
And it would be hard to talk to std::wcin using a joystick.
And an output device need not be a bitmap either;
it might communicate with the user with holography or sound;
it could use a robot arm, as in a plotter;
it can interact directly with the user's brain;
there can be many devices I cannot think of.
There is no way to match them all against one framework.
You can use POSIX open, close, read, write and ioctl;
but read and write need not be supported
whereas open and ioctl would be totally unportable
(specific device names, operation codes, argument types depending on both:
the code compiles but the programme does not work as expected.
This is the opposite of what C++ is meant to be.).

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                      ]

"Kristof Zelechovski" wrote:
> Uzytkownik "Francis Glassborow" <francis@robinton.demon.co.uk> napisal w
> wiadomosci news:UvvqlIS46taFFwvB@robinton.demon.co.uk...
> > In article <ekd1ul$o3r$1@kujawiak.man.lodz.pl>, Sektor van Skijlen
> > <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes
> >>Stating GUI, as an example, with current approach to the standard, either
> >>the standard has GUI thus making compilers for embedded platforms nonstandard,
> >>or it doesn't have, which means that there is no "standard GUI" thus making a
> >>user learned in "Standard C++" useless for making GUI in favor of guys
> >>learned
> >>in C# or Java.
> >
> > There is a far more fundamental problem. Try defining a portable GUI that
> > is efficient on all platforms that support a GUI concept.
>
> There is a far more fundamental problem.
> GUI must support devices; and the number of input devices is potentially
> infinite.
> It would be unwise to define a standard input device
> that any device driver should be able to emulate.
> std::wcin is such a device; but std::wcin is not a GUI.
> And it would be hard to talk to std::wcin using a joystick.
> And an output device need not be a bitmap either;
> it might communicate with the user with holography or sound;
> it could use a robot arm, as in a plotter;
> it can interact directly with the user's brain;
> there can be many devices I cannot think of.
> There is no way to match them all against one framework.
> You can use POSIX open, close, read, write and ioctl;
> but read and write need not be supported
> whereas open and ioctl would be totally unportable
> (specific device names, operation codes, argument types depending on both:
> the code compiles but the programme does not work as expected.
> This is the opposite of what C++ is meant to be.).

There does not need to be a physical device. There can be a standard to
write to a logical device. Now that you can do from anything - embedded
or not. You can write to a printer, you can print graphics on an
advertising board.

In between the coded instruction in C++ and the physical device there
will be some translation, just like there is when text is written to a
console.

You can also define a system of graphic device based events, eg
selecting, positioning, and event-driven commands.

Now we can then put them all together as "a mouse click event occurred
whilst the mouse was pointed at coordinate (x,y) on a logical graphic
device". And of course if we have defined a concept of a "button" we
can say that the button was "clicked".

Once again, this does not have to be on a physical device attached to
the computer. It could be like X-Windows whereby the VDU is on a remote
machine somewhere.


]

---
[ 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 "Earl Purple" <earlpurple@gmail.com> napisal w wiadomosci
news:1164672100.910750.78080@45g2000cws.googlegroups.com...
>
> Now we can then put them all together as "a mouse click event occurred
> whilst the mouse was pointed at coordinate (x,y) on a logical graphic
> device". And of course if we have defined a concept of a "button" we
> can say that the button was "clicked".

In order to define the mouse click, you need to know what the mouse is and
that it can point and click.
What events would you define for the crocodile?
And how can you be sure you have not missed anything important?
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                      ]

"Kristof Zelechovski" wrote:
> Uzytkownik "Earl Purple" <earlpurple@gmail.com> napisal w wiadomosci
> news:1164672100.910750.78080@45g2000cws.googlegroups.com...
> >
> > Now we can then put them all together as "a mouse click event occurred
> > whilst the mouse was pointed at coordinate (x,y) on a logical graphic
> > device". And of course if we have defined a concept of a "button" we
> > can say that the button was "clicked".
>
> In order to define the mouse click, you need to know what the mouse is and
> that it can point and click.
> What events would you define for the crocodile?
> And how can you be sure you have not missed anything important?
> Chris

You have defined the mouse exactly, at least with regard to this
situation, it can point and it can click.

It doesn't have to look like a computer mouse. You could touch the
screen in a location with your finger. You could use the remote control
on your digital TV to achieve it.

The logic of a mouse click is a location and an event. Events are
something that require handling in pretty much any situation that has a
microprocessor, even pressing one of the buttons on my microwave.

Now sometimes, often in fact, the area is split into regions such that
the click in an area translates to a click on one of an enumerable
number of regions (eg pressing a button).

There is no standard concept of an event-driven application, as such,
in C++. That, perhaps, is the concept the OP was trying to aim at. And
that, perhaps, is what might be standardised in such a way that any GUI
could be implemented with regards to such.

And why, by the way, is there no such thing as C++ scripting 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                      ]

Francis Glassborow wrote:
> In article <ekd1ul$o3r$1@kujawiak.man.lodz.pl>, Sektor van Skijlen
> <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes
> >Stating GUI, as an example, with current approach to the standard, either the
> >standard has GUI thus making compilers for embedded platforms nonstandard, or
> >it doesn't have, which means that there is no "standard GUI" thus making a
> >user learned in "Standard C++" useless for making GUI in favor of guys learned
> >in C# or Java.
>
>
> There is a far more fundamental problem. Try defining a portable GUI
> that is efficient on all platforms that support a GUI concept.

Provide a virtual platform and you remove the problem.
hmm.... I wonder why no one has thought of that.... ;-)

regards
Andy Little

---
[ 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 "Dave Harris" <brangdon@cix.co.uk> napisa=B3 w wiadomo=B6ci=20
news:memo.20061121003513.3496A@brangdon.cix.compulink.co.uk...
> which reflected that UI directly. However, the C++ standard tries to be
> portable and so aims at the highest common denominator. And Windows aim=
s

Lowest, if you please.
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                      ]

giecrilj@stegny.2a.pl ("K=F8i=B9tof =AEelechovski") wrote (abridged):
> > However, the C++ standard tries to be portable and so aims at
> > the highest common denominator.
>=20
> Lowest, if you please.

Why would it aim to be lowest? Note the word "common". If some high=20
feature is available on every platform, portability is not lost by=20
exploiting it and we gain whatever facility it provides.

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