www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [Semi OT] Language for Game Development talk

reply Max Klyga <max.klyga gmail.com> writes:
Jonathan Blow just recorded a talk about the needs and ideas for a 
programming language for game developer.

https://www.youtube.com/watch?v=TH9VCN6UkyQ

This talk mentions D quite a lot of times.
D is mentioned as the most probable to be adopted if it were possible 
for frictionless interaction with existing codebase.
An interesting talk if you want to look at language design from game 
developer perspective.
Sep 19 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/19/14, 4:47 PM, Max Klyga wrote:

 Jonathan Blow just recorded a talk about the needs and ideas for a
 programming language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were possible
 for frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design from game
 developer perspective.


Awesome, thanks. More evidence that we're putting our chips on seamless 
C++ compatibility.

Andrei
Sep 19 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Max Klyga:


 https://www.youtube.com/watch?v=TH9VCN6UkyQ


I like the focus on correctness of the Rust language (but 
currently Rust seems to ignore several kinds of correctness, 
focusing only on two kinds), but I understand that the needs of 
creating a modern browser (that is a long lived project, where 
like in a kernel the correctness is very important, and the speed 
of writing code is not important) are different from the needs of 
creating a modern video game. So he chooses differently than Rust.

It's a long talk. He doesn't like exceptions, not GCs. Several of 
the things he says are already present in D, but he is looking 
for a language that is simpler than D.

He suggests code like this (the syntax is not so important) in 
his new language:


--------------------------
struct Mesh {
     Vector3 []! positions;
     int []! indices;         joint positions
     Vector2 []! uvs;          joint positions
}

mesh.positions.reserve(num_vertices);
mesh.indices.reserve(num_indices);
mesh.uvs.reserve(num_vertices);
--------------------------

"int []" seems like a D dynamic array, it contains the pointer to 
the data and its length.

The "!" means the memory of this array is owned by the Mesh 
stuct. So when the Mesh instantiation goes out of scope, all the 
memory it owns gets deallocated.

The " joint" annotation means that the memory of "indices" array 
is allocated in the same chunk of memory used to allocate 
"positions". The same happens for "uvs" array. So when you create 
a Mesh you allocate only one chunk of memory for its owned 
dynamic arrays.

"mesh.positions.reserve" allocates memory for the positions array 
of the instance "mesh", but the compiler sees the (optional) 
" joint" annotation, and merges the three allocations into a 
single one and then slices the memory for the three arrays (i 
think the compiler raises a compilation error if it can't merge 
them well).


He also likes an explicit simple syntax for nullable pointers. I 
think the compiler enforces the presence of the null test for 
nullable pointers (perhaps as in the Whiley language):

--------------------------
void do_something(Entity ?a) {
     if (a) {
         a.x = 0;
     }
}
--------------------------

Bye,
bearophile
Sep 19 2014
next sibling parent reply "po" <yes no.com> writes:
  He actually talks about Andre around 40' ;0

As a fellow game dev:

I don't agree with him about RAII, I find it useful

He kind of has a point about exceptions, I'm not big on them


I get the impression his C++ knowledge is about the level of C++ 
with classes, ie very low.

He claims using std:: inherently causes slow compilation, my 
experience says otherwise.

He goes on about "freeing free'd memory", this is never something 
that would happen in modern C++, so he is basically proposing an 
inferior language design.


  At one point he says you can't see the contents of std::vector 
in a debugger. What? This is trivial and has worked in every 
version of Visual Studio for the last 5+ years.

  I do agree the build systems used with C++ are idiotic

IMO, C++'s complexity is largely because of the stupid headers 
and all the mind numbing crap associated with it. That and the 
lack of any reflection.
Sep 19 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 20.09.2014 04:25, schrieb po:

   He actually talks about Andre around 40' ;0

 As a fellow game dev:

 I don't agree with him about RAII, I find it useful


He seems to miss the point that it is possible to write general purpose
RAII templated classes, since he keeps on talking about specific 
implementations for each type of resources.


 He kind of has a point about exceptions, I'm not big on them


Exceptions in most programming languages that have them are a good idea.

Exceptions in C++ are a broken concept.

Having to cope with C semantics, ability to disable them and mixing code
bases is what leads to the pain of writing exception safe code in C++.



 I get the impression his C++ knowledge is about the level of C++ with
 classes, ie very low.


At the end he states having only read K&R C, with everything else being 
learning on the job, it seems.


 He claims using std:: inherently causes slow compilation, my experience
 says otherwise.


Back when I was stil working with C++ at day job, doing a "make world" 
in a code base with Tools.h++ would cost a few hours.

And we were using ClearMake optimized build infrastructure.

You can have fast builds, but it requires knowledge of the whole 
architecture and coding for the build system, e.g. separating modules 
into real libraries.



 He goes on about "freeing free'd memory", this is never something that
 would happen in modern C++, so he is basically proposing an inferior
 language design.


   At one point he says you can't see the contents of std::vector in a
 debugger. What? This is trivial and has worked in every version of
 Visual Studio for the last 5+ years.


It also surprised me. Visual Studio has the best developer experience in 
terms of visualizing C++ data structures.


   I do agree the build systems used with C++ are idiotic

 IMO, C++'s complexity is largely because of the stupid headers and all
 the mind numbing crap associated with it. That and the lack of any
 reflection.


I wonder if modules in C++17 will already be too late.

By then, when looking at C++ project, it might be pre-C++98, C++11, 
C++14, C++17 with the accumulated set of semantics, differences and
styles each standard revision brings to the table.

--
Paulo
Sep 20 2014
prev sibling next sibling parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 20/09/2014 04:25, po a écrit :

   He actually talks about Andre around 40' ;0

 As a fellow game dev:

 I don't agree with him about RAII, I find it useful

 He kind of has a point about exceptions, I'm not big on them


 I get the impression his C++ knowledge is about the level of C++ with
 classes, ie very low.

 He claims using std:: inherently causes slow compilation, my experience
 says otherwise.


Maybe on some systems it's almost impossible to use pre-compiled headers?


 He goes on about "freeing free'd memory", this is never something that
 would happen in modern C++, so he is basically proposing an inferior
 language design.


   At one point he says you can't see the contents of std::vector in a
 debugger. What? This is trivial and has worked in every version of
 Visual Studio for the last 5+ years.


Maybe he don't use VS? I am using QtCreator for Android and Windows, I 
can tell you I have troubles with std::string,...
I am waiting for llvm and lld for the replacement of gdb under Windows.


   I do agree the build systems used with C++ are idiotic

 IMO, C++'s complexity is largely because of the stupid headers and all
 the mind numbing crap associated with it. That and the lack of any
 reflection.
Sep 24 2014
prev sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Saturday, 20 September 2014 at 02:25:31 UTC, po wrote:

 As a fellow game dev:

 I don't agree with him about RAII, I find it useful

 He kind of has a point about exceptions, I'm not big on them


...

 He goes on about "freeing free'd memory", this is never 
 something that would happen in modern C++, so he is basically 
 proposing an inferior language design.


It happens when you don't use RAII.  Sounds like he should review 
his concepts.

Regarding exceptions, they can be used incorrectly, but I think 
they tend to provide better error handling than return codes 
*because no one ever checks return codes*.  And when you do 
pathologically handle error codes, the amount of code duplication 
can be tremendous, and the chance for errors involving improper 
cleanup can be quite high.  Though again, RAII can be of 
incredible use here.


  At one point he says you can't see the contents of std::vector 
 in a debugger. What? This is trivial and has worked in every 
 version of Visual Studio for the last 5+ years.


std::string tends to be more complicated because of the small 
string optimization.  Most debuggers I've used don't handle that 
correctly out of the box, even if sorting it out really isn't 
difficult.
Sep 25 2014
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 25 September 2014 at 22:52:39 UTC, Sean Kelly wrote:

 On Saturday, 20 September 2014 at 02:25:31 UTC, po wrote:

 As a fellow game dev:

 I don't agree with him about RAII, I find it useful

 He kind of has a point about exceptions, I'm not big on them


 ...

 He goes on about "freeing free'd memory", this is never 
 something that would happen in modern C++, so he is basically 
 proposing an inferior language design.


 It happens when you don't use RAII.  Sounds like he should 
 review his concepts.


This is really missing the point. He knows RAII is useful and he 
knows RAII solves freeing free'd memory. Maybe it's time to 
re-watch the video.
Sep 25 2014
parent "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 25 September 2014 at 23:04:08 UTC, Peter Alexander 
wrote:

 This is really missing the point. He knows RAII is useful and 
 he knows RAII solves freeing free'd memory. Maybe it's time to 
 re-watch the video.


I was replying to the comments.  Sorry if I misunderstood.
Sep 25 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 3:52 PM, Sean Kelly wrote:

 Regarding exceptions, they can be used incorrectly, but I think they tend to
 provide better error handling than return codes *because no one ever checks
 return codes*.  And when you do pathologically handle error codes, the amount
of
 code duplication can be tremendous, and the chance for errors involving
improper
 cleanup can be quite high.  Though again, RAII can be of incredible use here.


Yup. A very common source of bugs in C code is all the incorrectly written "if 
(error) goto cleanup;" code. Exceptions and RAII take care of most of that.
Sep 25 2014
prev sibling parent reply "po" <yes no.com> writes:
 std::string tends to be more complicated because of the small 
 string optimization.  Most debuggers I've used don't handle 
 that correctly out of the box, even if sorting it out really 
 isn't difficult.


  Almost all game developers use Visual Studio, and VS has 
supported visualization of all STL containers(including string) 
since VS2005.



This is really missing the point. He knows RAII is useful and he 
knows RAII solves freeing free'd memory. Maybe it's time to 
re-watch the video.


  I watched it. None of what he said made much sense.
His claims:
1. RAII is bad because exceptions.
   -Nothing forces to use exceptions, so irrelevant
2. RAII is bad because you must write copy constructor,destructor 
etc each time.
   -No you write a few basic template classes and reuse them.




Regarding exceptions, they can be used incorrectly, but I think 
they tend to provide better error handling than return codes 
*because no one ever checks return codes*.  And when you do 
pathologically handle error codes, the amount of code 
duplication can be tremendous, and the chance for errors 
involving improper cleanup can be quite high.  Though again, 
RAII can be of incredible use here.


  That is all true, I agree that exceptions are better than error 
codes.
But for games, the general design is that errors are impossible.
The game should never fail so exceptions serve little purpose.

-ran out of memory? Shut game down, this should not happen
-couldn't open a file? Shut game down, this should never happen
-out of bounds array access, invalid iterator etc: abort game, 
found during development, fixed, should never happen.

-networking? This is one place where you do need to handle 
errors, but do you need exceptions just to handle this one case? 
Probably not
Sep 26 2014
next sibling parent "po" <yes no.com> writes:
  More stupidity from JB:

  At one point he talks about merging the memory of Mesh's 
positions & indices & UV, but he does this manually like a 
friggin moron;0

  The proper way is using an allocator, but I'm guessing JB 
doesn't grok allocators- "cause they be weird templates stuff 
derp!" & "templates r slow, derp!"
Sep 26 2014
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 07:24:48 UTC, po wrote:

  I watched it. None of what he said made much sense.
 His claims:
 1. RAII is bad because exceptions.
   -Nothing forces to use exceptions, so irrelevant
 2. RAII is bad because you must write copy 
 constructor,destructor etc each time.
   -No you write a few basic template classes and reuse them.


The way I interpreted him:

- He does not want exceptions.
- RAII makes most sense if you have exceptions.
- He want to share views to memory blocks without RC
- He needs debugging aids to resolve free() issues
- He does not want to write new classes to manage resources (not 
only memory, but shaders etc).
- Writing useful classes in C++ => tedious boilerplate.

He might not say it explicitly, but he seemed to assume people to 
hold those views. So that probably means he usually works with 
people who code in the same patterns.


 -ran out of memory? Shut game down, this should not happen


On IOS or PNaCl you might have to accept that it may happen...
Sep 26 2014
parent reply "po" <yes no.com> writes:
 - RAII makes most sense if you have exceptions.


   RAII is orthogonal to exceptions, so his claim is nonsense.


 - He does not want to write new classes to manage resources 
 (not only memory, but shaders etc).


  I manage all resources using RAII, it did not require me to 
write a new RAII class for each resource type.
  I suspect he thinks that to implement RAII for a Mesh class you 
would need to create constructor/copy constructor/destructor. 
This is not how it is actually done. Instead the vertices/indices 
wrapped by an RAII template type.

  You can see on one slide he attempts to use std::unique_ptr<> 
but his syntax is completely wrong, a good indication he doesn't 
actually have any clue how this stuff works.


 - Writing useful classes in C++ => tedious boilerplate.


   I saw his claim, but again it is nonsense. In C++ we rarely if 
ever manually write copy constructor/move constructor/destructor. 
These are auto generated 99% of the time. His claim comes out of 
ignorance of how to properly use C++.



 He might not say it explicitly, but he seemed to assume people 
 to hold those views. So that probably means he usually works 
 with people who code in the same patterns.


  I've worked with people who think exactly like him. They are 
generally somewhat older, and started programming games in the 
80/90's. I was not impressed by the coding ability of the 
individuals I met who had this mentality.


  If he updated his toolbox he might not have spent 5 years 
working on his latest game--
Sep 26 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:

  I've worked with people who think exactly like him. They are 
 generally somewhat older, and started programming games in the 
 80/90's. I was not impressed by the coding ability of the 
 individuals I met who had this mentality.


I'm not surprised, but if you are going to create a language for 
current practices you have to cater to whatever the practice is. 
They are probably less eager to relearn how to use C/C++.

I also think many just don't want to attempt to deal with C++ 
std:: libs, due to bad experience with them in the past. So they 
use their own stuff instead.
Sep 26 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 2:11 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:

  I've worked with people who think exactly like him. They are generally
 somewhat older, and started programming games in the 80/90's. I was not
 impressed by the coding ability of the individuals I met who had this
mentality.


 I'm not surprised, but if you are going to create a language for current
 practices you have to cater to whatever the practice is. They are probably less
 eager to relearn how to use C/C++.

 I also think many just don't want to attempt to deal with C++ std:: libs, due
to
 bad experience with them in the past. So they use their own stuff instead.


I can understand the attitude. I tend to do the same thing. Including invent 
another programming language :-)
Sep 26 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:

 - RAII makes most sense if you have exceptions.


   RAII is orthogonal to exceptions, so his claim is nonsense.


 - He does not want to write new classes to manage resources 
 (not only memory, but shaders etc).


  I manage all resources using RAII, it did not require me to 
 write a new RAII class for each resource type.
  I suspect he thinks that to implement RAII for a Mesh class 
 you would need to create constructor/copy 
 constructor/destructor. This is not how it is actually done. 
 Instead the vertices/indices wrapped by an RAII template type.

  You can see on one slide he attempts to use std::unique_ptr<> 
 but his syntax is completely wrong, a good indication he 
 doesn't actually have any clue how this stuff works.


 - Writing useful classes in C++ => tedious boilerplate.


   I saw his claim, but again it is nonsense. In C++ we rarely 
 if ever manually write copy constructor/move 
 constructor/destructor. These are auto generated 99% of the 
 time. His claim comes out of ignorance of how to properly use 
 C++.



 He might not say it explicitly, but he seemed to assume people 
 to hold those views. So that probably means he usually works 
 with people who code in the same patterns.


  I've worked with people who think exactly like him. They are 
 generally somewhat older, and started programming games in the 
 80/90's. I was not impressed by the coding ability of the 
 individuals I met who had this mentality.


  If he updated his toolbox he might not have spent 5 years 
 working on his latest game--


And I also question his skills given that he admits the only 
programming book he has ever read was K&R C.

So most likely he has very fragile bases from googling around and 
stuff.

--
Paulo
Sep 26 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:

 - RAII makes most sense if you have exceptions.


   RAII is orthogonal to exceptions, so his claim is nonsense.


Just a note: this isn't really true. RAII was initially used to 
deal with exceptions. If you want fast backtracking and just 
reset the stack pointer (rather than unwinding) then 
stack-allocated RAII objects won't work since they will be 
overwritten. You need to maintain a list of "destructors" in 
thread local memory or close to the stack root so that you can 
close files etc. Whether RAII is the best option really depends 
on what kind of execution patterns and performance 
characteristics you are aiming for.
Sep 26 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 26 September 2014 at 09:24:19 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:

 - RAII makes most sense if you have exceptions.


  RAII is orthogonal to exceptions, so his claim is nonsense.


 Just a note: this isn't really true. RAII was initially used to 
 deal with exceptions.


This is completely not true, we were using RAII in C++ before any 
compiler had real support for exceptions.

In the 90's exceptions were still being discussed at ANSI/ISO 
with very few compiler offering support for them. And those that 
did, suffered from implementation bugs.

--
Paulo
Sep 26 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 09:41:09 UTC, Paulo  Pinto wrote:

 This is completely not true, we were using RAII in C++ before 
 any compiler had real support for exceptions.


Well, I haven't read the 1990 edition of the annotated C++ 
reference by Stroustrup and Ellis since the mid 90s so my memory 
may be clouded, but that is how I remember it.

And wikipedia says the same:

«The technique was developed for exception-safe resource 
management in C++[3] during 1984–89»

http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
Sep 26 2014
next sibling parent "po" <yes no.com> writes:
«The technique was developed for exception-safe resource

 management in C++[3] during 1984–89»

 http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization


  It may have been developed for exceptions, that doesn't mean you 
have to use them together.

Alternative error reporting methods I prefer:
-return optional type, is empty if it failed
-accept continuation of what to do once operation secedes
   ie:
      open_file("blah.txt",
                [](file& f){..}}//called when it opened 
successfully
                //could also have a 2nd lambda for when it fails
Sep 26 2014
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 26 September 2014 at 10:01:32 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 26 September 2014 at 09:41:09 UTC, Paulo  Pinto 
 wrote:

 This is completely not true, we were using RAII in C++ before 
 any compiler had real support for exceptions.


 Well, I haven't read the 1990 edition of the annotated C++ 
 reference by Stroustrup and Ellis since the mid 90s so my 
 memory may be clouded, but that is how I remember it.

 And wikipedia says the same:

 «The technique was developed for exception-safe resource 
 management in C++[3] during 1984–89»

 http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization


I don't care what Wikipedia says, I was there in the early C++ 
days happily using Turbo and Borland C++ in MS-DOS.

--
Paulo
Sep 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 4:02 AM, Paulo Pinto wrote:

 On Friday, 26 September 2014 at 10:01:32 UTC, Ola Fosheim Grøstad wrote:

 On Friday, 26 September 2014 at 09:41:09 UTC, Paulo  Pinto wrote:

 This is completely not true, we were using RAII in C++ before any compiler
 had real support for exceptions.


 Well, I haven't read the 1990 edition of the annotated C++ reference by
 Stroustrup and Ellis since the mid 90s so my memory may be clouded, but that
 is how I remember it.

 And wikipedia says the same:

 «The technique was developed for exception-safe resource management in C++[3]
 during 1984–89»

 http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization


 I don't care what Wikipedia says, I was there in the early C++ days happily
 using Turbo and Borland C++ in MS-DOS.


I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions. Bjarne's 
1986 "The C++ Programming Language" does not mention RAII or exceptions, but 
does say on pg. 158:

"Calling constructors and destructors for static objects serves an extremely 
important function in C++. It is the way to ensure proper initialization and 
cleanup of data structures in libraries."
Sep 26 2014
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 26.09.2014 20:46, schrieb Walter Bright:

 On 9/26/2014 4:02 AM, Paulo Pinto wrote:

 On Friday, 26 September 2014 at 10:01:32 UTC, Ola Fosheim Grøstad wrote:

 On Friday, 26 September 2014 at 09:41:09 UTC, Paulo  Pinto wrote:

 This is completely not true, we were using RAII in C++ before any
 compiler
 had real support for exceptions.


 Well, I haven't read the 1990 edition of the annotated C++ reference by
 Stroustrup and Ellis since the mid 90s so my memory may be clouded,
 but that
 is how I remember it.

 And wikipedia says the same:

 «The technique was developed for exception-safe resource management
 in C++[3]
 during 1984–89»

 http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization


 I don't care what Wikipedia says, I was there in the early C++ days
 happily
 using Turbo and Borland C++ in MS-DOS.


 I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions.
 Bjarne's 1986 "The C++ Programming Language" does not mention RAII or
 exceptions, but does say on pg. 158:

 "Calling constructors and destructors for static objects serves an
 extremely important function in C++. It is the way to ensure proper
 initialization and cleanup of data structures in libraries."


This is what happens when people take for granted what Wikipedia says.

At least in this regard, there are still people alive that lived through 
the events.

--
Paulo
Sep 26 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 26, 2014 at 08:50:06PM +0200, Paulo Pinto via Digitalmars-d wrote:

 Am 26.09.2014 20:46, schrieb Walter Bright:

On 9/26/2014 4:02 AM, Paulo Pinto wrote:

On Friday, 26 September 2014 at 10:01:32 UTC, Ola Fosheim Grøstad wrote:

On Friday, 26 September 2014 at 09:41:09 UTC, Paulo  Pinto wrote:

This is completely not true, we were using RAII in C++ before any
compiler had real support for exceptions.


Well, I haven't read the 1990 edition of the annotated C++
reference by Stroustrup and Ellis since the mid 90s so my memory
may be clouded, but that is how I remember it.

And wikipedia says the same:

«The technique was developed for exception-safe resource management
in C++[3] during 1984–89»

http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization


I don't care what Wikipedia says, I was there in the early C++ days
happily using Turbo and Borland C++ in MS-DOS.


I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions.
Bjarne's 1986 "The C++ Programming Language" does not mention RAII or
exceptions, but does say on pg. 158:

"Calling constructors and destructors for static objects serves an
extremely important function in C++. It is the way to ensure proper
initialization and cleanup of data structures in libraries."


 
 This is what happens when people take for granted what Wikipedia says.
 
 At least in this regard, there are still people alive that lived
 through the events.


[...]

Then wikipedia should be edited to be more accurate, while said people
are still alive!! Otherwise the distorted version of the events will
come to be regarded as fact.


T

-- 
Nearly all men can stand adversity, but if you want to test a man's character,
give him power. -- Abraham Lincoln
Sep 26 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 11:52 AM, H. S. Teoh via Digitalmars-d wrote:

 Then wikipedia should be edited to be more accurate, while said people
 are still alive!! Otherwise the distorted version of the events will
 come to be regarded as fact.



I've been banned from editing Wikipedia for some reason. Someone else will have 
to do it :-(
Sep 26 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 26, 2014 at 12:33:06PM -0700, Walter Bright via Digitalmars-d wrote:

 On 9/26/2014 11:52 AM, H. S. Teoh via Digitalmars-d wrote:

Then wikipedia should be edited to be more accurate, while said
people are still alive!! Otherwise the distorted version of the
events will come to be regarded as fact.


 
 
 I've been banned from editing Wikipedia for some reason.


What, why?



 Someone else will have to do it :-(


I would, except that right now I'm working on a dmd PR. ;-) Do you have
references to back up your claims (references deemed acceptable by WP)?
Otherwise whatever I (or anyone else) put on there will just get
reverted by the editors. Unfortunately, there are a few WP editors
around who are overly draconian about deleting "unreferenced" material.
(Got burned by them myself a few times -- drove me to put stuff on my
own website instead, and then I discovered other people adding links to
my website from WP and adding the stuff back on my behalf. Ahhh, sweet
revenge. :-P)


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you
wish you hadn't.
Sep 26 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 12:47 PM, H. S. Teoh via Digitalmars-d wrote:

 I would, except that right now I'm working on a dmd PR. ;-)


No hurry.


 Do you have
 references to back up your claims (references deemed acceptable by WP)?


Yes, I quoted from Bjarne's 1986 book "The C++ Programming Language".

Bjarne writes in "Possible Directions for C++" he writes "Because of
destructors 
the C solution is insufficient and C++ will eventually be forced to develop an 
exception handling mechanism."

    -- Proceedings and Additional Papers C++ Workshop Santa Fe, NM, 1987

That's the first reference I can find to adding EH to C++. It does not propose 
any syntax.

In 1988 and 1990 there are proposals for ways to add EH to C++.
Sep 26 2014
prev sibling parent reply "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Friday, 26 September 2014 at 18:54:14 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 Then wikipedia should be edited to be more accurate, while said 
 people
 are still alive!! Otherwise the distorted version of the events 
 will
 come to be regarded as fact.


Stroustrup was planning for exceptions up till ARM in 1990 and 
RAII become an idiom through his writings. C++ compilers had ARM 
exception support at least by 1992/1993: HP, IBM, DEC, maybe SGI. 
  (ARM is the base document for the ISO standard and was regarded 
as the c++ bible.)

Those are not facts?
Sep 26 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 26.09.2014 22:10, schrieb Ola Fosheim Grostad:

 On Friday, 26 September 2014 at 18:54:14 UTC, H. S. Teoh via
 Digitalmars-d wrote:

 Then wikipedia should be edited to be more accurate, while said people
 are still alive!! Otherwise the distorted version of the events will
 come to be regarded as fact.


 Stroustrup was planning for exceptions up till ARM in 1990 and RAII
 become an idiom through his writings. C++ compilers had ARM exception
 support at least by 1992/1993: HP, IBM, DEC, maybe SGI.  (ARM is the
 base document for the ISO standard and was regarded as the c++ bible.)

 Those are not facts?


Yes Stroustroup was planning for exceptions and maybe there were even 
some articles flying around in C++ Report and The C Users Journal.

However, we were using MS-DOS systems networked via Novell Netware.

I started coding C++ on MS-DOS in 1993 with Turbo C++ 1.0 all the way up 
to Turbo C++ 1.5 for Windows 3.x. Also used Borland C++ occasionally.

I cannot remember any longer which version eventually added support for 
exceptions, but it was already a Windows 3.x version I would say.

The early 90's in Portugal, meant no Internet and no BBS access outside 
Porto and Lisbon.

We just learned on our own, by ourselves, reading books, magazines that 
sometimes lost their way into our small town or talking with our peers.

RAII just seemed a natural way to use destructors. Specially since I was 
already using this pattern in Turbo Pascal 6.0.

--
Paulo
Sep 26 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 20:48:20 UTC, Paulo Pinto wrote:

 I started coding C++ on MS-DOS in 1993 with Turbo C++ 1.0 all 
 the way up to Turbo C++ 1.5 for Windows 3.x. Also used Borland 
 C++ occasionally.

 I cannot remember any longer which version eventually added 
 support for exceptions, but it was already a Windows 3.x 
 version I would say.


Watcom had some exception support around 1993 according to 
comp.lang.c++, but it was probably not a big selling point to add 
it for other vendors on the MS platforms.

I remember it was very difficult to find a good free C++ 
implementation though. Cfront was kind of annoying (and did not 
support exceptions either). In the free software movement C/Unix 
was the real deal and my impression was that C++ was not viewed 
as "cool", so it took a while for g++ to get the quality up to 
acceptable standards.

My uni had DEC/SGI with C++, but at home where I preferred to do 
that type of programming I was stuck with C until g++ had 
improved by the mid 90s. And… of course… the uni did not teach 
C++ since it has a horrible design. I was only aware of one 
lecturer that had a C++ interest. I think they only had C++ 
available by accident (being part of a standard suite).


 The early 90's in Portugal, meant no Internet and no BBS access 
 outside Porto and Lisbon.


:-/ I did some BBSing in the late 80s, early 90s. It had a 
special feel to it, compared to the internet I think. More like a 
house/pub. I was lucky and got good Internet access at the 
university throughout the 90s (it was connected to 
ARPAnet/Internet already in 1973 so I think they gave it a high 
priority).
Sep 26 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 26, 2014 at 09:32:54PM +0000, via Digitalmars-d wrote:
[...]

 I remember it was very difficult to find a good free C++
 implementation though. Cfront was kind of annoying (and did not
 support exceptions either).  In the free software movement C/Unix was
 the real deal and my impression was that C++ was not viewed as "cool",
 so it took a while for g++ to get the quality up to acceptable
 standards.
 
 My uni had DEC/SGI with C++, but at home where I preferred to do that
 type of programming I was stuck with C until g++ had improved by the
 mid 90s.  And… of course… the uni did not teach C++ since it has a
 horrible design. I was only aware of one lecturer that had a C++
 interest. I think they only had C++ available by accident (being part
 of a standard suite).


[...]

Whoa, this brings back the memories! I remember taking a course in
college where the prof was teaching us this idiom, which by today's
standards is rather laughable (and probably no longer compiles -- this
dates back to before the first C++ standardization in 1998):

	class MyClass {
		...
		MyClass &Myclass(Myclass &);
		...
	}

	// Gotta love the audacious violation of DRY here:
	MyClass &MyClass::MyClass(MyClass &mc)
	{
		...
		return *this;
	}

This was on g++ in the early to mid 90's, just around the time C++
templates first became widely available. I still remember trying both
c++ (the compiler, not the language) and g++, and perhaps one or two
other compilers installed on the lab compute servers, and finding that
one compiler would support new feature X but not new feature Y, but the
other compiler that supported feature Y had a buggy implementation of
feature X. So it was quite frustrating that many of the cool new
features couldn't be used together 'cos of buggy compiler
implementations. Not to mention subtle differences in dialect that
sometimes makes your projects uncompilable with another compiler. Fun
times.


T

-- 
People tell me I'm stubborn, but I refuse to accept it!
Sep 26 2014
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 26.09.2014 23:32, schrieb "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>":

 On Friday, 26 September 2014 at 20:48:20 UTC, Paulo Pinto wrote:

 I started coding C++ on MS-DOS in 1993 with Turbo C++ 1.0 all the way
 up to Turbo C++ 1.5 for Windows 3.x. Also used Borland C++ occasionally.

 I cannot remember any longer which version eventually added support
 for exceptions, but it was already a Windows 3.x version I would say.


 Watcom had some exception support around 1993 according to
 comp.lang.c++, but it was probably not a big selling point to add it for
 other vendors on the MS platforms.


Watcom only became big on MS-DOS when they started offering a 32bit 
MS-DOS extender (remember those?). That feature, coupled with good code 
generation, made many game studios go for it.

But that is the only thing I know from it. In Portugal, Borland and 
Microsoft ruled the MS-DOS developer tools.


 I remember it was very difficult to find a good free C++ implementation
 though. Cfront was kind of annoying (and did not support exceptions
 either). In the free software movement C/Unix was the real deal and my
 impression was that C++ was not viewed as "cool", so it took a while for
 g++ to get the quality up to acceptable standards.


Back in those days I got to buy my tools. Only knew what FOSS was about 
around 1995.

In 1993 I got hold of Turbo C 2.0 and Turbo C++ 1.0, after a couple of 
years of doing Turbo Pascal, already with OOP using Turbo Vision.

C just looked stone age when compared with Turbo Pascal 6.0 features and 
I immediately switched to C++ after a few months of pure C.

Since then I have been on C++ troop ranks on the usual C vs C++ debates.

The sad thing is that nowadays many new C++ programmers behave against 
languages with automatic memory management, the same way we were seen by 
C programmers in those days.

You quite right about us not being cool in UNIX world. Outside of CORBA, 
it was always an uphill battle to use C++. Specially in the FOSS front.

I wrote one of the first tutorials on how to use yacc/bison and lex/flex 
with C++ instead of C, as I could not find any.

--
Paulo
Sep 27 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 26 Sep 2014 11:52:21 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:


 Then wikipedia should be edited to be more accurate, while said people
 are still alive!! Otherwise the distorted version of the events will
 come to be regarded as fact.


it's very hard to introduce correct facts to wikipedia.

the strange this is that it's very easy to introduce incorrect facts if
they are looking "normal".
Sep 26 2014
prev sibling next sibling parent "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Friday, 26 September 2014 at 18:46:19 UTC, Walter Bright wrote:

 I wrote a C++ compiler in 1987. Nobody had ever heard of 
 exceptions. Bjarne's 1986 "The C++ Programming Language" does 
 not mention RAII or exceptions, but does say on pg. 158:


Exceptions is chapter 15 in the 1990 edition. I should have it 
somewhere, a small brown hardcover and expensive!
Sep 26 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 18:46:19 UTC, Walter Bright wrote:

 I wrote a C++ compiler in 1987. Nobody had ever heard of 
 exceptions.


Lisp had exceptions in the 60s. In the 80s exception handling was 
fashionable in language design. :)


 Bjarne's 1986 "The C++ Programming Language" does not mention 
 RAII or exceptions, but does say on pg. 158:

 "Calling constructors and destructors for static objects serves 
 an extremely important function in C++. It is the way to ensure 
 proper initialization and cleanup of data structures in 
 libraries."


I would not call this RAII, but Simula67 did have the block 
prefixing idiom which I presume Stroustrup knew about.

http://www.olejohandahl.info/papers/Birth-of-S.pdf

RAII is a natural extension of block prefixing IMO. BETA, the 
follow up language to Simula, was developed in the 70s/80s and 
support RAII-style prefixing through the "inner"-statement. You 
can probably find many RAII-like idioms in various languages if 
you dig back in time, though.
Sep 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 2:04 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Friday, 26 September 2014 at 18:46:19 UTC, Walter Bright wrote:

 I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions.


 Lisp had exceptions in the 60s. In the 80s exception handling was fashionable
in
 language design. :)


I meant in the context of C++.



 Bjarne's 1986 "The C++ Programming Language" does not mention RAII or
 exceptions, but does say on pg. 158:

 "Calling constructors and destructors for static objects serves an extremely
 important function in C++. It is the way to ensure proper initialization and
 cleanup of data structures in libraries."


 I would not call this RAII,


I would. The whole point of destructors is to automatically clean up resources 
when the object goes away, which was (later) dubbed RAII.
Sep 26 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 21:19:29 UTC, Walter Bright wrote:

 I would. The whole point of destructors is to automatically 
 clean up resources when the object goes away, which was (later) 
 dubbed RAII.


Yeah, but RAII takes it to the extreme where you create dummy 
classes that only consist of constructors/destructors so that the 
stack unwinding does all cleanup/closing/freeing without any 
try/catch.

Before C++ templates that looked verbose and ugly syntactically, 
and it is still tedious if you only use the specific resource in 
one location.  "scope(exit)" is often more transparent IMO.
Sep 27 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 27 September 2014 at 10:01:05 UTC, Ola Fosheim 
Grøstad wrote:

 On Friday, 26 September 2014 at 21:19:29 UTC, Walter Bright 
 wrote:

 I would. The whole point of destructors is to automatically 
 clean up resources when the object goes away, which was 
 (later) dubbed RAII.


 Yeah, but RAII takes it to the extreme where you create dummy 
 classes that only consist of constructors/destructors so that 
 the stack unwinding does all cleanup/closing/freeing without 
 any try/catch.


This is not necessary in D as we have scope statements.


 Before C++ templates that looked verbose and ugly 
 syntactically, and it is still tedious if you only use the 
 specific resource in one location.  "scope(exit)" is often more 
 transparent IMO.


I guess this is matter of style and various tradeoff. A very 
common operation to rollback probably deserve its own RAII 
struct. An uncommon one is better served with scope.
Sep 28 2014
prev sibling next sibling parent reply "po" <yes no.com> writes:
 Just a note: this isn't really true. RAII was initially used to 
 deal with exceptions. If you want fast backtracking and just 
 reset the stack pointer (rather than unwinding) then 
 stack-allocated RAII objects won't work since they will be 
 overwritten. You need to maintain a list of "destructors" in 
 thread local memory or close to the stack root so that you can 
 close files etc. Whether RAII is the best option really depends 
 on what kind of execution patterns and performance 
 characteristics you are aiming for.


  Why would you reset the stack pointer? Keep in mind, nobody uses 
exceptions in games. No exceptions are going to be thrown in a 
game context.
Sep 26 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 09:42:14 UTC, po wrote:

  Why would you reset the stack pointer? Keep in mind, nobody 
 uses exceptions in games. No exceptions are going to be thrown 
 in a game context.


To backtrack quickly out of deep recursion, but I am not saying 
this is a typical use case or what JB referred to (hence it was 
just a side note). I think both RAII, "finally", and more global 
manager-objects are reasonable solutions depending on the task.
Sep 26 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 2:24 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:

 - RAII makes most sense if you have exceptions.


   RAII is orthogonal to exceptions, so his claim is nonsense.


 Just a note: this isn't really true. RAII was initially used to deal with
 exceptions.


RAII existed in C++ years before exceptions.
Sep 26 2014
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 September 2014 17:24, po via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 std::string tends to be more complicated because of the small string
 optimization.  Most debuggers I've used don't handle that correctly out of
 the box, even if sorting it out really isn't difficult.



  Almost all game developers use Visual Studio, and VS has supported
 visualization of all STL containers(including string) since VS2005.



 This is really missing the point. He knows RAII is useful and he knows
 RAII solves freeing free'd memory. Maybe it's time to re-watch the video.



  I watched it. None of what he said made much sense.
 His claims:
 1. RAII is bad because exceptions.
   -Nothing forces to use exceptions, so irrelevant
 2. RAII is bad because you must write copy constructor,destructor etc each
 time.
   -No you write a few basic template classes and reuse them.




 Regarding exceptions, they can be used incorrectly, but I think they tend
 to provide better error handling than return codes *because no one ever
 checks return codes*.  And when you do pathologically handle error codes,
 the amount of code duplication can be tremendous, and the chance for errors
 involving improper cleanup can be quite high.  Though again, RAII can be of
 incredible use here.



  That is all true, I agree that exceptions are better than error codes.
 But for games, the general design is that errors are impossible.
 The game should never fail so exceptions serve little purpose.

 -ran out of memory? Shut game down, this should not happen
 -couldn't open a file? Shut game down, this should never happen
 -out of bounds array access, invalid iterator etc: abort game, found during
 development, fixed, should never happen.

 -networking? This is one place where you do need to handle errors, but do
 you need exceptions just to handle this one case? Probably not


This.
I've never used an exception before. I can't imagine a reason I would
ever want to.
Networking problems won't be solved with an exception, that requires
very comprehensive logic.
Sep 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 8:21 AM, Manu via Digitalmars-d wrote:

 I've never used an exception before. I can't imagine a reason I would
 ever want to.


Nothrow is your friend, then!


BTW, you need exceptions if there appears in your code things like:

     if (errorHappened) goto LcleanupCode;
Sep 26 2014
next sibling parent =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
Walter Bright <newshound2 digitalmars.com> wrote:

 On 9/26/2014 8:21 AM, Manu via Digitalmars-d wrote:

 I've never used an exception before. I can't imagine a reason I would
 ever want to.


 
 Nothrow is your friend, then!
 
 
 BTW, you need exceptions if there appears in your code things like:
 
     if (errorHappened) goto LcleanupCode;


No you need destructors/RAII/finally. And all those work equally with
without exceptions (early return).

Tobi
Sep 26 2014
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 27 September 2014 04:20, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 9/26/2014 8:21 AM, Manu via Digitalmars-d wrote:

 I've never used an exception before. I can't imagine a reason I would
 ever want to.



 Nothrow is your friend, then!


It certainly is. The only thing that ever ruins my nothrow-ness are
phobos calls ;)


 BTW, you need exceptions if there appears in your code things like:

     if (errorHappened) goto LcleanupCode;


Initialisation logic often looks like this, and I buy the value of
exceptions in this case. However, I've never successfully implemented
it yet though, because the calls that create code like that always
seem to be extern-C calls in my experience... :/
I'm not sure why my D code doesn't manifest those patterns, D just
seems to produce different code than C/C++...
Sep 26 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-09-27 02:47, Manu via Digitalmars-d wrote:


 Initialisation logic often looks like this, and I buy the value of
 exceptions in this case. However, I've never successfully implemented
 it yet though, because the calls that create code like that always
 seem to be extern-C calls in my experience... :/


Perhaps you should wrap those call an throw an exception.

-- 
/Jacob Carlborg
Sep 27 2014
parent "Sean Kelly" <sean invisibleduck.org> writes:
On Saturday, 27 September 2014 at 09:32:19 UTC, Jacob Carlborg 
wrote:

 On 2014-09-27 02:47, Manu via Digitalmars-d wrote:


 Initialisation logic often looks like this, and I buy the 
 value of
 exceptions in this case. However, I've never successfully 
 implemented it yet though, because the calls that create code 
 like that always seem to be extern-C calls in my experience... 
 :/


 Perhaps you should wrap those call an throw an exception.


I often do something like this:

proc(someFunc(a, b, c));
proc(anotherFunc(d, e, f));

Where proc() processes the return value and conditionally throws 
on error.  You really need one such function per API, but that's 
not a big deal.  You can kind of get away with macros if you're 
using C, but all they can really do is jump to an expected Lerror 
label.
Sep 27 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-09-26 09:24, po wrote:


 -couldn't open a file? Shut game down, this should never happen


It depends on what file it's trying to open and what the failure is. If 
it can't find the settings file, just recreate it and move on. Perhaps 
report the error to the user.

-- 
/Jacob Carlborg
Sep 26 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
He also proposes of removing most or all implicit type 
conversions in his language, like bool->int.

D allows code like:

bool foo() { return true; }
void bar(int x) {}
void main() {
     bar(foo());
}


In past, removing implicit conversions from D forced you to write:

bar(cast(int)foo());

That is not much safer than having implicit conversions because 
cast() is a sharp powerful tool. In D programs the usage of 
cast() should be minimized as much as possible.

But if we keep disallowing implicit conversions, but we introduce 
a second kind of static cast that only work if the conversion is 
lossless, then we have code like (currently this is allowed in D 
because the int() syntax rides on the implicit conversions. So 
the semantic is a little different):

bar(int(foo()));

You also need suffixes to express most types with literals (like 
10u8 for an ubyte, or 'c'd for a dchar), to code in a more handy 
way.

Perhaps this new situation (no implicit conversions, plus two 
kinds of casts, and few extra literals) is safer than the current 
D situation (and I think no C code gains a new working meaning in 
this new situation).

Bye,
bearophile
Sep 20 2014
parent reply "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Saturday, 20 September 2014 at 08:38:49 UTC, bearophile wrote:

 Perhaps this new situation (no implicit conversions, plus two 
 kinds of casts, and few extra literals) is safer than the 
 current D situation (and I think no C code gains a new working 
 meaning in this new situation).


He want go-semantics. It also means that literals are untyped 
until bound, so you can do high precision calculations at compile 
time.

I would also like to see these explicit conversions (and find 
hacks like "alias this" somewhat annoying).

I also think arithmetics on ubytes should be done as ubytes etc 
to allow SIMD vectorization.

Go semantics is described well here:

http://blog.golang.org/constants
Sep 20 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Saturday, 20 September 2014 at 08:46:34 UTC, Ola Fosheim 
Grostad wrote:

 I also think arithmetics on ubytes should be done as ubytes etc 
 to allow SIMD vectorization.


Array operations do use SIMD. The code for this is in druntime.

https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d
Sep 20 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Brian Schott:


 Array operations do use SIMD.


Array ops aren't used often in most normal D code. Most usages of 
SIMD should come from auto-vectorization and core.simd (but 
perhaps core.simd design was not discussed and improved enough, 
and the implicit upcasting semantics of C could hurt 
auto-vectorization).

Bye,
bearophile
Sep 20 2014
parent "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Saturday, 20 September 2014 at 09:09:56 UTC, bearophile wrote:

 Brian Schott:


 Array operations do use SIMD.


 Array ops aren't used often in most normal D code. Most usages 
 of SIMD should come from auto-vectorization and core.simd (but 
 perhaps core.simd design was not discussed and improved enough, 
 and the implicit upcasting semantics of C could hurt 
 auto-vectorization).


Yes, I was thinking of auto vectorization/masking. Handcrafted 
simd is nice too, but I feel it is better done in a way the 
backend can understand. You might also want the compiler to 
generate fallback paths for older cpus...
Sep 20 2014
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 9/19/14, 9:52 PM, bearophile wrote:

 but currently Rust
 seems to ignore several kinds of correctness, focusing only on two
 kinds


Could you tell which are those two kinds and which other correctness are 
ignored? Just to learn more about Rust. Thanks!
Sep 20 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:


 Could you tell which are those two kinds and which other 
 correctness are ignored? Just to learn more about Rust. Thanks!


Rust does everything to be memory safe, and avoid data races 
outside its unsafe code zones. But in the real world there are 
many other sources of bugs that can wreak a program. Ada (and in 
a less intense way D) try to help the programmer write correct 
code for some of them too (and other languages are ATS, Whiley, 
F*, Idris, etc, cover other forms of correctness).

Bye,
bearophile
Sep 21 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 21.09.2014 11:30, schrieb bearophile:

 Ary Borenszweig:


 Could you tell which are those two kinds and which other correctness
 are ignored? Just to learn more about Rust. Thanks!


 Rust does everything to be memory safe, and avoid data races outside its
 unsafe code zones. But in the real world there are many other sources of
 bugs that can wreak a program. Ada (and in a less intense way D) try to
 help the programmer write correct code for some of them too (and other
 languages are ATS, Whiley, F*, Idris, etc, cover other forms of
 correctness).

 Bye,
 bearophile




Not as clean, but workable.

--
Paulo
Sep 21 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:


 (and other
 languages are ATS, Whiley, F*, Idris, etc, cover other forms of
 correctness).
...


 You can handle units of measure via tuples structs, since you 




http://research.microsoft.com/en-us/projects/fstar/

Bye,
bearophile
Sep 21 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 21.09.2014 12:47, schrieb bearophile:

 Paulo Pinto:


 (and other
 languages are ATS, Whiley, F*, Idris, etc, cover other forms of
 correctness).
 ...






 http://research.microsoft.com/en-us/projects/fstar/

 Bye,
 bearophile


Sorry, should have taken more coffee.
Sep 21 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2014 4:01 AM, Paulo Pinto wrote:

 Sorry, should have taken more coffee.


My excuse is I haven't had my beer yet.
Sep 24 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/19/2014 5:52 PM, bearophile wrote:

 The "!" means the memory of this array is owned by the Mesh stuct. So when the
 Mesh instantiation goes out of scope, all the memory it owns gets deallocated.


This stood out for me. Deallocated how? People who write high perf software
tend 
to have multiple allocators for different purposes.

I don't think this feature will work.
Sep 24 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 25/09/14 06:18, Walter Bright wrote:


 This stood out for me. Deallocated how? People who write high perf
 software tend to have multiple allocators for different purposes.

 I don't think this feature will work.


He says it's part of the same memory as the enclosing struct. I guess 
they would need to use the same allocator.

-- 
/Jacob Carlborg
Sep 24 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 This stood out for me. Deallocated how?


Calling free when the struct instance goes out of scope, I 
presume.



 People who write high perf software tend to have multiple
 allocators for different purposes.


I think that data is used all together, so it's reasonable to 
allocate it from a single allocator.



 I don't think this feature will work.


I think he's already using this strategy in production code. So I 
think it works. He's just asking for a language feature that 
implements this idiom for him in a shorter and cleaner way.

Bye,
bearophile
Sep 25 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 1:47 AM, bearophile wrote:

 This stood out for me. Deallocated how?


 Calling free when the struct instance goes out of scope, I presume.



 People who write high perf software tend to have multiple
 allocators for different purposes.


 I think that data is used all together, so it's reasonable to allocate it from
a
 single allocator.



 I don't think this feature will work.


 I think he's already using this strategy in production code. So I think it
 works. He's just asking for a language feature that implements this idiom for
 him in a shorter and cleaner way.


So how do you tell it to call myfree(p) instead of free(p) ?
Sep 25 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 So how do you tell it to call myfree(p) instead of free(p) ?


I think you can't in the form he has shown. He's far from being a 
good language designer, after all :-)

Bye,
bearophile
Sep 25 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 2:32 AM, bearophile wrote:

 Walter Bright:


 So how do you tell it to call myfree(p) instead of free(p) ?


 I think you can't in the form he has shown. He's far from being a good language
 designer, after all :-)


It's not as easy as it looks :-)
Sep 25 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright 
wrote:

 So how do you tell it to call myfree(p) instead of free(p) ?


Maybe stock malloc/free is enough for him?
Sep 25 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 4:33 AM, Kagamin wrote:

 On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright wrote:

 So how do you tell it to call myfree(p) instead of free(p) ?


 Maybe stock malloc/free is enough for him?


That kind of commitment shouldn't be baked into the language. That's why 
RAII and scope are better than his notation. -- Andrei
Sep 25 2014
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei 
Alexandrescu wrote:

 On 9/25/14, 4:33 AM, Kagamin wrote:

 On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright 
 wrote:

 So how do you tell it to call myfree(p) instead of free(p) ?


 Maybe stock malloc/free is enough for him?


 That kind of commitment shouldn't be baked into the language. 
 That's why RAII and scope are better than his notation.


Allocation is orthogonal to RAII and scope. Allocation creates 
resource, RAII tracks it.
Sep 25 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 8:12 AM, Kagamin wrote:

 On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei Alexandrescu wrote:

 On 9/25/14, 4:33 AM, Kagamin wrote:

 On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright wrote:

 So how do you tell it to call myfree(p) instead of free(p) ?


 Maybe stock malloc/free is enough for him?


 That kind of commitment shouldn't be baked into the language. That's
 why RAII and scope are better than his notation.


 Allocation is orthogonal to RAII and scope. Allocation creates resource,
 RAII tracks it.


Affirmative. -- Andrei
Sep 25 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 25 September 2014 at 15:34:31 UTC, Andrei
Alexandrescu wrote:

 On 9/25/14, 8:12 AM, Kagamin wrote:

 On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei 
 Alexandrescu wrote:

 On 9/25/14, 4:33 AM, Kagamin wrote:

 On Thursday, 25 September 2014 at 09:16:27 UTC, Walter 
 Bright wrote:

 So how do you tell it to call myfree(p) instead of free(p) ?


 Maybe stock malloc/free is enough for him?


 That kind of commitment shouldn't be baked into the language. 
 That's
 why RAII and scope are better than his notation.


 Allocation is orthogonal to RAII and scope. Allocation creates 
 resource,
 RAII tracks it.


 Affirmative. -- Andrei


And in many cases scope statements are simpler, better, harder,
stronger !
Sep 25 2014
prev sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei 
Alexandrescu wrote:

 On 9/25/14, 4:33 AM, Kagamin wrote:

 On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright 
 wrote:

 So how do you tell it to call myfree(p) instead of free(p) ?


 Maybe stock malloc/free is enough for him?


 That kind of commitment shouldn't be baked into the language. 
 That's why RAII and scope are better than his notation. -- 
 Andrei


Only if you accept "The Right Way" philosophy. A "Worse is 
Better" person may disagree. There is no "better", it's all 
tradeoffs.
Sep 25 2014
parent "Kagamin" <spam here.lot> writes:
On Thursday, 25 September 2014 at 18:38:36 UTC, Peter Alexander 
wrote:

 Only if you accept "The Right Way" philosophy. A "Worse is 
 Better" person may disagree. There is no "better", it's all 
 tradeoffs.


D already has a single allocation strategy built into the 
language: the `new` operator.
Sep 26 2014
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 19 September 2014 at 23:47:06 UTC, Max Klyga wrote:

 Jonathan Blow just recorded a talk about the needs and ideas 
 for a programming language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were 
 possible for frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design from 
 game developer perspective.


I haven't finished the talk yet, but already this is kind of 
upsetting. The claim that he want to create a programming 
language, but is unable to give concrete examples of any case he 
makes so far, grossly misrepresent what exists in other languages 
or flat out declare that he doesn't know.

If you are going down the road of creating a new programming 
language, you'd better be sure to know what exists fairly well 
and what shortcomings you are trying to overcome.

That would be true of anything, really, not simply programming 
language. The fact that, without deep knowledge of what is done 
in languages outside C++, he can assert of the difficulty of 
writing a compiler  the classroom example of Dunning Kruger.

It literally like me saying telling to general motor engineer 
hey, building a really good car is easy, You screw 4 wheels to a 
metal cage and done!

I'd concede that he is probably right on the fact that writing a 
front end is certainly easier that a game engine (ie I mean high 
end game engine with realistic physic, high quality rendering and 
all the goodies). But it is pretty clear from his talk so far 
that he grossly underestimate the difficulty to:
1/ Get language design right. It is a mix of technical constraint 
for the coder, the compiler, and plateform/runtime constraints, 
the whole thing being made extra hard as success depends on 
various social dynamics amongst developers.
2/ Getting compiler right. Parsing and dumping C like code into 
LLVM is one thing. Getting the whole thing to support various 
advanced features, meaningful errors messages, making it fast, 
making it resilient enough to wrong code so it can be useful for 
tooling, generating good quality IR, getting a good quality 
runtime that work on various platforms and implementing languages 
specific optimization is much harder.
Sep 19 2014
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
OK so I'm 1h in now. The guy is explaining slices in a languages 
that look like C or C++. But discarded D at the beginning because 
it is too close to C/C++.

Also I love how he keeps mentioning that adding debug support is 
easy.

His ! stuff looks interesting, but I guess this is already being 
discussed in D with uniqueness.

I also love the passage where he mention that you have strings 
everywhere, and you duplicate them and so on, and that you can a 
system to unique them and manage memory, but that would be crazy 
complicated. The obvious question that come to mind: what does he 
think a compiler does ?

OK now using pointer and value type via dot.

1h20 he is on nullable vs non nullable. According to him this is 
not an issue, but stats say otherwise. Still want to look into 
it. Not sure what is his point on that one.

He then goes on concurrency and make some very good points here 
but he doesn't look like he has anything to propose :(

1h25 annotate, serialize, introspect.

1h25 good point about build. All build system I've used so far 
sucks. But no solution.

At the end, I kind of agree on the problems, but the solution he 
mention already exists, and when they do not (or I think they do 
not) he don't have anything to propose.

1h30 now he is talking about CTFE and code generation...

What I take out of this, is that something like unique/isolated 
or whatever is key, and the memory mapping optimization is nice 
but probably realizable in D using code generation. But creating 
a new language instead of participating in existing ones seem 
very misguided and he does seems to realize how hard it is to 
create a language.
Sep 19 2014
prev sibling parent "Piotrek" <none nowhere.pl> writes:
On Saturday, 20 September 2014 at 04:28:58 UTC, deadalnix wrote:

 On Friday, 19 September 2014 at 23:47:06 UTC, Max Klyga wrote:

 Jonathan Blow just recorded a talk about the needs and ideas 
 for a programming language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were 
 possible for frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design 
 from game developer perspective.


 I haven't finished the talk yet, but already this is kind of 
 upsetting. The claim that he want to create a programming 
 language, but is unable to give concrete examples of any case 
 he makes so far, grossly misrepresent what exists in other 
 languages or flat out declare that he doesn't know.


I got similar feeling. If he joined D, there would be more value
than starting all from the ground.

I think D fits well his requirements. He admits it between the
lines when defines D as better C++, but not worth switching
because of not enough gain.

IMHO, D has the best cumulative score across all languages in
main 3 categories (despite tooling):

1. Kernel type (mostly no memory allocations) - the winner here
2. Game type (mostly manual memory management) - the winner here
3. Applications/Scripts (mostly automatic memory management))-
the winner in large scale apps. In terms of small ones, for most
people D places somewhere in 2nd place group because of static
typing (but honestly I prefer writing scripts in statically typed
languages)

After years of codding I think the following topics (pointed in
video) will never be solved entirely in any language
1. Resource handling
2. Error handing

As for the biggest D rival - Rust, despite all syntax choices I
don't accept, here is at least one thing that prevents Rust to be
ready for ver 1.0 in the end of year:

http://doc.rust-lang.org/guide-pointers.html#gc

Gc<T>

"In the future, Rust may have a real garbage collected type, and
so it has not yet been removed for that reason."

In my opinion, as a usual coder, memory model in Rust is not well
defined for now.

Piotrek
Sep 21 2014
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 20.09.2014 01:47, schrieb Max Klyga:

 Jonathan Blow just recorded a talk about the needs and ideas for a
 programming language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were possible
 for frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design from game
 developer perspective.


Many of his wishes have been answered in Algol68(1973), Modula-2(1978), 
Cedar(1983), Ada(1983), Turbo Pascal 6.0 (1990), but the industry at 
large decided to go elsewhere instead.

Which in the end boils down to this:

"Although the first edition of K&R described most of the rules that 
brought C's type structure to its present form, many programs written in 
the older, more relaxed style persisted, and so did compilers that 
tolerated it. To encourage people to pay more attention to the official 
language rules, to detect legal but suspicious constructions, and to 
help find interface mismatches undetectable with simple mechanisms for 
separate compilation, Steve Johnson adapted his pcc compiler to produce 
lint [Johnson 79b], which scanned a set of files and remarked on dubious 
constructions. " -- Dennis Ritche on history of C.

Already in 1979 it was clear that C without syntax analysis tooling 
wasn't a good idea.

This of course, also had an impact in C++ and Objective-C.

--
Paulo
Sep 20 2014
parent "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Saturday, 20 September 2014 at 11:11:23 UTC, Paulo Pinto wrote:

 Many of his wishes have been answered in Algol68(1973), 
 Modula-2(1978), Cedar(1983), Ada(1983), Turbo Pascal 6.0 
 (1990), but the industry at large decided to go elsewhere 
 instead.


I didn't get that impression. Seems like he wants to cover 
existing practices in a more time saving package, then add some 
neat stuff:

- automatic region allocator per object
- ctfe including executing external programs
- uda + static reflection
- debugging tools for freeing shared memory (without rc/tracing)
- go style literals + type system?
- swift style nullable

Seems he wants a streamlined nogc/nothrow version of D with a 
dedicated syntax for his field. D could probably be modified to 
fit pretty well.
Sep 20 2014
prev sibling next sibling parent "JN" <666total wp.pl> writes:
On Friday, 19 September 2014 at 23:47:06 UTC, Max Klyga wrote:

 Jonathan Blow just recorded a talk about the needs and ideas 
 for a programming language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were 
 possible for frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design from 
 game developer perspective.


Interesting to see him not worship RAII and even bash it a bit. 
Most game developers sticking with C++ and evaluating other 
languages swear by RAII and reject every GC-language for the lack 
of it.
Sep 21 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/19/2014 4:47 PM, Max Klyga wrote:

 Jonathan Blow just recorded a talk about the needs and ideas for a programming
 language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were possible for
 frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design from game developer
 perspective.



Looks like he reinvented D dynamic arrays at 1:02. Sigh.
Sep 25 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 2:27 AM, Walter Bright wrote:

 Looks like he reinvented D dynamic arrays at 1:02. Sigh.


At 1:16 he gives credit to Go for the -> and . becomes . thing. Says its great.

And he wants:

* D array declaration syntax.

* consistently sized integer types

* user defined attributes.

* multiple files compiled at once.

* permissive license.

* nested comments

* no preprocessor

* insert files into the source code (mixins)

* compile time function execution

And ...

     ... he's specified D!
Sep 25 2014
next sibling parent reply "currysoup" <sam92cutler hotmail.co.uk> writes:
Would just like to remind you all that he's trying to foster 
conversation rather than declare "this is the most perfect 
language ever". A lot of his ideas don't hold water in their 
current form but I'm sure D wasn't designed in a 2 hour live 
stream :). I'm personally really excited at the prospect of some 
momentum in a language designed specifically for games engineers.

D is really great and solves a lot of the issues raised in the 
video. A lot of D's features (GC in particular) become ugliness 
you've got to avoid. In addition all the  nogc, nothrow, pure, 
etc. becomes crufty.

I quite like the idea of "simple by default" and you enable 
features with annotations ( usegc,  throws,  pure).
Sep 25 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 25 Sep 2014 10:46:59 +0000
currysoup via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I quite like the idea of "simple by default" and you enable=20
 features with annotations ( usegc,  throws,  pure).


" usegc" will be major PITA. for example any function that does string
concatenation or format() will need this annotation. i see GC as
intergal and widely-used part of language, so " nogc" is ok.

what we need though is " gc" to allow things like this:

   nogc:
    void foo () { ... some no-gc code ... }
    void bar ()  gc { ... some gc code ... }

to be able to mark the whole part of the code as  nogc but still allow
to write one or two  gc functions by the way.

ah, and the same for 'final'.

sure one can just move necessary definitions to top of the file (i.e.
they will appear before " nogc:"), but this will hurt code readability.
Sep 25 2014
parent reply "currysoup" <sam92cutler hotmail.co.uk> writes:
On Thursday, 25 September 2014 at 11:30:16 UTC, ketmar via 
Digitalmars-d wrote:

 On Thu, 25 Sep 2014 10:46:59 +0000
 currysoup via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I quite like the idea of "simple by default" and you enable 
 features with annotations ( usegc,  throws,  pure).


 " usegc" will be major PITA. for example any function that does 
 string
 concatenation or format() will need this annotation. i see GC as
 intergal and widely-used part of language, so " nogc" is ok.

 what we need though is " gc" to allow things like this:

    nogc:
     void foo () { ... some no-gc code ... }
     void bar ()  gc { ... some gc code ... }

 to be able to mark the whole part of the code as  nogc but 
 still allow
 to write one or two  gc functions by the way.

 ah, and the same for 'final'.

 sure one can just move necessary definitions to top of the file 
 (i.e.
 they will appear before " nogc:"), but this will hurt code 
 readability.


I wasn't talking about D, just in general.
Sep 25 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 25 Sep 2014 12:16:16 +0000
currysoup via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I wasn't talking about D, just in general.


sorry, it's my frustration speaks. ;-)
Sep 25 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 25 September 2014 at 10:47:00 UTC, currysoup wrote:

 D is really great and solves a lot of the issues raised in the 
 video. A lot of D's features (GC in particular) become ugliness 
 you've got to avoid. In addition all the  nogc, nothrow, pure, 
 etc. becomes crufty.


I'd say nothrow and pure are of marginal utility.  nogc can be 
just

   nogc:

at the top of a module. And the last piece is libraries.
Sep 25 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 3:46 AM, currysoup wrote:

 I quite like the idea of "simple by default" and you enable features with
 annotations ( usegc,  throws,  pure).


I think simple by default doesn't have those annotations - by default meaning 
"the code works". Those annotations all work to restrict what the code can do.
Sep 25 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 3:46 AM, currysoup wrote:

 Would just like to remind you all that he's trying to foster conversation
rather
 than declare "this is the most perfect language ever". A lot of his ideas don't
 hold water in their current form but I'm sure D wasn't designed in a 2 hour
live
 stream :). I'm personally really excited at the prospect of some momentum in a
 language designed specifically for games engineers.


It is great to have a conversation. It's good to revisit assumptions about what 
a good language should be. Although I don't agree with him, I thought that it 
was great that he questioned the value of RAII.

But I think it's a waste of time to develop a new language that has 98% overlap 
with existing ones, like if I proposed a language just like C but with member 
functions.
Sep 25 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 25/09/14 21:59, Walter Bright wrote:


 But I think it's a waste of time to develop a new language that has 98%
 overlap with existing ones, like if I proposed a language just like C
 but with member functions.


It seems that people won't switch language, or rather create a new 
language, even though an existing would fit them, just because the 
existing one lacks one feature. It's like "Yeah, D is great it has 9 of 
the features I need, but it lacks the 10th. Therefore I can't switch, 
even though the language I use now doesn't have any of these 10 features."

-- 
/Jacob Carlborg
Sep 25 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 11:34 PM, Jacob Carlborg wrote:

 On 25/09/14 21:59, Walter Bright wrote:


 But I think it's a waste of time to develop a new language that has 98%
 overlap with existing ones, like if I proposed a language just like C
 but with member functions.


 It seems that people won't switch language, or rather create a new language,
 even though an existing would fit them, just because the existing one lacks one
 feature. It's like "Yeah, D is great it has 9 of the features I need, but it
 lacks the 10th. Therefore I can't switch, even though the language I use now
 doesn't have any of these 10 features."



People get comfortable with the language they use, and switching languages
takes 
work. But they don't want to say that, so they look for something to use as an 
excuse.

It's perfectly human, and I'm guilty of it too :-)
Sep 26 2014
prev sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 25 September 2014 at 09:58:31 UTC, Walter Bright 
wrote:

 On 9/25/2014 2:27 AM, Walter Bright wrote:

 Looks like he reinvented D dynamic arrays at 1:02. Sigh.


 At 1:16 he gives credit to Go for the -> and . becomes . thing. 
 Says its great.

 And he wants:

 <snip>

 And ...

     ... he's specified D!


Almost, but he also wants a language with the "Worse is Better" 
philosophy.

D does not have this, and I don't think we want it.
Sep 25 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 25 September 2014 at 09:27:16 UTC, Walter Bright
wrote:

 On 9/19/2014 4:47 PM, Max Klyga wrote:

 Jonathan Blow just recorded a talk about the needs and ideas 
 for a programming
 language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were 
 possible for
 frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design 
 from game developer
 perspective.



 Looks like he reinvented D dynamic arrays at 1:02. Sigh.


Yes the only thing that seems to be an issue between him and D is
the lack of ownership (his ! concept).
Sep 25 2014
prev sibling next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Friday, 19 September 2014 at 23:47:06 UTC, Max Klyga wrote:

 Jonathan Blow just recorded a talk about the needs and ideas 
 for a programming language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were 
 possible for frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design from 
 game developer perspective.


The sequel:


https://www.youtube.com/watch?v=5Nc68IdNKdg
Sep 27 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/27/2014 9:35 AM, ponce wrote:

 The sequel:


 https://www.youtube.com/watch?v=5Nc68IdNKdg


Yeah, I watched it. He advocates:

* pure functions

* local functions

* local functions with the same syntax as global functions

* safety which defaults to off

All of which D does right now.

The only interesting thing is he describes a way that functions (and blocks)
can 
specify what global data they access, and then have the compiler issue errors 
for accessing any other global data. He has a way to do that both locally and 
transitively.

However, the same effect can be achieved via pure annotations and passing the 
globals needed by reference as function parameters.

Based on his talks about what he wants in a language, I infer he's not looked
at 
D beyond "D has a GC, can't use it".

--------------------------------------

Another thing I found interesting is I had assumed he'd given these talks at a 
conference. Not so. He simply set up a webcam in his office. It's a great
method 
- we should look into doing that.
Sep 27 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Sep 27, 2014 at 02:51:14PM -0700, Walter Bright via Digitalmars-d wrote:
[...]

 The only interesting thing is he describes a way that functions (and
 blocks) can specify what global data they access, and then have the
 compiler issue errors for accessing any other global data. He has a
 way to do that both locally and transitively.


That sounds like PHP. *shudder*



 However, the same effect can be achieved via pure annotations and
 passing the globals needed by reference as function parameters.


[...]

I'm a fan of grouping related globals into structs with module level
instances, and passed by reference to functions that need those specific
globals. Truly-global globals are nasty, as are open sets of globals
where you either don't access a global, or you (potentially) access
*all* globals with no finer access granularity. (I had to debug C code
that did that once... boy it was mind-bending when every function call
could potentially arbitrarily change the global state.)


T

-- 
Computers are like a jungle: they have monitor lizards, rams, mice, c-moss,
binary trees... and bugs.
Sep 27 2014
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 27 September 2014 at 22:06:00 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Sat, Sep 27, 2014 at 02:51:14PM -0700, Walter Bright via 
 Digitalmars-d wrote:
 [...]

 The only interesting thing is he describes a way that 
 functions (and
 blocks) can specify what global data they access, and then 
 have the
 compiler issue errors for accessing any other global data. He 
 has a
 way to do that both locally and transitively.


 That sounds like PHP. *shudder*



 However, the same effect can be achieved via pure annotations 
 and
 passing the globals needed by reference as function parameters.


 [...]

 I'm a fan of grouping related globals into structs with module 
 level
 instances, and passed by reference to functions that need those 
 specific
 globals. Truly-global globals are nasty, as are open sets of 
 globals
 where you either don't access a global, or you (potentially) 
 access
 *all* globals with no finer access granularity. (I had to debug 
 C code
 that did that once... boy it was mind-bending when every 
 function call
 could potentially arbitrarily change the global state.)


 T


A fair amount of HPC code is still written in Fortran with a 
variables.f90 file that holds most program state as globals. Ick.
Sep 28 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 * local functions with the same syntax as global functions

 * safety which defaults to off

 All of which D does right now.


It could be nice to have a syntax like lambdas for small 
struct/class methods:
https://issues.dlang.org/show_bug.cgi?id=7176

struct Foo {
     int bar(int x) pure { return x * x; }
}

Becomes something like::

struct Foo {
     int bar = (int x) pure => x * x;
}


syntax).



 The only interesting thing is he describes a way that functions 
 (and blocks) can specify what global data they access, and then 
 have the compiler issue errors for accessing any other global 
 data. He has a way to do that both locally and transitively.


Unwanted access of global variables is a common source of 
troubles in my code. Time ago I suggested an optional  outer() 
function annotation:
https://d.puremagic.com/issues/show_bug.cgi?id=5007

Bye,
bearophile
Sep 27 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/27/2014 3:30 PM, bearophile wrote:

 Walter Bright:


 * local functions with the same syntax as global functions

 * safety which defaults to off

 All of which D does right now.


 It could be nice to have a syntax like lambdas for small struct/class methods:
 https://issues.dlang.org/show_bug.cgi?id=7176

 struct Foo {
      int bar(int x) pure { return x * x; }
 }

 Becomes something like::

 struct Foo {
      int bar = (int x) pure => x * x;
 }


I see no gain from that syntax.



 Unwanted access of global variables is a common source of troubles in my code.
 Time ago I suggested an optional  outer() function annotation:
 https://d.puremagic.com/issues/show_bug.cgi?id=5007


I suggest using 'pure' and passing the globals you actually need as ref
parameters.
Sep 27 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 It could be nice to have a syntax like lambdas for small 
 struct/class methods:
 https://issues.dlang.org/show_bug.cgi?id=7176

 struct Foo {
     int bar(int x) pure { return x * x; }
 }

 Becomes something like::

 struct Foo {
     int bar = (int x) pure => x * x;
 }


 I see no gain from that syntax.


Issue 7176 has currently seven votes, so someone seems to like it.

Now some D code is written in a functional style, this means many 
function bodies are very small, and sometimes they contain just a 
UFCS chain.
Usually editors (and Phobos style guides) format that bar 
function like:

int bar(int x) pure
{
     return x * x;
}

So now you have 4 lines instead of 1 line of the lambda-like 
syntax. Generally the presence of a  "return" is regarded as a 
"code smell" in functional-style code.



 I suggest using 'pure' and passing the globals you actually 
 need as ref parameters.


This is what I usually do in D, but it has some small 
disadvantages:
- It increases the number of function arguments (they are 8 bytes 
each), increasing the size of the function, adding some stack 
management instructions. This slows the function a little, if the 
function is performance-critical.
- Sometimes you can't use "pure", for various reasons, like 
Phobos functions not yet pure, I/O action in your function, or 
other causes.
- If your pure function foo receives two global argument as out 
and ref, the function bar that calls it needs to access to global 
variables or it too needs those two ref/out arguments. The 
current design of  outer() is not transitive, so only foo needs 
to state what global variables are in/out/inout.
-  outer is more DRY, because you don't need to specify the type 
of the global variable received by ref, you just need to know its 
name.
- With  outer you can tighten some old code, without changing the 
signature of a function. If you have an old D module (or a C 
function converted to C) you often can't (or you don't want) to 
change the function signature to add the global arguments passed 
by ref. With  outer() the function signature doesn't change, so 
you can improve your legacy code. It allows a simpler refactoring 
of code.

More notes:
- SPARK language has added a feature similar to  outer, but more 
verbose. See comment 5 in issue 5007.
-  outer() is optional and it's fiddly because not it's not meant 
for small D script-like programs, it's meant as a help for 
medium-integrity D programs (where you may think about using Ada 
language instead).

Bye,
bearophile
Sep 27 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/27/2014 4:20 PM, bearophile wrote:

 Walter Bright:


 It could be nice to have a syntax like lambdas for small struct/class methods:
 https://issues.dlang.org/show_bug.cgi?id=7176

 struct Foo {
     int bar(int x) pure { return x * x; }
 }

 Becomes something like::

 struct Foo {
     int bar = (int x) pure => x * x;
 }


 I see no gain from that syntax.


 Issue 7176 has currently seven votes, so someone seems to like it.


A feature without a solid rationale is no good in spite of how many votes it
has.



 Now some D code is written in a functional style, this means many function
 bodies are very small, and sometimes they contain just a UFCS chain.
 Usually editors (and Phobos style guides) format that bar function like:

 int bar(int x) pure
 {
      return x * x;
 }

 So now you have 4 lines instead of 1 line of the lambda-like syntax. Generally
 the presence of a  "return" is regarded as a "code smell" in functional-style
code.


D has a nice inline lamda syntax, which was needed. It is not needed for 
separate functions.



 I suggest using 'pure' and passing the globals you actually need as ref
 parameters.


 This is what I usually do in D, but it has some small disadvantages:
 - It increases the number of function arguments (they are 8 bytes each),
 increasing the size of the function, adding some stack management instructions.
 This slows the function a little, if the function is performance-critical.


If the function is small enough that parameter setup time is significant, it is 
likely to be inlined anyway which will erase the penalty.

Such arguments can also be passed as template alias parameters, which are zero
cost.


 - Sometimes you can't use "pure", for various reasons, like Phobos functions
not
 yet pure, I/O action in your function, or other causes.


Then you really aren't encapsulating the globals the function uses, anyway, and 
the feature is useless.



 - If your pure function foo receives two global argument as out and ref, the
 function bar that calls it needs to access to global variables or it too needs
 those two ref/out arguments. The current design of  outer() is not transitive,
 so only foo needs to state what global variables are in/out/inout.


Being global variables, they are accessible from everywhere :-) which is why 
they're an encapsulation problem in the first place.



 -  outer is more DRY, because you don't need to specify the type of the global
 variable received by ref, you just need to know its name.


That's why gawd invented templates.



 - With  outer you can tighten some old code, without changing the signature of
a
 function. If you have an old D module (or a C function converted to C) you
often
 can't (or you don't want) to change the function signature to add the global
 arguments passed by ref. With  outer() the function signature doesn't change,
so
 you can improve your legacy code. It allows a simpler refactoring of code.


You can always wrap it with a template and pass the global by alias.



 More notes:
 - SPARK language has added a feature similar to  outer, but more verbose. See
 comment 5 in issue 5007.
 -  outer() is optional and it's fiddly because not it's not meant for small D
 script-like programs, it's meant as a help for medium-integrity D programs
 (where you may think about using Ada language instead).


Better encapsulation is intended for larger programs - I agree it is useless
for 
small ones.
Sep 27 2014
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/28/2014 01:55 AM, Walter Bright wrote:

 On 9/27/2014 4:20 PM, bearophile wrote:

 Walter Bright:


 It could be nice to have a syntax like lambdas for small
 struct/class methods:
 https://issues.dlang.org/show_bug.cgi?id=7176

 struct Foo {
     int bar(int x) pure { return x * x; }
 }

 Becomes something like::

 struct Foo {
     int bar(int x) pure => x * x; // fixed
 }


 I see no gain from that syntax.


 Issue 7176 has currently seven votes, so someone seems to like it.


 A feature without a solid rationale  is no good in spite of how many
 votes it has.


Uniform syntax for parameter list followed by function body.

              (int x){ return 2; }
      function(int x){ return 2; }
auto separate(int x){ return 2; }
              (int x) => 2;
      function(int x) => 2;
auto separate(int x) => 2;

auto curriedAdd(int x) => (int y) => x + y;

It is a simplification that is also convenient.
Sep 27 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 A feature without a solid rationale is no good in spite of how 
 many votes it has.


I agree that the number of votes alone means very little. But 
perhaps those persons have reasons.
(If votes from people are not important, then better to remove 
this feature from Bugzilla.)



 D has a nice inline lamda syntax, which was needed. It is not 
 needed for separate functions.


The lambda syntax for function/class methods is not needed, but 
it's handy and it's sufficiently natural, expecially for many 
little methods. It's not an important feature, and there are D 
features that I need far more than this (like syntax to unpack 

with that, search for "Expression-bodied members" here:

http://www.dotnetcurry.com/showarticle.aspx?ID=1042



class Rectangle(int width, int height)
{
     public int Area => width * height;
}



 If the function is small enough that parameter setup time is 
 significant, it is likely to be inlined anyway which will erase 
 the penalty.


This is the theory :-) Sometimes I have seen this not to be true.



 Then you really aren't encapsulating the globals the function 
 uses, anyway, and the feature is useless.


The point of having an  outer() is to enforce what module-level 
names a function is using and how it is using them 
(in/out/inout), so it's useful for _impure_ functions. If your 
functions can be annotated with "pure" you don't need  outer much.



 Being global variables, they are accessible from everywhere :-) 
 which is why they're an encapsulation problem in the first 
 place.


In D we have modules, so variables are module-level, or they are 
imported from other modules (unfortunately names in a module are 
public on default when you import the module. I'd like the 
opposite, to be private to the module, and importable only if 
they are tagged with "public").
The problem with module-level variables is that sometimes I am 
using by mistake a global variable when I am instead trying to 
use a local one. Or on the opposite I am using a local variable 
by mistake when I'd like to use a module-level one. An attribute 
like "pure" disallows the access to global mutables, so it solves 
only half of the problem. Generally knowing exactly what 
module-level variables (and how) a function is using is very 
handy to understand the purpose and working of the function 
itself. So I see  outer() as a tool for code understanding, even 
legacy code because I can add  outer() to old code written by 
other persons.



 -  outer is more DRY, because you don't need to specify the 
 type of the global
 variable received by ref, you just need to know its name.


 That's why gawd invented templates.


Templates are a blunt tool to solve the problems faced by 
 outer().  outer() allows you to specify for each variable if 
it's going to just be read, written, or read-written. And 
 outer() is not named  globals() because it works for inner 
functions too, it allows to control and specify the access of 
names from the outer scopes, so an inner impure nonstatic 
function can use  outer() to specify what names it can use from 
the scope of the outer function:

void foo() {
   int x;
    outer(in x) void bar() {
     writeln(x);
   }
   bar();
}



 You can always wrap it with a template and pass the global by 
 alias.


I think I've never done this. To be tried.

Bye,
bearophile
Sep 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2014 2:16 AM, bearophile wrote:

 Walter Bright:

 If the function is small enough that parameter setup time is significant, it
 is likely to be inlined anyway which will erase the penalty.


 This is the theory :-) Sometimes I have seen this not to be true.


Inlining is not a random thing. If there's a case that doesn't inline, ask
about it.



 Then you really aren't encapsulating the globals the function uses, anyway,
 and the feature is useless.


 The point of having an  outer() is to enforce what module-level names a
function
 is using and how it is using them (in/out/inout), so it's useful for _impure_
 functions. If your functions can be annotated with "pure" you don't need  outer
 much.


 outer implies purity with a list of exceptions.



 -  outer is more DRY, because you don't need to specify the type of the global
 variable received by ref, you just need to know its name.


 That's why gawd invented templates.


 Templates are a blunt tool to solve the problems faced by  outer().  outer()
 allows you to specify for each variable if it's going to just be read, written,
 or read-written.


Again, template functions do that rather nicely, and no type is required.



 And  outer() is not named  globals() because it works for inner
 functions too, it allows to control and specify the access of names from the
 outer scopes, so an inner impure nonstatic function can use  outer() to specify
 what names it can use from the scope of the outer function:

 void foo() {
    int x;
     outer(in x) void bar() {
      writeln(x);
    }
    bar();
 }


This I find to be a bit more lame, because the declarations used will be right 
there. But if you really wanted to do it,

  void foo() {
     int x;
     static void bar(int x) {
       writeln(x);
     }
     bar(x);
  }
Sep 28 2014
next sibling parent reply "po" <yes no.com> writes:
  His entire reason for not using C++ lambda, and wanting local 
functions instead, is faulty

His reason: I heard they can perform heap allocation.

Reality: No they do not perform heap allocation, that would only 
happen if you stuffed it into an std::function
Sep 28 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2014 10:57 AM, po wrote:

   His entire reason for not using C++ lambda, and wanting local functions
 instead, is faulty

 His reason: I heard they can perform heap allocation.

 Reality: No they do not perform heap allocation, that would only happen if you
 stuffed it into an std::function



D's will also do heap allocation, but only if you take the address of the local 
function.
Sep 28 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 Inlining is not a random thing. If there's a case that doesn't 
 inline, ask about it.


Even when you use annotations like "forced_inline" and the like 
you can't be certain the compiler is doing what you ask for. I 
have seen several critical template functions not inlined even by 
ldc2 (dmd is usually worse). And if your function is in a 
pre-compiled object where the source code is not available, 
inlining doesn't happen.



  outer implies purity with a list of exceptions.


Right, an empty " outer()" equals to the D "weakly pure". But if 
I put those exceptions then I am essentially stating that a 
function is not pure. So you usually don't put  outer() on pure 
functions.



 Again, template functions do that rather nicely, and no type is 
 required.


I think templates are blunt tools for this purpose. But I will 
try to use them for this purpose, to see how they fare. I think I 
have not seen people use templates for this purpose, so I think 
it's not very natural.



 void foo() {
   int x;
    outer(in x) void bar() {
     writeln(x);
   }
   bar();
 }


 This I find to be a bit more lame, because the declarations 
 used will be right there.


Yes, and a module-level variable can be defined the line before 
the function definition. Or it can be far from it (it can even be 
from an imported module). The same is true for the variables 
defined in the outer function. That's why I have named it  outer 
instead of  globals. Even a large function is usually smaller 
than a whole module (and modern coding practices suggest to avoid 
very large functions), so the variable definition should be 
closer (and in D it must be lexically before the definition of 
the inner function), so the problems with module-level variables 
is bigger, but it's similar.



 But if you really wanted to do it,

  void foo() {
     int x;
     static void bar(int x) {
       writeln(x);
     }
     bar(x);
  }


As you said, the same is possible with global variables, you can 
often pass them as arguments, by value or by reference. I agree 
that the case of using  outer() for inner functions is weaker.

Bye,
bearophile
Sep 28 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Sep 28, 2014 at 10:19:36AM -0700, Walter Bright via Digitalmars-d wrote:
[...]

 Inlining is not a random thing. If there's a case that doesn't inline,
 ask about it.


[...]

This is not directly related to this thread, but recently in a Phobos PR
we discovered the following case:

	// This function gets inlined:
	int func1(int a) {
		if (someCondition) {
			return value1;
		} else {
			return value2;
		}
	}

	// But this one doesn't:
	int func2(int a) {
		if (someCondition) {
			return value1;
		}
		return value2;
	}

IIRC Kenji said something about the first case being convertible to an
expression, but the second can't. It would be nice if inlining worked
for both cases, since semantically they are the same.


T

-- 
Famous last words: I *think* this will work...
Sep 28 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2014 1:25 PM, H. S. Teoh via Digitalmars-d wrote:

 This is not directly related to this thread, but recently in a Phobos PR
 we discovered the following case:

 	// This function gets inlined:
 	int func1(int a) {
 		if (someCondition) {
 			return value1;
 		} else {
 			return value2;
 		}
 	}

 	// But this one doesn't:
 	int func2(int a) {
 		if (someCondition) {
 			return value1;
 		}
 		return value2;
 	}

 IIRC Kenji said something about the first case being convertible to an
 expression, but the second can't. It would be nice if inlining worked
 for both cases, since semantically they are the same.


https://issues.dlang.org/show_bug.cgi?id=7625
Sep 28 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-09-28 00:56, Walter Bright wrote:


 I see no gain from that syntax.


It's very convenient especially when using range based programming.

-- 
/Jacob Carlborg
Sep 28 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Max Klyga:


 https://www.youtube.com/watch?v=TH9VCN6UkyQ


A third talk (from another person) about related matters:
https://www.youtube.com/watch?v=rX0ItVEVjHc

He doesn't use RTTI, exceptions, multiple inheritance, STL, 
templates, and lot of other C++ stuff. On the other hand he 
writes data-oriented code manually, the compiler and language 
give him only very limited help, and the code he writes looks 
twiddly and bug-prone. So why aren't they designing a language 
without most of the C++ stuff they don't use, but with features 
that help them write the data-oriented code they need?

Bye,
bearophile
Oct 01 2014
next sibling parent reply "po" <yes no.com> writes:
On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote:

 Max Klyga:


 https://www.youtube.com/watch?v=TH9VCN6UkyQ


 A third talk (from another person) about related matters:
 https://www.youtube.com/watch?v=rX0ItVEVjHc

 He doesn't use RTTI, exceptions, multiple inheritance, STL, 
 templates, and lot of other C++ stuff. On the other hand he 
 writes data-oriented code manually, the compiler and language 
 give him only very limited help, and the code he writes looks 
 twiddly and bug-prone. So why aren't they designing a language 
 without most of the C++ stuff they don't use, but with features 
 that help them write the data-oriented code they need?

 Bye,
 bearophile


  He (deliberately I'd guess)conflates cache friendly data 
structures and access patterns with his particular preference for 
a C style.

  It is a fallacy that he presents as fact.

  The key to these type of fast code isn't the C style, it is the 
contiguous data layout, and cache friendly access patterns, both 
of which are easily enough to perform in modern C++.
Oct 01 2014
next sibling parent reply "currysoup" <sam92cutler hotmail.co.uk> writes:
On Wednesday, 1 October 2014 at 15:17:33 UTC, po wrote:

 On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote:

 Max Klyga:


 https://www.youtube.com/watch?v=TH9VCN6UkyQ


 A third talk (from another person) about related matters:
 https://www.youtube.com/watch?v=rX0ItVEVjHc

 He doesn't use RTTI, exceptions, multiple inheritance, STL, 
 templates, and lot of other C++ stuff. On the other hand he 
 writes data-oriented code manually, the compiler and language 
 give him only very limited help, and the code he writes looks 
 twiddly and bug-prone. So why aren't they designing a language 
 without most of the C++ stuff they don't use, but with 
 features that help them write the data-oriented code they need?

 Bye,
 bearophile


  He (deliberately I'd guess)conflates cache friendly data 
 structures and access patterns with his particular preference 
 for a C style.

  It is a fallacy that he presents as fact.

  The key to these type of fast code isn't the C style, it is 
 the contiguous data layout, and cache friendly access patterns, 
 both of which are easily enough to perform in modern C++.


OOP style and AoS in general does cause cache unfriendly data 
access. You can separate out your hot and cold data but at that 
point you're not really programming in an OO style. He doesn't 
use RTTI, templates, exceptions, etc. for different reasons than 
cache friendliness.

At what point does he say it's difficult to code in a SoA style 
in C++? He clearly states he sees no advantage to C++ over C.
Oct 01 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
currysoup:


 At what point does he say it's difficult to code in a SoA style 
 in C++?


Perhaps a (part of) language more fit/helpful/nice for that 
purpose/use can be invented.

Bye,
bearophile
Oct 01 2014
parent "po" <yes no.com> writes:
 Perhaps a (part of) language more fit/helpful/nice for that 
 purpose/use can be invented.

 Bye,
 bearophile


  It isn't as hard as he pretends to write SoA code in C++. In 
fact it is possible to abstract the underlying data you are 
operating on, and replace it with vector type

Example resembling his butt ugly code: operates only on 1 float 
at a time
struct Vec2{
   float x,y;
};
void Add2(Vec2* points, int howMany){
   for(int i = 0;i<howMany;++i){
      points[i].x += 2.0f;
      points[i].x += 2.0f;
    }
}

How I would do it, uses AVX256:

template<class T>
struct Vec2{
   T x,y;
};
typedef Vec2<float8> vec2_8f;

//float8 is a wrapper around AVX256 8 wide float type that 
behaves exactly like a //normal float but is actually 8 floats.

void Add2(range<vec2_8f> points){
   for(auto& p:points){
     p += 2.0f;
   }
}

C++ can abstract away the fact that float8 is actually 
implemented using a bunch of AVX intrinsics. Using his approach 
he'd be manually writing intrinsics until the cows came home.
Oct 01 2014
prev sibling parent reply "po" <yes no.com> writes:
 OOP style and AoS in general does cause cache unfriendly data 
 access. You can separate out your hot and cold data but at that 
 point you're not really programming in an OO style. He doesn't 
 use RTTI, templates, exceptions, etc. for different reasons 
 than cache friendliness.


  Modern C++ != OO style.

I'd say modern C++ is more generic + functional than OO.

He seems to think C++ is about programming in some sort of Java 
design pattern inspired way.


 At what point does he say it's difficult to code in a SoA style 
 in C++? He clearly states he sees no advantage to C++ over C.


1. He references Design patterns during his tirade against C++, 
who the hell uses design patterns in C++ these days?
2. He uses Ogre, a 15 year old terrible mess of a rendering 
engine, written in a nasty Java style, as an example of why C++ 
is bad
Oct 01 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 01.10.2014 23:03, schrieb po:

 OOP style and AoS in general does cause cache unfriendly data access.
 You can separate out your hot and cold data but at that point you're
 not really programming in an OO style. He doesn't use RTTI, templates,
 exceptions, etc. for different reasons than cache friendliness.


   Modern C++ != OO style.

 I'd say modern C++ is more generic + functional than OO.

 He seems to think C++ is about programming in some sort of Java design
 pattern inspired way.


If he is stuck in the late 90's/early 2000's, yes.


 At what point does he say it's difficult to code in a SoA style in
 C++? He clearly states he sees no advantage to C++ over C.


 1. He references Design patterns during his tirade against C++, who the
 hell uses design patterns in C++ these days?


Those architects, specially the CORBA ones, are nowadays doing J2EE and 
WPF MVVM applications.

And the original design patterns were actually targeted at Smalltalk, 
with C++ on the side as the language was started to get popular in the 
industry.


 2. He uses Ogre, a 15 year old terrible mess of a rendering engine,
 written in a nasty Java style, as an example of why C++ is bad


I never liked Ogre. A strange mix of OO with too much low level C like 
stuff still.

At least when I looked at it a few years ago.

--
Paulo
Oct 01 2014
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 October 2014 07:03, po via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 OOP style and AoS in general does cause cache unfriendly data access. You
 can separate out your hot and cold data but at that point you're not really
 programming in an OO style. He doesn't use RTTI, templates, exceptions, etc.
 for different reasons than cache friendliness.



  Modern C++ != OO style.

 I'd say modern C++ is more generic + functional than OO.

 He seems to think C++ is about programming in some sort of Java design
 pattern inspired way.


That's what a post-grad often tends to do...
Oct 01 2014
prev sibling next sibling parent reply "currysoup" <sam92cutler hotmail.co.uk> writes:
I certainly believe C++ style and it's community promote the idea 
of zero overhead abstractions and the kind of OOP style which 
_does_ cause cache misses.
Oct 01 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 01.10.2014 17:40, schrieb currysoup:

 I certainly believe C++ style and it's community promote the idea of
 zero overhead abstractions and the kind of OOP style which _does_ cause
 cache misses.


C++ does not imply OOP.

And the zero overhead abstractions are a culture heritage from C as it 
was the only way to sell C++ to most C developers.


--
Paulo
Oct 01 2014
prev sibling parent reply "po" <yes no.com> writes:
On Wednesday, 1 October 2014 at 15:40:59 UTC, currysoup wrote:

 I certainly believe C++ style and it's community promote the 
 idea of zero overhead abstractions and the kind of OOP style 
 which _does_ cause cache misses.


  Take a look at the STL. See any OOP? Right cause there isn't any.
  Boost? Nope.

  C++ jumped off the OOP bandwagon some time ago.
Oct 01 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 01.10.2014 23:16, schrieb po:

 On Wednesday, 1 October 2014 at 15:40:59 UTC, currysoup wrote:

 I certainly believe C++ style and it's community promote the idea of
 zero overhead abstractions and the kind of OOP style which _does_
 cause cache misses.


   Take a look at the STL. See any OOP? Right cause there isn't any.
   Boost? Nope.


I see lots of it. How many examples do you want?


   C++ jumped off the OOP bandwagon some time ago.


That I agree.

We have learned to not abuse hierarchies and to take advantage of the 
multi-paradigm capabilities of the language.

--
Paulo
Oct 01 2014
parent reply "po" <yes no.com> writes:
  Take a look at the STL. See any OOP? Right cause there isn't 
 any.
  Boost? Nope.


 I see lots of it. How many examples do you want?


  Well Boost might have some, I haven't looked at every library.

  I don't know of any OOP in the STL, unless you mean the 1980's 
stuff like iostreams and the other shit most people avoid using, 
but I don't think this is considered part of the STL
Oct 01 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 01.10.2014 23:44, schrieb po:

  Take a look at the STL. See any OOP? Right cause there isn't any.
  Boost? Nope.


 I see lots of it. How many examples do you want?


   Well Boost might have some, I haven't looked at every library.

   I don't know of any OOP in the STL, unless you mean the 1980's stuff
 like iostreams and the other shit most people avoid using, but I don't
 think this is considered part of the STL


Any use of a class instance is part of OOP.

IOStreams, iterators, strings, containers, ranges, filesytem, 
networking, graphics, traits

Being lazy, and counting its occurrences in comments and when used as
instead of typename in templates as well

/cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include
$ grep -R class * | uniq | wc -c
15601

STL is a name that stuck from the old days when it wasn't part of the 
language. Nowadays it is just the C++ standard library.

--
Paulo
Oct 01 2014
parent reply "po" <yes no.com> writes:
  I don't know of any OOP in the STL, unless you mean the 
 1980's stuff
 like iostreams and the other shit most people avoid using, but 
 I don't
 think this is considered part of the STL


 Any use of a class instance is part of OOP.

 IOStreams, iterators, strings, containers, ranges, filesytem, 
 networking, graphics, traits

 Being lazy, and counting its occurrences in comments and when 
 used as
 instead of typename in templates as well

 /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include
 $ grep -R class * | uniq | wc -c
 15601

 STL is a name that stuck from the old days when it wasn't part 
 of the language. Nowadays it is just the C++ standard library.

 --
 Paulo


  According to Stepanov STL author:

http://www.stlport.org/resources/StepanovUSA.html

"Yes. STL is not object oriented. I think that object 
orientedness is almost as much of a hoax as Artificial 
Intelligence. I have yet to see an interesting piece of code that 
comes from these OO people."

  I'd agree with him, just using a class, because it is the 
primary abstraction in C++, does not make your code OOP.
Oct 01 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 02.10.2014 00:11, schrieb po:

  I don't know of any OOP in the STL, unless you mean the 1980's stuff
 like iostreams and the other shit most people avoid using, but I don't
 think this is considered part of the STL


 Any use of a class instance is part of OOP.

 IOStreams, iterators, strings, containers, ranges, filesytem,
 networking, graphics, traits

 Being lazy, and counting its occurrences in comments and when used as
 instead of typename in templates as well

 /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include

 $ grep -R class * | uniq | wc -c
 15601

 STL is a name that stuck from the old days when it wasn't part of the
 language. Nowadays it is just the C++ standard library.

 --
 Paulo


   According to Stepanov STL author:

 http://www.stlport.org/resources/StepanovUSA.html

 "Yes. STL is not object oriented. I think that object orientedness is
 almost as much of a hoax as Artificial Intelligence. I have yet to see
 an interesting piece of code that comes from these OO people."

   I'd agree with him, just using a class, because it is the primary
 abstraction in C++, does not make your code OOP.


Well I disagree with him and can find examples of static and dynamic 
polymorphism, data encapsulation and aggregation everywhere in STL, even 
if he dislikes OO people.

Algorithms is probably the only part that is free of OO concepts.

--
Paulo
Oct 01 2014
parent reply Max Klyga <max.klyga gmail.com> writes:
On 2014-10-01 22:33:39 +0000, Paulo Pinto said:


 Am 02.10.2014 00:11, schrieb po:

 

 I don't know of any OOP in the STL, unless you mean the 1980's stuff
 like iostreams and the other shit most people avoid using, but I don't
 think this is considered part of the STL
 


 
 Any use of a class instance is part of OOP.
 
 IOStreams, iterators, strings, containers, ranges, filesytem,
 networking, graphics, traits
 
 Being lazy, and counting its occurrences in comments and when used as
 instead of typename in templates as well
 
 /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include
 
 $ grep -R class * | uniq | wc -c
 15601
 
 STL is a name that stuck from the old days when it wasn't part of the
 language. Nowadays it is just the C++ standard library.
 
 --
 Paulo


 
 According to Stepanov STL author:
 
 http://www.stlport.org/resources/StepanovUSA.html
 
 "Yes. STL is not object oriented. I think that object orientedness is
 almost as much of a hoax as Artificial Intelligence. I have yet to see
 an interesting piece of code that comes from these OO people."
 
 I'd agree with him, just using a class, because it is the primary
 abstraction in C++, does not make your code OOP.
 
 


 
 Well I disagree with him and can find examples of static and dynamic 
 polymorphism, data encapsulation and aggregation everywhere in STL, 
 even if he dislikes OO people.
 
 Algorithms is probably the only part that is free of OO concepts.


Data encapsulation is not unique to oop. STL is ADT not OOP.
Oct 01 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 02.10.2014 01:07, schrieb Max Klyga:

 On 2014-10-01 22:33:39 +0000, Paulo Pinto said:


 Am 02.10.2014 00:11, schrieb po:

 I don't know of any OOP in the STL, unless you mean the 1980's stuff
 like iostreams and the other shit most people avoid using, but I don't
 think this is considered part of the STL


 Any use of a class instance is part of OOP.

 IOStreams, iterators, strings, containers, ranges, filesytem,
 networking, graphics, traits

 Being lazy, and counting its occurrences in comments and when used as
 instead of typename in templates as well

 /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include


 $ grep -R class * | uniq | wc -c
 15601

 STL is a name that stuck from the old days when it wasn't part of the
 language. Nowadays it is just the C++ standard library.

 --
 Paulo


 According to Stepanov STL author:

 http://www.stlport.org/resources/StepanovUSA.html

 "Yes. STL is not object oriented. I think that object orientedness is
 almost as much of a hoax as Artificial Intelligence. I have yet to see
 an interesting piece of code that comes from these OO people."

 I'd agree with him, just using a class, because it is the primary
 abstraction in C++, does not make your code OOP.


 Well I disagree with him and can find examples of static and dynamic
 polymorphism, data encapsulation and aggregation everywhere in STL,
 even if he dislikes OO people.

 Algorithms is probably the only part that is free of OO concepts.


 Data encapsulation is not unique to oop. STL is ADT not OOP.


STL was ADT when it was initially written in Ada 83, not any longer.

First of all it doesn't exist any longer as such. The International 
Standard ISO/IEC 14882:2014(E) Programming Language C++ has zero 
occurrences of the word STL.

ADT implies using modules, data structures and functions that operate
on those functions. Which in C++ is achieved via separate compilation, 
namespaces and functions.

Basically what Ada 83, Mesa and Modula-2, UCSD Pascal offered as 
abstraction for organizing algorithms and data structures.

If a class is being used, then it already uses the first concept of OOP. 
Aggregation of data and member functions into a type. A module on steroids.

The door is also open to inheritance and aggregation.

If a class does not forbid inheritance, then it can have derived 
classes, even if the author did not intend it. Thus inheritance and 
dynamic polymorphism came into the picture.

Two other OOP concepts.

Finally, just for the fact that we have objects, member function 
invocations are now static dispatch. But if virtual methods are 
declared, then dynamic dispatch comes into play. Both properties of OOP 
systems.

Given the way C++ allows for function overloading, static multi-method
dispatch is also possible when used with NVO.

Just because inheritance is not used, it doesn't mean something isn't 
OOP. There are much more concepts at play.

When concepts lite come into the language, then C++ gains another way to 
deal with interfaces. Which will be used a lot in the standard library 
as well.

As I mentioned in another post. I can easily provide examples of the C++ 
standard library classes and how they use OOP concepts.

--
Paulo
Oct 01 2014
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 October 2014 01:17, po via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote:

 Max Klyga:


 https://www.youtube.com/watch?v=TH9VCN6UkyQ



 A third talk (from another person) about related matters:
 https://www.youtube.com/watch?v=rX0ItVEVjHc

 He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and
 lot of other C++ stuff. On the other hand he writes data-oriented code
 manually, the compiler and language give him only very limited help, and the
 code he writes looks twiddly and bug-prone. So why aren't they designing a
 language without most of the C++ stuff they don't use, but with features
 that help them write the data-oriented code they need?

 Bye,
 bearophile



  He (deliberately I'd guess)conflates cache friendly data structures and
 access patterns with his particular preference for a C style.

  It is a fallacy that he presents as fact.


He uses C style as an aggressive reminder of what you're actually
trying to do at all times.

We actually did this in our own engine long before he started giving
lectures like this. One of the best ways to stop people doing insane
shit in C++ is to ban C++.
The engine dev's loved this commitment to C, but the game logic
programmers hated us ;)

There is a middle ground though...
Oct 01 2014
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote:

 Max Klyga:


 https://www.youtube.com/watch?v=TH9VCN6UkyQ


 A third talk (from another person) about related matters:
 https://www.youtube.com/watch?v=rX0ItVEVjHc

 He doesn't use RTTI, exceptions, multiple inheritance, STL, 
 templates, and lot of other C++ stuff. On the other hand he 
 writes data-oriented code manually, the compiler and language 
 give him only very limited help, and the code he writes looks 
 twiddly and bug-prone. So why aren't they designing a language 
 without most of the C++ stuff they don't use, but with features 
 that help them write the data-oriented code they need?


Probably because C++ is good enough and already has mature 
infrastructure.
Oct 01 2014
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 October 2014 00:16, bearophile via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Max Klyga:


 https://www.youtube.com/watch?v=TH9VCN6UkyQ



 A third talk (from another person) about related matters:
 https://www.youtube.com/watch?v=rX0ItVEVjHc

 He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and
 lot of other C++ stuff. On the other hand he writes data-oriented code
 manually, the compiler and language give him only very limited help, and the
 code he writes looks twiddly and bug-prone. So why aren't they designing a
 language without most of the C++ stuff they don't use, but with features
 that help them write the data-oriented code they need?


Most gamedev's aren't quite as staunch as Mike Acton. The principle is
there, ingrained in every gamedev, but that doesn't mean we all love
flat C (although lots of us do!).

I've never used RTTI, I've never used exceptions, certainly never use
multiple inheritance, I rarely use templates (in C++)... but I'm still
attracted to D!?
I often find this strange... but not really. In D, I still don't use
RTTI, I still don't use exceptions, I tend to box use of templates
into their own worlds, so I would never use them pervasively (like
phobos).
You'll notice at one point that he talked about using offline text
processing tools to do codegen... this is basically because C's
preprocessor sucks, and C++ templates suck. D templates have proven to
eliminate a lot of those offline tools for me. The code is kept in the
same place, and built using the same tool.
I suspect even Acton would appreciate features like CTFE.
You'll also notice he made repeated reference to build environment
complexity and build times.
D also offers potential compiler advantages, purity, immutable, etc,
which give the optimiser information which it can use to improve
codegen which is awkward in C/C++.
Oct 01 2014
parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 02/10/2014 08:22, Manu via Digitalmars-d a écrit :

 On 2 October 2014 00:16, bearophile via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Max Klyga:


 https://www.youtube.com/watch?v=TH9VCN6UkyQ



 A third talk (from another person) about related matters:
 https://www.youtube.com/watch?v=rX0ItVEVjHc

 He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and
 lot of other C++ stuff. On the other hand he writes data-oriented code
 manually, the compiler and language give him only very limited help, and the
 code he writes looks twiddly and bug-prone. So why aren't they designing a
 language without most of the C++ stuff they don't use, but with features
 that help them write the data-oriented code they need?


 Most gamedev's aren't quite as staunch as Mike Acton. The principle is
 there, ingrained in every gamedev, but that doesn't mean we all love
 flat C (although lots of us do!).

 I've never used RTTI, I've never used exceptions, certainly never use
 multiple inheritance, I rarely use templates (in C++)... but I'm still
 attracted to D!?
 I often find this strange... but not really. In D, I still don't use
 RTTI, I still don't use exceptions, I tend to box use of templates
 into their own worlds, so I would never use them pervasively (like
 phobos).
 You'll notice at one point that he talked about using offline text
 processing tools to do codegen... this is basically because C's
 preprocessor sucks, and C++ templates suck. D templates have proven to
 eliminate a lot of those offline tools for me. The code is kept in the
 same place, and built using the same tool.
 I suspect even Acton would appreciate features like CTFE.
 You'll also notice he made repeated reference to build environment
 complexity and build times.
 D also offers potential compiler advantages, purity, immutable, etc,
 which give the optimiser information which it can use to improve
 codegen which is awkward in C/C++.


For the application I am working on the 3D developer wrote everything in 
c++ style, but he made a lot of mistakes that killing performances.
We are far away cache miss issues (or polymorphism,...), and more in 
instancing ones. Last week I removed allocation and deallocation of 
meshes made in the sort for transparent models. new and delete aren't 
the main problem, it was the code in constructors and destructors that 
made heavy use of vectors.
Things like vector.erase(vector.find("boo"));

One my PC (a gamer one) I just win 20FPS from 10 to 30. For a scene of 
700 objects (< 50 000 triangles). YEP this is really bad for my i7 and 
my 670GTX. I have a lot of work to do, normally on my PC for a such 
scene I can expect much more than 200 FPS.

This is just one of our performances issues, and for me it's not due to 
only C++ OOP. It's about experience. I had never worked on games or 
applications need a level of optimization impose me SOA design but 
reusing chunk of memories and avoiding unnecessary computations are 
always things I carry on.

For those are interested to see more about the application :
https://groups.google.com/forum/#!forum/home-design-3d-beta

This is also the one that inspired me and my friend for DQuick.
Oct 11 2014