Re: [Semi OT] Language for Game Development talk
Le 02/10/2014 08:22, Manu via Digitalmars-d a écrit : On 2 October 2014 00:16, bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote: Max Klyga: https://www.youtube.com/watch?v=TH9VCN6UkyQ A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Most gamedev's aren't quite as staunch as Mike Acton. The principle is there, ingrained in every gamedev, but that doesn't mean we all love flat C (although lots of us do!). I've never used RTTI, I've never used exceptions, certainly never use multiple inheritance, I rarely use templates (in C++)... but I'm still attracted to D!? I often find this strange... but not really. In D, I still don't use RTTI, I still don't use exceptions, I tend to box use of templates into their own worlds, so I would never use them pervasively (like phobos). You'll notice at one point that he talked about using offline text processing tools to do codegen... this is basically because C's preprocessor sucks, and C++ templates suck. D templates have proven to eliminate a lot of those offline tools for me. The code is kept in the same place, and built using the same tool. I suspect even Acton would appreciate features like CTFE. You'll also notice he made repeated reference to build environment complexity and build times. D also offers potential compiler advantages, purity, immutable, etc, which give the optimiser information which it can use to improve codegen which is awkward in C/C++. For the application I am working on the 3D developer wrote everything in c++ style, but he made a lot of mistakes that killing performances. We are far away cache miss issues (or polymorphism,...), and more in instancing ones. Last week I removed allocation and deallocation of meshes made in the sort for transparent models. new and delete aren't the main problem, it was the code in constructors and destructors that made heavy use of vectors. Things like vector.erase(vector.find(boo)); One my PC (a gamer one) I just win 20FPS from 10 to 30. For a scene of 700 objects ( 50 000 triangles). YEP this is really bad for my i7 and my 670GTX. I have a lot of work to do, normally on my PC for a such scene I can expect much more than 200 FPS. This is just one of our performances issues, and for me it's not due to only C++ OOP. It's about experience. I had never worked on games or applications need a level of optimization impose me SOA design but reusing chunk of memories and avoiding unnecessary computations are always things I carry on. For those are interested to see more about the application : https://groups.google.com/forum/#!forum/home-design-3d-beta This is also the one that inspired me and my friend for DQuick.
Re: [Semi OT] Language for Game Development talk
On 2 October 2014 00:16, bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote: Max Klyga: https://www.youtube.com/watch?v=TH9VCN6UkyQ A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Most gamedev's aren't quite as staunch as Mike Acton. The principle is there, ingrained in every gamedev, but that doesn't mean we all love flat C (although lots of us do!). I've never used RTTI, I've never used exceptions, certainly never use multiple inheritance, I rarely use templates (in C++)... but I'm still attracted to D!? I often find this strange... but not really. In D, I still don't use RTTI, I still don't use exceptions, I tend to box use of templates into their own worlds, so I would never use them pervasively (like phobos). You'll notice at one point that he talked about using offline text processing tools to do codegen... this is basically because C's preprocessor sucks, and C++ templates suck. D templates have proven to eliminate a lot of those offline tools for me. The code is kept in the same place, and built using the same tool. I suspect even Acton would appreciate features like CTFE. You'll also notice he made repeated reference to build environment complexity and build times. D also offers potential compiler advantages, purity, immutable, etc, which give the optimiser information which it can use to improve codegen which is awkward in C/C++.
Re: [Semi OT] Language for Game Development talk
On 2 October 2014 01:17, po via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote: Max Klyga: https://www.youtube.com/watch?v=TH9VCN6UkyQ A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Bye, bearophile He (deliberately I'd guess)conflates cache friendly data structures and access patterns with his particular preference for a C style. It is a fallacy that he presents as fact. He uses C style as an aggressive reminder of what you're actually trying to do at all times. We actually did this in our own engine long before he started giving lectures like this. One of the best ways to stop people doing insane shit in C++ is to ban C++. The engine dev's loved this commitment to C, but the game logic programmers hated us ;) There is a middle ground though...
Re: [Semi OT] Language for Game Development talk
On 2 October 2014 07:03, po via Digitalmars-d digitalmars-d@puremagic.com wrote: OOP style and AoS in general does cause cache unfriendly data access. You can separate out your hot and cold data but at that point you're not really programming in an OO style. He doesn't use RTTI, templates, exceptions, etc. for different reasons than cache friendliness. Modern C++ != OO style. I'd say modern C++ is more generic + functional than OO. He seems to think C++ is about programming in some sort of Java design pattern inspired way. That's what a post-grad often tends to do...
Re: [Semi OT] Language for Game Development talk
Max Klyga: https://www.youtube.com/watch?v=TH9VCN6UkyQ A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Bye, bearophile
Re: [Semi OT] Language for Game Development talk
On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote: Max Klyga: https://www.youtube.com/watch?v=TH9VCN6UkyQ A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Bye, bearophile He (deliberately I'd guess)conflates cache friendly data structures and access patterns with his particular preference for a C style. It is a fallacy that he presents as fact. The key to these type of fast code isn't the C style, it is the contiguous data layout, and cache friendly access patterns, both of which are easily enough to perform in modern C++.
Re: [Semi OT] Language for Game Development talk
On Wednesday, 1 October 2014 at 15:17:33 UTC, po wrote: On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote: Max Klyga: https://www.youtube.com/watch?v=TH9VCN6UkyQ A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Bye, bearophile He (deliberately I'd guess)conflates cache friendly data structures and access patterns with his particular preference for a C style. It is a fallacy that he presents as fact. The key to these type of fast code isn't the C style, it is the contiguous data layout, and cache friendly access patterns, both of which are easily enough to perform in modern C++. OOP style and AoS in general does cause cache unfriendly data access. You can separate out your hot and cold data but at that point you're not really programming in an OO style. He doesn't use RTTI, templates, exceptions, etc. for different reasons than cache friendliness. At what point does he say it's difficult to code in a SoA style in C++? He clearly states he sees no advantage to C++ over C.
Re: [Semi OT] Language for Game Development talk
I certainly believe C++ style and it's community promote the idea of zero overhead abstractions and the kind of OOP style which _does_ cause cache misses.
Re: [Semi OT] Language for Game Development talk
currysoup: At what point does he say it's difficult to code in a SoA style in C++? Perhaps a (part of) language more fit/helpful/nice for that purpose/use can be invented. Bye, bearophile
Re: [Semi OT] Language for Game Development talk
On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote: Max Klyga: https://www.youtube.com/watch?v=TH9VCN6UkyQ A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Probably because C++ is good enough and already has mature infrastructure.
Re: [Semi OT] Language for Game Development talk
Am 01.10.2014 17:40, schrieb currysoup: I certainly believe C++ style and it's community promote the idea of zero overhead abstractions and the kind of OOP style which _does_ cause cache misses. C++ does not imply OOP. And the zero overhead abstractions are a culture heritage from C as it was the only way to sell C++ to most C developers. -- Paulo
Re: [Semi OT] Language for Game Development talk
OOP style and AoS in general does cause cache unfriendly data access. You can separate out your hot and cold data but at that point you're not really programming in an OO style. He doesn't use RTTI, templates, exceptions, etc. for different reasons than cache friendliness. Modern C++ != OO style. I'd say modern C++ is more generic + functional than OO. He seems to think C++ is about programming in some sort of Java design pattern inspired way. At what point does he say it's difficult to code in a SoA style in C++? He clearly states he sees no advantage to C++ over C. 1. He references Design patterns during his tirade against C++, who the hell uses design patterns in C++ these days? 2. He uses Ogre, a 15 year old terrible mess of a rendering engine, written in a nasty Java style, as an example of why C++ is bad
Re: [Semi OT] Language for Game Development talk
On Wednesday, 1 October 2014 at 15:40:59 UTC, currysoup wrote: I certainly believe C++ style and it's community promote the idea of zero overhead abstractions and the kind of OOP style which _does_ cause cache misses. Take a look at the STL. See any OOP? Right cause there isn't any. Boost? Nope. C++ jumped off the OOP bandwagon some time ago.
Re: [Semi OT] Language for Game Development talk
Am 01.10.2014 23:03, schrieb po: OOP style and AoS in general does cause cache unfriendly data access. You can separate out your hot and cold data but at that point you're not really programming in an OO style. He doesn't use RTTI, templates, exceptions, etc. for different reasons than cache friendliness. Modern C++ != OO style. I'd say modern C++ is more generic + functional than OO. He seems to think C++ is about programming in some sort of Java design pattern inspired way. If he is stuck in the late 90's/early 2000's, yes. At what point does he say it's difficult to code in a SoA style in C++? He clearly states he sees no advantage to C++ over C. 1. He references Design patterns during his tirade against C++, who the hell uses design patterns in C++ these days? Those architects, specially the CORBA ones, are nowadays doing J2EE and WPF MVVM applications. And the original design patterns were actually targeted at Smalltalk, with C++ on the side as the language was started to get popular in the industry. 2. He uses Ogre, a 15 year old terrible mess of a rendering engine, written in a nasty Java style, as an example of why C++ is bad I never liked Ogre. A strange mix of OO with too much low level C like stuff still. At least when I looked at it a few years ago. -- Paulo
Re: [Semi OT] Language for Game Development talk
Perhaps a (part of) language more fit/helpful/nice for that
purpose/use can be invented.
Bye,
bearophile
It isn't as hard as he pretends to write SoA code in C++. In
fact it is possible to abstract the underlying data you are
operating on, and replace it with vector type
Example resembling his butt ugly code: operates only on 1 float
at a time
struct Vec2{
float x,y;
};
void Add2(Vec2* points, int howMany){
for(int i = 0;ihowMany;++i){
points[i].x += 2.0f;
points[i].x += 2.0f;
}
}
How I would do it, uses AVX256:
templateclass T
struct Vec2{
T x,y;
};
typedef Vec2float8 vec2_8f;
//float8 is a wrapper around AVX256 8 wide float type that
behaves exactly like a //normal float but is actually 8 floats.
void Add2(rangevec2_8f points){
for(auto p:points){
p += 2.0f;
}
}
C++ can abstract away the fact that float8 is actually
implemented using a bunch of AVX intrinsics. Using his approach
he'd be manually writing intrinsics until the cows came home.
Re: [Semi OT] Language for Game Development talk
Am 01.10.2014 23:16, schrieb po: On Wednesday, 1 October 2014 at 15:40:59 UTC, currysoup wrote: I certainly believe C++ style and it's community promote the idea of zero overhead abstractions and the kind of OOP style which _does_ cause cache misses. Take a look at the STL. See any OOP? Right cause there isn't any. Boost? Nope. I see lots of it. How many examples do you want? C++ jumped off the OOP bandwagon some time ago. That I agree. We have learned to not abuse hierarchies and to take advantage of the multi-paradigm capabilities of the language. -- Paulo
Re: [Semi OT] Language for Game Development talk
Take a look at the STL. See any OOP? Right cause there isn't any. Boost? Nope. I see lots of it. How many examples do you want? Well Boost might have some, I haven't looked at every library. I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL
Re: [Semi OT] Language for Game Development talk
Am 01.10.2014 23:44, schrieb po: Take a look at the STL. See any OOP? Right cause there isn't any. Boost? Nope. I see lots of it. How many examples do you want? Well Boost might have some, I haven't looked at every library. I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo
Re: [Semi OT] Language for Game Development talk
I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo According to Stepanov STL author: http://www.stlport.org/resources/StepanovUSA.html Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. I'd agree with him, just using a class, because it is the primary abstraction in C++, does not make your code OOP.
Re: [Semi OT] Language for Game Development talk
Am 02.10.2014 00:11, schrieb po: I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo According to Stepanov STL author: http://www.stlport.org/resources/StepanovUSA.html Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. I'd agree with him, just using a class, because it is the primary abstraction in C++, does not make your code OOP. Well I disagree with him and can find examples of static and dynamic polymorphism, data encapsulation and aggregation everywhere in STL, even if he dislikes OO people. Algorithms is probably the only part that is free of OO concepts. -- Paulo
Re: [Semi OT] Language for Game Development talk
On 2014-10-01 22:33:39 +, Paulo Pinto said: Am 02.10.2014 00:11, schrieb po: I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo According to Stepanov STL author: http://www.stlport.org/resources/StepanovUSA.html Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. I'd agree with him, just using a class, because it is the primary abstraction in C++, does not make your code OOP. Well I disagree with him and can find examples of static and dynamic polymorphism, data encapsulation and aggregation everywhere in STL, even if he dislikes OO people. Algorithms is probably the only part that is free of OO concepts. Data encapsulation is not unique to oop. STL is ADT not OOP.
Re: [Semi OT] Language for Game Development talk
Am 02.10.2014 01:07, schrieb Max Klyga: On 2014-10-01 22:33:39 +, Paulo Pinto said: Am 02.10.2014 00:11, schrieb po: I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo According to Stepanov STL author: http://www.stlport.org/resources/StepanovUSA.html Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. I'd agree with him, just using a class, because it is the primary abstraction in C++, does not make your code OOP. Well I disagree with him and can find examples of static and dynamic polymorphism, data encapsulation and aggregation everywhere in STL, even if he dislikes OO people. Algorithms is probably the only part that is free of OO concepts. Data encapsulation is not unique to oop. STL is ADT not OOP. STL was ADT when it was initially written in Ada 83, not any longer. First of all it doesn't exist any longer as such. The International Standard ISO/IEC 14882:2014(E) Programming Language C++ has zero occurrences of the word STL. ADT implies using modules, data structures and functions that operate on those functions. Which in C++ is achieved via separate compilation, namespaces and functions. Basically what Ada 83, Mesa and Modula-2, UCSD Pascal offered as abstraction for organizing algorithms and data structures. If a class is being used, then it already uses the first concept of OOP. Aggregation of data and member functions into a type. A module on steroids. The door is also open to inheritance and aggregation. If a class does not forbid inheritance, then it can have derived classes, even if the author did not intend it. Thus inheritance and dynamic polymorphism came into the picture. Two other OOP concepts. Finally, just for the fact that we have objects, member function invocations are now static dispatch. But if virtual methods are declared, then dynamic dispatch comes into play. Both properties of OOP systems. Given the way C++ allows for function overloading, static multi-method dispatch is also possible when used with NVO. Just because inheritance is not used, it doesn't mean something isn't OOP. There are much more concepts at play. When concepts lite come into the language, then C++ gains another way to deal with interfaces. Which will be used a lot in the standard library as well. As I mentioned in another post. I can easily provide examples of the C++ standard library classes and how they use OOP concepts. -- Paulo
Re: [Semi OT] Language for Game Development talk
On Saturday, 27 September 2014 at 10:01:05 UTC, Ola Fosheim Grøstad wrote: On Friday, 26 September 2014 at 21:19:29 UTC, Walter Bright wrote: I would. The whole point of destructors is to automatically clean up resources when the object goes away, which was (later) dubbed RAII. Yeah, but RAII takes it to the extreme where you create dummy classes that only consist of constructors/destructors so that the stack unwinding does all cleanup/closing/freeing without any try/catch. This is not necessary in D as we have scope statements. Before C++ templates that looked verbose and ugly syntactically, and it is still tedious if you only use the specific resource in one location. scope(exit) is often more transparent IMO. I guess this is matter of style and various tradeoff. A very common operation to rollback probably deserve its own RAII struct. An uncommon one is better served with scope.
Re: [Semi OT] Language for Game Development talk
On 2014-09-28 00:56, Walter Bright wrote: I see no gain from that syntax. It's very convenient especially when using range based programming. -- /Jacob Carlborg
Re: [Semi OT] Language for Game Development talk
On Saturday, 27 September 2014 at 22:06:00 UTC, H. S. Teoh via Digitalmars-d wrote: On Sat, Sep 27, 2014 at 02:51:14PM -0700, Walter Bright via Digitalmars-d wrote: [...] The only interesting thing is he describes a way that functions (and blocks) can specify what global data they access, and then have the compiler issue errors for accessing any other global data. He has a way to do that both locally and transitively. That sounds like PHP. *shudder* However, the same effect can be achieved via pure annotations and passing the globals needed by reference as function parameters. [...] I'm a fan of grouping related globals into structs with module level instances, and passed by reference to functions that need those specific globals. Truly-global globals are nasty, as are open sets of globals where you either don't access a global, or you (potentially) access *all* globals with no finer access granularity. (I had to debug C code that did that once... boy it was mind-bending when every function call could potentially arbitrarily change the global state.) T A fair amount of HPC code is still written in Fortran with a variables.f90 file that holds most program state as globals. Ick.
Re: [Semi OT] Language for Game Development talk
Walter Bright:
A feature without a solid rationale is no good in spite of how
many votes it has.
I agree that the number of votes alone means very little. But
perhaps those persons have reasons.
(If votes from people are not important, then better to remove
this feature from Bugzilla.)
D has a nice inline lamda syntax, which was needed. It is not
needed for separate functions.
The lambda syntax for function/class methods is not needed, but
it's handy and it's sufficiently natural, expecially for many
little methods. It's not an important feature, and there are D
features that I need far more than this (like syntax to unpack
tuples), but some people like it. Apparently C#6 designers agree
with that, search for Expression-bodied members here:
http://www.dotnetcurry.com/showarticle.aspx?ID=1042
The C#6 syntax is the same as the proposed one for D:
class Rectangle(int width, int height)
{
public int Area = width * height;
}
If the function is small enough that parameter setup time is
significant, it is likely to be inlined anyway which will erase
the penalty.
This is the theory :-) Sometimes I have seen this not to be true.
Then you really aren't encapsulating the globals the function
uses, anyway, and the feature is useless.
The point of having an @outer() is to enforce what module-level
names a function is using and how it is using them
(in/out/inout), so it's useful for _impure_ functions. If your
functions can be annotated with pure you don't need @outer much.
Being global variables, they are accessible from everywhere :-)
which is why they're an encapsulation problem in the first
place.
In D we have modules, so variables are module-level, or they are
imported from other modules (unfortunately names in a module are
public on default when you import the module. I'd like the
opposite, to be private to the module, and importable only if
they are tagged with public).
The problem with module-level variables is that sometimes I am
using by mistake a global variable when I am instead trying to
use a local one. Or on the opposite I am using a local variable
by mistake when I'd like to use a module-level one. An attribute
like pure disallows the access to global mutables, so it solves
only half of the problem. Generally knowing exactly what
module-level variables (and how) a function is using is very
handy to understand the purpose and working of the function
itself. So I see @outer() as a tool for code understanding, even
legacy code because I can add @outer() to old code written by
other persons.
- @outer is more DRY, because you don't need to specify the
type of the global
variable received by ref, you just need to know its name.
That's why gawd invented templates.
Templates are a blunt tool to solve the problems faced by
@outer(). @outer() allows you to specify for each variable if
it's going to just be read, written, or read-written. And
@outer() is not named @globals() because it works for inner
functions too, it allows to control and specify the access of
names from the outer scopes, so an inner impure nonstatic
function can use @outer() to specify what names it can use from
the scope of the outer function:
void foo() {
int x;
@outer(in x) void bar() {
writeln(x);
}
bar();
}
You can always wrap it with a template and pass the global by
alias.
I think I've never done this. To be tried.
Bye,
bearophile
Re: [Semi OT] Language for Game Development talk
On 9/28/2014 2:16 AM, bearophile wrote:
Walter Bright:
If the function is small enough that parameter setup time is significant, it
is likely to be inlined anyway which will erase the penalty.
This is the theory :-) Sometimes I have seen this not to be true.
Inlining is not a random thing. If there's a case that doesn't inline, ask
about it.
Then you really aren't encapsulating the globals the function uses, anyway,
and the feature is useless.
The point of having an @outer() is to enforce what module-level names a function
is using and how it is using them (in/out/inout), so it's useful for _impure_
functions. If your functions can be annotated with pure you don't need @outer
much.
@outer implies purity with a list of exceptions.
- @outer is more DRY, because you don't need to specify the type of the global
variable received by ref, you just need to know its name.
That's why gawd invented templates.
Templates are a blunt tool to solve the problems faced by @outer(). @outer()
allows you to specify for each variable if it's going to just be read, written,
or read-written.
Again, template functions do that rather nicely, and no type is required.
And @outer() is not named @globals() because it works for inner
functions too, it allows to control and specify the access of names from the
outer scopes, so an inner impure nonstatic function can use @outer() to specify
what names it can use from the scope of the outer function:
void foo() {
int x;
@outer(in x) void bar() {
writeln(x);
}
bar();
}
This I find to be a bit more lame, because the declarations used will be right
there. But if you really wanted to do it,
void foo() {
int x;
static void bar(int x) {
writeln(x);
}
bar(x);
}
Re: [Semi OT] Language for Game Development talk
His entire reason for not using C++ lambda, and wanting local functions instead, is faulty His reason: I heard they can perform heap allocation. Reality: No they do not perform heap allocation, that would only happen if you stuffed it into an std::function
Re: [Semi OT] Language for Game Development talk
Walter Bright:
Inlining is not a random thing. If there's a case that doesn't
inline, ask about it.
Even when you use annotations like forced_inline and the like
you can't be certain the compiler is doing what you ask for. I
have seen several critical template functions not inlined even by
ldc2 (dmd is usually worse). And if your function is in a
pre-compiled object where the source code is not available,
inlining doesn't happen.
@outer implies purity with a list of exceptions.
Right, an empty @outer() equals to the D weakly pure. But if
I put those exceptions then I am essentially stating that a
function is not pure. So you usually don't put @outer() on pure
functions.
Again, template functions do that rather nicely, and no type is
required.
I think templates are blunt tools for this purpose. But I will
try to use them for this purpose, to see how they fare. I think I
have not seen people use templates for this purpose, so I think
it's not very natural.
void foo() {
int x;
@outer(in x) void bar() {
writeln(x);
}
bar();
}
This I find to be a bit more lame, because the declarations
used will be right there.
Yes, and a module-level variable can be defined the line before
the function definition. Or it can be far from it (it can even be
from an imported module). The same is true for the variables
defined in the outer function. That's why I have named it @outer
instead of @globals. Even a large function is usually smaller
than a whole module (and modern coding practices suggest to avoid
very large functions), so the variable definition should be
closer (and in D it must be lexically before the definition of
the inner function), so the problems with module-level variables
is bigger, but it's similar.
But if you really wanted to do it,
void foo() {
int x;
static void bar(int x) {
writeln(x);
}
bar(x);
}
As you said, the same is possible with global variables, you can
often pass them as arguments, by value or by reference. I agree
that the case of using @outer() for inner functions is weaker.
Bye,
bearophile
Re: [Semi OT] Language for Game Development talk
On 9/28/2014 10:57 AM, po wrote: His entire reason for not using C++ lambda, and wanting local functions instead, is faulty His reason: I heard they can perform heap allocation. Reality: No they do not perform heap allocation, that would only happen if you stuffed it into an std::function D's will also do heap allocation, but only if you take the address of the local function.
Re: [Semi OT] Language for Game Development talk
On Sun, Sep 28, 2014 at 10:19:36AM -0700, Walter Bright via Digitalmars-d wrote:
[...]
Inlining is not a random thing. If there's a case that doesn't inline,
ask about it.
[...]
This is not directly related to this thread, but recently in a Phobos PR
we discovered the following case:
// This function gets inlined:
int func1(int a) {
if (someCondition) {
return value1;
} else {
return value2;
}
}
// But this one doesn't:
int func2(int a) {
if (someCondition) {
return value1;
}
return value2;
}
IIRC Kenji said something about the first case being convertible to an
expression, but the second can't. It would be nice if inlining worked
for both cases, since semantically they are the same.
T
--
Famous last words: I *think* this will work...
Re: [Semi OT] Language for Game Development talk
On 9/28/2014 1:25 PM, H. S. Teoh via Digitalmars-d wrote:
This is not directly related to this thread, but recently in a Phobos PR
we discovered the following case:
// This function gets inlined:
int func1(int a) {
if (someCondition) {
return value1;
} else {
return value2;
}
}
// But this one doesn't:
int func2(int a) {
if (someCondition) {
return value1;
}
return value2;
}
IIRC Kenji said something about the first case being convertible to an
expression, but the second can't. It would be nice if inlining worked
for both cases, since semantically they are the same.
https://issues.dlang.org/show_bug.cgi?id=7625
Re: [Semi OT] Language for Game Development talk
On 2014-09-27 02:47, Manu via Digitalmars-d wrote: Initialisation logic often looks like this, and I buy the value of exceptions in this case. However, I've never successfully implemented it yet though, because the calls that create code like that always seem to be extern-C calls in my experience... :/ Perhaps you should wrap those call an throw an exception. -- /Jacob Carlborg
Re: [Semi OT] Language for Game Development talk
On Friday, 26 September 2014 at 21:19:29 UTC, Walter Bright wrote: I would. The whole point of destructors is to automatically clean up resources when the object goes away, which was (later) dubbed RAII. Yeah, but RAII takes it to the extreme where you create dummy classes that only consist of constructors/destructors so that the stack unwinding does all cleanup/closing/freeing without any try/catch. Before C++ templates that looked verbose and ugly syntactically, and it is still tedious if you only use the specific resource in one location. scope(exit) is often more transparent IMO.
Re: [Semi OT] Language for Game Development talk
Am 26.09.2014 23:32, schrieb Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com: On Friday, 26 September 2014 at 20:48:20 UTC, Paulo Pinto wrote: I started coding C++ on MS-DOS in 1993 with Turbo C++ 1.0 all the way up to Turbo C++ 1.5 for Windows 3.x. Also used Borland C++ occasionally. I cannot remember any longer which version eventually added support for exceptions, but it was already a Windows 3.x version I would say. Watcom had some exception support around 1993 according to comp.lang.c++, but it was probably not a big selling point to add it for other vendors on the MS platforms. Watcom only became big on MS-DOS when they started offering a 32bit MS-DOS extender (remember those?). That feature, coupled with good code generation, made many game studios go for it. But that is the only thing I know from it. In Portugal, Borland and Microsoft ruled the MS-DOS developer tools. I remember it was very difficult to find a good free C++ implementation though. Cfront was kind of annoying (and did not support exceptions either). In the free software movement C/Unix was the real deal and my impression was that C++ was not viewed as cool, so it took a while for g++ to get the quality up to acceptable standards. Back in those days I got to buy my tools. Only knew what FOSS was about around 1995. In 1993 I got hold of Turbo C 2.0 and Turbo C++ 1.0, after a couple of years of doing Turbo Pascal, already with OOP using Turbo Vision. C just looked stone age when compared with Turbo Pascal 6.0 features and I immediately switched to C++ after a few months of pure C. Since then I have been on C++ troop ranks on the usual C vs C++ debates. The sad thing is that nowadays many new C++ programmers behave against languages with automatic memory management, the same way we were seen by C programmers in those days. You quite right about us not being cool in UNIX world. Outside of CORBA, it was always an uphill battle to use C++. Specially in the FOSS front. I wrote one of the first tutorials on how to use yacc/bison and lex/flex with C++ instead of C, as I could not find any. -- Paulo
Re: [Semi OT] Language for Game Development talk
On Saturday, 27 September 2014 at 09:32:19 UTC, Jacob Carlborg wrote: On 2014-09-27 02:47, Manu via Digitalmars-d wrote: Initialisation logic often looks like this, and I buy the value of exceptions in this case. However, I've never successfully implemented it yet though, because the calls that create code like that always seem to be extern-C calls in my experience... :/ Perhaps you should wrap those call an throw an exception. I often do something like this: proc(someFunc(a, b, c)); proc(anotherFunc(d, e, f)); Where proc() processes the return value and conditionally throws on error. You really need one such function per API, but that's not a big deal. You can kind of get away with macros if you're using C, but all they can really do is jump to an expected Lerror label.
Re: [Semi OT] Language for Game Development talk
On Friday, 19 September 2014 at 23:47:06 UTC, Max Klyga wrote: Jonathan Blow just recorded a talk about the needs and ideas for a programming language for game developer. https://www.youtube.com/watch?v=TH9VCN6UkyQ This talk mentions D quite a lot of times. D is mentioned as the most probable to be adopted if it were possible for frictionless interaction with existing codebase. An interesting talk if you want to look at language design from game developer perspective. The sequel: A Programming Language for Games, talk #2 https://www.youtube.com/watch?v=5Nc68IdNKdg
Re: [Semi OT] Language for Game Development talk
On 9/27/2014 9:35 AM, ponce wrote: The sequel: A Programming Language for Games, talk #2 https://www.youtube.com/watch?v=5Nc68IdNKdg Yeah, I watched it. He advocates: * pure functions * local functions * local functions with the same syntax as global functions * safety which defaults to off All of which D does right now. The only interesting thing is he describes a way that functions (and blocks) can specify what global data they access, and then have the compiler issue errors for accessing any other global data. He has a way to do that both locally and transitively. However, the same effect can be achieved via pure annotations and passing the globals needed by reference as function parameters. Based on his talks about what he wants in a language, I infer he's not looked at D beyond D has a GC, can't use it. -- Another thing I found interesting is I had assumed he'd given these talks at a conference. Not so. He simply set up a webcam in his office. It's a great method - we should look into doing that.
Re: [Semi OT] Language for Game Development talk
On Sat, Sep 27, 2014 at 02:51:14PM -0700, Walter Bright via Digitalmars-d wrote: [...] The only interesting thing is he describes a way that functions (and blocks) can specify what global data they access, and then have the compiler issue errors for accessing any other global data. He has a way to do that both locally and transitively. That sounds like PHP. *shudder* However, the same effect can be achieved via pure annotations and passing the globals needed by reference as function parameters. [...] I'm a fan of grouping related globals into structs with module level instances, and passed by reference to functions that need those specific globals. Truly-global globals are nasty, as are open sets of globals where you either don't access a global, or you (potentially) access *all* globals with no finer access granularity. (I had to debug C code that did that once... boy it was mind-bending when every function call could potentially arbitrarily change the global state.) T -- Computers are like a jungle: they have monitor lizards, rams, mice, c-moss, binary trees... and bugs.
Re: [Semi OT] Language for Game Development talk
Walter Bright:
* local functions with the same syntax as global functions
* safety which defaults to off
All of which D does right now.
It could be nice to have a syntax like lambdas for small
struct/class methods:
https://issues.dlang.org/show_bug.cgi?id=7176
struct Foo {
int bar(int x) pure { return x * x; }
}
Becomes something like::
struct Foo {
int bar = (int x) pure = x * x;
}
Ada2012 and C#6 have something like that (with a different
syntax).
The only interesting thing is he describes a way that functions
(and blocks) can specify what global data they access, and then
have the compiler issue errors for accessing any other global
data. He has a way to do that both locally and transitively.
Unwanted access of global variables is a common source of
troubles in my code. Time ago I suggested an optional @outer()
function annotation:
https://d.puremagic.com/issues/show_bug.cgi?id=5007
Bye,
bearophile
Re: [Semi OT] Language for Game Development talk
On 9/27/2014 3:30 PM, bearophile wrote:
Walter Bright:
* local functions with the same syntax as global functions
* safety which defaults to off
All of which D does right now.
It could be nice to have a syntax like lambdas for small struct/class methods:
https://issues.dlang.org/show_bug.cgi?id=7176
struct Foo {
int bar(int x) pure { return x * x; }
}
Becomes something like::
struct Foo {
int bar = (int x) pure = x * x;
}
I see no gain from that syntax.
Unwanted access of global variables is a common source of troubles in my code.
Time ago I suggested an optional @outer() function annotation:
https://d.puremagic.com/issues/show_bug.cgi?id=5007
I suggest using 'pure' and passing the globals you actually need as ref
parameters.
Re: [Semi OT] Language for Game Development talk
Walter Bright:
It could be nice to have a syntax like lambdas for small
struct/class methods:
https://issues.dlang.org/show_bug.cgi?id=7176
struct Foo {
int bar(int x) pure { return x * x; }
}
Becomes something like::
struct Foo {
int bar = (int x) pure = x * x;
}
I see no gain from that syntax.
Issue 7176 has currently seven votes, so someone seems to like it.
Now some D code is written in a functional style, this means many
function bodies are very small, and sometimes they contain just a
UFCS chain.
Usually editors (and Phobos style guides) format that bar
function like:
int bar(int x) pure
{
return x * x;
}
So now you have 4 lines instead of 1 line of the lambda-like
syntax. Generally the presence of a return is regarded as a
code smell in functional-style code.
I suggest using 'pure' and passing the globals you actually
need as ref parameters.
This is what I usually do in D, but it has some small
disadvantages:
- It increases the number of function arguments (they are 8 bytes
each), increasing the size of the function, adding some stack
management instructions. This slows the function a little, if the
function is performance-critical.
- Sometimes you can't use pure, for various reasons, like
Phobos functions not yet pure, I/O action in your function, or
other causes.
- If your pure function foo receives two global argument as out
and ref, the function bar that calls it needs to access to global
variables or it too needs those two ref/out arguments. The
current design of @outer() is not transitive, so only foo needs
to state what global variables are in/out/inout.
- @outer is more DRY, because you don't need to specify the type
of the global variable received by ref, you just need to know its
name.
- With @outer you can tighten some old code, without changing the
signature of a function. If you have an old D module (or a C
function converted to C) you often can't (or you don't want) to
change the function signature to add the global arguments passed
by ref. With @outer() the function signature doesn't change, so
you can improve your legacy code. It allows a simpler refactoring
of code.
More notes:
- SPARK language has added a feature similar to @outer, but more
verbose. See comment 5 in issue 5007.
- @outer() is optional and it's fiddly because not it's not meant
for small D script-like programs, it's meant as a help for
medium-integrity D programs (where you may think about using Ada
language instead).
Bye,
bearophile
Re: [Semi OT] Language for Game Development talk
On 9/27/2014 4:20 PM, bearophile wrote:
Walter Bright:
It could be nice to have a syntax like lambdas for small struct/class methods:
https://issues.dlang.org/show_bug.cgi?id=7176
struct Foo {
int bar(int x) pure { return x * x; }
}
Becomes something like::
struct Foo {
int bar = (int x) pure = x * x;
}
I see no gain from that syntax.
Issue 7176 has currently seven votes, so someone seems to like it.
A feature without a solid rationale is no good in spite of how many votes it
has.
Now some D code is written in a functional style, this means many function
bodies are very small, and sometimes they contain just a UFCS chain.
Usually editors (and Phobos style guides) format that bar function like:
int bar(int x) pure
{
return x * x;
}
So now you have 4 lines instead of 1 line of the lambda-like syntax. Generally
the presence of a return is regarded as a code smell in functional-style
code.
D has a nice inline lamda syntax, which was needed. It is not needed for
separate functions.
I suggest using 'pure' and passing the globals you actually need as ref
parameters.
This is what I usually do in D, but it has some small disadvantages:
- It increases the number of function arguments (they are 8 bytes each),
increasing the size of the function, adding some stack management instructions.
This slows the function a little, if the function is performance-critical.
If the function is small enough that parameter setup time is significant, it is
likely to be inlined anyway which will erase the penalty.
Such arguments can also be passed as template alias parameters, which are zero
cost.
- Sometimes you can't use pure, for various reasons, like Phobos functions not
yet pure, I/O action in your function, or other causes.
Then you really aren't encapsulating the globals the function uses, anyway, and
the feature is useless.
- If your pure function foo receives two global argument as out and ref, the
function bar that calls it needs to access to global variables or it too needs
those two ref/out arguments. The current design of @outer() is not transitive,
so only foo needs to state what global variables are in/out/inout.
Being global variables, they are accessible from everywhere :-) which is why
they're an encapsulation problem in the first place.
- @outer is more DRY, because you don't need to specify the type of the global
variable received by ref, you just need to know its name.
That's why gawd invented templates.
- With @outer you can tighten some old code, without changing the signature of a
function. If you have an old D module (or a C function converted to C) you often
can't (or you don't want) to change the function signature to add the global
arguments passed by ref. With @outer() the function signature doesn't change, so
you can improve your legacy code. It allows a simpler refactoring of code.
You can always wrap it with a template and pass the global by alias.
More notes:
- SPARK language has added a feature similar to @outer, but more verbose. See
comment 5 in issue 5007.
- @outer() is optional and it's fiddly because not it's not meant for small D
script-like programs, it's meant as a help for medium-integrity D programs
(where you may think about using Ada language instead).
Better encapsulation is intended for larger programs - I agree it is useless for
small ones.
Re: [Semi OT] Language for Game Development talk
On 09/28/2014 01:55 AM, Walter Bright wrote:
On 9/27/2014 4:20 PM, bearophile wrote:
Walter Bright:
It could be nice to have a syntax like lambdas for small
struct/class methods:
https://issues.dlang.org/show_bug.cgi?id=7176
struct Foo {
int bar(int x) pure { return x * x; }
}
Becomes something like::
struct Foo {
int bar(int x) pure = x * x; // fixed
}
I see no gain from that syntax.
Issue 7176 has currently seven votes, so someone seems to like it.
A feature without a solid rationale is no good in spite of how many
votes it has.
Uniform syntax for parameter list followed by function body.
(int x){ return 2; }
function(int x){ return 2; }
auto separate(int x){ return 2; }
(int x) = 2;
function(int x) = 2;
auto separate(int x) = 2;
auto curriedAdd(int x) = (int y) = x + y;
It is a simplification that is also convenient.
Re: [Semi OT] Language for Game Development talk
On 25/09/14 21:59, Walter Bright wrote: But I think it's a waste of time to develop a new language that has 98% overlap with existing ones, like if I proposed a language just like C but with member functions. It seems that people won't switch language, or rather create a new language, even though an existing would fit them, just because the existing one lacks one feature. It's like Yeah, D is great it has 9 of the features I need, but it lacks the 10th. Therefore I can't switch, even though the language I use now doesn't have any of these 10 features. -- /Jacob Carlborg
Re: [Semi OT] Language for Game Development talk
On 9/25/2014 11:34 PM, Jacob Carlborg wrote: On 25/09/14 21:59, Walter Bright wrote: But I think it's a waste of time to develop a new language that has 98% overlap with existing ones, like if I proposed a language just like C but with member functions. It seems that people won't switch language, or rather create a new language, even though an existing would fit them, just because the existing one lacks one feature. It's like Yeah, D is great it has 9 of the features I need, but it lacks the 10th. Therefore I can't switch, even though the language I use now doesn't have any of these 10 features. People get comfortable with the language they use, and switching languages takes work. But they don't want to say that, so they look for something to use as an excuse. It's perfectly human, and I'm guilty of it too :-)
Re: [Semi OT] Language for Game Development talk
On Thursday, 25 September 2014 at 18:38:36 UTC, Peter Alexander wrote: Only if you accept The Right Way philosophy. A Worse is Better person may disagree. There is no better, it's all tradeoffs. D already has a single allocation strategy built into the language: the `new` operator.
Re: [Semi OT] Language for Game Development talk
std::string tends to be more complicated because of the small string optimization. Most debuggers I've used don't handle that correctly out of the box, even if sorting it out really isn't difficult. Almost all game developers use Visual Studio, and VS has supported visualization of all STL containers(including string) since VS2005. This is really missing the point. He knows RAII is useful and he knows RAII solves freeing free'd memory. Maybe it's time to re-watch the video. I watched it. None of what he said made much sense. His claims: 1. RAII is bad because exceptions. -Nothing forces to use exceptions, so irrelevant 2. RAII is bad because you must write copy constructor,destructor etc each time. -No you write a few basic template classes and reuse them. Regarding exceptions, they can be used incorrectly, but I think they tend to provide better error handling than return codes *because no one ever checks return codes*. And when you do pathologically handle error codes, the amount of code duplication can be tremendous, and the chance for errors involving improper cleanup can be quite high. Though again, RAII can be of incredible use here. That is all true, I agree that exceptions are better than error codes. But for games, the general design is that errors are impossible. The game should never fail so exceptions serve little purpose. -ran out of memory? Shut game down, this should not happen -couldn't open a file? Shut game down, this should never happen -out of bounds array access, invalid iterator etc: abort game, found during development, fixed, should never happen. -networking? This is one place where you do need to handle errors, but do you need exceptions just to handle this one case? Probably not
Re: [Semi OT] Language for Game Development talk
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!
Re: [Semi OT] Language for Game Development talk
On Friday, 26 September 2014 at 07:24:48 UTC, po wrote: I watched it. None of what he said made much sense. His claims: 1. RAII is bad because exceptions. -Nothing forces to use exceptions, so irrelevant 2. RAII is bad because you must write copy constructor,destructor etc each time. -No you write a few basic template classes and reuse them. The way I interpreted him: - He does not want exceptions. - RAII makes most sense if you have exceptions. - He want to share views to memory blocks without RC - He needs debugging aids to resolve free() issues - He does not want to write new classes to manage resources (not only memory, but shaders etc). - Writing useful classes in C++ = tedious boilerplate. He might not say it explicitly, but he seemed to assume people to hold those views. So that probably means he usually works with people who code in the same patterns. -ran out of memory? Shut game down, this should not happen On IOS or PNaCl you might have to accept that it may happen...
Re: [Semi OT] Language for Game Development talk
- RAII makes most sense if you have exceptions. RAII is orthogonal to exceptions, so his claim is nonsense. - He does not want to write new classes to manage resources (not only memory, but shaders etc). I manage all resources using RAII, it did not require me to write a new RAII class for each resource type. I suspect he thinks that to implement RAII for a Mesh class you would need to create constructor/copy constructor/destructor. This is not how it is actually done. Instead the vertices/indices wrapped by an RAII template type. You can see on one slide he attempts to use std::unique_ptr but his syntax is completely wrong, a good indication he doesn't actually have any clue how this stuff works. - Writing useful classes in C++ = tedious boilerplate. I saw his claim, but again it is nonsense. In C++ we rarely if ever manually write copy constructor/move constructor/destructor. These are auto generated 99% of the time. His claim comes out of ignorance of how to properly use C++. He might not say it explicitly, but he seemed to assume people to hold those views. So that probably means he usually works with people who code in the same patterns. I've worked with people who think exactly like him. They are generally somewhat older, and started programming games in the 80/90's. I was not impressed by the coding ability of the individuals I met who had this mentality. If he updated his toolbox he might not have spent 5 years working on his latest game--
Re: [Semi OT] Language for Game Development talk
On Friday, 26 September 2014 at 08:59:04 UTC, po wrote: I've worked with people who think exactly like him. They are generally somewhat older, and started programming games in the 80/90's. I was not impressed by the coding ability of the individuals I met who had this mentality. I'm not surprised, but if you are going to create a language for current practices you have to cater to whatever the practice is. They are probably less eager to relearn how to use C/C++. I also think many just don't want to attempt to deal with C++ std:: libs, due to bad experience with them in the past. So they use their own stuff instead.
Re: [Semi OT] Language for Game Development talk
On Friday, 26 September 2014 at 08:59:04 UTC, po wrote: - RAII makes most sense if you have exceptions. RAII is orthogonal to exceptions, so his claim is nonsense. - He does not want to write new classes to manage resources (not only memory, but shaders etc). I manage all resources using RAII, it did not require me to write a new RAII class for each resource type. I suspect he thinks that to implement RAII for a Mesh class you would need to create constructor/copy constructor/destructor. This is not how it is actually done. Instead the vertices/indices wrapped by an RAII template type. You can see on one slide he attempts to use std::unique_ptr but his syntax is completely wrong, a good indication he doesn't actually have any clue how this stuff works. - Writing useful classes in C++ = tedious boilerplate. I saw his claim, but again it is nonsense. In C++ we rarely if ever manually write copy constructor/move constructor/destructor. These are auto generated 99% of the time. His claim comes out of ignorance of how to properly use C++. He might not say it explicitly, but he seemed to assume people to hold those views. So that probably means he usually works with people who code in the same patterns. I've worked with people who think exactly like him. They are generally somewhat older, and started programming games in the 80/90's. I was not impressed by the coding ability of the individuals I met who had this mentality. If he updated his toolbox he might not have spent 5 years working on his latest game-- And I also question his skills given that he admits the only programming book he has ever read was KR C. So most likely he has very fragile bases from googling around and stuff. -- Paulo
Re: [Semi OT] Language for Game Development talk
On Friday, 26 September 2014 at 08:59:04 UTC, po wrote: - RAII makes most sense if you have exceptions. RAII is orthogonal to exceptions, so his claim is nonsense. Just a note: this isn't really true. RAII was initially used to deal with exceptions. If you want fast backtracking and just reset the stack pointer (rather than unwinding) then stack-allocated RAII objects won't work since they will be overwritten. You need to maintain a list of destructors in thread local memory or close to the stack root so that you can close files etc. Whether RAII is the best option really depends on what kind of execution patterns and performance characteristics you are aiming for.
Re: [Semi OT] Language for Game Development talk
On Friday, 26 September 2014 at 09:24:19 UTC, Ola Fosheim Grøstad wrote: On Friday, 26 September 2014 at 08:59:04 UTC, po wrote: - RAII makes most sense if you have exceptions. RAII is orthogonal to exceptions, so his claim is nonsense. Just a note: this isn't really true. RAII was initially used to deal with exceptions. This is completely not true, we were using RAII in C++ before any compiler had real support for exceptions. In the 90's exceptions were still being discussed at ANSI/ISO with very few compiler offering support for them. And those that did, suffered from implementation bugs. -- Paulo
Re: [Semi OT] Language for Game Development talk
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.
Re: [Semi OT] Language for Game Development talk
On Friday, 26 September 2014 at 09:42:14 UTC, po wrote: Why would you reset the stack pointer? Keep in mind, nobody uses exceptions in games. No exceptions are going to be thrown in a game context. To backtrack quickly out of deep recursion, but I am not saying this is a typical use case or what JB referred to (hence it was just a side note). I think both RAII, finally, and more global manager-objects are reasonable solutions depending on the task.
Re: [Semi OT] Language for Game Development talk
On Friday, 26 September 2014 at 09:41:09 UTC, Paulo Pinto wrote: This is completely not true, we were using RAII in C++ before any compiler had real support for exceptions. Well, I haven't read the 1990 edition of the annotated C++ reference by Stroustrup and Ellis since the mid 90s so my memory may be clouded, but that is how I remember it. And wikipedia says the same: «The technique was developed for exception-safe resource management in C++[3] during 1984–89» http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
Re: [Semi OT] Language for Game Development talk
«The technique was developed for exception-safe resource
management in C++[3] during 1984–89»
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
It may have been developed for exceptions, that doesn't mean you
have to use them together.
Alternative error reporting methods I prefer:
-return optional type, is empty if it failed
-accept continuation of what to do once operation secedes
ie:
open_file(blah.txt,
[](file f){..}}//called when it opened
successfully
//could also have a 2nd lambda for when it fails
Re: [Semi OT] Language for Game Development talk
On Friday, 26 September 2014 at 10:01:32 UTC, Ola Fosheim Grøstad wrote: On Friday, 26 September 2014 at 09:41:09 UTC, Paulo Pinto wrote: This is completely not true, we were using RAII in C++ before any compiler had real support for exceptions. Well, I haven't read the 1990 edition of the annotated C++ reference by Stroustrup and Ellis since the mid 90s so my memory may be clouded, but that is how I remember it. And wikipedia says the same: «The technique was developed for exception-safe resource management in C++[3] during 1984–89» http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization I don't care what Wikipedia says, I was there in the early C++ days happily using Turbo and Borland C++ in MS-DOS. -- Paulo
Re: [Semi OT] Language for Game Development talk
On 26 September 2014 17:24, po via Digitalmars-d digitalmars-d@puremagic.com wrote: std::string tends to be more complicated because of the small string optimization. Most debuggers I've used don't handle that correctly out of the box, even if sorting it out really isn't difficult. Almost all game developers use Visual Studio, and VS has supported visualization of all STL containers(including string) since VS2005. This is really missing the point. He knows RAII is useful and he knows RAII solves freeing free'd memory. Maybe it's time to re-watch the video. I watched it. None of what he said made much sense. His claims: 1. RAII is bad because exceptions. -Nothing forces to use exceptions, so irrelevant 2. RAII is bad because you must write copy constructor,destructor etc each time. -No you write a few basic template classes and reuse them. Regarding exceptions, they can be used incorrectly, but I think they tend to provide better error handling than return codes *because no one ever checks return codes*. And when you do pathologically handle error codes, the amount of code duplication can be tremendous, and the chance for errors involving improper cleanup can be quite high. Though again, RAII can be of incredible use here. That is all true, I agree that exceptions are better than error codes. But for games, the general design is that errors are impossible. The game should never fail so exceptions serve little purpose. -ran out of memory? Shut game down, this should not happen -couldn't open a file? Shut game down, this should never happen -out of bounds array access, invalid iterator etc: abort game, found during development, fixed, should never happen. -networking? This is one place where you do need to handle errors, but do you need exceptions just to handle this one case? Probably not This. I've never used an exception before. I can't imagine a reason I would ever want to. Networking problems won't be solved with an exception, that requires very comprehensive logic.
Re: [Semi OT] Language for Game Development talk
On 2014-09-26 09:24, po wrote: -couldn't open a file? Shut game down, this should never happen It depends on what file it's trying to open and what the failure is. If it can't find the settings file, just recreate it and move on. Perhaps report the error to the user. -- /Jacob Carlborg
Re: [Semi OT] Language for Game Development talk
On 9/26/2014 8:21 AM, Manu via Digitalmars-d wrote: I've never used an exception before. I can't imagine a reason I would ever want to. Nothrow is your friend, then! BTW, you need exceptions if there appears in your code things like: if (errorHappened) goto LcleanupCode;
Re: [Semi OT] Language for Game Development talk
On 9/26/2014 2:11 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 26 September 2014 at 08:59:04 UTC, po wrote: I've worked with people who think exactly like him. They are generally somewhat older, and started programming games in the 80/90's. I was not impressed by the coding ability of the individuals I met who had this mentality. I'm not surprised, but if you are going to create a language for current practices you have to cater to whatever the practice is. They are probably less eager to relearn how to use C/C++. I also think many just don't want to attempt to deal with C++ std:: libs, due to bad experience with them in the past. So they use their own stuff instead. I can understand the attitude. I tend to do the same thing. Including invent another programming language :-)
Re: [Semi OT] Language for Game Development talk
On 9/26/2014 2:24 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 26 September 2014 at 08:59:04 UTC, po wrote: - RAII makes most sense if you have exceptions. RAII is orthogonal to exceptions, so his claim is nonsense. Just a note: this isn't really true. RAII was initially used to deal with exceptions. RAII existed in C++ years before exceptions.
Re: [Semi OT] Language for Game Development talk
Am 26.09.2014 20:46, schrieb Walter Bright: On 9/26/2014 4:02 AM, Paulo Pinto wrote: On Friday, 26 September 2014 at 10:01:32 UTC, Ola Fosheim Grøstad wrote: On Friday, 26 September 2014 at 09:41:09 UTC, Paulo Pinto wrote: This is completely not true, we were using RAII in C++ before any compiler had real support for exceptions. Well, I haven't read the 1990 edition of the annotated C++ reference by Stroustrup and Ellis since the mid 90s so my memory may be clouded, but that is how I remember it. And wikipedia says the same: «The technique was developed for exception-safe resource management in C++[3] during 1984–89» http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization I don't care what Wikipedia says, I was there in the early C++ days happily using Turbo and Borland C++ in MS-DOS. I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions. Bjarne's 1986 The C++ Programming Language does not mention RAII or exceptions, but does say on pg. 158: Calling constructors and destructors for static objects serves an extremely important function in C++. It is the way to ensure proper initialization and cleanup of data structures in libraries. This is what happens when people take for granted what Wikipedia says. At least in this regard, there are still people alive that lived through the events. -- Paulo
Re: [Semi OT] Language for Game Development talk
On 9/26/2014 4:02 AM, Paulo Pinto wrote: On Friday, 26 September 2014 at 10:01:32 UTC, Ola Fosheim Grøstad wrote: On Friday, 26 September 2014 at 09:41:09 UTC, Paulo Pinto wrote: This is completely not true, we were using RAII in C++ before any compiler had real support for exceptions. Well, I haven't read the 1990 edition of the annotated C++ reference by Stroustrup and Ellis since the mid 90s so my memory may be clouded, but that is how I remember it. And wikipedia says the same: «The technique was developed for exception-safe resource management in C++[3] during 1984–89» http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization I don't care what Wikipedia says, I was there in the early C++ days happily using Turbo and Borland C++ in MS-DOS. I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions. Bjarne's 1986 The C++ Programming Language does not mention RAII or exceptions, but does say on pg. 158: Calling constructors and destructors for static objects serves an extremely important function in C++. It is the way to ensure proper initialization and cleanup of data structures in libraries.
Re: [Semi OT] Language for Game Development talk
On Fri, Sep 26, 2014 at 08:50:06PM +0200, Paulo Pinto via Digitalmars-d wrote: Am 26.09.2014 20:46, schrieb Walter Bright: On 9/26/2014 4:02 AM, Paulo Pinto wrote: On Friday, 26 September 2014 at 10:01:32 UTC, Ola Fosheim Grøstad wrote: On Friday, 26 September 2014 at 09:41:09 UTC, Paulo Pinto wrote: This is completely not true, we were using RAII in C++ before any compiler had real support for exceptions. Well, I haven't read the 1990 edition of the annotated C++ reference by Stroustrup and Ellis since the mid 90s so my memory may be clouded, but that is how I remember it. And wikipedia says the same: «The technique was developed for exception-safe resource management in C++[3] during 1984–89» http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization I don't care what Wikipedia says, I was there in the early C++ days happily using Turbo and Borland C++ in MS-DOS. I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions. Bjarne's 1986 The C++ Programming Language does not mention RAII or exceptions, but does say on pg. 158: Calling constructors and destructors for static objects serves an extremely important function in C++. It is the way to ensure proper initialization and cleanup of data structures in libraries. This is what happens when people take for granted what Wikipedia says. At least in this regard, there are still people alive that lived through the events. [...] Then wikipedia should be edited to be more accurate, while said people are still alive!! Otherwise the distorted version of the events will come to be regarded as fact. T -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln
Re: [Semi OT] Language for Game Development talk
On Friday, 26 September 2014 at 18:46:19 UTC, Walter Bright wrote: I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions. Bjarne's 1986 The C++ Programming Language does not mention RAII or exceptions, but does say on pg. 158: Exceptions is chapter 15 in the 1990 edition. I should have it somewhere, a small brown hardcover and expensive!
Re: [Semi OT] Language for Game Development talk
On 9/26/2014 11:52 AM, H. S. Teoh via Digitalmars-d wrote: Then wikipedia should be edited to be more accurate, while said people are still alive!! Otherwise the distorted version of the events will come to be regarded as fact. I've been banned from editing Wikipedia for some reason. Someone else will have to do it :-(
Re: [Semi OT] Language for Game Development talk
On Fri, Sep 26, 2014 at 12:33:06PM -0700, Walter Bright via Digitalmars-d wrote: On 9/26/2014 11:52 AM, H. S. Teoh via Digitalmars-d wrote: Then wikipedia should be edited to be more accurate, while said people are still alive!! Otherwise the distorted version of the events will come to be regarded as fact. I've been banned from editing Wikipedia for some reason. What, why? Someone else will have to do it :-( I would, except that right now I'm working on a dmd PR. ;-) Do you have references to back up your claims (references deemed acceptable by WP)? Otherwise whatever I (or anyone else) put on there will just get reverted by the editors. Unfortunately, there are a few WP editors around who are overly draconian about deleting unreferenced material. (Got burned by them myself a few times -- drove me to put stuff on my own website instead, and then I discovered other people adding links to my website from WP and adding the stuff back on my behalf. Ahhh, sweet revenge. :-P) T -- Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.
Re: [Semi OT] Language for Game Development talk
On Friday, 26 September 2014 at 18:54:14 UTC, H. S. Teoh via Digitalmars-d wrote: Then wikipedia should be edited to be more accurate, while said people are still alive!! Otherwise the distorted version of the events will come to be regarded as fact. Stroustrup was planning for exceptions up till ARM in 1990 and RAII become an idiom through his writings. C++ compilers had ARM exception support at least by 1992/1993: HP, IBM, DEC, maybe SGI. (ARM is the base document for the ISO standard and was regarded as the c++ bible.) Those are not facts?
Re: [Semi OT] Language for Game Development talk
Am 26.09.2014 22:10, schrieb Ola Fosheim Grostad: On Friday, 26 September 2014 at 18:54:14 UTC, H. S. Teoh via Digitalmars-d wrote: Then wikipedia should be edited to be more accurate, while said people are still alive!! Otherwise the distorted version of the events will come to be regarded as fact. Stroustrup was planning for exceptions up till ARM in 1990 and RAII become an idiom through his writings. C++ compilers had ARM exception support at least by 1992/1993: HP, IBM, DEC, maybe SGI. (ARM is the base document for the ISO standard and was regarded as the c++ bible.) Those are not facts? Yes Stroustroup was planning for exceptions and maybe there were even some articles flying around in C++ Report and The C Users Journal. However, we were using MS-DOS systems networked via Novell Netware. I started coding C++ on MS-DOS in 1993 with Turbo C++ 1.0 all the way up to Turbo C++ 1.5 for Windows 3.x. Also used Borland C++ occasionally. I cannot remember any longer which version eventually added support for exceptions, but it was already a Windows 3.x version I would say. The early 90's in Portugal, meant no Internet and no BBS access outside Porto and Lisbon. We just learned on our own, by ourselves, reading books, magazines that sometimes lost their way into our small town or talking with our peers. RAII just seemed a natural way to use destructors. Specially since I was already using this pattern in Turbo Pascal 6.0. -- Paulo
Re: [Semi OT] Language for Game Development talk
On Friday, 26 September 2014 at 18:46:19 UTC, Walter Bright wrote: I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions. Lisp had exceptions in the 60s. In the 80s exception handling was fashionable in language design. :) Bjarne's 1986 The C++ Programming Language does not mention RAII or exceptions, but does say on pg. 158: Calling constructors and destructors for static objects serves an extremely important function in C++. It is the way to ensure proper initialization and cleanup of data structures in libraries. I would not call this RAII, but Simula67 did have the block prefixing idiom which I presume Stroustrup knew about. http://www.olejohandahl.info/papers/Birth-of-S.pdf RAII is a natural extension of block prefixing IMO. BETA, the follow up language to Simula, was developed in the 70s/80s and support RAII-style prefixing through the inner-statement. You can probably find many RAII-like idioms in various languages if you dig back in time, though.
Re: [Semi OT] Language for Game Development talk
On 9/26/2014 12:47 PM, H. S. Teoh via Digitalmars-d wrote: I would, except that right now I'm working on a dmd PR. ;-) No hurry. Do you have references to back up your claims (references deemed acceptable by WP)? Yes, I quoted from Bjarne's 1986 book The C++ Programming Language. Bjarne writes in Possible Directions for C++ he writes Because of destructors the C solution is insufficient and C++ will eventually be forced to develop an exception handling mechanism. -- Proceedings and Additional Papers C++ Workshop Santa Fe, NM, 1987 That's the first reference I can find to adding EH to C++. It does not propose any syntax. In 1988 and 1990 there are proposals for ways to add EH to C++.
Re: [Semi OT] Language for Game Development talk
On 9/26/2014 2:04 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 26 September 2014 at 18:46:19 UTC, Walter Bright wrote: I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions. Lisp had exceptions in the 60s. In the 80s exception handling was fashionable in language design. :) I meant in the context of C++. Bjarne's 1986 The C++ Programming Language does not mention RAII or exceptions, but does say on pg. 158: Calling constructors and destructors for static objects serves an extremely important function in C++. It is the way to ensure proper initialization and cleanup of data structures in libraries. I would not call this RAII, I would. The whole point of destructors is to automatically clean up resources when the object goes away, which was (later) dubbed RAII.
Re: [Semi OT] Language for Game Development talk
On Friday, 26 September 2014 at 20:48:20 UTC, Paulo Pinto wrote: I started coding C++ on MS-DOS in 1993 with Turbo C++ 1.0 all the way up to Turbo C++ 1.5 for Windows 3.x. Also used Borland C++ occasionally. I cannot remember any longer which version eventually added support for exceptions, but it was already a Windows 3.x version I would say. Watcom had some exception support around 1993 according to comp.lang.c++, but it was probably not a big selling point to add it for other vendors on the MS platforms. I remember it was very difficult to find a good free C++ implementation though. Cfront was kind of annoying (and did not support exceptions either). In the free software movement C/Unix was the real deal and my impression was that C++ was not viewed as cool, so it took a while for g++ to get the quality up to acceptable standards. My uni had DEC/SGI with C++, but at home where I preferred to do that type of programming I was stuck with C until g++ had improved by the mid 90s. And… of course… the uni did not teach C++ since it has a horrible design. I was only aware of one lecturer that had a C++ interest. I think they only had C++ available by accident (being part of a standard suite). The early 90's in Portugal, meant no Internet and no BBS access outside Porto and Lisbon. :-/ I did some BBSing in the late 80s, early 90s. It had a special feel to it, compared to the internet I think. More like a house/pub. I was lucky and got good Internet access at the university throughout the 90s (it was connected to ARPAnet/Internet already in 1973 so I think they gave it a high priority).
Re: [Semi OT] Language for Game Development talk
On Fri, 26 Sep 2014 11:52:21 -0700 H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: Then wikipedia should be edited to be more accurate, while said people are still alive!! Otherwise the distorted version of the events will come to be regarded as fact. it's very hard to introduce correct facts to wikipedia. the strange this is that it's very easy to introduce incorrect facts if they are looking normal. signature.asc Description: PGP signature
Re: [Semi OT] Language for Game Development talk
Walter Bright newshou...@digitalmars.com wrote: On 9/26/2014 8:21 AM, Manu via Digitalmars-d wrote: I've never used an exception before. I can't imagine a reason I would ever want to. Nothrow is your friend, then! BTW, you need exceptions if there appears in your code things like: if (errorHappened) goto LcleanupCode; No you need destructors/RAII/finally. And all those work equally with without exceptions (early return). Tobi
Re: [Semi OT] Language for Game Development talk
On Fri, Sep 26, 2014 at 09:32:54PM +, via Digitalmars-d wrote:
[...]
I remember it was very difficult to find a good free C++
implementation though. Cfront was kind of annoying (and did not
support exceptions either). In the free software movement C/Unix was
the real deal and my impression was that C++ was not viewed as cool,
so it took a while for g++ to get the quality up to acceptable
standards.
My uni had DEC/SGI with C++, but at home where I preferred to do that
type of programming I was stuck with C until g++ had improved by the
mid 90s. And… of course… the uni did not teach C++ since it has a
horrible design. I was only aware of one lecturer that had a C++
interest. I think they only had C++ available by accident (being part
of a standard suite).
[...]
Whoa, this brings back the memories! I remember taking a course in
college where the prof was teaching us this idiom, which by today's
standards is rather laughable (and probably no longer compiles -- this
dates back to before the first C++ standardization in 1998):
class MyClass {
...
MyClass Myclass(Myclass );
...
}
// Gotta love the audacious violation of DRY here:
MyClass MyClass::MyClass(MyClass mc)
{
...
return *this;
}
This was on g++ in the early to mid 90's, just around the time C++
templates first became widely available. I still remember trying both
c++ (the compiler, not the language) and g++, and perhaps one or two
other compilers installed on the lab compute servers, and finding that
one compiler would support new feature X but not new feature Y, but the
other compiler that supported feature Y had a buggy implementation of
feature X. So it was quite frustrating that many of the cool new
features couldn't be used together 'cos of buggy compiler
implementations. Not to mention subtle differences in dialect that
sometimes makes your projects uncompilable with another compiler. Fun
times.
T
--
People tell me I'm stubborn, but I refuse to accept it!
Re: [Semi OT] Language for Game Development talk
On 27 September 2014 04:20, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 9/26/2014 8:21 AM, Manu via Digitalmars-d wrote: I've never used an exception before. I can't imagine a reason I would ever want to. Nothrow is your friend, then! It certainly is. The only thing that ever ruins my nothrow-ness are phobos calls ;) BTW, you need exceptions if there appears in your code things like: if (errorHappened) goto LcleanupCode; Initialisation logic often looks like this, and I buy the value of exceptions in this case. However, I've never successfully implemented it yet though, because the calls that create code like that always seem to be extern-C calls in my experience... :/ I'm not sure why my D code doesn't manifest those patterns, D just seems to produce different code than C/C++...
Re: [Semi OT] Language for Game Development talk
On 25/09/14 06:18, Walter Bright wrote: This stood out for me. Deallocated how? People who write high perf software tend to have multiple allocators for different purposes. I don't think this feature will work. He says it's part of the same memory as the enclosing struct. I guess they would need to use the same allocator. -- /Jacob Carlborg
Re: [Semi OT] Language for Game Development talk
Walter Bright: This stood out for me. Deallocated how? Calling free when the struct instance goes out of scope, I presume. People who write high perf software tend to have multiple allocators for different purposes. I think that data is used all together, so it's reasonable to allocate it from a single allocator. I don't think this feature will work. I think he's already using this strategy in production code. So I think it works. He's just asking for a language feature that implements this idiom for him in a shorter and cleaner way. Bye, bearophile
Re: [Semi OT] Language for Game Development talk
On 9/25/2014 1:47 AM, bearophile wrote: This stood out for me. Deallocated how? Calling free when the struct instance goes out of scope, I presume. People who write high perf software tend to have multiple allocators for different purposes. I think that data is used all together, so it's reasonable to allocate it from a single allocator. I don't think this feature will work. I think he's already using this strategy in production code. So I think it works. He's just asking for a language feature that implements this idiom for him in a shorter and cleaner way. So how do you tell it to call myfree(p) instead of free(p) ?
Re: [Semi OT] Language for Game Development talk
On 9/19/2014 4:47 PM, Max Klyga wrote: Jonathan Blow just recorded a talk about the needs and ideas for a programming language for game developer. https://www.youtube.com/watch?v=TH9VCN6UkyQ This talk mentions D quite a lot of times. D is mentioned as the most probable to be adopted if it were possible for frictionless interaction with existing codebase. An interesting talk if you want to look at language design from game developer perspective. Looks like he reinvented D dynamic arrays at 1:02. Sigh.
Re: [Semi OT] Language for Game Development talk
Walter Bright: So how do you tell it to call myfree(p) instead of free(p) ? I think you can't in the form he has shown. He's far from being a good language designer, after all :-) Bye, bearophile
Re: [Semi OT] Language for Game Development talk
On 9/25/2014 2:27 AM, Walter Bright wrote: Looks like he reinvented D dynamic arrays at 1:02. Sigh. At 1:16 he gives credit to Go for the - and . becomes . thing. Says its great. And he wants: * D array declaration syntax. * consistently sized integer types * user defined attributes. * multiple files compiled at once. * permissive license. * nested comments * no preprocessor * insert files into the source code (mixins) * compile time function execution And ... ... he's specified D!
Re: [Semi OT] Language for Game Development talk
On 9/25/2014 2:32 AM, bearophile wrote: Walter Bright: So how do you tell it to call myfree(p) instead of free(p) ? I think you can't in the form he has shown. He's far from being a good language designer, after all :-) It's not as easy as it looks :-)
Re: [Semi OT] Language for Game Development talk
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).
Re: [Semi OT] Language for Game Development talk
On Thu, 25 Sep 2014 10:46:59 +
currysoup via Digitalmars-d digitalmars-d@puremagic.com wrote:
I quite like the idea of simple by default and you enable
features with annotations (@usegc, @throws, @pure).
@usegc will be major PITA. for example any function that does string
concatenation or format() will need this annotation. i see GC as
intergal and widely-used part of language, so @nogc is ok.
what we need though is @gc to allow things like this:
@nogc:
void foo () { ... some no-gc code ... }
void bar () @gc { ... some gc code ... }
to be able to mark the whole part of the code as @nogc but still allow
to write one or two @gc functions by the way.
ah, and the same for 'final'.
sure one can just move necessary definitions to top of the file (i.e.
they will appear before @nogc:), but this will hurt code readability.
signature.asc
Description: PGP signature
Re: [Semi OT] Language for Game Development talk
On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright wrote: So how do you tell it to call myfree(p) instead of free(p) ? Maybe stock malloc/free is enough for him?
Re: [Semi OT] Language for Game Development talk
On Thursday, 25 September 2014 at 10:47:00 UTC, currysoup wrote: D is really great and solves a lot of the issues raised in the video. A lot of D's features (GC in particular) become ugliness you've got to avoid. In addition all the @nogc, nothrow, pure, etc. becomes crufty. I'd say nothrow and pure are of marginal utility. @nogc can be just @nogc: at the top of a module. And the last piece is libraries.
Re: [Semi OT] Language for Game Development talk
On Thursday, 25 September 2014 at 09:58:31 UTC, Walter Bright wrote: On 9/25/2014 2:27 AM, Walter Bright wrote: Looks like he reinvented D dynamic arrays at 1:02. Sigh. At 1:16 he gives credit to Go for the - and . becomes . thing. Says its great. And he wants: snip And ... ... he's specified D! Almost, but he also wants a language with the Worse is Better philosophy. D does not have this, and I don't think we want it.
Re: [Semi OT] Language for Game Development talk
On Thursday, 25 September 2014 at 11:30:16 UTC, ketmar via
Digitalmars-d wrote:
On Thu, 25 Sep 2014 10:46:59 +
currysoup via Digitalmars-d digitalmars-d@puremagic.com wrote:
I quite like the idea of simple by default and you enable
features with annotations (@usegc, @throws, @pure).
@usegc will be major PITA. for example any function that does
string
concatenation or format() will need this annotation. i see GC as
intergal and widely-used part of language, so @nogc is ok.
what we need though is @gc to allow things like this:
@nogc:
void foo () { ... some no-gc code ... }
void bar () @gc { ... some gc code ... }
to be able to mark the whole part of the code as @nogc but
still allow
to write one or two @gc functions by the way.
ah, and the same for 'final'.
sure one can just move necessary definitions to top of the file
(i.e.
they will appear before @nogc:), but this will hurt code
readability.
I wasn't talking about D, just in general.
Re: [Semi OT] Language for Game Development talk
On Thu, 25 Sep 2014 12:16:16 + currysoup via Digitalmars-d digitalmars-d@puremagic.com wrote: I wasn't talking about D, just in general. sorry, it's my frustration speaks. ;-) signature.asc Description: PGP signature
Re: [Semi OT] Language for Game Development talk
On 9/25/14, 4:33 AM, Kagamin wrote: On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright wrote: So how do you tell it to call myfree(p) instead of free(p) ? Maybe stock malloc/free is enough for him? That kind of commitment shouldn't be baked into the language. That's why RAII and scope are better than his notation. -- Andrei
Re: [Semi OT] Language for Game Development talk
On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei Alexandrescu wrote: On 9/25/14, 4:33 AM, Kagamin wrote: On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright wrote: So how do you tell it to call myfree(p) instead of free(p) ? Maybe stock malloc/free is enough for him? That kind of commitment shouldn't be baked into the language. That's why RAII and scope are better than his notation. Allocation is orthogonal to RAII and scope. Allocation creates resource, RAII tracks it.
Re: [Semi OT] Language for Game Development talk
On 9/25/14, 8:12 AM, Kagamin wrote: On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei Alexandrescu wrote: On 9/25/14, 4:33 AM, Kagamin wrote: On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright wrote: So how do you tell it to call myfree(p) instead of free(p) ? Maybe stock malloc/free is enough for him? That kind of commitment shouldn't be baked into the language. That's why RAII and scope are better than his notation. Allocation is orthogonal to RAII and scope. Allocation creates resource, RAII tracks it. Affirmative. -- Andrei
Re: [Semi OT] Language for Game Development talk
On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei Alexandrescu wrote: On 9/25/14, 4:33 AM, Kagamin wrote: On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright wrote: So how do you tell it to call myfree(p) instead of free(p) ? Maybe stock malloc/free is enough for him? That kind of commitment shouldn't be baked into the language. That's why RAII and scope are better than his notation. -- Andrei Only if you accept The Right Way philosophy. A Worse is Better person may disagree. There is no better, it's all tradeoffs.
Re: [Semi OT] Language for Game Development talk
On 9/25/2014 3:46 AM, currysoup wrote: I quite like the idea of simple by default and you enable features with annotations (@usegc, @throws, @pure). I think simple by default doesn't have those annotations - by default meaning the code works. Those annotations all work to restrict what the code can do.
