• Dgame (25/25) Jul 01 2017 Hi there. I hope that is the right place for this topic.
• rikki cattermole (4/4) Jul 01 2017 Not too helpful but a few points that may interest you:
• Nicholas Wilson (10/36) Jul 01 2017 If you haven't watched it yet, Walter's dconf keynote this year
• Dgame (10/19) Jul 01 2017 Yes, that's what I call "security oriented software technology
• ketmar (9/11) Jul 01 2017 i can actually finish 'em. most of the time when i'm working with D, i f...
• Dgame (4/17) Jul 01 2017 Is that described somewhere? Or do you have examples or both?
• ketmar (28/42) Jul 01 2017 basically, all of my projects. ;-) like zx spectrum emulator, which took...
• Patrick Schluter (2/51) Jul 01 2017 Amen.
• ketmar (8/8) Jul 01 2017 p.s.: as a side note. i planned to write my own email client for *decade...
• Ecstatic Coder (25/51) Jul 01 2017 Whatever the object oriented language you use, you can keep
• Dgame (7/32) Jul 02 2017 That's a good statement which I found very often recently. Maybe
• Ecstatic Coder (9/12) Jul 02 2017 Maybe changing the application domain could give you a better
• Ecstatic Coder (6/16) Jul 03 2017 Btw that doesn't mean you should not implement the SDL game

Dgame <r.schuett.1987 gmail.com> writes:

Hi there. I hope that is the right place for this topic.
I'm currently writing my master thesis and just like in my 
bachelor thesis, D will play a significant role in my master 
thesis. My thesis will discuss the impact of software engineering 
concepts of security-oriented programming languages on software 
development with a focus on the effects on software design / 
design patterns and specifically software architecture. As said, 
D will be one of the few secure programming languages which I 
will present. Others will be Rust & Ada and on the other side 
C/C++ will be one example of the many unsecure programming 
languages. That as a short introduction of the purpose of my 
master thesis and what I intend to do in the next six months. 
Currently, I'm collecting links, literature and other stuff on 
that topic. But I thought that maybe some of you know more about 
that and can give me hints, links or maybe even real live 
experience/examples. That would be really kind of you. :)

For example:
Which impact would have D on the software-architecture, if it 
would be choosen for a 2D game instead of C/C++?
The 2D game is my choosen case example since I programmed small 
games on gamejams in C/C++ and D, until two years ago. Of course, 
any architecture regarding that topic is of interest.

Have you already made such experience or do you know people who 
have and maybe even wrote articles about?

Many thanks in advance!

rikki cattermole <rikki cattermole.co.nz> writes:

Not too helpful but a few points that may interest you:
- All dynamic arrays are slices. T[] array = ptr[0 .. length];
- Compute values at CTFE, compare, contrast against e.g. unittests for 
extra verification

Nicholas Wilson <iamthewilsonator hotmail.com> writes:

On Saturday, 1 July 2017 at 08:48:19 UTC, Dgame wrote:
 Hi there. I hope that is the right place for this topic.
 I'm currently writing my master thesis and just like in my 
 bachelor thesis, D will play a significant role in my master 
 thesis. My thesis will discuss the impact of software 
 engineering concepts of security-oriented programming languages 
 on software development with a focus on the effects on software 
 design / design patterns and specifically software 
 architecture. As said, D will be one of the few secure 
 programming languages which I will present. Others will be Rust 
 & Ada and on the other side C/C++ will be one example of the 
 many unsecure programming languages. That as a short 
 introduction of the purpose of my master thesis and what I 
 intend to do in the next six months. Currently, I'm collecting 
 links, literature and other stuff on that topic. But I thought 
 that maybe some of you know more about that and can give me 
 hints, links or maybe even real live experience/examples. That 
 would be really kind of you. :)

 For example:
 Which impact would have D on the software-architecture, if it 
 would be choosen for a 2D game instead of C/C++?
 The 2D game is my choosen case example since I programmed small 
 games on gamejams in C/C++ and D, until two years ago. Of 
 course, any architecture regarding that topic is of interest.

 Have you already made such experience or do you know people who 
 have and maybe even wrote articles about?

 Many thanks in advance!

If you haven't watched it yet, Walter's dconf keynote this year 
is a good place to start as are the discussion on dip1000 and the 
dip itself.

But as Rikki said the fact that all arrays carry they length 
means that we have array bounds checking, which rules out one 
class of very common bugs you would get in C.

I'm about to hand in my Honours thesis on Monday after doing it 
for a year, I don't think I could do one in six months, so best 
of luck!

Dgame <r.schuett.1987 gmail.com> writes:

 If you haven't watched it yet, Walter's dconf keynote this year 
 is a good place to start as are the discussion on dip1000 and 
 the dip itself.

Thanks, that's a good hint, I'll definitely watch it. :)

 But as Rikki said the fact that all arrays carry they length 
 means that we have array bounds checking, which rules out one 
 class of very common bugs you would get in C.

Yes, that's what I call "security oriented software technology 
concept" or "vulnerability avoiding concept". It's one of the 
many things D did right and which I want to mention (there are so 
many!), but it's not a  concrete impact on software architecture. 
That's what I mainly seek. It's not that easy to find concrete 
impacts IMO.

 I'm about to hand in my Honours thesis on Monday after doing it 
 for a year, I don't think I could do one in six months, so best 
 of luck!

If I could, I would also happily wrote a year or more, since 
there is so much to write about, but we only have six months for 
our master thesis.

ketmar <ketmar ketmar.no-ip.org> writes:

Dgame wrote:

 Which impact would have D on the software-architecture, if it would be 
 choosen for a 2D game instead of C/C++?

i can actually finish 'em. most of the time when i'm working with D, i feel 
that compiler tries to help me. EVERY TIME i'm working with C/C++, i know 
for sure that compiler silently setting traps for me ('cause it is 
absolutely impossible to write safe and secure C/C++ code -- tnx to 
standard committee and compiler implementers, anything can turn into UB 
unexpectedly, and writing UB-free code is tedious and it will have UB 
anyway).

otherwise, i hate writing articles: writing code is way more fun. ;-)

Dgame <r.schuett.1987 gmail.com> writes:

On Saturday, 1 July 2017 at 14:40:36 UTC, ketmar wrote:
 Dgame wrote:

 Which impact would have D on the software-architecture, if it 
 would be choosen for a 2D game instead of C/C++?

 i can actually finish 'em. most of the time when i'm working 
 with D, i feel that compiler tries to help me. EVERY TIME i'm 
 working with C/C++, i know for sure that compiler silently 
 setting traps for me ('cause it is absolutely impossible to 
 write safe and secure C/C++ code

Do you have examples (code and/or personal experience) about that?

 -- tnx to standard committee and compiler implementers, 
 anything can turn into UB unexpectedly, and writing UB-free 
 code is tedious and it will have UB anyway).

Is that described somewhere? Or do you have examples or both?

 otherwise, i hate writing articles: writing code is way more 
 fun. ;-)

Same here. :D

ketmar <ketmar ketmar.no-ip.org> writes:

Dgame wrote:

 On Saturday, 1 July 2017 at 14:40:36 UTC, ketmar wrote:
 Dgame wrote:

 Which impact would have D on the software-architecture, if it would be 
 choosen for a 2D game instead of C/C++?

 i can actually finish 'em. most of the time when i'm working with D, i 
 feel that compiler tries to help me. EVERY TIME i'm working with C/C++, 
 i know for sure that compiler silently setting traps for me ('cause it 
 is absolutely impossible to write safe and secure C/C++ code

 Do you have examples (code and/or personal experience) about that?

basically, all of my projects. ;-) like zx spectrum emulator, which took 
monthes in C, and only weeks in D (and it almost on par feature-wise with C 
version, and even more advanced in some areas like FDC emulation).

 -- tnx to standard committee and compiler implementers, anything can 
 turn into UB unexpectedly, and writing UB-free code is tedious and it 
 will have UB anyway).

 Is that described somewhere? Or do you have examples or both?

ah, many people are complaining. just recent ones (there are MUCH MORE out 
there, just follow the links in the articles, for example):

http://www.yodaiken.com/2017/06/26/the-c-standard-versus-c-and-the-mother-of-all-hacks/
http://www.yodaiken.com/2017/01/05/undefined-behavior-and-the-purpose-of-c/

everything compiler authors has to say is (see gcc bugzilla link in one of the 
articles): "it is permitted by the standard. don't write code with UB". 
that is, modern optimizing C compilers are *actively* trying to 
*subvert* your code. using modern C compiler ends up in you being punished 
for all kind of random things: compiler is using *any* your error against 
you. it probably helps to win some stupid compiler benchmarks, but it is 
crystal clear that modern C is not made to write real-world programs in it: 
programmer have to manually track the things, and make machine happy. this 
is exactly the *opposite* of the machine's purpose: it is machine's task to 
make human happy, and free human from tedious and error-prone work, not vice 
versa! ;-)

besides those issues, the GREAT advantage of D is well-defined low-level 
types. `uint` is always 32 bits, `short` is always 16 bits and 2-complement 
(and it has overflow defined!), and so on. no need to `stdint.h` anymore 
(and why do we need it in C at all? winning several CPU cycles on the 
occasion vs hours of fighting to write portable code... OBEY THE MACHINE, 
YOU WORTHLESS HUMAN! ;-)

i dropped C years ago, switched to D, and i will NEVER return. D was made 
by humans, for humans, not by committee and compiler writers to win useless 
benchmarks.

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

On Saturday, 1 July 2017 at 15:58:04 UTC, ketmar wrote:
 Dgame wrote:

 On Saturday, 1 July 2017 at 14:40:36 UTC, ketmar wrote:
 Dgame wrote:

 Which impact would have D on the software-architecture, if 
 it would be choosen for a 2D game instead of C/C++?

 i can actually finish 'em. most of the time when i'm working 
 with D, i feel that compiler tries to help me. EVERY TIME i'm 
 working with C/C++, i know for sure that compiler silently 
 setting traps for me ('cause it is absolutely impossible to 
 write safe and secure C/C++ code

 Do you have examples (code and/or personal experience) about 
 that?

 basically, all of my projects. ;-) like zx spectrum emulator, 
 which took monthes in C, and only weeks in D (and it almost on 
 par feature-wise with C version, and even more advanced in some 
 areas like FDC emulation).

 -- tnx to standard committee and compiler implementers, 
 anything can turn into UB unexpectedly, and writing UB-free 
 code is tedious and it will have UB anyway).

 Is that described somewhere? Or do you have examples or both?

 ah, many people are complaining. just recent ones (there are 
 MUCH MORE out there, just follow the links in the articles, for 
 example):

 http://www.yodaiken.com/2017/06/26/the-c-standard-versus-c-and-the-mother-of-all-hacks/
 http://www.yodaiken.com/2017/01/05/undefined-behavior-and-the-purpose-of-c/

 everything compiler authors has to say is (see gcc bugzilla 
 link in one of the articles): "it is permitted by the standard. 
 don't write code with UB". that is, modern optimizing C 
 compilers are *actively* trying to *subvert* your code. using 
 modern C compiler ends up in you being punished for all kind of 
 random things: compiler is using *any* your error against you. 
 it probably helps to win some stupid compiler benchmarks, but 
 it is crystal clear that modern C is not made to write 
 real-world programs in it: programmer have to manually track 
 the things, and make machine happy. this is exactly the 
 *opposite* of the machine's purpose: it is machine's task to 
 make human happy, and free human from tedious and error-prone 
 work, not vice versa! ;-)

 besides those issues, the GREAT advantage of D is well-defined 
 low-level types. `uint` is always 32 bits, `short` is always 16 
 bits and 2-complement (and it has overflow defined!), and so 
 on. no need to `stdint.h` anymore (and why do we need it in C 
 at all? winning several CPU cycles on the occasion vs hours of 
 fighting to write portable code... OBEY THE MACHINE, YOU 
 WORTHLESS HUMAN! ;-)

 i dropped C years ago, switched to D, and i will NEVER return. 
 D was made by humans, for humans, not by committee and compiler 
 writers to win useless benchmarks.

Amen.

ketmar <ketmar ketmar.no-ip.org> writes:

p.s.: as a side note. i planned to write my own email client for *decades*. 
literally. but never managed to fight my way through C (and let's don't 
even start to talk about C++!). with D, my dream finally turned into 
reality: i am using Chiroptera e-mail/nntp client, written by me, from 
scratch, in D. and i must confess that i prefer to not switch off/reboot my 
box, so my e-mail client should not crash. now, Chiroptera works for 
monthes without any crash or (significant ;-) memleak. and i don't have to 
restart it ocasionally, 'cause it crashed, or eats gigabytes of RAM. ;-)

Ecstatic Coder <ecstatic.coder gmail.com> writes:

On Saturday, 1 July 2017 at 08:48:19 UTC, Dgame wrote:
 Hi there. I hope that is the right place for this topic.
 I'm currently writing my master thesis and just like in my 
 bachelor thesis, D will play a significant role in my master 
 thesis. My thesis will discuss the impact of software 
 engineering concepts of security-oriented programming languages 
 on software development with a focus on the effects on software 
 design / design patterns and specifically software 
 architecture. As said, D will be one of the few secure 
 programming languages which I will present. Others will be Rust 
 & Ada and on the other side C/C++ will be one example of the 
 many unsecure programming languages. That as a short 
 introduction of the purpose of my master thesis and what I 
 intend to do in the next six months. Currently, I'm collecting 
 links, literature and other stuff on that topic. But I thought 
 that maybe some of you know more about that and can give me 
 hints, links or maybe even real live experience/examples. That 
 would be really kind of you. :)

 For example:
 Which impact would have D on the software-architecture, if it 
 would be choosen for a 2D game instead of C/C++?
 The 2D game is my choosen case example since I programmed small 
 games on gamejams in C/C++ and D, until two years ago. Of 
 course, any architecture regarding that topic is of interest.

 Have you already made such experience or do you know people who 
 have and maybe even wrote articles about?

 Many thanks in advance!

Whatever the object oriented language you use, you can keep 
exactly the same global game architecture, using more or less the 
same classes for your game subsystems and gameplay elements.

Therefore, as an old game industry veteran, I confirm what you 
already know, which is that it's all about memory allocation, 
access and deallocation when comparing a game made in C++, D or 
Rust.

I'm not saying that other matters are not important, but many 
game development directors apply Bertrand Meyer's architectural 
advices (design by contract with pre/post condition assertions, 
etc) since the early nineties, so there is not much difference 
between a C++ game and a D/Rust game in this area.


So all that remains in the end are just concurrency and 
memory-related features, like immutable data, array memory 
slicing, automatic array bound and null pointer checking, object 
destruction and deallocation through variable scope and garbage 
collection, etc.

This of course includes interfacing with C/C++, i.e. managing the 
memory and lifecycle of C/C++ structs/objects from D or Rust.

With D, my biggest concern was about avoiding the application 
thread to freeze during a GC, while C++ and Rust can completely 
ignore this problem.

IMHO just these last points could already explain why Rust and 
C++ still remain preferred to D for game development...

Dgame <r.schuett.1987 gmail.com> writes:

On Saturday, 1 July 2017 at 21:00:14 UTC, Ecstatic Coder wrote:
 Whatever the object oriented language you use, you can keep 
 exactly the same global game architecture, using more or less 
 the same classes for your game subsystems and gameplay elements.

 Therefore, as an old game industry veteran, I confirm what you 
 already know, which is that it's all about memory allocation, 
 access and deallocation when comparing a game made in C++, D or 
 Rust.

 I'm not saying that other matters are not important, but many 
 game development directors apply Bertrand Meyer's architectural 
 advices (design by contract with pre/post condition assertions, 
 etc) since the early nineties, so there is not much difference 
 between a C++ game and a D/Rust game in this area.


 So all that remains in the end are just concurrency and 
 memory-related features, like immutable data, array memory 
 slicing, automatic array bound and null pointer checking, 
 object destruction and deallocation through variable scope and 
 garbage collection, etc.

 This of course includes interfacing with C/C++, i.e. managing 
 the memory and lifecycle of C/C++ structs/objects from D or 
 Rust.

 With D, my biggest concern was about avoiding the application 
 thread to freeze during a GC, while C++ and Rust can completely 
 ignore this problem.

 IMHO just these last points could already explain why Rust and 
 C++ still remain preferred to D for game development...

That's a good statement which I found very often recently. Maybe 
I should change my main focus from architecture to 
software-engineering per se...
Maybe an comparison between different software-products (one in 
an insecure  and one in a secure programming language) to show 
the difference and potential vulnerabilities.

Ecstatic Coder <ecstatic.coder gmail.com> writes:

 Maybe an comparison between different software-products (one in 
 an insecure  and one in a secure programming language) to show 
 the difference and potential vulnerabilities.

Maybe changing the application domain could give you a better 
dissertation axis for your thesis.

For instance comparing the architecture and implementation 
details of the same game server application implemented in 
languages like C++, Rust, D, Go, Java, etc.

As any web-related application, a game server executable MUST be 
BOTH safe and robust, there is no other choice, it must be able 
to run for days and weeks without crashing, resisting to low 
memory conditions, network saturation, connection attacks, etc.

Ecstatic Coder <ecstatic.coder gmail.com> writes:

 Maybe changing the application domain could give you a better 
 dissertation axis for your thesis.

 For instance comparing the architecture and implementation 
 details of the same game server application implemented in 
 languages like C++, Rust, D, Go, Java, etc.

 As any web-related application, a game server executable MUST 
 be BOTH safe and robust, there is no other choice, it must be 
 able to run for days and weeks without crashing, resisting to 
 low memory conditions, network saturation, connection attacks, 
 etc.

Btw that doesn't mean you should not implement the SDL game 
client with these same languages.

I'm just saying that implementing the server side too, with a 
simple communication protocol allowing for instance the game to 
submit the player highscores, could give you a broader perpective 
for the safety and security problems.