Re: no-arg constructor for structs (again)

2012-09-20 Thread Felix Hufnagel 

On Thursday, 20 September 2012 at 00:14:04 UTC, Jonathan M Davis
wrote:

On Thursday, September 20, 2012 00:12:04 Felix Hufnagel wrote:

isn't it even worse?

import std.stdio;
struct S
{
int i;
this(void* p = null){this.i = 5;}
}
void main()
{
//S l(); //gives a linker error
auto k = S();
writeln(k.i); //prints 0
}


Of course that generates a linker error. You just declared a 
function without

a body.

- Jonathan M Davis


sure, but it's a bit unexpected. do we need to be able to declare
empty functions?

but whats even more confusing: you are not allowed to declare an
no_arg constructor. but you are allowed to declare one where all
parameters have default parameters. but then, how to call it
without args? auto k = S(); doesn't work?

Re: no-arg constructor for structs (again)

2012-09-19 Thread Felix Hufnagel 

isn't it even worse?

import std.stdio;
struct S
{
int i;
this(void* p = null){this.i = 5;}
}
void main()
{
//S l(); //gives a linker error
auto k = S();
writeln(k.i); //prints 0
}

Re: New hash API: namespace

2012-06-25 Thread Felix Hufnagel 

+1 for
hashes into std.hash
and cryptographic primitives into std.crypto

and we should have a std.net (std.uri, std.socket, std.socketstream ,  
std.net.curl, ...),

std.io. for (Outbuffer, file, )
and probably std.database or something like that for (csv, json, xml, ...)

...


Am 25.06.2012, 17:31 Uhr, schrieb Jonathan M Davis jmdavisp...@gmx.com:


On Monday, June 25, 2012 12:24:44 Piotr Szturmaj wrote:

Jonathan M Davis wrote:
 On Monday, June 25, 2012 11:35:33 Johannes Pfau wrote:
 OK, so I understand std.util is probably not a good idea.

 So the candidates for the namespace are:
 * std.crypto.hash
 * std.checksum
 * std.crypto.hash and std.checksum
 * std.hash

 and the same with hash replaced by digest.
 So which one should we use?

 The previous discussions on this resulted in us going with  
std.hash.md5,
 std.hash.sha1, and std.hash.crc32. I don't see any reason to change  
that,

 and crypto was specifically _not_ chosen, because crc32 isn't
 cryptographically sound. But std.hash encompasses things quite nicely,
 since they're all hashes.
IMHO crypto should be chosen because beside of hashes there are other
cryptographic primitives (ciphers, PKI, MACs, etc.) and it would be nice
to have them in one place. std.hash is too narrow because when std gets
crypto there will be too many namespaces like std.ciphers, std.ssl,
std.mac. All of them will nicely fit in std.crypto or similar.

As you can see crypto isn't good candidate for checksums so another
package std.checksum is proposed. Likewise mixing checksums and
cryptographic hashes under one namespace (std.hash) isn't a right choice
IMO.

Having cryptographic primitives splitted to std.hash and std.crypto.*
isn't a good choice either.


Except that the same hashes could be used for either checksums or crypto  
stuff.
It makes no sense to sense to split them between two packages. And you  
could

probably get into arguments over whether any particular hash was
cryptographically sound, particularly since that can change over time,  
can't
it, given that at least part of what determines whether a hash is  
considered
cryptographically sound is how easy it is to break. SHA-1 may or may not  
be

considered cryptographically sound now, but it sure won't be forever, so
putting it in std.crypto would become decreasingly accurate over time.

So, as far as the hashes go, it makes the most sense IMHO to just stuff  
them
all in std.hash and be done with it. If we ever end up adding  
crypto-specific
stuff to Phobos, then that stuff can go in std.crypto, but the hashes  
are _not_
crypto-specific. They just so happen to be used in cryptography. They  
aren't

restricted to it.

- Jonathan M Davis



--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

Re: JPG and PNG decoder

2012-06-21 Thread Felix Hufnagel 
it's not that hard to write a baseline jpeg encoder. it's not harder than  
decoding.

there are many tutorials and examples online.




Am 17.06.2012, 09:55 Uhr, schrieb cal callumena...@gmail.com:


On Sunday, 17 June 2012 at 07:07:35 UTC, Philippe Sigaud wrote:

Still, I'm interested in writing a JPEG/PNG to disk from a
ubyte[3][][], or whatever.


Do you mean that you want to encode a ubyte array to disk as JPEG/PNG?  
Encoding a JPEG would be a bit of work I think, the format's kind of a  
monster. PNG should be easier, depending on how good you want the  
compression to be. If you don't care too much about compression level,  
you simply zlib compress the data, write it out by image row/scanline,  
include appropriate header and chunk info, and you're done. I'll give a  
simple encoder a go if you think you could use it.


Cheers,
cal




--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

Re: Sharing your openGL Shader struct

2012-04-20 Thread Felix Hufnagel 

Dav1d has one : https://bitbucket.org/dav1d/glamour/overview

what we have in Derp:  
https://github.com/svenstaro/derp/blob/master/derp/graphics/shader.d

Re: Proposal: __traits(code, ...) and/or .codeof

2012-03-22 Thread Felix Hufnagel 
in addition to .codeof, let's think about .astof returning an abstract  
syntax tree.

Re: unittest ddoc.

2012-01-30 Thread Felix Hufnagel 

+1