Re: Partial specialisation: howto? (in the right news group this time. *sigh*)
div0 wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks Simen, That's nicer than the chained static ifs. Is there anyway to get rid of the enum though? Using the enum is a pain as it means you have to edit that import anytime you need to create a specialistion. It's nearly impossible to answer your question without knowing what you're trying to achieve. For example, you're specializing on T... which means there are more template arguments. Is there anything differentiating the cases in those? Another candidate is a class hierarchy (or use of an interface) where createHandlerCode is defined in the base definition, and each inheriting class overrides the method.
Re: Partial specialisation: howto? (in the right news group this time. *sigh*)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason House wrote: div0 wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks Simen, That's nicer than the chained static ifs. Is there anyway to get rid of the enum though? Using the enum is a pain as it means you have to edit that import anytime you need to create a specialistion. It's nearly impossible to answer your question without knowing what you're trying to achieve. For example, you're specializing on T... which means there are more template arguments. Is there anything differentiating the cases in those? Another candidate is a class hierarchy (or use of an interface) where createHandlerCode is defined in the base definition, and each inheriting class overrides the method. I've just reread it and realised I deleted too much stuff for anybody to get what I was after. doh. But as per usual, I thought of a much easier way to do it about 10 minutes after I asked the question. Thanks for your responses though! :) - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKEEglT9LetA9XoXwRAt+wAJ9tdu/LdSan1W4+YPNtFRs9BcCATgCfTBIQ M+um8KGHgwngYTkQIvv1OGA= =tXiu -END PGP SIGNATURE-
Re: Partial specialisation: howto? (in the right news group this time. *sigh*)
div0 wrote:
Thanks Simen,
That's nicer than the chained static ifs.
Is there anyway to get rid of the enum though?
I would believe this to work:
template createHandlerCode( T... ) if ( is( T == msgRangeHdlr ) ) {
string format( ) {
return createMessageRangeHandler!(T).format();
}
}
template createHandlerCode( T... ) if ( is( T == msgHdlr ) ) {
string format( ) {
return createMessageHandler!(T).format();
}
}
template createHandlerCode( T... ) if ( is( T == cmdIdHdlr ) ) {
string format( ) {
return createCommandIdHandler!(T).format();
}
}
--
Simen
Comparing D structs
Structs can't easily be compared in C because of potential 'padding' inside the struct which may (or may not) exist. I was jut wondering if D somehow gets round this, and allows something like memcmp to easily compare two structs.
Re: Comparing D structs
On Sun, May 17, 2009 at 3:55 PM, Dan twinbe...@skytopia.com wrote: Structs can't easily be compared in C because of potential 'padding' inside the struct which may (or may not) exist. I was jut wondering if D somehow gets round this, and allows something like memcmp to easily compare two structs. As grauzone said, you just use == to compare them. D solves the issue with C's uninitialized holes by always initializing structs. Therefore the padding holes are always filled with 0s.
Re: Comparing D structs
That sounds great, and seems like yet another reason for me to switch to D (other than the removal of header files which always seemed like a kludge). Just for the record though, I think one can initialize/blank/calloc C structs too, but the problem is that some struct elements (of the same array) may have padding while others don't, or perhaps they have different size paddings. Dan Jarrett Billingsley Wrote: On Sun, May 17, 2009 at 3:55 PM, Dan twinbe...@skytopia.com wrote: Structs can't easily be compared in C because of potential 'padding' inside the struct which may (or may not) exist. I was jut wondering if D somehow gets round this, and allows something like memcmp to easily compare two structs. As grauzone said, you just use == to compare them. D solves the issue with C's uninitialized holes by always initializing structs. Therefore the padding holes are always filled with 0s.
Re: Comparing D structs
Dan wrote:
That sounds great, and seems like yet another reason for me to switch to D
(other than the removal of header files which always seemed like a kludge).
I heard that the compiler can change the padding bytes to non-null on
some occasions. For example, the compiler could treat member a as 32 bit
value when assigning it:
struct {
char a; //offset 0
int b; //offset 4
}
Nothing in the C standard says that the compiler has to preserve the
padding bytes between a and b. So I was told.
Just for the record though, I think one can initialize/blank/calloc C structs
too, but the problem is that some struct elements (of the same array) may have
padding while others don't, or perhaps they have different size paddings.
Not sure what you mean.
Sellecting randomly from a range
This is more a tutorial which I'll put up on a wiki, but one question I have is
why can't 0..8 work in a randomCover, and wouldn't it be nice to use regex for
creating a range ([A-Z] being all uppercase letters)?
Selecting randomly from a collection of elements is common and usually entails
selecting random numbers and making sure they haven't been used before. D2 has
several templated functions that when put together make this very easy.
The first thing to look at comes from std.random, randomCover(range, rnd). This
takes the range of items and creates a new range that is a random
representation of the elements.
Then found in std.range is take(count, range). This will give us the count
items from our range giving us yet another range. From here we are able to use
a foreach loop to grab each item, but what if we want to store this someplace
for latter use?
This brings us to std.algorithms where we find fill(range1, range2). It is
important to note that D arrays can be use as a range.
If we combine this with D's array slices you are able to fill the results from
two ranges. The code below is an example using all of this and selecting a
random number of elements from each list.
(If this ends up being poorly formatted I apologize
http://paste.dprogramming.com/dpi1a1wn )
import std.algorithm;
import std.random;
import std.range;
import std.stdio;
string[] list = [one, two, three, four, five];
string[] list2 = [1, 2, 3, 4, 5];
void main(string[] args) {
auto rnd = new Random(unpredictableSeed);
int count = uniform(1, list.length, rnd);
string[] result = new string[count*2];
fill(result[0..count], take(count, randomCover(list, rnd)));
fill(result[count..$], take(count, randomCover(list2, rnd)));
writeln(result);
}
Re: Comparing D structs
Jarrett Billingsley Wrote: On Sun, May 17, 2009 at 5:00 PM, Dan twinbe...@skytopia.com wrote: That sounds great, and seems like yet another reason for me to switch to D (other than the removal of header files which always seemed like a kludge). Just for the record though, I think one can initialize/blank/calloc C structs too, but the problem is that some struct elements (of the same array) may have padding while others don't, or perhaps they have different size paddings. Sure, you can calloc or memset a C struct. I've never heard of padding varying for different instances of the same struct type, but who knows. So much of C is implementation-defined.. Perhaps I'm mistaken there. However, going through about 5-10 results on Google, it would seem there's no real solution in C to compare structs of the same type, because of whatever issues the padding thing may do. If it was as simple as memset/calloc, I'm sure that would've been mentioned.
Re: D1/D2 co-install?
BCS wrote: Does anyone have a good solution to installing both D1 and D2 on the same system? Possible solutions: * Rename the D2 dmd binary to dmd2 and make sure it uses a different config file for each to use the right libs. * Install them in different directories and use a script to update your $PATH depending on if you want to use D1 or D2 * Create a script that uses a different version of dmd depending on what parameters you pass to it (eg dmd -1 or dmd -2). * The simplest solution would probably be something like the following (on non-windows OSes): alias dmd='/path/to/dmd1/binary/here' alias dmd2='/path/to/dmd2/binary/here' This will allow you to use dmd to compile D1 and dmd2 for D2.
Re: D1/D2 co-install?
BCS wrote: Does anyone have a good solution to installing both D1 and D2 on the same system? ~$ cd /usr/local/digitalmars/ digitalmars$ ls -l total 25216 drwxr-xr-x 9 root root 4096 2009-04-03 03:19 dmd1042 -rw-r--r-- 1 root root 7240365 2009-04-03 03:18 dmd.1.042.zip drwxr-xr-x 9 root root 4096 2009-04-20 13:32 dmd2029 -rw-rw-r-- 1 root root 9353643 2009-04-20 13:30 dmd.2.029.zip digitalmars$ cd ~$ grep dmd .bashrc alias dmd1=/usr/local/digitalmars/dmd1042/linux/bin/dmd alias dmd2=/usr/local/digitalmars/dmd2029/linux/bin/dmd ~$ Of course, using /home/georg/dcompilers/dmd1042 or whatever, would be the same, unless I want others to use D, too. (The zip files aren't of course needed, but that's as good a place as any to store them if I don't want to delete them after unzipping.) I don't add the dmd directories to the path, edit dmd.conf, or do anything else. Except, of course chmod +x dmd :-)
Re: D1/D2 co-install?
BCS wrote: Does anyone have a good solution to installing both D1 and D2 on the same system? I have... (goes to check) 10 different compilers on my system. There's \dmd\bin\dmd-default which is the only one on the PATH (and is basically a stable version of Tango and DMD). If I want to use the others, I use the full path to them. OR, you can use rebuild and configure it with extra compiler profiles, then use (for example): rebuild -dc=dmd-1.035 stuff -- Daniel
