[Semi OT] Language for Game Development talk

Post by Max Klyga via Digitalmars-d
Jonathan Blow just recorded a talk about the needs and ideas for a
programming language for game developer.
http://youtu.be/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

bearophile via Digitalmars-d

2014-09-20 00:52:04 UTC

Post by Max Klyga via Digitalmars-d
http://youtu.be/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

po via Digitalmars-d

2014-09-20 02:25:30 UTC

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.

Paulo Pinto via Digitalmars-d

2014-09-20 11:25:32 UTC

Post by po via Digitalmars-d
He actually talks about Andre around 40' ;0
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.

Post by po via Digitalmars-d
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++.

Post by po via Digitalmars-d
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.

Post by po via Digitalmars-d
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.

Post by po via Digitalmars-d
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.

Post by po via Digitalmars-d
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

Xavier Bigand via Digitalmars-d

2014-09-24 18:45:30 UTC

Post by po via Digitalmars-d
He actually talks about Andre around 40' ;0
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?

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.

Sean Kelly via Digitalmars-d

2014-09-25 22:52:37 UTC

Post by po via Digitalmars-d
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

...

Post by po via Digitalmars-d
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.

Post by po via Digitalmars-d
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.

Peter Alexander via Digitalmars-d

2014-09-25 23:04:02 UTC

Post by Sean Kelly via Digitalmars-d

Post by po via Digitalmars-d
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

...

Post by po via Digitalmars-d
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.

Sean Kelly via Digitalmars-d

2014-09-25 23:55:42 UTC

On Thursday, 25 September 2014 at 23:04:08 UTC, Peter Alexander

Post by Peter Alexander via Digitalmars-d
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.

Walter Bright via Digitalmars-d

2014-09-25 23:39:54 UTC

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.

po via Digitalmars-d

2014-09-26 07:24:47 UTC

Post by Sean Kelly via Digitalmars-d
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.

Post by Sean Kelly via Digitalmars-d
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.

Post by Sean Kelly via Digitalmars-d
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

po via Digitalmars-d

2014-09-26 07:44:07 UTC

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!"

via Digitalmars-d

2014-09-26 08:36:07 UTC

Post by po via Digitalmars-d
I watched it. None of what he said made much sense.
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.

Post by po via Digitalmars-d
-ran out of memory? Shut game down, this should not happen

On IOS or PNaCl you might have to accept that it may happen...

po via Digitalmars-d

2014-09-26 08:59:04 UTC

Post by via Digitalmars-d
- RAII makes most sense if you have exceptions.

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

Post by via Digitalmars-d
- 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.

Post by via Digitalmars-d
- 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++.

Post by via Digitalmars-d
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--

via Digitalmars-d

2014-09-26 09:11:28 UTC

Post by po via Digitalmars-d
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.

Walter Bright via Digitalmars-d

2014-09-26 18:37:51 UTC

On 9/26/2014 2:11 AM, "Ola Fosheim GrÃžstad"

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 :-)

Paulo Pinto via Digitalmars-d

2014-09-26 09:13:07 UTC

Post by via Digitalmars-d
- RAII makes most sense if you have exceptions.

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

Post by via Digitalmars-d
- 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.

Post by via Digitalmars-d
- 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++.

Post by via Digitalmars-d
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

via Digitalmars-d

2014-09-26 09:24:18 UTC

Post by via Digitalmars-d
- 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.

Paulo Pinto via Digitalmars-d

2014-09-26 09:41:08 UTC

On Friday, 26 September 2014 at 09:24:19 UTC, Ola Fosheim GrÃžstad

Post by via Digitalmars-d

Post by via Digitalmars-d
- 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

via Digitalmars-d

2014-09-26 10:01:31 UTC

Post by Paulo Pinto via Digitalmars-d
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

po via Digitalmars-d

2014-09-26 10:18:00 UTC

Â«The technique was developed for exception-safe resource

Post by via Digitalmars-d
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

Paulo Pinto via Digitalmars-d

2014-09-26 11:02:42 UTC

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

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

Post by Paulo Pinto via Digitalmars-d
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.
Â«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

Walter Bright via Digitalmars-d

2014-09-26 18:46:21 UTC

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.
Â«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."

Paulo Pinto via Digitalmars-d

2014-09-26 18:50:06 UTC

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.
Â«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
"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

H. S. Teoh via Digitalmars-d

2014-09-26 18:52:21 UTC

Post by Paulo Pinto via Digitalmars-d

Post by via Digitalmars-d

Post by Paulo Pinto via Digitalmars-d
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.
Â«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.

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

ketmar via Digitalmars-d

2014-09-26 21:53:25 UTC

On Fri, 26 Sep 2014 11:52:21 -0700

Post by H. S. Teoh via Digitalmars-d
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".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140927/adceef09/attachment.sig>

Walter Bright via Digitalmars-d

2014-09-26 19:33:06 UTC

I've been banned from editing Wikipedia for some reason. Someone else will have
to do it :-(

H. S. Teoh via Digitalmars-d

2014-09-26 19:47:36 UTC

Post by H. S. Teoh via Digitalmars-d
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?

Post by Walter Bright via Digitalmars-d
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.

Walter Bright via Digitalmars-d

2014-09-26 21:08:51 UTC

Post by H. S. Teoh via Digitalmars-d
I would, except that right now I'm working on a dmd PR. ;-)

No hurry.

Post by H. S. Teoh via Digitalmars-d
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++.

Ola Fosheim Grostad via Digitalmars-d

2014-09-26 20:10:32 UTC

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

Post by H. S. Teoh via Digitalmars-d
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?

Paulo Pinto via Digitalmars-d

2014-09-26 20:48:27 UTC

Post by Ola Fosheim Grostad via Digitalmars-d
On Friday, 26 September 2014 at 18:54:14 UTC, H. S. Teoh via

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

via Digitalmars-d

2014-09-26 21:32:54 UTC

Post by Paulo Pinto via Digitalmars-d
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).

Post by Paulo Pinto via Digitalmars-d
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).

H. S. Teoh via Digitalmars-d

2014-09-26 22:19:06 UTC

On Fri, Sep 26, 2014 at 09:32:54PM +0000, via Digitalmars-d wrote:
[...]

Post by via Digitalmars-d
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!

Paulo Pinto via Digitalmars-d

2014-09-27 13:57:26 UTC

Am 26.09.2014 23:32, schrieb "Ola Fosheim GrÃžstad"

Post by via Digitalmars-d

Post by Paulo Pinto via Digitalmars-d
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.

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

Ola Fosheim Grostad via Digitalmars-d

2014-09-26 19:16:01 UTC

Post by Walter Bright via Digitalmars-d
I wrote a C++ compiler in 1987. Nobody had ever heard of
exceptions. Bjarne's 1986 "The C++ Programming Language" does

Exceptions is chapter 15 in the 1990 edition. I should have it
somewhere, a small brown hardcover and expensive!

via Digitalmars-d

2014-09-26 21:04:46 UTC

Post by Walter Bright via Digitalmars-d
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. :)

Post by Walter Bright via Digitalmars-d
Bjarne's 1986 "The C++ Programming Language" does not mention
"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.

Walter Bright via Digitalmars-d

2014-09-26 21:19:31 UTC

On 9/26/2014 2:04 PM, "Ola Fosheim GrÃžstad"

Post by Walter Bright via Digitalmars-d
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++.

Post by Walter Bright via Digitalmars-d
Bjarne's 1986 "The C++ Programming Language" does not mention RAII or
"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.

via Digitalmars-d

2014-09-27 10:01:04 UTC

Post by Walter Bright via Digitalmars-d
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.

deadalnix via Digitalmars-d

2014-09-28 07:12:30 UTC

On Saturday, 27 September 2014 at 10:01:05 UTC, Ola Fosheim

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

Post by Walter Bright via Digitalmars-d
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.

po via Digitalmars-d

2014-09-26 09:42:13 UTC

Post by via Digitalmars-d
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.

via Digitalmars-d

2014-09-26 09:56:06 UTC

Post by po via Digitalmars-d
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.

Walter Bright via Digitalmars-d

2014-09-26 18:39:09 UTC

On 9/26/2014 2:24 AM, "Ola Fosheim GrÃžstad"

Post by via Digitalmars-d
- 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.

Manu via Digitalmars-d

2014-09-26 15:21:17 UTC

On 26 September 2014 17:24, po via Digitalmars-d

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

Jacob Carlborg via Digitalmars-d

2014-09-26 15:52:19 UTC

Post by po via Digitalmars-d
-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

Walter Bright via Digitalmars-d

2014-09-26 18:20:26 UTC

Post by Manu via Digitalmars-d
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;

Tobias Müller via Digitalmars-d

2014-09-26 22:04:23 UTC

Post by Manu via Digitalmars-d
I've never used an exception before. I can't imagine a reason I would
ever want to.

Nothrow is your friend, then!
if (errorHappened) goto LcleanupCode;

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

Tobi

Manu via Digitalmars-d

2014-09-27 00:47:33 UTC

On 27 September 2014 04:20, Walter Bright via Digitalmars-d

Post by Manu via Digitalmars-d
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 ;)

Post by Walter Bright via Digitalmars-d
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++...

Jacob Carlborg via Digitalmars-d

2014-09-27 09:32:18 UTC

Post by Manu via Digitalmars-d
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

Sean Kelly via Digitalmars-d

2014-09-27 15:52:59 UTC

Post by Jacob Carlborg via Digitalmars-d

On Saturday, 27 September 2014 at 09:32:19 UTC, Jacob Carlborg

Post by Manu via Digitalmars-d
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.

bearophile via Digitalmars-d

2014-09-20 08:38:48 UTC

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

Ola Fosheim Grostad via Digitalmars-d

2014-09-20 08:46:33 UTC

Post by bearophile via Digitalmars-d
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

Brian Schott via Digitalmars-d

2014-09-20 08:59:45 UTC

On Saturday, 20 September 2014 at 08:46:34 UTC, Ola Fosheim

Post by Ola Fosheim Grostad via Digitalmars-d
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

bearophile via Digitalmars-d

2014-09-20 09:09:55 UTC

Post by Brian Schott via Digitalmars-d
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

Ola Fosheim Grostad via Digitalmars-d

2014-09-20 11:17:44 UTC

Post by Brian Schott via Digitalmars-d
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...

Ary Borenszweig via Digitalmars-d

2014-09-21 05:14:52 UTC

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!

bearophile via Digitalmars-d

2014-09-21 09:30:13 UTC

Post by Ary Borenszweig via Digitalmars-d
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

Paulo Pinto via Digitalmars-d

2014-09-21 10:44:17 UTC

Post by Ary Borenszweig via Digitalmars-d
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

You can handle units of measure via tuples structs, since you mention F#.

Not as clean, but workable.

--
Paulo

bearophile via Digitalmars-d

2014-09-21 10:47:55 UTC

Post by Paulo Pinto via Digitalmars-d

Post by bearophile via Digitalmars-d
(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
mention F#.

Here I mentioned F*, not F#:
http://research.microsoft.com/en-us/projects/fstar/

Bye,
bearophile

Paulo Pinto via Digitalmars-d

2014-09-21 11:01:51 UTC

Post by Paulo Pinto via Digitalmars-d

Post by bearophile via Digitalmars-d
(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 mention F#.

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

Sorry, should have taken more coffee.

Walter Bright via Digitalmars-d

2014-09-25 04:22:20 UTC

Post by Paulo Pinto via Digitalmars-d
Sorry, should have taken more coffee.

My excuse is I haven't had my beer yet.

Walter Bright via Digitalmars-d

2014-09-25 04:18:34 UTC

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.

Jacob Carlborg via Digitalmars-d

2014-09-25 06:53:29 UTC

Post by Walter Bright via Digitalmars-d
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

bearophile via Digitalmars-d

2014-09-25 08:47:24 UTC

Post by Walter Bright via Digitalmars-d
This stood out for me. Deallocated how?

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

Post by Walter Bright via Digitalmars-d
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.

Post by Walter Bright via Digitalmars-d
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

Walter Bright via Digitalmars-d

2014-09-25 09:16:22 UTC

Post by Walter Bright via Digitalmars-d
This stood out for me. Deallocated how?

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

Post by Walter Bright via Digitalmars-d
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.

Post by Walter Bright via Digitalmars-d
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) ?

bearophile via Digitalmars-d

2014-09-25 09:32:53 UTC

Post by Walter Bright via Digitalmars-d
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

Walter Bright via Digitalmars-d

2014-09-25 09:57:58 UTC

Post by Walter Bright via Digitalmars-d
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 :-)

Kagamin via Digitalmars-d

2014-09-25 11:33:07 UTC

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

Post by Walter Bright via Digitalmars-d
So how do you tell it to call myfree(p) instead of free(p) ?

Maybe stock malloc/free is enough for him?

Andrei Alexandrescu via Digitalmars-d

2014-09-25 13:57:18 UTC

Post by Kagamin via Digitalmars-d

Post by Walter Bright via Digitalmars-d
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

Kagamin via Digitalmars-d

2014-09-25 15:12:53 UTC

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

Post by Kagamin via Digitalmars-d
On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright

Post by Walter Bright via Digitalmars-d
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.

Andrei Alexandrescu via Digitalmars-d

2014-09-25 15:34:31 UTC

Post by Kagamin via Digitalmars-d

Post by Walter Bright via Digitalmars-d
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

deadalnix via Digitalmars-d

2014-09-25 20:38:04 UTC

On Thursday, 25 September 2014 at 15:34:31 UTC, Andrei

Post by Kagamin via Digitalmars-d
On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei

Post by Kagamin via Digitalmars-d
On Thursday, 25 September 2014 at 09:16:27 UTC, Walter

Post by Walter Bright via Digitalmars-d
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 !

Peter Alexander via Digitalmars-d

2014-09-25 18:38:34 UTC

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

Post by Kagamin via Digitalmars-d
On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright

Post by Walter Bright via Digitalmars-d
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.

Kagamin via Digitalmars-d

2014-09-26 07:18:07 UTC

On Thursday, 25 September 2014 at 18:38:36 UTC, Peter Alexander

Post by Peter Alexander via Digitalmars-d
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.

deadalnix via Digitalmars-d

2014-09-20 04:28:56 UTC

Post by Max Klyga via Digitalmars-d
Jonathan Blow just recorded a talk about the needs and ideas
for a programming language for game developer.
http://youtu.be/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.

deadalnix via Digitalmars-d

2014-09-20 05:34:32 UTC

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.

Piotrek via Digitalmars-d

2014-09-21 13:09:57 UTC

Post by deadalnix via Digitalmars-d

Post by Max Klyga via Digitalmars-d
Jonathan Blow just recorded a talk about the needs and ideas
for a programming language for game developer.
http://youtu.be/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 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

Paulo Pinto via Digitalmars-d

2014-09-20 11:11:26 UTC

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

Ola Fosheim Grostad via Digitalmars-d

2014-09-20 11:30:21 UTC

Post by Paulo Pinto via Digitalmars-d
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.

JN via Digitalmars-d

2014-09-21 11:08:59 UTC

Post by Max Klyga via Digitalmars-d
Jonathan Blow just recorded a talk about the needs and ideas
for a programming language for game developer.
http://youtu.be/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.

Walter Bright via Digitalmars-d

2014-09-25 09:27:10 UTC

Jonathan Blow just recorded a talk about the needs and ideas for a programming
language for game developer.
http://youtu.be/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.

Walter Bright via Digitalmars-d

2014-09-25 09:58:26 UTC

Post by Walter Bright via Digitalmars-d
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!

currysoup via Digitalmars-d

2014-09-25 10:46:59 UTC

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).

ketmar via Digitalmars-d

2014-09-25 11:30:05 UTC

On Thu, 25 Sep 2014 10:46:59 +0000

Post by currysoup via Digitalmars-d
I quite like the idea of "simple by default" and you enable

"@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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140925/17fac3e4/attachment.sig>

Kagamin via Digitalmars-d

2014-09-25 11:42:46 UTC

Post by currysoup via Digitalmars-d
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
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.

currysoup via Digitalmars-d

2014-09-25 12:16:16 UTC

On Thursday, 25 September 2014 at 11:30:16 UTC, ketmar via

Post by ketmar via Digitalmars-d
On Thu, 25 Sep 2014 10:46:59 +0000

Post by currysoup via Digitalmars-d
I quite like the idea of "simple by default" and you enable

string
concatenation or format() will need this annotation. i see GC as
void foo () { ... some no-gc code ... }
still allow
ah, and the same for 'final'.
sure one can just move necessary definitions to top of the file
(i.e.
readability.

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

ketmar via Digitalmars-d

2014-09-25 12:26:14 UTC

On Thu, 25 Sep 2014 12:16:16 +0000

Post by currysoup via Digitalmars-d
I wasn't talking about D, just in general.

sorry, it's my frustration speaks. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140925/dbe34dd1/attachment.sig>

Walter Bright via Digitalmars-d

2014-09-25 19:54:55 UTC

I quite like the idea of "simple by default" and you enable features with

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.

Walter Bright via Digitalmars-d

2014-09-25 19:59:24 UTC

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.

Jacob Carlborg via Digitalmars-d

2014-09-26 06:34:01 UTC

Post by Walter Bright via Digitalmars-d
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

Walter Bright via Digitalmars-d

2014-09-26 07:14:32 UTC

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 :-)

Peter Alexander via Digitalmars-d

2014-09-25 12:05:10 UTC

On Thursday, 25 September 2014 at 09:58:31 UTC, Walter Bright

Post by Walter Bright via Digitalmars-d
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.
<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.

deadalnix via Digitalmars-d

2014-09-25 20:23:55 UTC

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

Post by Max Klyga via Digitalmars-d
Jonathan Blow just recorded a talk about the needs and ideas
for a programming
language for game developer.
http://youtu.be/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).

ponce via Digitalmars-d

2014-09-27 16:35:10 UTC

Post by Max Klyga via Digitalmars-d
Jonathan Blow just recorded a talk about the needs and ideas
for a programming language for game developer.
http://youtu.be/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:

A Programming Language for Games, talk #2

Walter Bright via Digitalmars-d

2014-09-27 21:51:14 UTC

Post by ponce via Digitalmars-d
A Programming Language for Games, talk #2
http://youtu.be/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.

H. S. Teoh via Digitalmars-d

2014-09-27 22:04:07 UTC

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

Post by Walter Bright via Digitalmars-d
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*

Post by Walter Bright via Digitalmars-d
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.

bearophile via Digitalmars-d

2014-09-27 22:30:41 UTC

Post by Walter Bright via Digitalmars-d
* 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;
}

Ada2012 and C#6 have something like that (with a different
syntax).

Post by Walter Bright via Digitalmars-d
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

Walter Bright via Digitalmars-d

2014-09-27 22:56:57 UTC

Post by Walter Bright via Digitalmars-d
* local functions with the same syntax as global functions
* safety which defaults to off
All of which D does right now.

https://issues.dlang.org/show_bug.cgi?id=7176
struct Foo {
int bar(int x) pure { return x * x; }
}
struct Foo {
int bar = (int x) pure => x * x;
}

I see no gain from that syntax.

Post by bearophile via Digitalmars-d
Unwanted access of global variables is a common source of troubles in my code.
https://d.puremagic.com/issues/show_bug.cgi?id=5007

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

bearophile via Digitalmars-d

2014-09-27 23:20:03 UTC

Post by bearophile via Digitalmars-d
It could be nice to have a syntax like lambdas for small
https://issues.dlang.org/show_bug.cgi?id=7176
struct Foo {
int bar(int x) pure { return x * x; }
}
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.

Post by Walter Bright via Digitalmars-d
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

Walter Bright via Digitalmars-d

2014-09-27 23:55:20 UTC

Post by bearophile via Digitalmars-d
https://issues.dlang.org/show_bug.cgi?id=7176
struct Foo {
int bar(int x) pure { return x * x; }
}
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.

Post by bearophile via Digitalmars-d
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.
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.

Post by Walter Bright via Digitalmars-d
I suggest using 'pure' and passing the globals you actually need as ref parameters.

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

Post by bearophile via Digitalmars-d
- 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.

Post by bearophile via Digitalmars-d
- 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
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.

Post by bearophile via Digitalmars-d
variable received by ref, you just need to know its name.

That's why gawd invented templates.

Post by bearophile via Digitalmars-d
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
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.

Post by bearophile via Digitalmars-d
comment 5 in issue 5007.
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.

Timon Gehr via Digitalmars-d

2014-09-28 00:51:45 UTC