John-Carmack quotes the D programming language
A very good article by John-Carmack about purity http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/
(Non)Abstract Funcs, Linker Errors, and Wild Goose Chases
Consider this:
abstract class Base
{
void foo(); // Oops! Forgot "abstract"!
}
AIUI, that's *legal* because of two things:
1. Abstract classes are allowed to include functions that *do* have
implementations.
2. D's compilation model, inherited from C, allows functions to be
implemented in a separate source file if you use function stubs, such as
above.
In D's abstract classes, wanting to include an abstract function is much,
much more common than wanting to include
separate-compilation/function-stubbing. So get it wrong, and thanks to those
two normally-benign features above, you're treated to a mangled, ugly linker
error and the associated deep-sinking feeling of "..Fuck!"
Now, maybe I was simply being stupid, but I just wasted two full days
getting tripped up by this damn, uhh, non-bug. Completely reworked my whole
approach at least a couple times trying to work around...the wrong issues.
Even ran DustMite a couple times trying to get a test case demonstrating
(what I *thought* was) DMD forgetting to instantiate some templated code.
Only to eventually solve the whole damn thing by just simply typing in a
stupid...little..."abstract ". Ugh.
The fact that optlink crashed while spitting out the errors certainly didn't
help point me in the right direction. That's, of coruse, in addition to the
"Symbol undefined" errors including some fun red herrings that appered to be
from inside druntime/phobos.
There is an issue in bugzilla for this, #6485 (
http://d.puremagic.com/issues/show_bug.cgi?id=6485 ), but *unfortunately* I
think it's invalid for the reasons I described above. However, maybe it's
just frustration over the last couple days talking, but I think at least
*something* should be done about this, even if it's not what #6485 is
requesting.
Thoughts?
Re: Notice/Warning on narrowStrings .length
On 27.04.2012 5:36, H. S. Teoh wrote: On Thu, Apr 26, 2012 at 09:03:59PM -0400, Nick Sabalausky wrote: [...] Heh, any usage of Notepad *needs* to be justified. For example, it has an undo buffer of exactly ONE change. Come on, notepad is a real nice in one job only: getting rid of style and fonts of a copied text fragment. I use it as clean-up scratch pool daily. Would be a shame if they ever add fonts and layout to it ;) -- Dmitry Olshansky
Re: John-Carmack quotes the D programming language
On Friday, 27 April 2012 at 07:26:52 UTC, Guillaume Chatelet wrote: A very good article by John-Carmack about purity http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ So all that Twitter spamming finally led to something? :P SCNR, David
Re: Notice/Warning on narrowStrings .length
On 27.04.2012 1:23, H. S. Teoh wrote: On Thu, Apr 26, 2012 at 01:51:17PM -0400, Nick Sabalausky wrote: "James Miller" wrote in message news:qdgacdzxkhmhojqce...@forum.dlang.org... I'm writing an introduction/tutorial to using strings in D, paying particular attention to the complexities of UTF-8 and 16. I realised that when you want the number of characters, you normally actually want to use walkLength, not length. Is is reasonable for the compiler to pick this up during semantic analysis and point out this situation? It's just a thought because a lot of the time, using length will get the right answer, but for the wrong reasons, resulting in lurking bugs. You can always cast to immutable(ubyte)[] or immutable(short)[] if you want to work with the actual bytes anyway. I find that most of the time I actually *do* want to use length. Don't know if that's common, though, or if it's just a reflection of my particular use-cases. Also, keep in mind that (unless I'm mistaken) walkLength does *not* return the number of "characters" (ie, graphemes), but merely the number of code points - which is not the same thing (due to existence of the [confusingly-named] "combining characters"). [...] And don't forget that some code points (notably from the CJK block) are specified as "double-width", so if you're trying to do text layout, you'll want yet a different length (layoutLength?). So we really need all four lengths. Ain't unicode fun?! :-) Array length is simple. Walklength is already implemented. Grapheme length requires recognition of 'combining characters' (or rather, ignoring said characters), and layout length requires recognizing widthless, single- and double-width characters. I've been thinking about unicode processing recently. Traditionally, we have to decode narrow strings into UTF-32 (aka dchar) then do table lookups and such. But unicode encoding and properties, etc., are static information (at least within a single unicode release). So why bother with hardcoding tables and stuff at all? Of course they are generated. What we *really* should be doing, esp. for commonly-used functions like computing various lengths, is to automatically process said tables and encode the computation in finite-state machines that can then be optimized at the FSM level (there are known algos for generating optimal FSMs), FSA are based on tables so it's all runs in the circle. Only the layout changes. Yet the speed gains of non-decoding are huge. codegen'd, and then optimized again at the assembly level by the compiler. These FSMs will operate at the native narrow string char type level, so that there will be no need for explicit decoding. The generation algo can then be run just once per unicode release, and everything will Just Work. This year Unicode in D will receive a nice upgrade. http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/dolsh/20002# Anyway keep me posted if you have these FSA ever come to soil your sleep ;) -- Dmitry Olshansky
Re: John-Carmack quotes the D programming language
"Guillaume Chatelet" wrote in message news:llzwwxmdgnwydqcyf...@forum.dlang.org... >A very good article by John-Carmack about purity > > http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ Yea, that is good. Sometimes I agree with Carmack, and sometimes I don't, but he's always fascinating to listen to, and I'm always impressed by his intelligence and clairity-of-thought on complex matters.
Re: ^^ limitation
On 04/27/2012 03:55 AM, James Miller wrote: On Friday, 27 April 2012 at 00:56:13 UTC, Tryo[17] wrote: D provides an auto type facility that determins which the type that can best accommodate a particular value. What prevents the from determining that the only type that can accommodate that value is a BigInt? The same way it decides between int, long, ulong, etc. Because the compiler doesn't know how to make a BigInt, BigInt is part of the library, not the language. Why couldn't to!string be overloaded to take a BigInt? It is, its the same overload that takes other objects. The point is this, currently 2^^31 will produce a negative long value on my system. Not that the value is wrong, the variable simply cannot support the magnitude of the result for this calculation so it wraps around and produces a negative value. However, 2^^n for n>=32 produces a value of 0. Why not produce the value and let the user choose what to put it into? Why not make the he language BigInt aware? What is the negative effect of taking BigInt out of the library and make it an official part of the language? Because this is a native language. The idea is to be close to the hardware, and that means fixed-sized integers, fixed-sized floats and having to live with that. Making BigInt part of the language opens up the door for a whole host of other things to become "part of the language". While we're at it, why don't we make matrices part of the language, and regexes, and we might aswell move all that datetime stuff into the language too. Oh and I would love to see all the signals stuff in there too. The reason we don't put everything in the language is because the more you put into the language, the harder it is to move. There are more than enough bugs in D s/in D/in the DMD frontend/ right now, and adding more features into the language means a higher burden for core development. There is a trend of trying to move away from tight integration into the compiler, and by extension the language. Associative arrays are being worked on to make most of the work be done in object.d, with the end result being the compiler only has to convert T[U] into AA(T, U) and do a similar conversion for aa literals. This means that there is no extra fancy work for the compiler to do to support AA's Also, D is designed for efficiency, if I don't want a BigInt, and all of the extra memory that comes with, then I would rather have an error. I don't want what /should/ be a fast system to slow down because I accidentally type 1 << 33 instead of 1 << 23, I want an error of some sort. The real solution here isn't to just blindly allow arbitrary features to be "in the language" as it were, but to make it easier to integrate library solutions so they feel like part of the language. -- James Miller
Re: Notice/Warning on narrowStrings .length
"Dmitry Olshansky" wrote in message news:jndkji$23ni$2...@digitalmars.com... > On 27.04.2012 5:36, H. S. Teoh wrote: >> On Thu, Apr 26, 2012 at 09:03:59PM -0400, Nick Sabalausky wrote: >> [...] >>> Heh, any usage of Notepad *needs* to be justified. For example, it has >>> an >>> undo buffer of exactly ONE change. >> > > Come on, notepad is a real nice in one job only: getting rid of style and > fonts of a copied text fragment. I use it as clean-up scratch pool daily. > Would be a shame if they ever add fonts and layout to it ;) > That's the #1 biggest thing I use it for!! :) And yes, daily. I frequently wish I had a global setting for "Don't include style in the clipboard", and maybe a *separate* "Copy with style" command. Or at least a standard "copy without style", or "remove style from clipboard" command. *Something*. 99% of the times I copy/paste text I *don't* want to include style. Drives me crazy.
Re: Notice/Warning on narrowStrings .length
"H. S. Teoh" wrote in message news:mailman.1.1335507187.22023.digitalmar...@puremagic.com... > On Thu, Apr 26, 2012 at 09:55:54PM -0400, Nick Sabalausky wrote: > [...] >> Crazy stuff! Some of them look rather similar to Arabic or Korean's >> Hangul (sp?), at least to my untrained eye. And then others are just >> *really* interesting-looking, like: >> >> http://www.omniglot.com/writing/12480.htm >> http://www.omniglot.com/writing/ayeri.htm >> http://www.omniglot.com/writing/oxidilogi.htm >> >> You're right though, if I were in charge of Unicode and tasked with >> handling some of those, I think I'd just say "Screw it. Unicode is now >> depricated. Use ASCII instead. Doesn't have the characters for your >> langauge? Tough! Fix your language!" :) > > You think that's crazy, huh? Check this out: > > http://www.omniglot.com/writing/sumerian.htm > > Now take a deep breath... > > ... this writing was *actually used* in ancient times. Yeah. > Jesus, I could *easily* mistake that for hardware schematics. That's wild.
Re: Notice/Warning on narrowStrings .length
On 27.04.2012 12:31, Nick Sabalausky wrote: "Dmitry Olshansky" wrote in message news:jndkji$23ni$2...@digitalmars.com... On 27.04.2012 5:36, H. S. Teoh wrote: On Thu, Apr 26, 2012 at 09:03:59PM -0400, Nick Sabalausky wrote: [...] Heh, any usage of Notepad *needs* to be justified. For example, it has an undo buffer of exactly ONE change. Come on, notepad is a real nice in one job only: getting rid of style and fonts of a copied text fragment. I use it as clean-up scratch pool daily. Would be a shame if they ever add fonts and layout to it ;) That's the #1 biggest thing I use it for!! :) And yes, daily. I frequently wish I had a global setting for "Don't include style in the clipboard", and maybe a *separate* "Copy with style" command. Or at least a standard "copy without style", or "remove style from clipboard" command. *Something*. 99% of the times I copy/paste text I *don't* want to include style. Drives me crazy. Yup I certainly wouldn't mind a separate "copy with my font settings" ;) -- Dmitry Olshansky
Re: How can D become adopted at my company?
On Thursday, 26 April 2012 at 09:28:30 UTC, Jonathan M Davis wrote: Whether the backend is open or not has _zero_ impact on your ability to use it. The source is freely available, so you can look at and see what it does. Casual users are generally ignorant about licenses (as long as they can use the software), but not geeks - and proprietary software has bad publicity, it's not something technical, just a reputation.
Re: Cairo Deimos bindings
James Miller wrote: > I am currently writing D bindings for Cairo for submission into > Deimos, could somebody please make the repository so I can fork > it? > > Thanks > > -- > James Miller Is it a binding, or a wrapper?
Re: Static method conflicts with non-static method?
On Fri, 27 Apr 2012 01:07:03 -0400, H. S. Teoh
wrote:
Is this a bug? Code:
import std.stdio;
struct S {
static int func(int x) { return x+1; }
int func(int x) { return x+2; }
}
void main() {
S s;
writeln(s.func(1));
}
DMD (latest git) output:
test.d(10): Error: function test.S.func called with argument types:
((int))
matches both:
test.S.func(int x)
and:
test.S.func(int x)
The error message is unhelpful, but basically the complaint is that the
static method is conflicting with the non-static method.
But I would've thought it is unambiguous; I'd expect that s.func should
resolve to the non-static method, and S.func to the static method. After
all, no object is needed to invoke the static method, and the static
method cannot be invoked without an object.
It's not a bug, it's intended behavior. Static members are accessible via
an instance pointer. My personal belief is that it shouldn't be this way,
especially since you can make factory static methods that look like they
are doing something on an instance. I brought this up a while ago, but
since when did anyone listen to me? :)
Here is a relevant discussion:
http://forum.dlang.org/post/j3fi1u$1uge$1...@digitalmars.com
One of the counter-arguments from Andrei was that static methods can be
used as "methods" on types for generic programming. With the advent of
UFCS, this argument has much less teeth. Maybe it should be revisited...
-Steve
Re: (Non)Abstract Funcs, Linker Errors, and Wild Goose Chases
On Fri, 27 Apr 2012 03:36:48 -0400, Nick Sabalausky
wrote:
Consider this:
abstract class Base
{
void foo(); // Oops! Forgot "abstract"!
}
AIUI, that's *legal* because of two things:
1. Abstract classes are allowed to include functions that *do* have
implementations.
2. D's compilation model, inherited from C, allows functions to be
implemented in a separate source file if you use function stubs, such as
above.
In D's abstract classes, wanting to include an abstract function is much,
much more common than wanting to include
separate-compilation/function-stubbing. So get it wrong, and thanks to
those
two normally-benign features above, you're treated to a mangled, ugly
linker
error and the associated deep-sinking feeling of "..Fuck!"
Now, maybe I was simply being stupid, but I just wasted two full days
getting tripped up by this damn, uhh, non-bug. Completely reworked my
whole
approach at least a couple times trying to work around...the wrong
issues.
Even ran DustMite a couple times trying to get a test case demonstrating
(what I *thought* was) DMD forgetting to instantiate some templated code.
Only to eventually solve the whole damn thing by just simply typing in a
stupid...little..."abstract ". Ugh.
The fact that optlink crashed while spitting out the errors certainly
didn't
help point me in the right direction. That's, of coruse, in addition to
the
"Symbol undefined" errors including some fun red herrings that appered
to be
from inside druntime/phobos.
There is an issue in bugzilla for this, #6485 (
http://d.puremagic.com/issues/show_bug.cgi?id=6485 ), but
*unfortunately* I
think it's invalid for the reasons I described above. However, maybe it's
just frustration over the last couple days talking, but I think at least
*something* should be done about this, even if it's not what #6485 is
requesting.
Thoughts?
You have my sympathy. Since working with D, I don't think I've *ever*
used the "declare then implement" model. My personal opinion is that the
compiler should require .di files for declaring stubbed methods.
Other than that, I don't see a way to "fix" this problem, because you
absolutely have to be able to declare an abstract class with non-abstract
methods. If you want a fully abstract class, use an interface ;)
Another thought, burn this into your neurons:
abstract class C
{
abstract:
...
}
At least you only have to type it *once*. Of course, you'd have to put
all concrete methods before the abstract, which may hinder organization of
your methods.
No really good solutions, sorry :(
-Steve
Re: Static method conflicts with non-static method?
On Friday, 27 April 2012 at 10:48:29 UTC, Steven Schveighoffer wrote: With the advent of UFCS, this argument has much less teeth. Maybe it should be revisited... -Steve Elaborate please how UFCS would help in that context.
Re: Cairo Deimos bindings
On Friday, 27 April 2012 at 09:50:21 UTC, Dejan Lekic wrote: James Miller wrote: I am currently writing D bindings for Cairo for submission into Deimos, could somebody please make the repository so I can fork it? Thanks -- James Miller Is it a binding, or a wrapper? It is a binding. There are some very minor cosmetic changes that will be detailed, but otherwise you can just copy-paste a C example into D, make it D-compatible and it will work as intended. -- James Miller
Re: Static method conflicts with non-static method?
On Fri, 27 Apr 2012 07:03:02 -0400, so wrote: On Friday, 27 April 2012 at 10:48:29 UTC, Steven Schveighoffer wrote: With the advent of UFCS, this argument has much less teeth. Maybe it should be revisited... -Steve Elaborate please how UFCS would help in that context. Hm... thinking about it, UFCS requires passing the instance, while static methods do not. So it doesn't make as much sense as I thought... I still think static methods should not be callable on instances without opt-in from the aggregate author. The confusion it can cause is not worth the benefits IMO. -Steve
Re: Cairo Deimos bindings
On Friday, 27 April 2012 at 11:09:41 UTC, James Miller wrote: It is a binding. There are some very minor cosmetic changes that will be detailed, but otherwise you can just copy-paste a C example into D, make it D-compatible and it will work as intended. It depends on how minor the changes are, but generally please refrain from making »cosmetic« changes to the C API. Deimos bindings should be the verbatim headers translated to D, and just that (this also means that importing them never requires an additional compilation unit to be linked in) – anything else is better left to wrapper projects. David
Re: Static method conflicts with non-static method?
On Friday, 27 April 2012 at 11:23:39 UTC, Steven Schveighoffer wrote: On Fri, 27 Apr 2012 07:03:02 -0400, so wrote: On Friday, 27 April 2012 at 10:48:29 UTC, Steven Schveighoffer wrote: With the advent of UFCS, this argument has much less teeth. Maybe it should be revisited... -Steve Elaborate please how UFCS would help in that context. Hm... thinking about it, UFCS requires passing the instance, while static methods do not. So it doesn't make as much sense as I thought... I still think static methods should not be callable on instances without opt-in from the aggregate author. The confusion it can cause is not worth the benefits IMO. I agree it is ugly. If there is a way out (reason why i asked), we should just dump it.
Re: How can D become adopted at my company?
On 04/26/2012 10:59 AM, Don Clugston wrote: No, I don't mean "GPL compatible". I'd be perfectly happy for the DMD backend to be released under a GPL-incompatible free/open source licence like the CDDL. The problem is not GPL compatibility but whether sufficient freedoms are granted to distribute and modify sources. And the only one such limitation of freedom which has ever been identified, in numerous posts (hundreds!) on this topic, is that the license is not GPL compatible and therefore cannot be distributed with (say) OS distributions. I don't understand your fixation on the GPL, as even a GPL-incompatible license would allow it to be distributed on FOSS operating systems like Debian or Fedora. The important principle, which you've been ignoring for some reason, is that you can redistribute the source along with modifications. This is not special to GPL, and is fundamental both to open source and Free Software.
Re: Static method conflicts with non-static method?
On Apr 27, 2012 7:34 AM, "so" wrote: > > I agree it is ugly. If there is a way out (reason why i asked), we should just dump it. I don't like the idea either because it is confusing. The only reason I can imagine is if there was polymorphism on statics which I see as a fairly useless feature. I would be interested to hear of possible use cases though.
Re: Static method conflicts with non-static method?
On Fri, 27 Apr 2012 07:31:50 -0400, so wrote:
On Friday, 27 April 2012 at 11:23:39 UTC, Steven Schveighoffer wrote:
On Fri, 27 Apr 2012 07:03:02 -0400, so wrote:
On Friday, 27 April 2012 at 10:48:29 UTC, Steven Schveighoffer wrote:
With the advent of UFCS, this argument has much less teeth. Maybe it
should be revisited...
-Steve
Elaborate please how UFCS would help in that context.
Hm... thinking about it, UFCS requires passing the instance, while
static methods do not. So it doesn't make as much sense as I thought...
I still think static methods should not be callable on instances
without opt-in from the aggregate author. The confusion it can cause
is not worth the benefits IMO.
I agree it is ugly. If there is a way out (reason why i asked), we
should just dump it.
The idea I came up with in my proposal
(http://d.puremagic.com/issues/show_bug.cgi?id=6579) was to allow aliasing
the static method into the instance namespace:
struct S1
{
static void foo() {}
alias S1.foo this.foo;
}
struct S2
{
static void foo() {}
}
void main()
{
S1 i1;
S2 i2;
S1.foo(); // ok
i1.foo(); // ok
S2.foo(); // ok
i2.foo(); // error
}
-Steve
Re: Static method conflicts with non-static method?
On Friday, 27 April 2012 at 11:49:08 UTC, Kevin Cox wrote:
On Apr 27, 2012 7:34 AM, "so" wrote:
I agree it is ugly. If there is a way out (reason why i
asked), we should
just dump it.
I don't like the idea either because it is confusing. The only
reason I
can imagine is if there was polymorphism on statics which I see
as a fairly
useless feature. I would be interested to hear of possible
use cases
though.
This one is quite important for templates.
struct A(T)
{
static T mini() { return T.min; }
static T maxi() { return T.max; }
}
struct B(T)
{
T[] v;
T mini() { return min(v); }
T maxi() { return max(v); }
}
void test(T)(T a)
{
writeln("min: ", a.mini());
writeln("max: ", a.maxi());
}
Re: Static method conflicts with non-static method?
On Friday, 27 April 2012 at 11:51:40 UTC, Steven Schveighoffer
wrote:
The idea I came up with in my proposal
(http://d.puremagic.com/issues/show_bug.cgi?id=6579) was to
allow aliasing the static method into the instance namespace:
struct S1
{
static void foo() {}
alias S1.foo this.foo;
}
struct S2
{
static void foo() {}
}
void main()
{
S1 i1;
S2 i2;
S1.foo(); // ok
i1.foo(); // ok
S2.foo(); // ok
i2.foo(); // error
}
-Steve
But call site remains unchanged, which was the main reason of
confusion. If we expect user to read the function declaration
anyway, an extra alias won't do much good or probably complicate
it even further.
Re: John-Carmack quotes the D programming language
On Friday, 27 April 2012 at 08:21:07 UTC, Nick Sabalausky wrote: "Guillaume Chatelet" wrote in message news:llzwwxmdgnwydqcyf...@forum.dlang.org... A very good article by John-Carmack about purity http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ Yea, that is good. Sometimes I agree with Carmack, and sometimes I don't, but he's always fascinating to listen to, and I'm always impressed by his intelligence and clairity-of-thought on complex matters. Plus, he is extremely down to earth when tackling problems. He has been rather conservative when coming to programming languages, so if he talks about issues like purity, he probably has studied and practiced them well enough to feel authorized to talk about them. And I bet he started to look at it because of he need for multithreaded programming.
Re: John-Carmack quotes the D programming language
Le 27/04/2012 09:26, Guillaume Chatelet a écrit : A very good article by John-Carmack about purity http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ The drawTriangle example is a very good example of why weak purity is good. D have made a very good move here.
Re: Static method conflicts with non-static method?
On Fri, 27 Apr 2012 08:11:48 -0400, so wrote:
On Friday, 27 April 2012 at 11:51:40 UTC, Steven Schveighoffer wrote:
The idea I came up with in my proposal
(http://d.puremagic.com/issues/show_bug.cgi?id=6579) was to allow
aliasing the static method into the instance namespace:
struct S1
{
static void foo() {}
alias S1.foo this.foo;
}
struct S2
{
static void foo() {}
}
void main()
{
S1 i1;
S2 i2;
S1.foo(); // ok
i1.foo(); // ok
S2.foo(); // ok
i2.foo(); // error
}
-Steve
But call site remains unchanged, which was the main reason of confusion.
If we expect user to read the function declaration anyway, an extra
alias won't do much good or probably complicate it even further.
Huh? The main reason of confusion is that the static method is named in
such a way that it looks like an instance method. So we prevent that,
unless the author of the class (who is deciding the name of the function)
deems it should be called on instances
example:
struct File
{
static File open(string name) {...} // factory method
this(string name);
}
File f = File("hello");
f.open("world"); // oops! Just opened file world and threw it away
f = File.open("world");// better!
I challenge you to name File.open some way where it *wouldn't* be
confusing when called on an instance :)
-Steve
Re: John-Carmack quotes the D programming language
On Friday, 27 April 2012 at 07:26:52 UTC, Guillaume Chatelet wrote: A very good article by John-Carmack about purity http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ Just a glance AND my eyes managed to parse "axilmar" in thousands of words. I better get some fresh air.
Re: export extern (C) void Fun Error
On Friday, 27 April 2012 at 01:21:56 UTC, Trass3r wrote: export c callback fun: alias void function(int id) ConnectedCallBack; alias void function(int id, void* data, int len) ReadCallBack; add extern(C) to be safe Thank, Trass3r! Finally correct, why have to export these two?
Re: Static method conflicts with non-static method?
On Friday, 27 April 2012 at 12:35:53 UTC, Steven Schveighoffer
wrote:
Huh? The main reason of confusion is that the static method is
named in such a way that it looks like an instance method. So
we prevent that, unless the author of the class (who is
deciding the name of the function) deems it should be called on
instances
example:
struct File
{
static File open(string name) {...} // factory method
this(string name);
}
File f = File("hello");
f.open("world"); // oops! Just opened file world and threw it
away
f = File.open("world");// better!
With your proposal you can still do "f.open("world");" and get
the same result if the author provided alias. You are trying to
solve another problem, that the author should better state if
this is intended. The problem i see is user assumming author is a
smart guy. But at the end he finds out the author is as dumb as
himself {he should have RTFM :)}
I challenge you to name File.open some way where it *wouldn't*
be confusing when called on an instance :)
-Steve
Easy! Don't call on an instance! openFile() out of the struct.
I always add "make_" before any static function, otherwise static
methods should be precise as
http://forum.dlang.org/post/araqkvvgyspzmdecx...@forum.dlang.org
Re: Static method conflicts with non-static method?
On Fri, 27 Apr 2012 09:15:31 -0400, so wrote:
On Friday, 27 April 2012 at 12:35:53 UTC, Steven Schveighoffer wrote:
Huh? The main reason of confusion is that the static method is named
in such a way that it looks like an instance method. So we prevent
that, unless the author of the class (who is deciding the name of the
function) deems it should be called on instances
example:
struct File
{
static File open(string name) {...} // factory method
this(string name);
}
File f = File("hello");
f.open("world"); // oops! Just opened file world and threw it away
f = File.open("world");// better!
With your proposal you can still do "f.open("world");" and get the same
result if the author provided alias.
The point is, don't provide the alias. Why would anyone do that in this
case?
You are trying to solve another problem, that the author should better
state if this is intended. The problem i see is user assumming author is
a smart guy. But at the end he finds out the author is as dumb as
himself {he should have RTFM :)}
There is no protection D could ever provide against dumb authors ;) He
could have named it "close", or "r72" and the compiler is powerless to
prevent this! It's useless to try and prevent such things, D compiler is
not a psychologist.
The problem I see here is that *smart* authors are inhibited from writing
smart code.
I challenge you to name File.open some way where it *wouldn't* be
confusing when called on an instance :)
-Steve
Easy! Don't call on an instance! openFile() out of the struct.
I always add "make_" before any static function, otherwise static
methods should be precise as
http://forum.dlang.org/post/araqkvvgyspzmdecx...@forum.dlang.org
I like having open inside the struct, just a matter of preference. I
think File.open implies better than it returns a File more than openFile.
-Steve
Re: John-Carmack quotes the D programming language
Guillaume Chatelet:
A very good article by John-Carmack about purity
http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/
Returning everything by value is the natural functional
programming style, but relying on compilers to always perform
return value optimization can be hazardous to performance, so
passing reference parameter for output of complex data
structures is often justifiable, but it has the unfortunate
effect of preventing you from declaring the returned value as
const to enforce single assignment.<
Is this what he is talking about?
class Foo {
int x;
}
const(Foo) bar() pure {
auto f = new Foo;
f.x = 1;
return f;
}
void main() pure {}
--
Regarding D purity I have asked for another little improvements:
http://d.puremagic.com/issues/show_bug.cgi?id=7994
It's related to this other example:
import std.string: text;
string foo() {
return text(1);
}
void main() pure {
enum s = foo(); // currently an error
}
Bye,
bearophile
Re: Static method conflicts with non-static method?
On 2012-04-27 07:07, H. S. Teoh wrote:
Is this a bug? Code:
import std.stdio;
struct S {
static int func(int x) { return x+1; }
int func(int x) { return x+2; }
}
void main() {
S s;
writeln(s.func(1));
}
DMD (latest git) output:
test.d(10): Error: function test.S.func called with argument types:
((int))
matches both:
test.S.func(int x)
and:
test.S.func(int x)
The error message is unhelpful, but basically the complaint is that the
static method is conflicting with the non-static method.
But I would've thought it is unambiguous; I'd expect that s.func should
resolve to the non-static method, and S.func to the static method. After
all, no object is needed to invoke the static method, and the static
method cannot be invoked without an object.
It's intended behavior but there's a suggestion to change that:
http://d.puremagic.com/issues/show_bug.cgi?id=3345
--
/Jacob Carlborg
Re: John-Carmack quotes the D programming language
On Friday, 27 April 2012 at 14:51:01 UTC, bearophile wrote:
John Carmack:
Returning everything by value is the natural functional
programming style, but relying on compilers to always perform
return value optimization can be hazardous to performance, so
passing reference parameter for output of complex data
structures is often justifiable, but it has the unfortunate
effect of preventing you from declaring the returned value as
const to enforce single assignment.<
Is this what he is talking about?
class Foo {
int x;
}
const(Foo) bar() pure {
auto f = new Foo;
f.x = 1;
return f;
}
void main() pure {}
No, he is referring to the call site of the function which
returns something by ref, where you can't declare the »target«
const:
---
/* const */ Foo foo;
initializeFoo(foo);
---
David
Re: export extern (C) void Fun Error
On Friday, 27 April 2012 at 13:02:56 UTC, 拖狗散步 wrote: On Friday, 27 April 2012 at 01:21:56 UTC, Trass3r wrote: export c callback fun: alias void function(int id) ConnectedCallBack; alias void function(int id, void* data, int len) ReadCallBack; add extern(C) to be safe Thank, Trass3r! Finally correct, why have to export these two? You specified the C calling convention with UnmanagedFunctionPointer(CallingConvention.Cdecl), and extern(C) means use the C calling convention. Otherwise they'll be expecting a function using the D calling convention, which is incompatible.
Re: Cairo Deimos bindings
Am Fri, 27 Apr 2012 13:26:49 +0200 schrieb "David Nadlinger" : > On Friday, 27 April 2012 at 11:09:41 UTC, James Miller wrote: > > It is a binding. There are some very minor cosmetic changes that > > will be detailed, but otherwise you can just copy-paste a C > > example into D, make it D-compatible and it will work as > > intended. > > It depends on how minor the changes are, but generally please > refrain from making »cosmetic« changes to the C API. Deimos > bindings should be the verbatim headers translated to D, and just > that (this also means that importing them never requires an > additional compilation unit to be linked in) – anything else is > better left to wrapper projects. > > David I think it is understood and he was referring to renaming the enum members, for which you have to write different code when using them in D anyway: In C: STATUS_SUCCESS In D unmodified: cairo_status_t.STATUS_SUCCESS In D with cosmetic changes: cairo_status_t.SUCCESS It doesn't change the semantics or add code. It could just as well be a Deimos coding standard. -- Marco
Re: Cross module version specs
Am Thu, 26 Apr 2012 21:22:46 -0700 schrieb bcs : > One monster of a string mixin? Take a look at the GtkD sources, more specifically the files in gtkc/ :-) -- Marco
Re: Cross module version specs
Am Thu, 26 Apr 2012 21:24:46 -0700 schrieb bcs : > On 04/26/2012 05:37 AM, Steven Schveighoffer wrote: > > > > versions should be defined for the *entire program*, not just for > > certain files. And if they are defined just for certain files, define > > them in the file itself. > > > > Versions should be defined for the *entire program*, not just for > whatever you happen to be compiling right now. > > Is there any way to make different modules complain if you link object > files built with diffident versions set? You would need to modify the linker (optlink/ld) to understand that two object files compiled by a D compiler include a section that informs it about enabled version tags, or maybe abuse existing systems to the end that the poor programmer mixing versions up gets a generic error message that doesn't make any sense. But more importantly, you can bundle up object files into .a archives aka static _libraries_ with yet another tool, I think ar is its name. It would not work out if e.g. GtkD compiled its static libraries with one set of versions and you compile your app with another set. Or in contrast, you would have to enable versions like 'cairo_new_backend', 'druntime_use_old_gc', 'whatever_any_other_object_file_was_compiled_with' for your program, even if you don't need them. To sort that mess out again, the compiler would have to create a list of versions that affect the currently compiled module at all. It would then find out that for your program 'druntime_use_old_gc' is irrelevant and exclude it from the version check. my_app GtkD Phobos my_veron - - no unusedoff - - no cairo_new_backend - on- no druntime_use_old_gc - - off no debug on off off yes X86_64on - on no In this case the linker would complain only about a version named 'debug' that was enabled in your application, but not for the object files of GtkD and Phobos. -- Marco P.S.: Can I have a software patent on this?
Re: comma operator causes hard to spot bugs
I fully agree! I wonder why the comma operator made it into D at all. This would have been exactly the kind of nasty language details that D could have cleaned out. On 21.04.2012 14:23, Benjamin Thaut wrote: Hi, I just had a bug due to the unitentional usage of the comma operator. So I'm wondering if there could something be done so that the compiler prevents something like this: memStart = cast(T*)(m_allocator.AllocateMemory(size * T.sizeof), InitializeMemoryWith.NOTHING); This first excutes AllocateMemory, then throws away the result and then casts the enum InitializeMemory.NOTHING value to a pointer, which will always result in a null pointer. This took me quite some time to spot. What I actually wanted to do: memStart = cast(T*)(m_allocator.AllocateMemory(size * T.sizeof, InitializeMemoryWith.NOTHING)); 1) So is it actually neccessary that enums can be casted directly to pointers? 2) Is the functionality provided by the comma operator actually worth the bugs it causes? Kind Regards Benjamin Thaut
Re: (Non)Abstract Funcs, Linker Errors, and Wild Goose Chases
On Friday, April 27, 2012 06:57:28 Steven Schveighoffer wrote: > You have my sympathy. Since working with D, I don't think I've *ever* > used the "declare then implement" model. My personal opinion is that the > compiler should require .di files for declaring stubbed methods. That would be a problem because of documentation. You need to be able to include stubbed out functions for ddoc (Phobos generally does that with version(StdDdoc) when it needs to), otherwise platform-specific stuff doesn't end up in the documentation when you generate it on _other_ platforms. And I think that it would be unreasonable to require that that be done with .di files. - Jonathan M Davis
Re: ^^ limitation
Am Fri, 27 Apr 2012 02:56:11 +0200 schrieb "Tryo[17]" : > On Tuesday, 24 April 2012 at 22:45:37 UTC, Marco Leise wrote: > > Well... what do you want to hear? I like to know that the > > Honestly, I just want to hear the rationale for why things are > the way they are. I see thing possible in other languages that > I know are not as powerful as D and I get to wonder why... If > I don't understand enough to make a determination on my > own, I simply ask. In the first moment I wasn't sure if you were trolling. It seems so obvious and clear to me that the result of a calculation cannot change its type depending on the exact magnitudes of the operands, that I interpreted ^^ as *g* or :p. "Ha! Ha! Limitation!" Considering that you probably have more experience with higher-level languages, where the actual data type can be more or less hidden and dynamically changed, I can understand the confusion. The word powerful can mean different things to different people. Powerful can mean, that you have a high-level foreach loop, but it can also mean that you are able to implement a foreach loop in low-level assembly. A warning could be useful. I don't know about: (3 ^^ 99) & 0x though. I.e. cases where you may be aware of the overflow, but want the 2^32 modulo anyway for some kind of hash function. -- Marco
Re: (Non)Abstract Funcs, Linker Errors, and Wild Goose Chases
On Fri, 27 Apr 2012 13:31:22 -0400, Jonathan M Davis wrote: On Friday, April 27, 2012 06:57:28 Steven Schveighoffer wrote: You have my sympathy. Since working with D, I don't think I've *ever* used the "declare then implement" model. My personal opinion is that the compiler should require .di files for declaring stubbed methods. That would be a problem because of documentation. You need to be able to include stubbed out functions for ddoc (Phobos generally does that with version(StdDdoc) when it needs to), otherwise platform-specific stuff doesn't end up in the documentation when you generate it on _other_ platforms. And I think that it would be unreasonable to require that that be done with .di files. Creating a stub function with implementation is quite easy. -Steve
generic indexOf() for arrays ?
I'd like to know if there's a generic function over arrays to find the index of a specific elemnt therein, something like, say: int indexOf(S) (in S[] arr, S elem); which works the same way the std.string.indexOf() function works... couldn't find anything in the std.array module for this scenario. Would be nice to have this functionality built-in somehow. Or is there a completely different / better approach to this in D? Thx, M.
Re: generic indexOf() for arrays ?
On Friday, 27 April 2012 at 19:49:33 UTC, M.Gore wrote: I'd like to know if there's a generic function over arrays to find the index of a specific elemnt therein, something like, say: int indexOf(S) (in S[] arr, S elem); which works the same way the std.string.indexOf() function works... couldn't find anything in the std.array module for this scenario. Would be nice to have this functionality built-in somehow. Or is there a completely different / better approach to this in D? Thx, M. countUntil in std.algorithm should work fine. http://dlang.org/phobos/std_algorithm.html#countUntil Regards, Brad Anderson
Re: generic indexOf() for arrays ?
countUntil in std.algorithm should work fine. http://dlang.org/phobos/std_algorithm.html#countUntil Yup, it does! Just didn't see it there in the algorithm collection. Thanks a lot.
Re: Cross module version specs
What about a templated module? module test(bool option1, T); Imported like this: import test!(true, Foo); It could act like the entire module was wrapped in a template, and the import would become: import test; mixin test.test_template!(true, Foo);
Re: Cross module version specs
On 28.04.2012 0:22, Matt Peterson wrote: What about a templated module? module test(bool option1, T); Imported like this: import test!(true, Foo); It could act like the entire module was wrapped in a template, and the import would become: import test; mixin test.test_template!(true, Foo); I would rather see this as import test with specified version identifiers. import test!(some_version); //imports module but treats it contents as if with "version = some_version;" added at the top of it -- Dmitry Olshansky
Re: Cross module version specs
On Friday, 27 April 2012 at 20:26:38 UTC, Dmitry Olshansky wrote: I would rather see this as import test with specified version identifiers. import test!(some_version); //imports module but treats it contents as if with "version = some_version;" added at the top of it This is inconsistent with the syntax and the way templates work in the rest of the language, as well as being a lot less flexible. It wouldn't be hard to mixin a string built from a list of identifiers passed in to set those versions.
Re: The new std.process?
Just stopping by to say I'm using your new std.process now. pipeProcess() is what I was looking for to compare the output of a C program and the corresponding D port. -- Marco
Re: Cairo Deimos bindings
On 4/27/12, Marco Leise wrote: > In C: > STATUS_SUCCESS > > In D unmodified: > cairo_status_t.STATUS_SUCCESS > > In D with cosmetic changes: > cairo_status_t.SUCCESS cairo_status_t.SUCCESS is like going halfway there but stopping. It looks rather ugly imo. I think you either want the existing C names, or names that *fully* fit the D coding style. So maybe the choice should be between this: cairo_status_t.STATUS_SUCCESS and this: CairoStatus.Success
Re: comma operator causes hard to spot bugs
Benjamin Thaut wrote: > I just had a bug due to the unitentional usage of the comma operator. No language is able to read between the lines. Actually you moved a closing parenthesis over a lexical distance of four token. On this groundadition one can make up similar fruitless remarks. unintentional usage of exponential: | f( 1.0, 1.0e9) but wanted | fe9( 1.0, 1.0) -manfred
Re: Notice/Warning on narrowStrings .length
On Fri, Apr 27, 2012 at 12:20:13PM +0400, Dmitry Olshansky wrote: > On 27.04.2012 1:23, H. S. Teoh wrote: [...] > >What we *really* should be doing, esp. for commonly-used functions > >like computing various lengths, is to automatically process said > >tables and encode the computation in finite-state machines that can > >then be optimized at the FSM level (there are known algos for > >generating optimal FSMs), > > FSA are based on tables so it's all runs in the circle. Only the > layout changes. Yet the speed gains of non-decoding are huge. Yes, but hand-coded tables tend to go out of date, be prone to bugs, or are missing optimizations done by an FSA generator (e.g. a lexer generator). Collapsed FSA states, for example, can greatly reduce table size and speed things up. > codegen'd, and then optimized again at the assembly level by the > >compiler. These FSMs will operate at the native narrow string char > >type level, so that there will be no need for explicit decoding. > > > >The generation algo can then be run just once per unicode release, > >and everything will Just Work. > > > This year Unicode in D will receive a nice upgrade. > http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/dolsh/20002# > > Anyway keep me posted if you have these FSA ever come to soil your > sleep ;) [...] One area where autogenerated Unicode algos will be very useful is in normalization. Unicode normalization is non-trivial, to say the least; it involves looking up various character properties and performing mappings between them in a specified order. If we can encode this process as FSA, then we can let an automated FSA optimizer produce code that maps directly between the (non-decoded!) source string and the target (non-decoded!) normalized string. Similar things can be done for string concatenation (which requires arbitrarily-distant scanning in either direction from the joining point, though in normal use cases the distance should be very short). T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Re: The new std.process?
On Friday, 27 April 2012 at 20:47:10 UTC, Marco Leise wrote: Just stopping by to say I'm using your new std.process now. pipeProcess() is what I was looking for to compare the output> of a C program and the corresponding D port. Awesome. :) Please let us know if you discover any bugs, or if you see anything that could be improved. -Lars
Re: The new std.process?
On 4/28/12, Lars T. Kyllingstad wrote: > Please let us know if you discover any bugs, or if > you see anything that could be improved. I've been out of the loop, but is this compilable now in 2.059 or do we require some sort of DMC patch? https://github.com/kyllingstad/phobos.git
Re: The new std.process?
On 4/28/12, Andrej Mitrovic wrote: > On 4/28/12, Lars T. Kyllingstad wrote: >> Please let us know if you discover any bugs, or if >> you see anything that could be improved. > > I've been out of the loop, but is this compilable now in 2.059 or do > we require some sort of DMC patch? > https://github.com/kyllingstad/phobos.git > I mean for win32 btw.
Re: How can D become adopted at my company?
On Tuesday, 24 April 2012 at 12:50:27 UTC, Eljay wrote: --- And the most important bit of information: I use vi (Vim). I think that the type of application where D is proving itself right now is high performance server applications, and particularly web servers. D seems completely fit to replace Java on most server apps, with both better performance and better memory usage. The web interface to the newsgroups, as well as the recently revealed vibe.d web server seem to support this view. D can handle both batch and real time treatments really well I think. That is where it can gain a lot of weight in the enterprise, even before games and scientific applications.
Re: How can D become adopted at my company?
On Friday, 27 April 2012 at 23:28:09 UTC, SomeDude wrote: On Tuesday, 24 April 2012 at 12:50:27 UTC, Eljay wrote: --- And the most important bit of information: I use vi (Vim). I think that the type of application where D is proving itself right now is high performance server applications, and particularly web servers. D seems completely fit to replace Java on most server apps, with both better performance and better memory usage. The web interface to the newsgroups, as well as the recently revealed vibe.d web server seem to support this view. D can handle both batch and real time treatments really well I think. That is where it can gain a lot of weight in the enterprise, even before games and scientific applications. The other thing that would make it attractive among the C++ developers, would be the development of a lightweight, high performance, minimal library that doesn't use the GC at all. Ideally, it would be compatible with Phobos. I bet if such a library existed, flocks of C++ developers would suddenly switch to D.
Re: comma operator causes hard to spot bugs
On Friday, 27 April 2012 at 21:08:33 UTC, Manfred Nowak wrote: unintentional usage of exponential: | f( 1.0, 1.0e9) but wanted | fe9( 1.0, 1.0) I wait for the post where you admit that you made _that_ mistake in code as well. Sorry, but I think your own remark is quite a bit more fruitless than the one you were commenting on… David
Re: Notice/Warning on narrowStrings .length
On Friday, 27 April 2012 at 06:12:01 UTC, H. S. Teoh wrote: On Thu, Apr 26, 2012 at 09:55:54PM -0400, Nick Sabalausky wrote: [...] Crazy stuff! Some of them look rather similar to Arabic or Korean's Hangul (sp?), at least to my untrained eye. And then others are just *really* interesting-looking, like: http://www.omniglot.com/writing/12480.htm http://www.omniglot.com/writing/ayeri.htm http://www.omniglot.com/writing/oxidilogi.htm You're right though, if I were in charge of Unicode and tasked with handling some of those, I think I'd just say "Screw it. Unicode is now depricated. Use ASCII instead. Doesn't have the characters for your langauge? Tough! Fix your language!" :) You think that's crazy, huh? Check this out: http://www.omniglot.com/writing/sumerian.htm Now take a deep breath... ... this writing was *actually used* in ancient times. Yeah. Which means it probably has a Unicode block assigned to it, right now. :-) It was actually the first human writing ever. Which Phoenician scribe knew that his innovation of the alphabet would make programming easier thousands of years later?
Re: How can D become adopted at my company?
On Sat, Apr 28, 2012 at 01:31:32AM +0200, SomeDude wrote: [...] > The other thing that would make it attractive among the C++ > developers, would be the development of a lightweight, high > performance, minimal library that doesn't use the GC at all. Ideally, > it would be compatible with Phobos. I bet if such a library existed, > flocks of C++ developers would suddenly switch to D. I know the current GC leaves much room for improvement, but what's the hangup about the GC anyway? If -- and yes this is a very big if -- the GC has real-time guarantees, would that make it more palatable to C++ devs? Or is it just because they have trouble with the idea of having a GC in the first place? T -- Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel
Re: comma operator causes hard to spot bugs
On Saturday, 21 April 2012 at 16:54:49 UTC, bearophile wrote:
Jonathan M Davis:
There have been discussions about the comma operator before. I
don't expect that it's going anywhere,
Maybe there are intermediate solutions between keeping wild
commas in D and disallowing them fully. I think most of my bugs
caused by commas are similar to the one shown by the OP. This
means this is not a common source of bugs:
foo(), bar();
While this is sometimes a trap:
auto x = foo(), bar();
So maybe it's enough to disallow using the last expression of a
comma sequence as result of the whole expression? I don't know.
I almost never use commas for such purposes. What are the use
case for those commas?
Well here's my two cents. Commas should only be used to separate
parameters, and one exception to this is in for and foreach where
they have specific purposes. With the way automatic type
detection I would say instead remove them entirely. For the few
for cases where you need multiple commands, use a block statement
instead.
for(; c < x.length; c++, othercommands)
becomes
for(; c < x.length; {c++; othercommands;})
Actually seeing that you know the last block is together within
the {}'s. Could also add that for the init part, but not the
conditional. Course if it had to return something, then 'return'
could be applicable. No return, then it's automatically type void.
//TDPL pg 61
int a = 5
int b = 10
int c = (a = b, b = 7, 8);
becomes:
int c = {a = b; b = 7; 8;};
int c = {a = b; b = 7; return 8;};
int[] x;
foreach(i, val; x) //still applicable, but only real case now
that i can think of.
Like this it looks less like a function call and a scope
instead; but still returns something from a scope as it's return
value. Although then it's almost a lambda function, except
without calling parameters. Mmm thoughts?
Re: Cairo Deimos bindings
On Friday, 27 April 2012 at 20:49:54 UTC, Andrej Mitrovic wrote: On 4/27/12, Marco Leise wrote: In C: STATUS_SUCCESS In D unmodified: cairo_status_t.STATUS_SUCCESS In D with cosmetic changes: cairo_status_t.SUCCESS cairo_status_t.SUCCESS is like going halfway there but stopping. It looks rather ugly imo. I think you either want the existing C names, or names that *fully* fit the D coding style. So maybe the choice should be between this: cairo_status_t.STATUS_SUCCESS and this: CairoStatus.Success I'm going for the second one, due mostly to the fact that if I'm going to change the enum to fit in with D, I might make it fit in with D style-wise. The difference in style should help to make it obvious to spot. Also, most functions would get covered by a wrapper, but there is little use to wrapping enums, so it is worthwhile making it nice to work with in "normal" D code. -- James Miller
Re: comma operator causes hard to spot bugs
On Saturday, 28 April 2012 at 03:19:19 UTC, Era Scarecrow wrote:
becomes:
int c = {a = b; b = 7; 8;};
int c = {a = b; b = 7; return 8;};
Like this it looks less like a function call and a scope
instead; but still returns something from a scope as it's
return value. Although then it's almost a lambda function,
except without calling parameters. Mmm thoughts?
I tend to edit my text all over the place so sorry.
The first one {a = b; b = 7; 8;}; was suppose to have a note it
would error while assigning value of void return value.
Using the blocks/scope makes the book example look less like a
function call; But can still return something from a scope as
it's return value. Although then it's almost a lambda function
except without calling parameters.
Most likely it wouldn't return anything, if you needed a return
you use a lambda instead. So:
a = b; b = 7;
int c = 8; //returns void so there is simply no block
or
int c = (){a = b; b = 7; return 8;};
Re: generic indexOf() for arrays ?
On 4/28/12 3:51 AM, Brad Anderson wrote: On Friday, 27 April 2012 at 19:49:33 UTC, M.Gore wrote: I'd like to know if there's a generic function over arrays to find the index of a specific elemnt therein, something like, say: int indexOf(S) (in S[] arr, S elem); which works the same way the std.string.indexOf() function works... couldn't find anything in the std.array module for this scenario. Would be nice to have this functionality built-in somehow. Or is there a completely different / better approach to this in D? Thx, M. countUntil in std.algorithm should work fine. http://dlang.org/phobos/std_algorithm.html#countUntil Regards, Brad Anderson --- sizediff_t indexOf(alias pred = "a == b", R1, R2)(R1 haystack, R2 needle); Scheduled for deprecation. Please use std.algorithm.countUntil instead. Same as countUntil. This symbol has been scheduled for deprecation because it is easily confused with the homonym function in std.string. --- But isn't it the same funcionality? Why use a different name for the same funcionality?
Re: generic indexOf() for arrays ?
On Saturday, April 28, 2012 12:18:57 Ary Manzana wrote:
> But isn't it the same funcionality? Why use a different name for the
> same funcionality?
It's _not_ the same functionality, even if it's similar.
std.string.indexOf varies drastically from std.algorithm.countUntil and in a
way that easily leads to confusion if they're both named indexOf.
std.array.indexOf returns the index of the string that you passed in. That
number doesn't say _anything_ about how many characters are before that sub-
string. If str.indexOf("hello") returns 6, that's index 6, but it could be the
third character rather than the sixth, because strings are UTF-8 and therefore
variably-lengthed encoded.
std.algorithm.countUntil returns the number of elements in the range up to the
range passed in and does not necessarily have any relation with any index
(particularly if the range isn't random access). In the case of
str.countUntil("hello"), it will return one minus the number of the character
that "hello" starts at. So, if it's the third character, then the result will
be 2, whereas the result of std.string.indexOf could have been 6.
Also, the result of indexOf isn't necessarily an index (particularly in the
case of strings - but also in the case where a range is not random access), so
calling countUntil indexOf is arguably a poor choice.
- Jonathan M Davis
Re: More bugs...
Okay, final exams are coming up again, and so are my bugs (I have no idea
what the correlation is, don't ask...)
I guess I should post this on bugzilla, but oh well... I continued the
thread instead.
Try compiling this (I did this on Windows, DMD 2.059):
void main() { Foo!(int[])([[1], [2]]); }
struct Foo(T) { auto foo() { Foo!(T[]) t; return t; } }
Re: More bugs...
Oh sorry, here's the previous thread... somehow it got detached because of the subject line change: http://lists.puremagic.com/pipermail/digitalmars-d/2011-December/117172.html
Re: More bugs...
On Saturday, 28 April 2012 at 04:45:59 UTC, Mehrdad wrote:
Okay, final exams are coming up again, and so are my bugs (I
have no idea what the correlation is, don't ask...)
I guess I should post this on bugzilla, but oh well... I
continued the thread instead.
Try compiling this (I did this on Windows, DMD 2.059):
void main() { Foo!(int[])([[1], [2]]); }
struct Foo(T) { auto foo() { Foo!(T[]) t; return t; } }
You expected that to work? Extra extra, infinite recursion is
infinite! You are asking the compiler to instantiate Foo with the
type int[], then use that type to instantiate Foo with int[][],
which then instantiates Foo with type int[][][].
Try thinking about your code before mouthing off here. Would you
fault C for causing a stack overflow in this case:
int rec(int a){
return rec(a + 1);
}
I mean what did you expect, that the compiler could magically
create infinite types? I can't even see where you might have gone
wrong here, since the code is so simple. What I can see is that
the constructor wouldn't work because there are no fields. I can
see that you have some very strange ideas about templates, Foo(T)
instantiates Foo(T[]), which is a different type, so it goes
through and instantiates Foo(T[][]) which is, again, a different
type.
Think before declaring D to have bugs.
--
James Miller
Re: Notice/Warning on narrowStrings .length
"H. S. Teoh" wrote in message
news:mailman.1.1335507187.22023.digitalmar...@puremagic.com...
>
> For example, just today I was playing around with a regex-based version
> of formattedRead: you pass in a regex and a bunch of pointers, and the
> function uses compile-time introspection to convert regex matches into
> the correct value types. So you could call it like this:
>
> int year;
> string month;
> int day;
> regexRead(input, `(\d{4})\s+(\w+)\s+(\d{2})`, &year, &month, &day);
> [...]
That's pretty cool.
Re: More bugs...
You expected that to work?
Uhm, why not?
template
struct F
{
F > f() { return F >(); }
};
int main()
{
F().f().f().f().f().f(); // etc.
return 0;
}
Try thinking about your code before mouthing off here.
Not trying to to be rude, but did you think about *your* reason before
responding?
Re: comma operator causes hard to spot bugs
David Nadlinger wrote: > quite a bit more fruitless than the one you were commenting on May be. But then a definition of fruitfullness is missing. Walter once changed the language because a change of a "." to a "," or vice versa might change an actual parameter list from | (1,2.3) to | (1,2,3) That is a distance of zero for characters and token. The problem presented here shows distances of about twenty characters or four token. Does fruitfullness reach up to hundred characters or ten tokens? Please specify the upper bound. -manfred
