Re: Struct default constructor - need some kind of solution for C++ interop
Presence of compile-time valid T.init for any type T is absolutely critical for generic programming and must not be compromised.
Re: Let's kill 80bit real at CTFE
On 9 September 2016 at 21:50, Stefan Koch via Digitalmars-d wrote: > Hi, > > In short 80bit real are a real pain to support cross-platform. > emulating them in software is prohibitively slow, and more importantly hard > to get right. > 64bit floating-point numbers are supported on more architectures and are > much better supported. > They are also trivial to use at ctfe. > I vote for killing the 80bit handling at constant folding. > > Destroy! I just want CTFE '^^'. Please, can we have that? It's impossible to CTFE any non-linear function. It's ridiculous, I constantly want to generate a curve at compile time!
Re: Let's kill 80bit real at CTFE
On Friday, 9 September 2016 at 11:50:08 UTC, Stefan Koch wrote: Hi, In short 80bit real are a real pain to support cross-platform. emulating them in software is prohibitively slow, Supposedly, well-optimized 128-bit software floating-point is actually a bit faster than hardware 80-bit. (Intel keeps 80-bit around primarily for backwards compatibility, and hasn't put much effort or die space into improving its hardware speed in many years.) and more importantly hard to get right. 64bit floating-point numbers are supported on more architectures and are much better supported. They are also trivial to use at ctfe. I vote for killing the 80bit handling at constant folding. Destroy! This has been debated to death in the past. Reducing the maximum precision is not an acceptable option, but 80-bit could potentially be replaced by a software 128-bit implementation if that helps.
Voldemort Types on Reddit
https://www.reddit.com/r/programming/comments/523hm3/til_the_d_language_has_a_voldemort_type/
Re: Templates do maybe not need to be that slow (no promises)
On Friday, 9 September 2016 at 07:56:04 UTC, Stefan Koch wrote: There is a direct linear relationship between the generated code and the template body. So If the range of change inside the template body can be linked to the changed range in the binray and we link this to the template parameters we can produce a pure function that can give us the change in the binary code when provided with the template parameters. And the need to rerun the instanciation and code-gen is reduced to just the changed sections. I am not yet sure if this is viable to implement. I think I have found a way to avoid subtree-comparisons for the most part and speed them up significantly for the rest. At the expense of limiting the number of compile-time entities (types, expressions ... anything) to a maximum 2^(28) (When using a 64bit id)
Any video transcoding lib like this?
Hello community, has anyone done a lib published/unpublihed in D
like https://github.com/senko/python-video-converter . It was
developed in python and uses ffmpeg behind the scene.
It works this way;
from converter import Converter
c = Converter()
info = c.probe('test1.ogg')
conv = c.convert('test1.ogg', '/tmp/output.mkv', {
'format': 'mkv',
'audio': {
'codec': 'mp3',
'samplerate': 11025,
'channels': 2
},
'video': {
'codec': 'h264',
'width': 720,
'height': 400,
'fps': 15
}})
for timecode in conv:
print "Converting (%f) ...\r" % timecode
Re: Struct default constructor - need some kind of solution for C++ interop
On Wednesday, 7 September 2016 at 11:20:18 UTC, Lodovico Giaretta wrote: I guess the only thing you can ask and obtain here (I mean, with a bug report) is that @disable this() should be allowed to coexist with static opCall(). That would prevent your users from instantiating structs the wrong way (both nested in other structs and on the stack). Or perhaps explicit this() could be allowed if we have `@disable S init` defined for S: S s; // error, S.init is disabled S s = S(); // OK So how would this deal with Walter's 4 axioms: 1. So S.init is a valid initializer No, S.init is disallowed. Any code that needs it should fail to compile. 2. So all instances of S can be guaranteed to contain a valid instance Yes, because the only instances that exist are those explicitly constructed by constructor call. 3. So default initialization is guaranteed to succeed No, this is disallowed (see 1). 4. So any struct constructor starts with a valid state This can be handled by initializing fields to their respective .init values before any constructor of S is called.
Re: Struct default constructor - need some kind of solution for C++ interop
On Saturday, 10 September 2016 at 08:26:44 UTC, rikki cattermole wrote: Is there a good example library for this that does not involve a full blown (game)framework? Not that I'm aware of.
Re: Struct default constructor - need some kind of solution for C++ interop
On 10/09/2016 8:22 PM, Ethan Watson wrote:
On Saturday, 10 September 2016 at 05:56:55 UTC, Marco Leise wrote:
But what about the parts of the code that handle the game
initialization before streaming starts? Is there no
config = new GameConfig("settings.ini");
or
db = new AssetDatabase("menu.pkg");
that perform I/O during construction and potentially display an
exception error messages ?
Everything streams. No exceptions. The only file operations provided to
game code at run time are asynchronous operations.
And if you exploit that correctly, this is one of those things that can
increase boot times, actually. Create your config/database/whatever
objects, request files, instead of initialising them all in order and
slowing down because of synchronous IO they all go to sleep and
streaming system can serve files up as quick as it gets them from disk.
Is there a good example library for this that does not involve a full
blown (game)framework?
Re: Struct default constructor - need some kind of solution for C++ interop
On Saturday, 10 September 2016 at 08:22:59 UTC, Ethan Watson wrote: And if you exploit that correctly, this is one of those things that can increase boot times, actually. *decrease boot times. Take that, edit button.
Re: Struct default constructor - need some kind of solution for C++ interop
On Saturday, 10 September 2016 at 05:56:55 UTC, Marco Leise wrote:
But what about the parts of the code that handle the game
initialization before streaming starts? Is there no
config = new GameConfig("settings.ini");
or
db = new AssetDatabase("menu.pkg");
that perform I/O during construction and potentially display an
exception error messages ?
Everything streams. No exceptions. The only file operations
provided to game code at run time are asynchronous operations.
And if you exploit that correctly, this is one of those things
that can increase boot times, actually. Create your
config/database/whatever objects, request files, instead of
initialising them all in order and slowing down because of
synchronous IO they all go to sleep and streaming system can
serve files up as quick as it gets them from disk.
