Re: Minecraft

[Lynn McGuire]

On 1/28/2016 2:48 PM, Stefan Ram wrote:
> Lynn McGuire <l...@winsim.com> writes:
>> new Minecraft Education Edition - written in C++
>
> One can write Minecraft in Java.
>
> One can't write it in C++, except when one would use
> non-standard libraries.
>
> But with Java one can write it
> with only the standard library »Java SE«
> which is usually called just »Java«.
>
> So, in »in C++« »in« does not mean the same as
> in »in Java«.

You are just illustrating my argument that C++ needs a standard graphics (2D and 3D) library and a standard user interface toolkit.

Lynn

[Öö Tiib]

That has to be separate standard since "graphics" means few LEDs
for lot of devices where C++ runs.

Should C++ committee standardize something like OpenGL API or
like Qt or like Unreal Engine?

[Lynn McGuire]

Not sure what you mean by "few LEDs" ?

Or a uitk like wxWidgets.

A standard in both of these items would solve a lot of problems.

Lynn

[Alf P. Steinbach]

On 1/28/2016 10:30 PM, Öö Tiib wrote:
>
> Should C++ committee standardize something like OpenGL API or like Qt
> or like Unreal Engine?

There is a proposal, with Herb Sutter as co-author, for adding an
essentially cleaned up version of Cairo to the standard library.

<url: https://isocpp.org/blog/2014/01/n3888>

It would not surprise if that's what Microsoft used to create the
Minecraft game in C++, considering that Herb is chief architect of
Visual C++.

And if so, then it was probably done to verify that the proposal is
complete in a real-world sense, that it can actually be used for and is
sufficient for something non-trivial.


Cheers & hth.,

- Alf

[Öö Tiib]

On Thursday, 28 January 2016 23:39:00 UTC+2, Lynn McGuire wrote:
> On 1/28/2016 3:30 PM, Öö Tiib wrote:
> > That has to be separate standard since "graphics" means few LEDs
> > for lot of devices where C++ runs.
> >
>

> Not sure what you mean by "few LEDs" ?

I meant that lot of equipment where C++ runs has only few "light emitting
diodes" if any as end-user output. The standard IO may be is used during
production of device thru UART ("universal asynchronous receiver/transmitter")
or the like.

As far I know the C++ standards committee does not like to specify
language or library subsets and prefers the implementations to implement
the whole language.

[Öö Tiib]

Ok, seems logical. I still don't understand why Microsoft bought Nokia
but purchase of Minecraft starts to make sense that way.

[Lynn McGuire]

I wonder what happened to the proposal since it was proposed in Jan of 2014?

I suspect that the compiler writers are squashing this as much as possible as it would be a large addition to the compilers.

Lynn

[Ian Collins]

Would it? I don't see anything there tat would require language
support. It would be a new library.

--
Ian Collins

[Scott Lurndal]

Ian Collins <ian-...@hotmail.com> writes:
>Lynn McGuire wrote:
>> On 1/28/2016 3:47 PM, Alf P. Steinbach wrote:

>>> On 1/28/2016 10:30 PM, 嘱 Tiib wrote:
>>>>
>>>> Should C++ committee standardize something like OpenGL API or like Qt
>>>> or like Unreal Engine?
>>>
>>> There is a proposal, with Herb Sutter as co-author, for adding an essentially cleaned up version of Cairo to the standard library.
>>>
>>> <url: https://isocpp.org/blog/2014/01/n3888>
>>>
>>> It would not surprise if that's what Microsoft used to create the Minecraft game in C++, considering that Herb is chief architect of
>>> Visual C++.
>>>
>>> And if so, then it was probably done to verify that the proposal is complete in a real-world sense, that it can actually be used for
>>> and is sufficient for something non-trivial.
>>>
>>>
>>> Cheers & hth.,
>>>
>>> - Alf
>>
>> I wonder what happened to the proposal since it was proposed in Jan of 2014?
>>
>> I suspect that the compiler writers are squashing this as much as possible as it would be a large addition to the compilers.
>
>Would it? I don't see anything there tat would require language
>support. It would be a new library.

Which needs to be distributed as part of the compiler suite. So,
additional testing and development resources would be required by
the compiler vendor (along with domain-specific knowledge vis-a-vis
Cairo and the underlying graphics subsystems on all target operating systems).

[Chris M. Thomasson]

>"Stefan Ram" wrote in message
>news:Minecraft-20...@ram.dialup.fu-berlin.de...

>>Lynn McGuire <l...@winsim.com> writes:
>>new Minecraft Education Edition - written in C++

> One can write Minecraft in Java.

> One can't write it in C++, except when one would use
> non-standard libraries.

If I had to write a Minecraft game I would use OpenGL.
It works very nicely with C/C++.

It would be nice if OpenGL was part of a "standard" graphics
library. But, I do not mind using it as a third party
non-standard lib. I just bust out the Glew library, and
modern OpenGL works fine.

[Lynn McGuire]

Don't all of the compiler vendors supply their own versions of the standard libraries?

Lynn

[Ian Collins]

Not all, no. The two I use day to day both use the GNU standard library.

--
Ian Collins

[Jorgen Grahn]

On Sat, 2016-01-30, Ian Collins wrote:
> Lynn McGuire wrote:
>> On 1/29/2016 1:40 PM, Ian Collins wrote:
>>> Lynn McGuire wrote:
>>>> On 1/28/2016 3:47 PM, Alf P. Steinbach wrote:

>>>>> On 1/28/2016 10:30 PM, 嘱 Tiib wrote:
>>>>>>
>>>>>> Should C++ committee standardize something like OpenGL API or like Qt
>>>>>> or like Unreal Engine?
>>>>>
>>>>> There is a proposal, with Herb Sutter as co-author, for adding
>>>>> an essentially cleaned up version of Cairo to the standard
>>>>> library.
>>>>>
>>>>> <url: https://isocpp.org/blog/2014/01/n3888>

...

>>>> I wonder what happened to the proposal since it was proposed in
>>>> Jan of 2014?
>>>>
>>>> I suspect that the compiler writers are squashing this as much as
>>>> possible as it would be a large addition to the compilers.
>>>
>>> Would it? I don't see anything there tat would require language
>>> support. It would be a new library.
>>
>> Don't all of the compiler vendors supply their own versions of the
>> standard libraries?
>
> Not all, no. The two I use day to day both use the GNU standard library.

And besides it would be easy to say "we ship all of the standard
library minus the GUI stuff". Then some other group could provide
that part separately.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[bartekltg]

Do you use threads, dynamic memory and heavy foating point random
number generators on tiny microcontrollers?
No, you do not. But these still are included in the standard.


Also, the standard prefers U2 as integer number implementation;-)

bartekltg

[Öö Tiib]

On Saturday, 30 January 2016 11:55:13 UTC+2, bartekltg wrote:
> On 28.01.2016 23:35, Öö Tiib wrote:
> > On Thursday, 28 January 2016 23:39:00 UTC+2, Lynn McGuire wrote:
> >> On 1/28/2016 3:30 PM, Öö Tiib wrote:
> >>> That has to be separate standard since "graphics" means few LEDs
> >>> for lot of devices where C++ runs.
> >>>
> >>
> >> Not sure what you mean by "few LEDs" ?
> >
> > I meant that lot of equipment where C++ runs has only few "light emitting
> > diodes" if any as end-user output. The standard IO may be is used during
> > production of device thru UART ("universal asynchronous receiver/transmitter")
> > or the like.
> >
> > As far I know the C++ standards committee does not like to specify
> > language or library subsets and prefers the implementations to implement
> > the whole language.
>
> Do you use threads, dynamic memory and heavy foating point random
> number generators on tiny microcontrollers?

I indeed do use threads and dynamic allocations. The <random> in C++
is relatively lightweight but I don't need it typically.

> No, you do not. But these still are included in the standard.

What you mean? Over 70% of things that can run software sold today are
MCU, so someone got to program these buggers and that is fairly frequent
need.
The typical MCU that are used now are way more powerful than the
computers that I did learn to program on decades ago, are dirt cheap and
take next to no power.
See http://www.eetimes.com/document.asp?doc_id=1322014&print=yes
Majority of market is WiFi, then Bluetooth.

In most of programs I don't use most of standard library since I do
not need it for resolving particular problem. I may need them in
next. However graphics as such does not make sense whatsoever about
most MCU so it should be separate library not standard C++ library.

>
> Also, the standard prefers U2 as integer number implementation;-)

I failed to decipher what you mean. U2? Bono, Edge, Adam, Larry?

[David Brown]

Most compiler /developers/ don't make libraries. The phrase "compiler
/vendor/" implies someone that /sells/ compilers, and usually when a
compiler is sold for money it comes along with assemblers, linkers,
libraries, IDE, debugger, etc. But the people actually /writing/
compilers frequently don't make the libraries (or anything else), except
"compiler support libraries" for things like software floating point
support. Even when a single company makes, packages and distributes a
complete toolchain, the compiler and library teams are normally separate
(but with close cooperation, of course).

For the clearest example, the gcc development team don't make the
assembler or linker for any target platforms, and they don't make a
standard library. People use a wide range of standard libraries with
the same versions of the compiler, because they are looking for a range
of different features in the libraries (some people want small
libraries, some what fully-featured libraries, some want OS-specific
libraries, etc.)

[David Brown]

On 30/01/16 17:17, 嘱 Tiib wrote:
> On Saturday, 30 January 2016 11:55:13 UTC+2, bartekltg wrote:

>> On 28.01.2016 23:35, 嘱 Tiib wrote:
>>> On Thursday, 28 January 2016 23:39:00 UTC+2, Lynn McGuire wrote:

>>>> On 1/28/2016 3:30 PM, 嘱 Tiib wrote:
>>>>> That has to be separate standard since "graphics" means few LEDs
>>>>> for lot of devices where C++ runs.
>>>>>
>>>>
>>>> Not sure what you mean by "few LEDs" ?
>>>
>>> I meant that lot of equipment where C++ runs has only few "light emitting
>>> diodes" if any as end-user output. The standard IO may be is used during
>>> production of device thru UART ("universal asynchronous receiver/transmitter")
>>> or the like.
>>>
>>> As far I know the C++ standards committee does not like to specify
>>> language or library subsets and prefers the implementations to implement
>>> the whole language.
>>
>> Do you use threads, dynamic memory and heavy foating point random
>> number generators on tiny microcontrollers?
>
> I indeed do use threads and dynamic allocations. The <random> in C++
> is relatively lightweight but I don't need it typically.
>
>> No, you do not. But these still are included in the standard.
>
> What you mean? Over 70% of things that can run software sold today are
> MCU, so someone got to program these buggers and that is fairly frequent
> need.
> The typical MCU that are used now are way more powerful than the
> computers that I did learn to program on decades ago, are dirt cheap and
> take next to no power.
> See http://www.eetimes.com/document.asp?doc_id=1322014&print=yes
> Majority of market is WiFi, then Bluetooth.
>

Point of fact - the majority of MCUs do /not/ have WiFi or anything of
the sort. It is believable that of the people who responded to that
survey, that about 50% said that when they used some sort of wireless
communication on a project, it included WiFi. But that's all.

Similarly, reading that page quickly gives the impression that 17% of
embedded systems run Android, when in reality microcontrollers that are
not powerful enough to run Android outsell ones that are by a factor of
something like 10,000 to 1.

However, it is certainly true that a typical modern MCU is more powerful
than those of only a few years ago, and 32-bit systems (especially
Cortex M) are very much on the increase. This makes it a lot more
realistic to use "big system" features of C++ in a wider range of
embedded systems.

> In most of programs I don't use most of standard library since I do
> not need it for resolving particular problem. I may need them in
> next. However graphics as such does not make sense whatsoever about
> most MCU so it should be separate library not standard C++ library.
>

At least it should be optional, rather than required. And certainly the
sort of graphics needed in embedded systems covers a wide range - from
no visible interface, through simple screens or LEDs, then small
graphics screens with very limited features, to full computer-like
screens. There is no standard in what hardware is available, and no
standard in the type of software features needed.

>>
>> Also, the standard prefers U2 as integer number implementation;-)
>
> I failed to decipher what you mean. U2? Bono, Edge, Adam, Larry?
>

I've no idea either.

[Bo Persson]

On 2016-01-30 19:36, David Brown wrote:

> On 30/01/16 17:17, Öö Tiib wrote:
>
>> In most of programs I don't use most of standard library since I do
>> not need it for resolving particular problem. I may need them in
>> next. However graphics as such does not make sense whatsoever about
>> most MCU so it should be separate library not standard C++ library.
>>
>
> At least it should be optional, rather than required. And certainly the
> sort of graphics needed in embedded systems covers a wide range - from
> no visible interface, through simple screens or LEDs, then small
> graphics screens with very limited features, to full computer-like
> screens. There is no standard in what hardware is available, and no
> standard in the type of software features needed.
>

The standards committee really doesn't like optional parts of the
standard. That creates dialects.

Once upon a time, the Cobol standards committee released a standard with
12 optional packages. Sorting, report writer, etc. Not until later did
they discover that they had instantly created 4096 different languages,
all 100% standards compliant.

We don't want to repeat that.


Bo Persson

[Alf P. Steinbach]

On 1/30/2016 7:52 PM, Bo Persson wrote:
>
> Once upon a time, the Cobol standards committee released a standard with
> 12 optional packages. Sorting, report writer, etc. Not until later did
> they discover that they had instantly created 4096 different languages,
> all 100% standards compliant.
>
> We don't want to repeat that.

Oh, it's already happened, and more is on the way.

Already happened: e.g. support for converting function pointer to
`void*` and vice versa, is optional, since C++11.

More is on the way: e.g. support for wide character string constructors
for file system library in C++17.


Cheers, & gulp!,

- Alf

[Alf P. Steinbach]

On 1/30/2016 10:32 PM, Alf P. Steinbach wrote:
> On 1/30/2016 7:52 PM, Bo Persson wrote:
>>
>> Once upon a time, the Cobol standards committee released a standard with
>> 12 optional packages. Sorting, report writer, etc. Not until later did
>> they discover that they had instantly created 4096 different languages,
>> all 100% standards compliant.
>>
>> We don't want to repeat that.
>
> Oh, it's already happened, and more is on the way.
>
> Already happened: e.g. support for converting function pointer to
> `void*` and vice versa, is optional, since C++11.
>
> More is on the way: e.g. support for wide character string constructors

^^^^^^
for ... stream constructors with wide character filenames

[Öö Tiib]

On Saturday, 30 January 2016 20:36:17 UTC+2, David Brown wrote:

> On 30/01/16 17:17, Öö Tiib wrote:
> > On Saturday, 30 January 2016 11:55:13 UTC+2, bartekltg wrote:

It may be that there are more 8 bit MCUs sold than 10% but the overall
development effort share for such very constrained platforms can be very
likely only around 10% or less.

>
> Similarly, reading that page quickly gives the impression that 17% of
> embedded systems run Android, when in reality microcontrollers that are
> not powerful enough to run Android outsell ones that are by a factor of
> something like 10,000 to 1.

The survey can be skewed in one or other way, I do not also take it
as full truth. May be the Linuxes are not so common as it seems from that
page but even with next to nothing Micrium RTOS (µC/OS-II, III) we can do
multi-threading and dynamic resource management just fine if it is needed.
It is wise to keep things as simple and robust as possible (but not simpler
than possible).

>
> However, it is certainly true that a typical modern MCU is more powerful
> than those of only a few years ago, and 32-bit systems (especially
> Cortex M) are very much on the increase. This makes it a lot more
> realistic to use "big system" features of C++ in a wider range of
> embedded systems.

It seems to be the trend. Embedded software is more complex and
"wise" so development cost affects price of end products more. Couple
cents for more powerful MCU can help to cut some tens of thousands
from development cost thanks to better tools and also allow bigger
ease of improving the product with software updates later.

[Alf P. Steinbach]

On 1/31/2016 2:07 AM, Öö Tiib wrote:
>
> It is wise to keep things as simple and robust as possible (but not simpler
> than possible).

Oh, Einstein rears his ugly head again, LOLs. :)

Cheers, & happy weekend!,

- Alf

[David Brown]

That's another matter, of course. All sorts of statistics can be
produced to say all sorts of things. My main point is that it nonsense
to think that 50% of MCU's are used with WiFi, no matter how you count
it (units shipped, developers using them, number of projects, dollars,
whatever).

I believe we agree on the basic points here anyway.

>
>>
>> Similarly, reading that page quickly gives the impression that 17% of
>> embedded systems run Android, when in reality microcontrollers that are
>> not powerful enough to run Android outsell ones that are by a factor of
>> something like 10,000 to 1.
>
> The survey can be skewed in one or other way, I do not also take it
> as full truth. May be the Linuxes are not so common as it seems from that
> page but even with next to nothing Micrium RTOS (µC/OS-II, III) we can do
> multi-threading and dynamic resource management just fine if it is needed.
> It is wise to keep things as simple and robust as possible (but not simpler
> than possible).
>
>>
>> However, it is certainly true that a typical modern MCU is more powerful
>> than those of only a few years ago, and 32-bit systems (especially
>> Cortex M) are very much on the increase. This makes it a lot more
>> realistic to use "big system" features of C++ in a wider range of
>> embedded systems.
>
> It seems to be the trend. Embedded software is more complex and
> "wise" so development cost affects price of end products more. Couple
> cents for more powerful MCU can help to cut some tens of thousands
> from development cost thanks to better tools and also allow bigger
> ease of improving the product with software updates later.
>

Certainly that's the trend - though I am not sure that it cuts
development costs so much in practice. The most powerful micros give
you new opportunities (such as the freedom to use C++), but also make
some things more complex. When you use an AVR with a crystal reference,
the chip starts up running at the speed you picked with the choice of
crystal. When you use an M4 with a crystal reference, you usually have
a startup code enabling the oscillator, waiting for it to stabilise,
then sorting out your PLL's, dividers, clock enables, etc., for all the
different parts of the system. The ability to use 32-bit integers and
basic maths without worrying about the time and space costs does not
greatly reduce the effort. And then you get the boss and/or customer
and/or company salesman saying "since you have such a powerful
microcontroller, let's add /this/ feature to the software..." :-)

[Öö Tiib]

I meant that if more complexities are required to product's external
behavior then it is generally cheaper to do same on more powerful
and more general purpose architecture. There can be exceptions but
basics of those are common, can be reused and so can be even provided
as part of API from chip manufacturer. Everybody counts money so if
new features provide no benefits then they order and use older version.

> The ability to use 32-bit integers and
> basic maths without worrying about the time and space costs does not
> greatly reduce the effort. And then you get the boss and/or customer
> and/or company salesman saying "since you have such a powerful
> microcontroller, let's add /this/ feature to the software..." :-)

They know that more features cost more time and effort. If the idea
will likely fall short then I may have opportunity to improve on it that
we can do something similar that is more useful. Or if it is rare and
immediately useful idea then I have opportunity to make a better (more
likely winning on market) product. Or if it is bad idea then I have
opportunity to explain that our baby carriage does not perhaps benefit
from such expensive snowplough but we can try it out of course if we
have budget. On very rare case I have the misery to tell that it is
impossible (that they may interpret as me being lazy or stupid) and
so I am positive hero in eyes of those people.