Re: interface function overloading
%u: func(cast(I2)(new C())); That code smells a bit (http://en.wikipedia.org/wiki/Code_smell ). Bye, bearophile
Re: dmd compile with imported modules
I just compiled xfbuild on 32bit ubuntu, but when I try to compile, I get the following error: Build failed: /usr/include/d/dmd/druntime/import/core/stdc/errno.o: Invalid cross-device link. Does anyone know how to solve this problem?
Re: dmd compile with imported modules
I solved the problem by copying the source files from my shared vm- folder to my desktop in my vm.
Re: writef vs writeln and printing to the console
On 01/08/11 17:03, Jesse Phillips wrote: Andrej Mitrovic Wrote: Unfortunately I can't provide a simple test case, but I have a case where using: writef(..\n); inside a loop that runs a dozen times does not print out each line as the statement is reached, instead it prints out everything at once when the application is done. If I use this: writeln(.); then I get each line printed out at the exact moment as this statement is reached. Is this normal behavior? I don't think new line means to flush the buffer like it does in printf. I think you can use stdout.flush() from stdio; What Jesse said, but also: I can't help wondering if there's a special reason why you cannot (or would rather not) use writefln(.)? -- Chris N-S
Re: interface function overloading
== Quote from bearophile (bearophileh...@lycos.com)'s article
%u:
func(cast(I2)(new C()));
That code smells a bit (http://en.wikipedia.org/wiki/Code_smell ).
Bye,
bearophile
Extract the construction and you get:
module main;
interface I1{}
interface I2 : I1{}
class C : I2{
this(){}
}
void func(I1 i){}
void func(I2 i){}
void main(){
C c = new C();
func( cast(I2)c );
}
What is the deeper problem in this little snippet?
Or do you mean there is something wrong if you encounter this pattern.
I don't think it's really that much worse than renaming one(or both) of the
funcs.
It forces you to cast all class:I2 objects to the func you want called, but all
class:I1 objects already call the correct func.
I think different named funcs is a better solution, but I don't think the cast
solution exemplifies a pattern of indication to a deeper problem.
Re: interface function overloading
%u: What is the deeper problem in this little snippet? Or do you mean there is something wrong if you encounter this pattern. You are right, sorry :-) Bye, bearophile
Re: writef vs writeln and printing to the console
On 1/9/11, Christopher Nicholson-Sauls ibisbase...@gmail.com wrote: What Jesse said, but also: I can't help wondering if there's a special reason why you cannot (or would rather not) use writefln(.)? Oh it's not a problem. I was converting some C code and it used printf's with embedded newlines in the string. So I converted these to the safer writefln, but I got a different behavior when I compiled compared to the C version.
Re: writef vs writeln and printing to the console
*I meant I converted them to writef, not writefln, and got a different behavior*. writefln works fine.
File.size() is a ulong
From a recent update in File I've seen that size() returns an ulong, given by seek(): http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d?rev=2284#L585 http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d?rev=2284#L1245 It uses fseek, that seems to return a signed value: http://www.cplusplus.com/reference/clibrary/cstdio/ftell/ Isn't it better and safer if those functions of File return a long instead of an ulong? Bye, bearophile
Re: druntime
On 2011-01-09 04:02, Jonathan M Davis wrote: On Saturday 08 January 2011 13:32:19 Ellery Newcomer wrote: where did libdruntime.a go in dmd.2.051.zip:/linux/lib ? I think that it's included inside of libphobos.a now, and has been for a few releases. The libraries are still separate, and you can build them separately, but from what I can tell, it looks like phobos ends up including the druntime stuff in itself when you build it. So, having a separate libdruntime.a would be kind of pointless unless you were specifically trying to avoid linking in any Phobos stuff, which would be highly abnormal, and in which case you could build druntime yourself. But Sean or someone else who's been involved in that build process may have a better answer as to what exactly is going on now and why. - Jonathan M Davis Since Phobos depends on druntime and both libraries are statically linked I think libdruntime.a has never been needed. It's never been listed in dmd.conf/ini as far as I know. -- /Jacob Carlborg
Re: File.size() is a ulong
On Sun, 09 Jan 2011 08:29:47 -0500 bearophile bearophileh...@lycos.com wrote: From a recent update in File I've seen that size() returns an ulong, given by seek(): http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d?rev=2284#L585 http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d?rev=2284#L1245 It uses fseek, that seems to return a signed value: http://www.cplusplus.com/reference/clibrary/cstdio/ftell/ Isn't it better and safer if those functions of File return a long instead of an ulong? For any reason, I would rather expect sizediff_t (read: a cardinal). Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
use of regex
Hello, After getting a MatchResult by calling match(source, engine): Seems that, if match has failed, calling result.hit() throws an assertion error. Then, how can I know whether match was successful? As there is always a matchResult object returned. I'm looking for a kind of success.failure flag on the matchResult. Note: this is for single match at start of source. I found this strange thingie in the online docs: struct RegexMatch(Range = string); ... bool chr(ref uint si, E c); Returns whether string s matches this. ??? Whether string s (which?) matches this (RegexMatch object): ??? And what are 'si' 'c'? Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
dmc can't find masm386 in path when building druntime
I don't know what it is with DMC, but it's unable to find masm386 in my path. Take a look: D:\DMD\dmd2\src\druntimedmc -c src\rt\minit.asm masm386 -DM_I386=1 -D_WIN32 -Mx src\rt\minit.asm; Can't run 'masm386', check PATH But if I run it manually: D:\DMD\dmd2\src\druntimemasm386 -DM_I386=1 -D_WIN32 -Mx src\rt\minit.asm Then it works. So what's wrong with DMC? I've put masm386.exe in the bin folder of DMC, it's in the PATH..
Re: dmc can't find masm386 in path when building druntime
Sorry, it's not an issue with DMC. It's an issue with Walter's make from the looks of it. I'm still trying to figure out why it can't find masm though..
use of regex -- PS
Hello again, I also have an issue with the func 'match': instead of simply trying to match and fail if not found, it seems to search for a matching snippet all along the source: what a method 'find' or 'search' usually does, as opposed to 'match' precisely. Thus, i'm forced to prefix all regex patterns with '^'. What am I missing? (If I'm not missing anything, would be useful to have match vs find, don't you think?) Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: writef vs writeln and printing to the console
On 01/09/11 06:52, Andrej Mitrovic wrote: *I meant I converted them to writef, not writefln, and got a different behavior*. writefln works fine. Okay, gotcha. I'll agree that the behavioral change is unexpected (when coming from C). I believe there was actually a long discussion a while back on to flush or not to flush with regard to stdio functions, and apparently it was decided not to have the non *ln routines flush. Worth noting in the documentation if it isn't already. -- Chris N-S
Re: use of regex
spir Wrote: Hello, After getting a MatchResult by calling match(source, engine): Seems that, if match has failed, calling result.hit() throws an assertion error. Then, how can I know whether match was successful? As there is always a matchResult object returned. I'm looking for a kind of success.failure flag on the matchResult. Note: this is for single match at start of source. You'll want to use: if(!m.empty) where m is your RegexMatch instance. I found this strange thingie in the online docs: struct RegexMatch(Range = string); ... bool chr(ref uint si, E c); Returns whether string s matches this. ??? Whether string s (which?) matches this (RegexMatch object): ??? And what are 'si' 'c'? File a bug.
Re: use of regex -- PS
If you want your regular expression which matches at the begging of the string you use ^ (carrot). A regex is for describing what it takes to make a match, if your regex doesn't use this than it can match anywhere in the string. So to me having a match and find is redundant. I mean what does find do when you have ^ and $ surrounding the expression? spir Wrote: Hello again, I also have an issue with the func 'match': instead of simply trying to match and fail if not found, it seems to search for a matching snippet all along the source: what a method 'find' or 'search' usually does, as opposed to 'match' precisely. Thus, i'm forced to prefix all regex patterns with '^'. What am I missing? (If I'm not missing anything, would be useful to have match vs find, don't you think?) Denis -- -- -- -- -- -- -- vit esse estrany ⣠spir.wikidot.com
Re: Implicit type conversion
On Saturday 08 January 2011 13:16:54 Michal Minich wrote:
Use case:
import std.variant;
void foo (Variant v) {}
void main () {
Variant v = 3; // ok, this () called
v = 3; // ok, opAssing called
foo (v); // ok, struct copy, this(this) called
foo (3); // error
}
I'm trying to understand what is needed to make this work from language
design perspective. Is there already known/proposed solution to make this
work? What comes to my mind as first - Variant constructor should be
called on last line, the same way as on the first. But maybe to solve
this, another operator is needed, opImplicitConvertFrom ...
There are definitely folks who want opImplicitCast (I think that it's pretty
much
going to be necessary to get std.typecons.Rebindable to work entirely
correctly), and there's at least a decent chance that it will get added, but in
general, D avoids implicit casting in order to avoid issues where you call
functions which you don't really want to call (see http://is.gd/ksVli ).
Regardless, opImplicitCast wouldn't help you here anyway, because you need to
cast from an int to a Variant rather than the other way around, and it's not
like int is going to have opImplicitCast defined, even if it did exist.
Generally, you just need to give the correct type, which in this case would
presumably mean foo(Variant(3)). It might be a bid annoying, but it avoids
problems where you end up calling a function overload that you didn't intend
to.
If you really don't want to do that, then I believe that you're going to have
to
create another function overload for Foo which takes an int and deals with the
conversion to Variant for you.
Second question. Why is needed to have both - strut constructor (this)
and opAssing. In variant case, constructor just forwards to opAssing.
From high level point of view, I don't see any reason both should behave
differently...
There could be a difference of efficiency depending on the type. It could be
more
efficient to do something differently in one. For instance, that's why we have
both
opAssign and opOpAssign. Technically, you could just not have opOpAssign and
use
the combination of opAssign and opBinary to do it, but then you're likely to
end
up with extra heap allocations and the like. It could be the same with a
constructor and opAssign, depending on the type.
For the most part, D has tried to reduce how many operators you have to declare
when they're related (such us using opCmp() to give you , =, =, and ), but
it does create extra ones in cases where there's a good chance that it's more
efficient to have separate definitions (such as using opEquals() for == and !=
rather than using opCmp() for that).
- Jonathan M Davis
Re: File.size() is a ulong
On Sunday 09 January 2011 05:29:47 bearophile wrote: From a recent update in File I've seen that size() returns an ulong, given by seek(): http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d?re v=2284#L585 http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d?re v=2284#L1245 It uses fseek, that seems to return a signed value: http://www.cplusplus.com/reference/clibrary/cstdio/ftell/ Isn't it better and safer if those functions of File return a long instead of an ulong? Well, create a bug report then. fseek() does appear to take a long, so it probably would make more sense for File's size() function to use long as well. However, given that it makes no sense for a file's size to be negative, I'm not sure that it really matters. - Jonathan M Davis
Memory mapped IO
I'm exploring D for embedded work as a nice alternative to C/C++ for the
32-bitters and am finding it has a nice set of features. But, what is
the best way handle memory mapped IO? I don't see volatile like in C.
Is writing asm {} the best way to ensure memory access?
Thanks,
Dan Olson
