Re: module std.regex
31-Dec-2013 00:03, Benji пишет: On Monday, 30 December 2013 at 19:27:43 UTC, Dmitry Olshansky wrote: 30-Dec-2013 22:08, Benji пишет: Hello, when I try to run following code: [snip] This is part of core developers discussion and isn't something easily tweaked (else it would've been already fixed). Thanks! Could be downgrading to 2.063 the solution? If 2.063 works for you, sure it can. -- Dmitry Olshansky
Re: A better way to write this function? (style question)
On 2013-12-30 23:51, John Colvin wrote: Anyway, the big problem I've hit is that AFAICT std.algorithm makes a complete mess of unicode and i can't find a byCodeUnit range anywhere in order to make it correct. There's a byGrapheme and a byCodePoint function in std.uni. It was recently added. -- /Jacob Carlborg
Re: How to organize using modules?
On 2013-12-31 07:01, Afshin wrote: Is it possible to describe modules in terms of packages (as found in Java)? The features that Java packages have that I can't seem to get in D are: 1) You can have classes that are in the same package, but kept in separate files. See below. 2) You can import many classes using the '*' syntax. You cannot do that in D. You can do something similar as described here: http://forum.dlang.org/thread/garueoxkjjqgqpqqh...@forum.dlang.org#post-sdueirvfgsxjtahmapla:40forum.dlang.org Is this possible in D? What I understand is that if I have ClassA and ClassB in Module1, and I want to keep the classes in separate files, then I have to use the following module statements: in ClassA: module Module1.ClassA; in ClassB: module Module1.ClassB; But now it becomes cumbersome to use the classes because now I have to import them explicitely: import Module1.ClassA; import Module1.ClassB; Yes, that's how it works in D. That's because in Java there's a one-to-one mapping of classes and files. In D you can have many classes (or other declarations) in the same file. I suggest you use this approach. If I wanted to use: import Module1; Then it seems I have to have ClassA and ClassB in the same D file. Am I missing something? -- /Jacob Carlborg
Re: How to organize using modules?
Afshin: in ClassA: module Module1.ClassA; in ClassB: module Module1.ClassB; In D module names usually start with a lowercase letter (usually they are all lowercase, because different file systems manage upper case letters in different ways). Bye, bearophile
Re: Slices, appending to arbitrary position
On Mon, 30 Dec 2013 18:40:24 -, Dfr defle...@yandex.ru wrote: Thank you for replies, i think here i can use assoc array, but sometimes it is not suitable because it is not preserve order. What order do you want it in? The index order? If so, iterating over aa.keys.sort() will give you the keys in that order, and you can use that key to get the value aa[key] etc. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Arrays of an interface
Hi all, hoping someone can help, I'm used to coding to interfaces and I'm using them very lightly in an application I'm writing (a CPP wrapper like SWIG, except in D). Every now and then I touch a piece of code which seems almost unrelated and then get a bunch of compile errors such as the following (Method is the interface, MethodImpl is the implementation): smidgen/ast/klass.d(108): Error: function smidgen.ast.klass.Klass.addMethod (Method method) is not callable using argument types (MethodImpl) smidgen/ast/klass.d(113): Error: function smidgen.ast.klass.Klass.addMethod (Method method) is not callable using argument types (MethodImpl) smidgen/ast/klass.d(293): Error: cannot append type smidgen.ast.method.Method to type Method[] smidgen/ast/klass.d(322): Error: forward reference to getAllWrappedMethods smidgen/ast/klass.d(360): Error: forward reference to type Method[] smidgen/ast/klass.d(360): Error: cannot implicitly convert expression (baseMethods) of type Method[] to Method[] smidgen/ast/klass.d(363): Error: cannot implicitly convert expression (baseKlass.methods) of type Method[] to Method[] smidgen/ast/klass.d(542): Error: forward reference to getAllWrappedMethods smidgen/ast/klass.d(636): Error: forward reference to getAllWrappedMethods smidgen/ast/klass.d(672): Error: forward reference to getAllWrappedMethods smidgen/ast/klass.d(15): Error: size of type Method is not known smidgen/ast/klass.d(709): Error: function smidgen.ast.klass.Klass.isCovariantMethod (Method otherMethod) is not callable using argument types (Method) smidgen/ast/klass.d(746): Error: forward reference to type Method[] smidgen/ast/klass.d(746): Error: cannot implicitly convert expression (allWrappedMethods) of type Method[] to Method[] I have a feeling that D doesn't fully support arrays of interfaces, e.g. Method[], particularly as a return type. Is there a better way to pass around lists of instances of an interface? I'm using DMD 2.064 on Linux 64bit, thanks
Re: Arrays of an interface
Abdulhaq: I have a feeling that D doesn't fully support arrays of interfaces, e.g. Method[], particularly as a return type. If that's true, than it seems a D bug worth fixing. Are you able and willing to create a minimized example (later useful for Bugzilla)? Bye, bearophile
Re: Slices, appending to arbitrary position
Regan Heath: What order do you want it in? The index order? If so, iterating over aa.keys.sort() will give you the keys in that order, and you can use that key to get the value aa[key] etc. I also suggested this: http://d.puremagic.com/issues/show_bug.cgi?id=10733 Bye, bearophile
Re: Arrays of an interface
On Tuesday, 31 December 2013 at 14:26:33 UTC, bearophile wrote: Abdulhaq: I have a feeling that D doesn't fully support arrays of interfaces, e.g. Method[], particularly as a return type. If that's true, than it seems a D bug worth fixing. Are you able and willing to create a minimized example (later useful for Bugzilla)? Bye, bearophile Honestly I'd like to do that but I'm pretty swamped ATM and I don't think a simple example is going to be easy to knock up. It might simply be a quirk somewhere in the code that's causing a load of spurious error messages. I'm going to try backing out my last change set and slowly reapply and see where it goes haywire, but I'm losing confidence in arrays of interfaces and really would like an alternative so that I can get coding on the real problem.
Re: Arrays of an interface
Can you post more of the code? Maybe MethodImpl forgot to inherit from Method or there's a const mismatch or something like that.
Re: Arrays of an interface
Sorry to reply to me own post so quickly, a clue (it seems to me)
is this part of the error:
smidgen/ast/klass.d(15): Error: size of type Method is not known
Line 15 is where I import the interface:
import smidgen.ast.method: Method, MethodImpl, Visibility, SMID;
and in the relevant file,
interface Method: ConverterManagerProvider {
bool virtual();
bool abstract_();
bool static_();
bool constructor();
bool destructor();
bool hasEllipsis();
bool const_();
bool transferBack();
etc...
Well, interfaces don't have sizes, do they? So does [] only
really work for classes?
Re: Arrays of an interface
On Tuesday, 31 December 2013 at 14:43:25 UTC, Abdulhaq wrote: Well, interfaces don't have sizes, do they? They have fixed size, interfaces are always implemented as pointers. Could be a forward reference problem, make sure you import the module with the interface above any use of it, and do a full import instead of a selective one and see what happens.
Re: Arrays of an interface
On Tuesday, 31 December 2013 at 14:54:31 UTC, Adam D. Ruppe wrote: On Tuesday, 31 December 2013 at 14:43:25 UTC, Abdulhaq wrote: Well, interfaces don't have sizes, do they? They have fixed size, interfaces are always implemented as pointers. Could be a forward reference problem, make sure you import the module with the interface above any use of it, and do a full import instead of a selective one and see what happens. Ah! Great, doing the full import fixed it. The interface precedes the implementation in the same file, so it seems to me it's possibly a subtle glitch in the compiler with selective imports (the change I was making was in another module where I was subclassing Klass, which was the class with the array on it). Thanks both for your speedy replies!
Re: Arrays of an interface
Abdulhaq: Ah! Great, doing the full import fixed it. The interface precedes the implementation in the same file, so it seems to me it's possibly a subtle glitch in the compiler with selective imports (the change I was making was in another module where I was subclassing Klass, which was the class with the array on it). Please create a reduced example that shows the problem, to be put in Bugzilla. Bye, bearophile
Re: A little DUB question
On Tuesday, 31 December 2013 at 10:42:35 UTC, ponce wrote: $ dub --build=release --combined I guess this is something very recent, latest binary version from http://code.dlang.org/download doesn't know this word yet.
DDOC- how to customize
In ddoc, if there is a way, how could I make, say, class names in the generated documentation be blue? Here I only want to change class and struct titles, and possibly enums; I'd also like to make functions be, say, green. (FWIW, I don't want to change the documentation text, only the titles.) -- Charles Hixson
Task to throw away string parts, use joiner and splitter not very successful
Hello, i have string like this.is.a.string and want to throw away some parts separated by dots, here is first attempt: name = this.is.a.string; // -- want to make this.is.a from this auto nameparts = splitter(name, '.'); auto name1 = joiner(nameparts[0 .. $-1], '.'); And got this error: Error: Result cannot be sliced with [] So, kinda fixed it (correct way?): name = this.is.a.string; auto nameparts = splitter(name, '.').array; auto name1 = joiner(nameparts[0 .. $-1], '.'); got this: Error: template std.algorithm.joiner does not match any function template declaration. Candidates are: /usr/include/dmd/phobos/std/algorithm.d(2846): std.algorithm.joiner(RoR, Separator)(RoR r, Separator sep) if (isInputRange!RoR isInputRange!(ElementType!RoR) isForwardRange!Separator is(ElementType!Separator : ElementType!(ElementType!RoR))) Stuck here, thank you for any help.
Re: Task to throw away string parts, use joiner and splitter not very successful
On Tuesday, 31 December 2013 at 20:49:55 UTC, Dfr wrote: Hello, i have string like this.is.a.string and want to throw away some parts separated by dots, here is first attempt: name = this.is.a.string; // -- want to make this.is.a from this auto nameparts = splitter(name, '.'); auto name1 = joiner(nameparts[0 .. $-1], '.'); And got this error: Error: Result cannot be sliced with [] So, kinda fixed it (correct way?): name = this.is.a.string; auto nameparts = splitter(name, '.').array; auto name1 = joiner(nameparts[0 .. $-1], '.'); got this: Error: template std.algorithm.joiner does not match any function template declaration. Candidates are: /usr/include/dmd/phobos/std/algorithm.d(2846): std.algorithm.joiner(RoR, Separator)(RoR r, Separator sep) if (isInputRange!RoR isInputRange!(ElementType!RoR) isForwardRange!Separator is(ElementType!Separator : ElementType!(ElementType!RoR))) Stuck here, thank you for any help. From your error message: isForwardRange!Separator Your separator is a character, which isn't a forward range. Try this: `auto name1 = joiner(nameparts[0 .. $-1], .);`
Re: Task to throw away string parts, use joiner and splitter not very successful
As Chris wrote, using double quotes to use strings instead of char
solves the typing issse.
I'd also suggest the following alternative, if you're going to discard a
lot of last elements in your code:
import std.stdio;
import std.algorithm;
import std.array;
import std.range;
/// Return seq without its last element.
auto poppedBack (T) (T seq) if (isInputRange!T) {
seq.popBack; // Discards the last element.
return seq;
}
void main () {
// Prints this.is.a.
this.is.a.string
.splitter (.)
.poppedBack
.joiner (.)
.array
.writeln;
}
On 12/31/2013 09:57 PM, Chris Cain wrote:
On Tuesday, 31 December 2013 at 20:49:55 UTC, Dfr wrote:
Hello, i have string like this.is.a.string and want to throw away
some parts separated by dots, here is first attempt:
name = this.is.a.string; // -- want to make this.is.a from this
auto nameparts = splitter(name, '.');
auto name1 = joiner(nameparts[0 .. $-1], '.');
And got this error: Error: Result cannot be sliced with []
So, kinda fixed it (correct way?):
name = this.is.a.string;
auto nameparts = splitter(name, '.').array;
auto name1 = joiner(nameparts[0 .. $-1], '.');
got this:
Error: template std.algorithm.joiner does not match any function
template declaration. Candidates are:
/usr/include/dmd/phobos/std/algorithm.d(2846):
std.algorithm.joiner(RoR, Separator)(RoR r, Separator sep) if
(isInputRange!RoR isInputRange!(ElementType!RoR)
isForwardRange!Separator is(ElementType!Separator :
ElementType!(ElementType!RoR)))
Stuck here, thank you for any help.
From your error message: isForwardRange!Separator
Your separator is a character, which isn't a forward range. Try this:
`auto name1 = joiner(nameparts[0 .. $-1], .);`
Re: DDOC- how to customize
On 12/31/2013 02:57 PM, Jonathan M Davis wrote: On Tuesday, December 31, 2013 12:33:06 Charles Hixson wrote: In ddoc, if there is a way, how could I make, say, class names in the generated documentation be blue? Here I only want to change class and struct titles, and possibly enums; I'd also like to make functions be, say, green. (FWIW, I don't want to change the documentation text, only the titles.) http://stackoverflow.com/questions/18672679/richer-coloring-and-typesetting-in-ddoc-output - Jonathan M Davis I'm definitely not an expert at html, but it looks as if that answer is saying You can't do it. ddoc considers class declarations and function declarations to be the same kind of thing. (I.e., it looks as if styles are defined in terms of level of indentation, h1, ..., h6.) I'm not real sure about this because, as I said, I'm not an html expert, and my css and javascript skills are only what carry over from other languages I happen to know. -- Charles Hixson
Re: Task to throw away string parts, use joiner and splitter not very successful
Chris Cain: From your error message: isForwardRange!Separator Your separator is a character, which isn't a forward range. Try this: `auto name1 = joiner(nameparts[0 .. $-1], .);` But splitting on a char is a common operation, and isn't it more efficient than splitting on a string? Bye, bearophile
Re: Interface abstraction
On Wednesday, 1 January 2014 at 00:31:03 UTC, Frustrated wrote: auto a = new B; // should return cast(A)(new B); A a = new B; case where a being of type B will hurt since it is always implicitly castable to type A. Right, it'll always be usable anyway.
Easy way to implement interface properties?
Is there an easy way to implement properties of an interface
within a class instead of having to duplicate almost the exact
same code with generic properties?
interface A
{
@property int data();
@property int data(int value);
}
class B : A
{
@property int data() { return m_data; } // read property
@property int data(int value) { return m_data = value; } //
write property
}
lots of duplicate info, specially when there are a lot of
properties, and changing anything in the interface requires
changing it in the class.
Instead I'd like to do something like
class B : A
{
implement!A;
}
where implement!A implements all the properties and functions in
A that are not already defined in B using simple methods(just
returning default values for functions and wrapping a field for
properties).
This way I can design the structural aspect of the software
without having to worry about implementation but still do some
basic testing. I can also slowly build up the functionality of
the code by implementing properties and functions without having
to worry about an all or nothing approach(or having to worry
about the original problem of code duplication).
Re: Interface abstraction
On Wednesday, 1 January 2014 at 00:31:58 UTC, Adam D. Ruppe wrote: On Wednesday, 1 January 2014 at 00:31:03 UTC, Frustrated wrote: auto a = new B; // should return cast(A)(new B); A a = new B; case where a being of type B will hurt since it is always implicitly castable to type A. Right, it'll always be usable anyway. I guess I was thinking just for consistency since I'll always being trying to use interfaces instead of classes. I guess it's not a big deal though. In setting up little test units I'll end up using the classes and auto but probably not in the full project where I'll use factories and such.
Re: Easy way to implement interface properties?
On Wednesday, 1 January 2014 at 00:48:13 UTC, Frustrated wrote:
Is there an easy way to implement properties of an interface
within a class instead of having to duplicate almost the exact
same code with generic properties?
interface A
{
@property int data() { return m_data; } // read property
@property int data(int value) { return m_data = value; } //
write property
}
Without access to some members, yes: make the methods final.
With (as in your case): Only with an abstract class or with a
mixin template.
Re: Easy way to implement interface properties?
On Wednesday, 1 January 2014 at 00:53:53 UTC, Namespace wrote:
On Wednesday, 1 January 2014 at 00:48:13 UTC, Frustrated wrote:
Is there an easy way to implement properties of an interface
within a class instead of having to duplicate almost the exact
same code with generic properties?
interface A
{
@property int data() { return m_data; } // read property
@property int data(int value) { return m_data = value; } //
write property
}
Without access to some members, yes: make the methods final.
With (as in your case): Only with an abstract class or with a
mixin template.
This was somehow posted before I finished.
Final is not the way I want to do it(I'll still have to write
code with it, but that's besides the point as it adds extra work
that is not necessary).
I simply need a way to build up the functionality of the code
instead of having to write a bunch of code that will change
anyways. One can't use interfaces directly(since they generally
contain no code) and one can't build up an interface full of code
since that defeats the purpose(just use classes in the first
place).
I just don't see any reason(and there is none, except to waste
time, or for love of typing) to implement default generic
behavior over and over when it can *easily* be automated.
Re: Easy way to implement interface properties?
On Wednesday, 1 January 2014 at 00:52:24 UTC, Frustrated wrote:
@property int data() { return m_data; } // read property
@property int data(int value) { return m_data = value; } //
write property
Put that stuff in a mixin template.
interface A {
@property int data();
@property int data(int value);
}
mixin template A_Impl() {
private int m_data;
@property int data() { return m_data; }
@property int data(int value) { return m_data = value; }
}
class B : A {
mixin A_Impl!();
}
where implement!A implements all the properties and functions
in A that are not already defined in B using simple methods
The mixin template handles this too:
class B : A {
mixin A_Impl!();
@property int data() { return m_data; }
@property int data(int value) { return m_data = value; }
}
There, it uses the property from the mixin, but B defines its own
property implementations. Something explicitly written in the
class definition overrides the item with the same name from the
mixin.
Here, this looks silly, but if you had several properties in the
mixin template, you could selectively customize just one while
reusing the others.
Note however that overloads don't cross this. So if class B only
implemented the getter, it would complain that the setter isn't
there: defining one function called data meant it didn't bring
in *any* data methods from the mixin. But all the others would
still be there.
This interface + impl mixin template is also how I'd recommend
doing multiple inheritance in D, you just do this same deal for
each one.
Re: A little DUB question
On Tuesday, 31 December 2013 at 10:42:35 UTC, ponce wrote: Looks like a bug. In the meantime you can compile combined. $ dub --build=release --combined Error executing command run: Failed to find a package named '--combined'.
Re: Easy way to implement interface properties?
On Wednesday, 1 January 2014 at 01:33:04 UTC, Frustrated wrote: But your template mixin is still duplicating generic code that should be easily handled automatically. (Generic properties are just wrappers around private fields that always have the same code (just return or set the field)) Oh yeah, that can be done too. Here's an example: http://arsdnet.net/dcode/autoimpl.d The mixin template is implemented by a helper function, which loops over the interface methods and builds a code string for it. It doesn't handle complex cases, like a setter without a getter, but it is a start. The pragma(msg) in there shows you the generated code when it compiles, which can help debugging or just show you what's going on, of course you can remove that when you're happy with it.
How do I choose the correct primative?
First, let me say that I am iextremely/i enthused about D. I
did research on it last year for a project and absolutely fell in
love with it. But praise should go in another thread...
My question comes down to:
Does dmd pack non-array primative variables in memory such that
they are touching, or are they zero-padded out to the computer's
native word size?
I have a fun little project I work on when I have time (for
which D is redicuosly perfect, BTW), and right now I am merely
listing the prototypes of functions that will comprise its API.
On my first go-through of the function protypes, I thoughtfully
figured out the smallest primatives I could safely use for inputs
and outputs. Obviously, when it comes to programming, I'm a
little OCD - who cares about memory to that degree anymore when
we have gigabytes of RAM? This might not even come into play on
the Raspberry Pi.
I also figured that choosing a safe minimum would make the code
more self-commented by queing the reader into what the expected
value range for the variable is.
Then I took Architecture Assembly class. There I learned that
the load instruction grabs an entire native word size, every
time, regardless of how many bits your variable takes up.
When we programmed in assembly in that class, for both
performance and coding ease, we only worked with variables that
were the native code size.
I found out that it's actually extra work for the processor to
use values smaller than the native word size: it has to AND off
the unwanted bits and possibly shift them over.
So, if dmd packs variables together, I would want to always use
the native word size to avoid that extra work, and I would never
want to use shorts, ints, or longs. Instead, I'd want to do this:
code
version (X86)
{
alias int native; //ints are 32-bit, the native size in this
case.
alias uint unative;
}
version (X86_64)
{
alias long native; //longs are 64-bit, the native size in this
case.
alias ulong unative;
}
/code
And then only use natives, unatives, and booleans (can't avoid
them) for my primatives.
I really hope this isn't the case because it would make D's
entire primative system pointless. In acedamia, C is often
scolded for its ints always being the native word size, while
Java is praised for being consistent from platform to platform.
But if dmd packs its variables, D is the one that should be
scolded and C is the one that should be praised for the same
reason of the opposite.
If, however, dmd always zero-pads its variables so that each load
instruction only grabs the desired value with no need of extra
work, I would never have to worry about whether my variable is
the native word size.
However, this knowledge would still affect my programming:
If I know my code will only ever be compiled for 32-bit machines
and up, I should never use shorts. Doing so would always waste at
least 16-bits per short. Even if I think I will never overflow a
short, why not just take the whole 32 bits; they're allocated for
the variable anyways; not using those bits would be wasteful.
Also, if I know I don't need anymore than 32 bits for a variable,
I should use an int, never a long. That way, the processor does
not have to do extra work on a 32-bit machine or a 64-bit machine
or any higher bitage. If I always default to longs like a good
acedemically trained computer scientist fighting crusades against
hard caps, 32-bit machines (and 64-bit machines still running
32-bit OSes!!!) would have to do extra work to work on 64-bit
values split across two native words.
And lastly, if I absolutely must have more than 32-bits for a
single value, I have no choice but to use a long.
So, I need to have this question answered to even get past the
function prototype stage - each answer would result in different
code.
Thank you very much,
I love D,
Jake
Re: How do I choose the correct primative?
On Wednesday, 1 January 2014 at 04:17:30 UTC, Jake Thomas wrote:
First, let me say that I am iextremely/i enthused about D.
I did research on it last year for a project and absolutely
fell in love with it. But praise should go in another thread...
My question comes down to:
Does dmd pack non-array primative variables in memory such
that they are touching, or are they zero-padded out to the
computer's native word size?
I have a fun little project I work on when I have time (for
which D is redicuosly perfect, BTW), and right now I am
merely listing the prototypes of functions that will comprise
its API.
On my first go-through of the function protypes, I thoughtfully
figured out the smallest primatives I could safely use for
inputs and outputs. Obviously, when it comes to programming,
I'm a little OCD - who cares about memory to that degree
anymore when we have gigabytes of RAM? This might not even come
into play on the Raspberry Pi.
I also figured that choosing a safe minimum would make the code
more self-commented by queing the reader into what the expected
value range for the variable is.
Then I took Architecture Assembly class. There I learned that
the load instruction grabs an entire native word size, every
time, regardless of how many bits your variable takes up.
When we programmed in assembly in that class, for both
performance and coding ease, we only worked with variables that
were the native code size.
I found out that it's actually extra work for the processor to
use values smaller than the native word size: it has to AND off
the unwanted bits and possibly shift them over.
So, if dmd packs variables together, I would want to always use
the native word size to avoid that extra work, and I would
never want to use shorts, ints, or longs. Instead, I'd want to
do this:
code
version (X86)
{
alias int native; //ints are 32-bit, the native size in this
case.
alias uint unative;
}
version (X86_64)
{
alias long native; //longs are 64-bit, the native size in
this case.
alias ulong unative;
}
/code
And then only use natives, unatives, and booleans (can't avoid
them) for my primatives.
I really hope this isn't the case because it would make D's
entire primative system pointless. In acedamia, C is often
scolded for its ints always being the native word size, while
Java is praised for being consistent from platform to platform.
But if dmd packs its variables, D is the one that should be
scolded and C is the one that should be praised for the same
reason of the opposite.
If, however, dmd always zero-pads its variables so that each
load instruction only grabs the desired value with no need of
extra work, I would never have to worry about whether my
variable is the native word size.
However, this knowledge would still affect my programming:
If I know my code will only ever be compiled for 32-bit
machines and up, I should never use shorts. Doing so would
always waste at least 16-bits per short. Even if I think I will
never overflow a short, why not just take the whole 32 bits;
they're allocated for the variable anyways; not using those
bits would be wasteful.
Also, if I know I don't need anymore than 32 bits for a
variable, I should use an int, never a long. That way, the
processor does not have to do extra work on a 32-bit machine or
a 64-bit machine or any higher bitage. If I always default to
longs like a good acedemically trained computer scientist
fighting crusades against hard caps, 32-bit machines (and
64-bit machines still running 32-bit OSes!!!) would have to do
extra work to work on 64-bit values split across two native
words.
And lastly, if I absolutely must have more than 32-bits for a
single value, I have no choice but to use a long.
So, I need to have this question answered to even get past the
function prototype stage - each answer would result in
different code.
Thank you very much,
I love D,
Jake
We have size_t defined as uint on 32bit and ulong on 64bit.
ptrdiff_t for int/long.
I don't know how dmd handles it, although you do have the ability
to align variables.
You may want to consider gdc or ldc more than dmd as they have
better optimization.
Converting char to int
I hope you'll forgive my asking an overly easy question: I've been searching for an answer and having trouble finding one, and am getting frustrated. My issue is this: I'm trying to convert character types to integers using to!int from std.conv, and I'm getting, for example, '0'-48, '1'-49, etc. It seems like there should be a simple way around this, but it's eluding me.
Re: Converting char to int
On Wednesday, 1 January 2014 at 06:21:05 UTC, Caeadas wrote: My issue is this: I'm trying to convert character types to integers using to!int from std.conv, and I'm getting, for example, '0'-48, '1'-49, etc. It seems like there should be a simple way around this, but it's eluding me. Well, in ASCII (as well as UTF-8 and many others) the character '0' is represented by number 48, character '1' is 49 etc., so if you want to convert '5' to 5 you just need to subtract '0's number from it, e.g. char c = ...; int x = c - '0';
Re: Converting char to int
On Wednesday, 1 January 2014 at 06:21:05 UTC, Caeadas wrote:
I hope you'll forgive my asking an overly easy question: I've
been searching for an answer and having trouble finding one, and
am getting frustrated.
My issue is this: I'm trying to convert character types to
integers using to!int from std.conv, and I'm getting, for
example, '0'-48, '1'-49, etc. It seems like there should be a
simple way around this, but it's eluding me.
Your code is working correctly. D's chars, for all values up to
255, are the same as the ASCII character set. If you look in the
ASCII table here: http://www.asciitable.com/ you will see that
'0' corresponds to 48, and '1' corresponds to 49. The easiest
solution that will fix your code is change to!int('0') and
to!int('1') to to!int(0) and to!int(1). It seems that for
characters the to! function just returns its ASCII value, but it
will definitely do what you want for strings. Strangely enough,
it doesn't seem like there's a function to do convert a character
to its numeric value in Phobos, but it's simple to implement.
int charToInt(char c)
{
return (c = 48 c = 57) ? cast(int)(c - 48) : -1;
}
void main()
{
assert(charToInt('0') == 0);
assert(charToInt('1') == 1);
assert(charToInt('9') == 9);
assert(charToInt('/') == -1);
assert(charToInt(':') == -1);
}
Re: Task to throw away string parts, use joiner and splitter not very successful
This is interesting, why i can't just do it simpler way ?
this.is.a.string
.splitter (.)
.popBack
.joiner (.)
.array
.writeln;
Because creating an extra function is not desired.
As Chris wrote, using double quotes to use strings instead of
char solves the typing issse.
I'd also suggest the following alternative, if you're going to
discard a lot of last elements in your code:
import std.stdio;
import std.algorithm;
import std.array;
import std.range;
/// Return seq without its last element.
auto poppedBack (T) (T seq) if (isInputRange!T) {
seq.popBack; // Discards the last element.
return seq;
}
void main () {
// Prints this.is.a.
this.is.a.string
.splitter (.)
.poppedBack
.joiner (.)
.array
.writeln;
}
On 12/31/2013 09:57 PM, Chris Cain wrote:
On Tuesday, 31 December 2013 at 20:49:55 UTC, Dfr wrote:
Hello, i have string like this.is.a.string and want to
throw away
some parts separated by dots, here is first attempt:
name = this.is.a.string; // -- want to make this.is.a
from this
auto nameparts = splitter(name, '.');
auto name1 = joiner(nameparts[0 .. $-1], '.');
And got this error: Error: Result cannot be sliced with []
So, kinda fixed it (correct way?):
name = this.is.a.string;
auto nameparts = splitter(name, '.').array;
auto name1 = joiner(nameparts[0 .. $-1], '.');
got this:
Error: template std.algorithm.joiner does not match any
function
template declaration. Candidates are:
/usr/include/dmd/phobos/std/algorithm.d(2846):
std.algorithm.joiner(RoR, Separator)(RoR r, Separator sep) if
(isInputRange!RoR isInputRange!(ElementType!RoR)
isForwardRange!Separator is(ElementType!Separator :
ElementType!(ElementType!RoR)))
Stuck here, thank you for any help.
From your error message: isForwardRange!Separator
Your separator is a character, which isn't a forward range.
Try this:
`auto name1 = joiner(nameparts[0 .. $-1], .);`
Determine if a member is a method
How does one determine if a member is a method and not anything else? Also, how does one get the exact code string of a member instead of having to piece it together from info from std.traits? (which requires a lot of work)?
Re: Task to throw away string parts, use joiner and splitter not very successful
And one more problem here: string name = test; auto nameparts = splitter(name, '.'); writeln(typeof(joiner(nameparts, .).array).stringof); This prints dchar[], but i need char[] or string, how to get my 'string' back ? On Tuesday, 31 December 2013 at 20:49:55 UTC, Dfr wrote: Hello, i have string like this.is.a.string and want to throw away some parts separated by dots, here is first attempt: name = this.is.a.string; // -- want to make this.is.a from this auto nameparts = splitter(name, '.'); auto name1 = joiner(nameparts[0 .. $-1], '.'); And got this error: Error: Result cannot be sliced with [] So, kinda fixed it (correct way?): name = this.is.a.string; auto nameparts = splitter(name, '.').array; auto name1 = joiner(nameparts[0 .. $-1], '.'); got this: Error: template std.algorithm.joiner does not match any function template declaration. Candidates are: /usr/include/dmd/phobos/std/algorithm.d(2846): std.algorithm.joiner(RoR, Separator)(RoR r, Separator sep) if (isInputRange!RoR isInputRange!(ElementType!RoR) isForwardRange!Separator is(ElementType!Separator : ElementType!(ElementType!RoR))) Stuck here, thank you for any help.
Re: Easy way to implement interface properties?
On Wednesday, 1 January 2014 at 01:55:19 UTC, Adam D. Ruppe wrote: On Wednesday, 1 January 2014 at 01:33:04 UTC, Frustrated wrote: But your template mixin is still duplicating generic code that should be easily handled automatically. (Generic properties are just wrappers around private fields that always have the same code (just return or set the field)) Oh yeah, that can be done too. Here's an example: http://arsdnet.net/dcode/autoimpl.d The mixin template is implemented by a helper function, which loops over the interface methods and builds a code string for it. It doesn't handle complex cases, like a setter without a getter, but it is a start. The pragma(msg) in there shows you the generated code when it compiles, which can help debugging or just show you what's going on, of course you can remove that when you're happy with it. This doesn't quite work(at least for me) and seems unstable. Doesn't get all the attributes(what if you have a safe property? And doesn't get methods. It is a start though
Re: Determine if a member is a method
Well, unashamedly copying from my own code, I have a template defined thusly: enum isMemberFunction(T, string member) = is(typeof(__traits(getMember, T.init, member)) == function); Where `T` is the type that `member` is a part of. You can also change `function` to any of class, interface, struct, enum, or union, do find out if the member is one of those. The only way I know of to determine if a member is a field though, is to determine that it is not a class, function, interface, struct, enum, or union. As to the second question, I suspect I'm failing at understanding what your asking, so I'll leave it to someone else (who's probably a bit more awake than I am) to answer that one. On 1/1/14, Frustrated c1514...@drdrb.com wrote: How does one determine if a member is a method and not anything else? Also, how does one get the exact code string of a member instead of having to piece it together from info from std.traits? (which requires a lot of work)?
