digitalmars.D - What's left for 1.0?
- Bill Baxter (7/7) Nov 16 2006 So, what's left on everyone's lists for D1.0 must-have features?
- Andre Osterhues (6/7) Nov 16 2006 I think that the "Design by Contract" methods need to be updated to matc...
- Bill Baxter (7/15) Nov 17 2006 Can you be a little more specific? What is it missing?
- Craig Black (14/14) Nov 16 2006 This is not a 1.0 blocker, but it is a blocker my development. D doesn'...
- Pragma (7/9) Nov 16 2006 Out of curiosity, what feature set are you looking for when it comes to
- Craig Black (7/14) Nov 16 2006 Like I said, full class loading would be nice, but my requirement is wha...
- Craig Black (8/22) Nov 16 2006 BTW, I didn't mean to belittle DDL in any way. Sorry if it seemed like ...
- Pragma (30/50) Nov 16 2006 Believe me, I know. This is *the* way to do things in an OOP-based
- Craig Black (8/58) Nov 16 2006 So it's possible for DDL to work in Linux. Are there plans for implemen...
- Pragma (41/46) Nov 16 2006 It's in the roadmap, although the milestones are really out of date.
- genie (12/12) Nov 16 2006 Well, I've been reading the D forums for quite a while with great
- Kyle Furlong (5/19) Nov 16 2006 A mostly complete port of the MinGW windows headers can be found here:
- genie (6/6) Nov 16 2006 Aye, I have tried a couple of SDK ports - they all require some
- Walter Bright (2/6) Nov 16 2006 I'm not sure why that wouldn't work now. What happens when you try it?
- Craig Black (4/10) Nov 16 2006 Can you load a DLL that implements an abstract class at run-time?
- Walter Bright (3/4) Nov 16 2006 Sure. Just like in C++. (Note that shared library support isn't there in...
- Craig Black (6/10) Nov 17 2006 Very good. I never tried it but for some reason always thought it could...
- Walter Bright (4/7) Nov 17 2006 Since D can call C functions, you can do it exactly the same way you do
- Craig Black (7/15) Nov 17 2006 Outstanding!
- Daniel Keep (9/19) Nov 17 2006 I believe there used to be one, but was taken out due to license
- John Reimer (5/17) Nov 17 2006 I think shared library support is available in gdc. Gdc works on more
- bobef (16/35) Dec 04 2006 I haven't been programming (for fun) for many months now and I decided
- Benji Smith (23/24) Nov 16 2006 Although D doesn't currently use a generational copying collector, it
- Bill Baxter (5/22) Nov 17 2006 You didn't get a lot of response to this. But it sounds reasonable to
- Jeff (2/2) Nov 20 2006 Though I don't really have anything interesting to add, I'll second
- Marcin Kuszczak (34/35) Nov 16 2006 I think that one thing which is missed in phobos right now is string cla...
- Aarti_pl (12/52) Nov 17 2006 I can not believe no one is using utf-8 characters in his program and is...
- Bill Baxter (14/25) Nov 17 2006 From previous discussions it seemed to me like there was a fair amount
- Samuel MV (5/34) Nov 17 2006 I don't think this is a library matter, because of it's the way char[]
- =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= (7/13) Nov 17 2006 Since D is a hybrid language, it needs string types AND a String class.
- Samuel MV (6/73) Nov 17 2006 char[] should be a real char[], not a sort of byte[] for text. It needs
- Bill Baxter (8/16) Nov 17 2006 That's what wchar and dchar are for. If all you want is to make sure
- Samuel MV (9/28) Nov 17 2006 Yep, memory is cheap, but then libraries has to support well
- Aarti_pl (10/29) Nov 17 2006 from my point of view currently char is just an "alias" for ubyte, and
- =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= (4/6) Nov 17 2006 char and wchar are nothing special, but char[] and wchar[] are magic.
- Aarti_pl (17/26) Nov 17 2006 so it works now? on dmd 0.172 it exits with:
- =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= (10/14) Nov 17 2006 Sure:
- Aarti_pl (17/36) Nov 17 2006 True... You are right...
- =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= (7/9) Nov 17 2006 I think that using dchar and the proposed "dstring" struct* would work ?
- Marcin Kuszczak (13/27) Nov 18 2006 Yes, that was my original proposal: dstring should be putted in standard
- =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= (10/21) Nov 18 2006 I don't think classes should be required. Built-in UTF strings are nice.
- Nahon (18/26) Nov 17 2006 If I create an a.d (ö is #f6):
- BCS (4/39) Nov 17 2006 http://www.digitalmars.com/d/lex.html
- Daniel Keep (23/26) Nov 17 2006 You can use Notepad to do it. Yes, the crappy old Notepad that comes
- Walter Bright (9/20) Nov 17 2006 Yes, I think you're right. Once one has a good handle on what UTF-8 is
- Bill Baxter (8/29) Nov 17 2006 I would like to try to use dchar[] as my standard string type, however
- Walter Bright (4/5) Nov 17 2006 "foo"d
- Bill Baxter (7/14) Nov 17 2006 Ok. Can you fix the link to StringLiterals on
- Alexander Panek (4/37) Nov 18 2006 Maybe this is interesting for you:
- Lars Ivar Igesund (6/17) Nov 19 2006 How so? I've never had any problems getting GVim probably setup for Unic...
- Daniel Keep (18/32) Nov 19 2006 It's basically a font problem. GVim allows you to select exactly two
- Lars Ivar Igesund (6/40) Nov 19 2006 Right, that is a usecase I've not needed to test :/
- Walter Bright (2/3) Nov 17 2006 One way is with Notepad - "Save As" and pick UTF-8.
- =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= (11/14) Nov 18 2006 I highly recommend *not* using a BOM with UTF-8,
- =?UTF-8?B?SnVsaW8gQ8Opc2FyIENhcnJhc2NhbCBVcnF1aWpv?= (3/10) Nov 18 2006 The added value appears when using tools that default to Latin1 unless
- Olli Aalto (22/26) Nov 20 2006 I'm not an expert on these things, but while reading Daniel Keep's
- Daniel Keep (19/59) Nov 20 2006 Imagine you compile the standard library with -version=UTF8. Let's take
- Olli Aalto (29/58) Nov 20 2006 How about if the standard library didn't use string? So it would still
- Walter Bright (3/3) Nov 20 2006 Something similar is done in the C world using #define UNICODE. It looks...
- =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= (12/15) Nov 20 2006 I always thought that in D it was whether to use char[] or wchar_t[] ?
- Bill Baxter (18/19) Nov 17 2006 For a language that has unheard of features like variadic template
- Kyle Furlong (2/30) Nov 17 2006 I agree this has been in the past and still is a weak point.
- Walter Bright (2/25) Nov 17 2006 C can't do any of those things.
- Bill Baxter (20/35) Nov 17 2006 C has no problem with this. I do it all the time:
- Walter Bright (10/47) Nov 17 2006 True, but that's only because C doesn't have dynamic arrays. In D,
- Samuel MV (8/68) Nov 18 2006 Ok, after reading this thread and testing some code it's obvious that I
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (6/15) Nov 18 2006 That is not C, that is C++, and gives a compiler error:
- Bill Baxter (34/82) Nov 18 2006 Yep it's great that D has built-in dynamic arrays, but the point is that...
- Johan Granberg (15/51) Nov 18 2006 I thought this would work but apparently it does not (what is the type o...
- Walter Bright (37/64) Nov 18 2006 If you want an array put into the static data segment,
- Bill Baxter (23/94) Nov 19 2006 Thanks for the reply.
- Walter Bright (2/4) Nov 22 2006 Possibly.
- Sean Kelly (5/55) Nov 18 2006 I think C++ 0x *might* be able to do this. They've added initializer
- Chris Miller (15/26) Nov 17 2006 ng!
- Chris Nicholson-Sauls (25/50) Nov 18 2006 Agreed. No idea off the top of my head, though, except maybe allowing s...
- Sean Kelly (6/25) Nov 18 2006 Maybe:
- BCS (10/20) Nov 19 2006 There is no way to differentiate between function overloads.
- Bill Baxter (4/30) Nov 19 2006 That should probably be an "error: ambiguous" if it isn't already, but
- Kirk McDonald (24/43) Nov 19 2006 I've played with just about every permutation of this problem during the...
- Bill Baxter (20/64) Nov 23 2006 Ugh. I just hit this using my flexible signals and slots wrapper.
- Bill Baxter (5/48) Nov 28 2006 If you had some extra condition like "I want to match the version with
- Kirk McDonald (7/21) Nov 28 2006 No, because there is no way to get another overload of a function beyond...
- Bill Baxter (10/29) Nov 28 2006 Hmm, I was hoping maybe there's a way to use a series of templates like
- Bill Baxter (34/67) Nov 28 2006 .. And it doesn't work. Just gives you the lexical ordering again:
- Stewart Gordon (13/43) Nov 28 2006 I can indeed. And indeed, trying to autotype such a thing should
So, what's left on everyone's lists for D1.0 must-have features? I glanced over the "Pending Peeves" list, but none of those things seems particularly serious to me. What about the iterators? Mostly that can be a library thing that comes after the 1.0 release, but it would be nice if foreach at least had the smarts built-in to use an iterator once the method names are decided upon. --bb
Nov 16 2006
== Quote from Bill Baxter (dnewsgroup billbaxter.com)'s articleSo, what's left on everyone's lists for D1.0 must-have features?I think that the "Design by Contract" methods need to be updated to match the documents. Still, there are no AssertException, InException, OutException, and InvariantException in Phobos. To me, Design by Contract is a killer feature seldom found in other languages, yet its implementation (sorry to say that) is still quite poor.
Nov 16 2006
Andre Osterhues wrote:== Quote from Bill Baxter (dnewsgroup billbaxter.com)'s articleCan you be a little more specific? What is it missing? As for the specific functions you listed, is the behavior you want them to have documented anywhere? And is there any reason you can't just write the functions yourself and submit them for approval? Do they require any additional compiler features? --bbSo, what's left on everyone's lists for D1.0 must-have features?I think that the "Design by Contract" methods need to be updated to match the documents. Still, there are no AssertException, InException, OutException, and InvariantException in Phobos. To me, Design by Contract is a killer feature seldom found in other languages, yet its implementation (sorry to say that) is still quite poor.
Nov 17 2006
This is not a 1.0 blocker, but it is a blocker my development. D doesn't have a good solution for cross-platform dynamic libraries. Full dynamic class loading would be nice, but D should at the very least do what C++ does and support overridding virtual method across DLL boundaries. I have a C++ code base that I want to port to D, but it uses an cross-platform plugin system that I can not replicate with D in its current state. I don't think this kind of functionality will get into 1.0, and that's OK, just as long as it does with the next year or so. Other than that, I can see no shortcoming in D that would hinder development. I'm really very anxious to port my code, but I don't want to start until D is ready. On the positive side of things, I forsee gobs and gobs of C++ template code shrinking down to nothing, and a fifteen minute compile time reduced to less than a minute. -Craig
Nov 16 2006
Craig Black wrote:This is not a 1.0 blocker, but it is a blocker my development. D doesn't have a good solution for cross-platform dynamic libraries.Out of curiosity, what feature set are you looking for when it comes to dynamic libs being "cross-platform"? Are you looking for write-once, deploy everywhere, some other killer feature, or is just seamless/effortless compilation-per-platform good enough? -- - EricAnderton at yahoo
Nov 16 2006
"Pragma" <ericanderton yahoo.removeme.com> wrote in message news:eji7vs$2cla$1 digitaldaemon.com...Craig Black wrote:Like I said, full class loading would be nice, but my requirement is what C++ currently offers. That is, I can compile the same code on Windows and Linux and get a .dll and an .so that are linked at run-time. I want to be able to use an abstract class to interface to them. -CraigThis is not a 1.0 blocker, but it is a blocker my development. D doesn't have a good solution for cross-platform dynamic libraries.Out of curiosity, what feature set are you looking for when it comes to dynamic libs being "cross-platform"? Are you looking for write-once, deploy everywhere, some other killer feature, or is just seamless/effortless compilation-per-platform good enough?
Nov 16 2006
"Craig Black" <cblack ara.com> wrote in message news:eji8g0$2dpp$1 digitaldaemon.com..."Pragma" <ericanderton yahoo.removeme.com> wrote in message news:eji7vs$2cla$1 digitaldaemon.com...BTW, I didn't mean to belittle DDL in any way. Sorry if it seemed like that is what I was doing. I might be able to use DDL instead of an abstract class if DDL worked in Linux. However, I don't think this is currently possible since last I heard DMD didn't produce shared objects in linux. Correct me if I'm wrong. -CraigCraig Black wrote:Like I said, full class loading would be nice, but my requirement is what C++ currently offers. That is, I can compile the same code on Windows and Linux and get a .dll and an .so that are linked at run-time. I want to be able to use an abstract class to interface to them.This is not a 1.0 blocker, but it is a blocker my development. D doesn't have a good solution for cross-platform dynamic libraries.Out of curiosity, what feature set are you looking for when it comes to dynamic libs being "cross-platform"? Are you looking for write-once, deploy everywhere, some other killer feature, or is just seamless/effortless compilation-per-platform good enough?
Nov 16 2006
Craig Black wrote:"Craig Black" <cblack ara.com> wrote in message news:eji8g0$2dpp$1 digitaldaemon.com...Believe me, I know. This is *the* way to do things in an OOP-based language. Once I saw java doing that 10 years ago, I haven't looked back. And to keep this marginally on-topic, I'll add that I never expect something like DDL to be embraced by Walter or DMD anyway. It's the kind of project that is really quite happy living as a lib."Pragma" <ericanderton yahoo.removeme.com> wrote in message news:eji7vs$2cla$1 digitaldaemon.com...Craig Black wrote:Like I said, full class loading would be nice, but my requirement is what C++ currently offers. That is, I can compile the same code on Windows and Linux and get a .dll and an .so that are linked at run-time. I want to be able to use an abstract class to interface to them.This is not a 1.0 blocker, but it is a blocker my development. D doesn't have a good solution for cross-platform dynamic libraries.Out of curiosity, what feature set are you looking for when it comes to dynamic libs being "cross-platform"? Are you looking for write-once, deploy everywhere, some other killer feature, or is just seamless/effortless compilation-per-platform good enough?BTW, I didn't mean to belittle DDL in any way. Sorry if it seemed like that is what I was doing. I might be able to use DDL instead of an abstract class if DDL worked in Linux. However, I don't think this is currently possible since last I heard DMD didn't produce shared objects in linux. Correct me if I'm wrong.It's no problem Craig. I know you've posted around here for a long time, but I couldn't recall (for the moment anyway) if you'd given it a shot yet or not. Plus I'm always fishing for better ways to do things, and insight from people who think it's not the right tool for the job. But to be fair DDL isn't 100% on Linux yet. Provided it was, you could do just what you're talking about: compile once per platform and deploy like you do with .dll and .so files now. DDL will be able to load ELF and Ar files much like it can do OMF .obj and .lib files now. As far as I know, DMD can create the needed file types to pull this off. DMD's shared-object capability (absent or not) isn't a problem, as DDL has a healthy appitite for ELF Modules straight from the compiler. The runtime linker does the rest. Futhermore, Shared-Objects of both the relocatable and non-relocatable varieties are by definition internally linked, which makes them questionable candidates for DDL's "full-linking" design anyway. I'm sure others will find creative ways to exploit them through DDL, but they're not a concern at this point. So that leaves only one sticking point: the differences in exception handling between operating systems (future 64bit compatibility notwithstanding). I haven't researched it fully, but I'm willing to bet that DDL could insert a thunk at link time that can bridge the gap for suitably coded (read: no OS-specific code) modules. -- - EricAnderton at yahoo
Nov 16 2006
So it's possible for DDL to work in Linux. Are there plans for implementing this in the near future? If so how long would you expect it to take? Also, it seems that Walter will eventually implement some kind of run-time reflection. How do you think native reflection would influence DDL? It seems to me that it would make it easier to do what you are doing. -Craig "Pragma" <ericanderton yahoo.removeme.com> wrote in message news:ejic3q$2jdj$1 digitaldaemon.com...Craig Black wrote:"Craig Black" <cblack ara.com> wrote in message news:eji8g0$2dpp$1 digitaldaemon.com...Believe me, I know. This is *the* way to do things in an OOP-based language. Once I saw java doing that 10 years ago, I haven't looked back. And to keep this marginally on-topic, I'll add that I never expect something like DDL to be embraced by Walter or DMD anyway. It's the kind of project that is really quite happy living as a lib."Pragma" <ericanderton yahoo.removeme.com> wrote in message news:eji7vs$2cla$1 digitaldaemon.com...Craig Black wrote:Like I said, full class loading would be nice, but my requirement is what C++ currently offers. That is, I can compile the same code on Windows and Linux and get a .dll and an .so that are linked at run-time. I want to be able to use an abstract class to interface to them.This is not a 1.0 blocker, but it is a blocker my development. D doesn't have a good solution for cross-platform dynamic libraries.Out of curiosity, what feature set are you looking for when it comes to dynamic libs being "cross-platform"? Are you looking for write-once, deploy everywhere, some other killer feature, or is just seamless/effortless compilation-per-platform good enough?BTW, I didn't mean to belittle DDL in any way. Sorry if it seemed like that is what I was doing. I might be able to use DDL instead of an abstract class if DDL worked in Linux. However, I don't think this is currently possible since last I heard DMD didn't produce shared objects in linux. Correct me if I'm wrong.It's no problem Craig. I know you've posted around here for a long time, but I couldn't recall (for the moment anyway) if you'd given it a shot yet or not. Plus I'm always fishing for better ways to do things, and insight from people who think it's not the right tool for the job. But to be fair DDL isn't 100% on Linux yet. Provided it was, you could do just what you're talking about: compile once per platform and deploy like you do with .dll and .so files now. DDL will be able to load ELF and Ar files much like it can do OMF .obj and .lib files now. As far as I know, DMD can create the needed file types to pull this off. DMD's shared-object capability (absent or not) isn't a problem, as DDL has a healthy appitite for ELF Modules straight from the compiler. The runtime linker does the rest. Futhermore, Shared-Objects of both the relocatable and non-relocatable varieties are by definition internally linked, which makes them questionable candidates for DDL's "full-linking" design anyway. I'm sure others will find creative ways to exploit them through DDL, but they're not a concern at this point. So that leaves only one sticking point: the differences in exception handling between operating systems (future 64bit compatibility notwithstanding). I haven't researched it fully, but I'm willing to bet that DDL could insert a thunk at link time that can bridge the gap for suitably coded (read: no OS-specific code) modules. -- - EricAnderton at yahoo
Nov 16 2006
Craig Black wrote:So it's possible for DDL to work in Linux. Are there plans for implementing this in the near future? If so how long would you expect it to take?It's in the roadmap, although the milestones are really out of date. It could be a very long time - weeks going into months - at the current level of manpower we have right now. Lars and I are working on it when we have time, but honestly, just grokking the spec (correctly) is going to eat up most of that. Having implemented OMF correctly (I'm pretty sure it's stable, it just needs some refactoring and TLC), I don't think ELF will take anywhere near as long. The upside is that the DDL core library is pretty much done. So the worst of it is loading and interpreting an ELF's data correctly.Also, it seems that Walter will eventually implement some kind of run-time reflection. How do you think native reflection would influence DDL? It seems to me that it would make it easier to do what you are doing.Honestly, I don't think Walter is going to go towards runtime introspection and reflection when he's so close to getting full introspection working great at compile-time. There are also problems with the sheer overhead of symbolic information. I think we're fare more likely to see this as a third-party thing, like a preprocessor that emits extra D code to cover where Typeinfo is lacking. But if D did have such a system in place, the only flaw would be that the .exe's compiled-in reflection system would likely be unaware of the dynamically loaded parts. DDL would have to provide a facade that makes access to the in-situ (.exe part) and dynamic reflection hooks, seamless. :) However, I am working on a fairly comprehensive runtime-reflection solution as a part of D. Since DDL's already playing with symbolic information, it's not a huge deal to serve it up in a way that's searchable and iterable. The only drawback is that it's limited to what gets exposed as symbols, so anything that's compiled into an offset or constant (struct/class fields, enums, etc) is lost. IMO functions, methods, modules and classes are adequate for most uses, so I'm going ahead with it. As to what would make it easier to do this, well I don't think reflection is the big stumbling block here. In order, the major hurdles have been: 1) Lack of experience (this is my first linker and module file loader) 2) Bad specifications (Just OMF. ELF has been a godsend by comparison) 3) Lack of working examples (there's Binutils and then there's DDL) 4) Loading & Linking problems are *very* hard to debug. That said, being able to extract anything useful from linked modules has been largely the work of Don and Tomasz. Actually, it's the one thing that folks using the lib have found easiest to improve. [another long-winded, rambling post by:] -- - EricAnderton at yahoo
Nov 16 2006
Well, I've been reading the D forums for quite a while with great interest but the news of upcoming v1 forced me into breaking the silence. Being an optimist, there are two features that I am dying to see in D to start using it in our production environment: well- fledged Win32 support (full SDK) and (ideally) an ability to use Microsoft DDK for driver development on D - this is the area where D would shine brightly. But SDK support is probably the biggest issue for me - I am quite well prepared now to shift some of the projected work in my company to D but can do that only in Windows platform infrastructure is ready. Just my 2c. Gene
Nov 16 2006
genie wrote:Well, I've been reading the D forums for quite a while with great interest but the news of upcoming v1 forced me into breaking the silence. Being an optimist, there are two features that I am dying to see in D to start using it in our production environment: well- fledged Win32 support (full SDK) and (ideally) an ability to use Microsoft DDK for driver development on D - this is the area where D would shine brightly. But SDK support is probably the biggest issue for me - I am quite well prepared now to shift some of the projected work in my company to D but can do that only in Windows platform infrastructure is ready. Just my 2c. GeneA mostly complete port of the MinGW windows headers can be found here: http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI Could you elaborate on which parts of the DDK you need? I just installed it, and can run bcd.gen on it, but its quite large.
Nov 16 2006
Aye, I have tried a couple of SDK ports - they all require some tweaking to work and I still have problems with some of the functionality. As of the driver support, I am mostly into NDIS-based development and D looks like a very good choice for safe and stable driver coding. 64- bit support would be great, too, but this can wait.
Nov 16 2006
Craig Black wrote:This is not a 1.0 blocker, but it is a blocker my development. D doesn't have a good solution for cross-platform dynamic libraries. Full dynamic class loading would be nice, but D should at the very least do what C++ does and support overridding virtual method across DLL boundaries.I'm not sure why that wouldn't work now. What happens when you try it?
Nov 16 2006
Can you load a DLL that implements an abstract class at run-time? -Craig "Walter Bright" <newshound digitalmars.com> wrote in message news:ejigt3$2o33$3 digitaldaemon.com...Craig Black wrote:This is not a 1.0 blocker, but it is a blocker my development. D doesn't have a good solution for cross-platform dynamic libraries. Full dynamic class loading would be nice, but D should at the very least do what C++ does and support overridding virtual method across DLL boundaries.I'm not sure why that wouldn't work now. What happens when you try it?
Nov 16 2006
Craig Black wrote:Can you load a DLL that implements an abstract class at run-time?Sure. Just like in C++. (Note that shared library support isn't there in the linux DMD yet, but this should work under Windows.)
Nov 16 2006
Very good. I never tried it but for some reason always thought it could not be done. Will Linux be getting this capability say, within a year or so? Also, is there a utility in phobos to load a DLL at run-time? -Craig "Walter Bright" <newshound digitalmars.com> wrote in message news:ejis3v$499$1 digitaldaemon.com...Craig Black wrote:Can you load a DLL that implements an abstract class at run-time?Sure. Just like in C++. (Note that shared library support isn't there in the linux DMD yet, but this should work under Windows.)
Nov 17 2006
Craig Black wrote:Very good. I never tried it but for some reason always thought it could not be done. Will Linux be getting this capability say, within a year or so?Yes.Also, is there a utility in phobos to load a DLL at run-time?Since D can call C functions, you can do it exactly the same way you do it in C for Windows, calling the same functions.
Nov 17 2006
"Walter Bright" <newshound digitalmars.com> wrote in message news:ejl0st$2rd9$1 digitaldaemon.com...Craig Black wrote:Outstanding!Very good. I never tried it but for some reason always thought it could not be done. Will Linux be getting this capability say, within a year or so?Yes.This is acceptable. However, it would be nice if there was a high level cross-platform way to do it. For example, Qt provides the QLibrary class. It provides the same interface for both Windows and Linux.. -CraigAlso, is there a utility in phobos to load a DLL at run-time?Since D can call C functions, you can do it exactly the same way you do it in C for Windows, calling the same functions.
Nov 17 2006
Craig Black wrote:...I believe there used to be one, but was taken out due to license concerns. Perhaps it's time to re-write it? -- Daniel -- Unlike Knuth, I have neither proven or tried the above; it may not even make sense. v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/This is acceptable. However, it would be nice if there was a high level cross-platform way to do it. For example, Qt provides the QLibrary class. It provides the same interface for both Windows and Linux.. -CraigAlso, is there a utility in phobos to load a DLL at run-time?Since D can call C functions, you can do it exactly the same way you do it in C for Windows, calling the same functions.
Nov 17 2006
On Fri, 17 Nov 2006 07:28:31 -0800, Craig Black <cblack ara.com> wrote:Very good. I never tried it but for some reason always thought it could not be done. Will Linux be getting this capability say, within a year or so? Also, is there a utility in phobos to load a DLL at run-time? -Craig "Walter Bright" <newshound digitalmars.com> wrote in message news:ejis3v$499$1 digitaldaemon.com...I think shared library support is available in gdc. Gdc works on more platforms anyway. I really wish it were the standard compiler, but unforunately this isn't possible. -JJRCraig Black wrote:Can you load a DLL that implements an abstract class at run-time?Sure. Just like in C++. (Note that shared library support isn't there in the linux DMD yet, but this should work under Windows.)
Nov 17 2006
I haven't been programming (for fun) for many months now and I decided to see what is happening to D and I see it will be called 1.0 soon. Many bugs fixed in the cangelog, so I decided to give it a try. Maybe even update rulesPlayer... Thread.getThis inside dynamically linked DLL still causes access violation. I brought up this long time ago but no attention was payed... I don't remember any details now but when I was dealing with the problem I dug deeper cause it was a real show stopper for me... So I really wouldn't call the DMD's DLL support 'decent'. I don't know if this will be ever fixed so lets hope for DDL :D struct point p={1,2}; is still not working!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! This is shocking for so advanced language! (I saw this was discussed but whatever I give my support on this point) Wish you the best guys. Craig Black wrote:This is not a 1.0 blocker, but it is a blocker my development. D doesn't have a good solution for cross-platform dynamic libraries. Full dynamic class loading would be nice, but D should at the very least do what C++ does and support overridding virtual method across DLL boundaries. I have a C++ code base that I want to port to D, but it uses an cross-platform plugin system that I can not replicate with D in its current state. I don't think this kind of functionality will get into 1.0, and that's OK, just as long as it does with the next year or so. Other than that, I can see no shortcoming in D that would hinder development. I'm really very anxious to port my code, but I don't want to start until D is ready. On the positive side of things, I forsee gobs and gobs of C++ template code shrinking down to nothing, and a fifteen minute compile time reduced to less than a minute. -Craig
Dec 04 2006
Bill Baxter wrote:So, what's left on everyone's lists for D1.0 must-have features?Although D doesn't currently use a generational copying collector, it would be nice if we could anticipate the hurdles to implementing a copying GC in the current language, and develop some syntactic extensions to the language for copying with a copying GC. In a language like Java, where there are only reference types and primitives (i.e., no pointers), the implementation of a copying GC is pretty straightforward, because when an object gets moved to a new location in memory, you never have to worry that it will leave behind a orphaned pointer. unsafe, and certain objects or pointers can be temporarily "pinned" to their current memory location. If the GC thread comes to life during the execution of an unsafe block, the GC will ignore any objects or pointers that have been pinned at their current location. Those items will be collected later, during a subsequent GC run, after they've been "un-pinned". It would be nice, before version 1.0 of D, to get the syntax in place for pinning pointers. With the current GC, all objects are permanently "pinned" anyhow, so this implementation would be semantically correct, even if it didn't do anything :) But at least, with the syntax in place, we'd be prepared for the eventual introduction of a generational copying GC, when such a thing is inevitably implemented. --benji
Nov 16 2006
Benji Smith wrote:Bill Baxter wrote: > So, what's left on everyone's lists for D1.0 must-have features? Although D doesn't currently use a generational copying collector, it would be nice if we could anticipate the hurdles to implementing a copying GC in the current language, and develop some syntactic extensions to the language for copying with a copying GC. [...] It would be nice, before version 1.0 of D, to get the syntax in place for pinning pointers. With the current GC, all objects are permanently "pinned" anyhow, so this implementation would be semantically correct, even if it didn't do anything :) But at least, with the syntax in place, we'd be prepared for the eventual introduction of a generational copying GC, when such a thing is inevitably implemented. --benjiYou didn't get a lot of response to this. But it sounds reasonable to me. The slowness of the garbage collector seems to come up as a topic fairly regularly here. --bb
Nov 17 2006
Though I don't really have anything interesting to add, I'll second this, since it's important to me.
Nov 20 2006
Bill Baxter wrote:So, what's left on everyone's lists for D1.0 must-have features?I think that one thing which is missed in phobos right now is string class which encapsulates utf-8/utf-16/utf-32 handling and issues connected with utf-8 strings e.g.: char[] foo = "hög"; assert(foo.length == 3); // Sorry UTF-8, this is == 4 assert(foo[1] == 'ö'); // Not a chance! It's really annoying to write application in language different than English (or multi-language application) using just currently available language support (please note that I am not saying that in C++ it's better :-) - I am just saying that it could be greatly improved). Problems which I see with current language support are: 1. You need 3 types of functions which are doing same, but getting different char arrays - char[]/wchar[]/dchar[] as parameters, to write good API you have to write. Best (maybe I should write worst ;-) ) example is Phobos API 2. It's quite easy to make wrong assumptions about utf-8 encoded arrays. See example above. It could cause slicing string in wrong place, making it improperly formatted utf-8 string. 3. What is char[] is probably not so clear for newbies. Especially for utf-8: is char really one character/code point? 4. String class should be more than just array of characters. It should probably have some more methods like e.g. removing characters from middle of string and much more. Some time ago Chris Miller posted on news list dstring implementation which looks quite good for me(link to site: http://www.dprogramming.com/dstring.php). But if Walter is not happy enough with this implementation now maybe there should be at least added alias in object.d: alias char[] string; I personally vote for dstring. -- Regards Marcin Kuszczak (Aarti_pl)
Nov 16 2006
I can not believe no one is using utf-8 characters in his program and is not concerned about issues with current D char[] implementation, so I repost my previous post. Sorry about reposting - if no one will comment I will get a lesson and thing that maybe this issue is not so much important. But preferably I will get some even negative comments about importance of having string class built in... For me string class is something what could significantly improve quality of libraries for D. Best Regards Marcin Kuszczak Marcin Kuszczak napisał(a):Bill Baxter wrote:So, what's left on everyone's lists for D1.0 must-have features?I think that one thing which is missed in phobos right now is string class which encapsulates utf-8/utf-16/utf-32 handling and issues connected with utf-8 strings e.g.: char[] foo = "hög"; assert(foo.length == 3); // Sorry UTF-8, this is == 4 assert(foo[1] == 'ö'); // Not a chance! It's really annoying to write application in language different than English (or multi-language application) using just currently available language support (please note that I am not saying that in C++ it's better :-) - I am just saying that it could be greatly improved). Problems which I see with current language support are: 1. You need 3 types of functions which are doing same, but getting different char arrays - char[]/wchar[]/dchar[] as parameters, to write good API you have to write. Best (maybe I should write worst ;-) ) example is Phobos API 2. It's quite easy to make wrong assumptions about utf-8 encoded arrays. See example above. It could cause slicing string in wrong place, making it improperly formatted utf-8 string. 3. What is char[] is probably not so clear for newbies. Especially for utf-8: is char really one character/code point? 4. String class should be more than just array of characters. It should probably have some more methods like e.g. removing characters from middle of string and much more. Some time ago Chris Miller posted on news list dstring implementation which looks quite good for me(link to site: http://www.dprogramming.com/dstring.php). But if Walter is not happy enough with this implementation now maybe there should be at least added alias in object.d: alias char[] string; I personally vote for dstring.
Nov 17 2006
Aarti_pl wrote:I can not believe no one is using utf-8 characters in his program and is not concerned about issues with current D char[] implementation, so I repost my previous post. Sorry about reposting - if no one will comment I will get a lesson and thing that maybe this issue is not so much important. But preferably I will get some even negative comments about importance of having string class built in... For me string class is something what could significantly improve quality of libraries for D.From previous discussions it seemed to me like there was a fair amount of support for a string class. I think the lack of response could be just that not so many folks feel like it is a "must-have" for 1.0. I think anything that can be done in a library can wait till post 1.0. C++ had very little in the way of a standard library at "1.0" (and really it still has very little). But for 1.0, the language itself better be in a state that it is *possible* to write every library on the wish list. If there is anything in the language itself that would prevent creating a string class like the one you speak of, then I think that needs to be addressed. But the string class itself can come later. Of course if dstring really is good enough as-is, then it might as well be in the std library for 1.0. --bb
Nov 17 2006
I don't think this is a library matter, because of it's the way char[] works. If 'hög' or 'aún' aren't 3 chars, it's broken ... :( Best regards, Samuel. Bill Baxter escribió:Aarti_pl wrote:I can not believe no one is using utf-8 characters in his program and is not concerned about issues with current D char[] implementation, so I repost my previous post. Sorry about reposting - if no one will comment I will get a lesson and thing that maybe this issue is not so much important. But preferably I will get some even negative comments about importance of having string class built in... For me string class is something what could significantly improve quality of libraries for D.From previous discussions it seemed to me like there was a fair amount of support for a string class. I think the lack of response could be just that not so many folks feel like it is a "must-have" for 1.0. I think anything that can be done in a library can wait till post 1.0. C++ had very little in the way of a standard library at "1.0" (and really it still has very little). But for 1.0, the language itself better be in a state that it is *possible* to write every library on the wish list. If there is anything in the language itself that would prevent creating a string class like the one you speak of, then I think that needs to be addressed. But the string class itself can come later. Of course if dstring really is good enough as-is, then it might as well be in the std library for 1.0. --bb
Nov 17 2006
Bill Baxter wrote:Since D is a hybrid language, it needs string types AND a String class. And since Phobos isn't a pure OOP library, the lack of a pure OOP string class isn't all that surprising. Especially after bashing std::string... But it would be nice to have one "official" String class, instead of everyone inventing their own which seems to be inevitable otherwise ? --andersFor me string class is something what could significantly improve quality of libraries for D.From previous discussions it seemed to me like there was a fair amount of support for a string class. I think the lack of response could be just that not so many folks feel like it is a "must-have" for 1.0.
Nov 17 2006
This is *very* serious for i18n:char[] should be a real char[], not a sort of byte[] for text. It needs to be fix for non-english. Best regards, Samuel. Aarti_pl escribió:char[] foo = "hög"; assert(foo.length == 3); // Sorry UTF-8, this is == 4 assert(foo[1] == 'ö'); // Not a chance!I can not believe no one is using utf-8 characters in his program and is not concerned about issues with current D char[] implementation, so I repost my previous post. Sorry about reposting - if no one will comment I will get a lesson and thing that maybe this issue is not so much important. But preferably I will get some even negative comments about importance of having string class built in... For me string class is something what could significantly improve quality of libraries for D. Best Regards Marcin Kuszczak Marcin Kuszczak napisał(a):Bill Baxter wrote:So, what's left on everyone's lists for D1.0 must-have features?I think that one thing which is missed in phobos right now is string class which encapsulates utf-8/utf-16/utf-32 handling and issues connected with utf-8 strings e.g.: char[] foo = "hög"; assert(foo.length == 3); // Sorry UTF-8, this is == 4 assert(foo[1] == 'ö'); // Not a chance! It's really annoying to write application in language different than English (or multi-language application) using just currently available language support (please note that I am not saying that in C++ it's better :-) - I am just saying that it could be greatly improved). Problems which I see with current language support are: 1. You need 3 types of functions which are doing same, but getting different char arrays - char[]/wchar[]/dchar[] as parameters, to write good API you have to write. Best (maybe I should write worst ;-) ) example is Phobos API 2. It's quite easy to make wrong assumptions about utf-8 encoded arrays. See example above. It could cause slicing string in wrong place, making it improperly formatted utf-8 string. 3. What is char[] is probably not so clear for newbies. Especially for utf-8: is char really one character/code point? 4. String class should be more than just array of characters. It should probably have some more methods like e.g. removing characters from middle of string and much more. Some time ago Chris Miller posted on news list dstring implementation which looks quite good for me(link to site: http://www.dprogramming.com/dstring.php). But if Walter is not happy enough with this implementation now maybe there should be at least added alias in object.d: alias char[] string; I personally vote for dstring.
Nov 17 2006
Samuel MV wrote:This is *very* serious for i18n: >> char[] foo = "hög"; >> assert(foo.length == 3); // Sorry UTF-8, this is == 4 >> assert(foo[1] == 'ö'); // Not a chance! char[] should be a real char[], not a sort of byte[] for text. It needs to be fix for non-english.That's what wchar and dchar are for. If all you want is to make sure your chars are chars, then use dchar everywhere and be happy. Just be aware that dchars are 32bits a piece. Not a big deal for most apps, but could be for a few. Is there any problem with dchar other than just the size of it being massive overkill for western languages? --bb
Nov 17 2006
Yep, memory is cheap, but then libraries has to support well char/wchar/dchar (quite unusual) ... I think that there should be only one kind of char, that internally works as UTF8, UTF16 or UTF32 (automatically or on demand), but you don't care about it except when you need to interface with non-D libraries, files, etc. (solved with a couple of functions) Best Regards, Samuel. Bill Baxter escribió:Samuel MV wrote:This is *very* serious for i18n: >> char[] foo = "hög"; >> assert(foo.length == 3); // Sorry UTF-8, this is == 4 >> assert(foo[1] == 'ö'); // Not a chance! char[] should be a real char[], not a sort of byte[] for text. It needs to be fix for non-english.That's what wchar and dchar are for. If all you want is to make sure your chars are chars, then use dchar everywhere and be happy. Just be aware that dchars are 32bits a piece. Not a big deal for most apps, but could be for a few. Is there any problem with dchar other than just the size of it being massive overkill for western languages? --bb
Nov 17 2006
Bill Baxter napisał(a):Samuel MV wrote:from my point of view currently char is just an "alias" for ubyte, and could/should be removed because it is superfluous. You can not make even char letter="ą"; // polish character a + , and in current state it is confusing... Maybe only dchar should be left and dchar should be renamed to char?... But ok. I can live with char... But I think good string class is really necessary in all cases... Regards Marcin KuszczakThis is *very* serious for i18n: >> char[] foo = "hög"; >> assert(foo.length == 3); // Sorry UTF-8, this is == 4 >> assert(foo[1] == 'ö'); // Not a chance! char[] should be a real char[], not a sort of byte[] for text. It needs to be fix for non-english.That's what wchar and dchar are for. If all you want is to make sure your chars are chars, then use dchar everywhere and be happy. Just be aware that dchars are 32bits a piece. Not a big deal for most apps, but could be for a few. Is there any problem with dchar other than just the size of it being massive overkill for western languages? --bb
Nov 17 2006
Aarti_pl wrote:from my point of view currently char is just an "alias" for ubyte, and could/should be removed because it is superfluous.char and wchar are nothing special, but char[] and wchar[] are magic. If those used ubyte[] and ushort[], code point looping wouldn't work. --anders
Nov 17 2006
Anders F Björklund napisał(a):Aarti_pl wrote:so it works now? on dmd 0.172 it exits with: Error: invalid UTF8 sequence ------------ import std.stdio; void main() { char[] text="Łóżko"; foreach(c; text) { writefln(c); } } -------------- With string class (e.g. dstring) it could work and some of magic could be removed from compiler :-). But now running this program is just disaster :-< It doesn't seem that char is in any way different from ubyte... BR Marcin Kuszczakfrom my point of view currently char is just an "alias" for ubyte, and could/should be removed because it is superfluous.char and wchar are nothing special, but char[] and wchar[] are magic. If those used ubyte[] and ushort[], code point looping wouldn't work. --anders
Nov 17 2006
Aarti_pl wrote:Sure: import std.stdio; void main() { char[] text="Łóżko"; foreach(wchar c; text) { writefln(c); } } --anderschar and wchar are nothing special, but char[] and wchar[] are magic. If those used ubyte[] and ushort[], code point looping wouldn't work.so it works now?
Nov 17 2006
Anders F Björklund napisał(a):Aarti_pl wrote:True... You are right... But anyway I don't think that we need magic in compiler... I would say that we need straightforward solutions which could be easily used. Making size of char equal to 4 bytes, and having string class, which can optimize different encodings would allow to get rid of all magic... :-) Below is just a dream: ubyte/ushort/char for different internal representation; string could optimize texts for speed or memory consumption Regards Marcin KuszczakSure: import std.stdio; void main() { char[] text="Łóżko"; foreach(wchar c; text) { writefln(c); } } --anderschar and wchar are nothing special, but char[] and wchar[] are magic. If those used ubyte[] and ushort[], code point looping wouldn't work.so it works now?
Nov 17 2006
Aarti_pl wrote:Making size of char equal to 4 bytes, and having string class, which can optimize different encodings would allow to get rid of all magic... :-)I think that using dchar and the proposed "dstring" struct* would work ? (not that I think it becomes less magic if you hide it behind a curtain) We need D "char" to be a 1-byte type for all future, or this won't work: extern (C) int printf(char *, ...); --anders * http://www.dprogramming.com/dstring.php
Nov 17 2006
Anders F Björklund wrote:Aarti_pl wrote:Yes, that was my original proposal: dstring should be putted in standard library. Or at least: alias char[] string; I would be already happy about it. Processing utf-8 strings in different places in std library/compiler/user code instead of one string class I would rather consider bad practice...Making size of char equal to 4 bytes, and having string class, which can optimize different encodings would allow to get rid of all magic... :-)I think that using dchar and the proposed "dstring" struct* would work ? (not that I think it becomes less magic if you hide it behind a curtain)We need D "char" to be a 1-byte type for all future, or this won't work: extern (C) int printf(char *, ...);Is it really not possible to solve? Maybe putting in extern(C) ubyte instead of char and allowing compiler silently translate it in this block to char for linking probably would solve problem...--anders * http://www.dprogramming.com/dstring.php-- Regards Marcin Kuszczak (Aarti_pl)
Nov 18 2006
Marcin Kuszczak wrote:Yes, that was my original proposal: dstring should be putted in standard library. Or at least: alias char[] string; I would be already happy about it.I think both should go in Phobos. Both string alias and dstring struct.Processing utf-8 strings in different places in std library/compiler/user code instead of one string class I would rather consider bad practice...I don't think classes should be required. Built-in UTF strings are nice.It's not a technical problem. D wants the familiar C types as a feature. I think using char and char[] (as "string") as an improvement over C is OK, and then recommend dchar and dstring as the "D way" of doing it ? And then if you use a real OOP stdlib like Mango, you move to String... (using classes also offers one solution to the mutable/immutable issue) Then D covers the entire "spectrum", from printf to writef to Writers. --andersWe need D "char" to be a 1-byte type for all future, or this won't work: extern (C) int printf(char *, ...);Is it really not possible to solve? Maybe putting in extern(C) ubyte instead of char and allowing compiler silently translate it in this block to char for linking probably would solve problem...
Nov 18 2006
Marcin Kuszczak wrote:I think that one thing which is missed in phobos right now is string class which encapsulates utf-8/utf-16/utf-32 handling and issues connected with utf-8 strings e.g.: char[] foo = "hög"; assert(foo.length == 3); // Sorry UTF-8, this is == 4 assert(foo[1] == 'ö'); // Not a chance!My Win version doesn't even start to parse the source file if an ASCII127 character is present even if it is in a comment!If I create an a.d (ö is #f6): void main() { //hög } And then run: $ dmd a The result is: a.d(3): invalid UTF-8 sequence I think that would be nice to somehow tell the parser which format is the source file. It could be a command line parameter -encoding:ANSI|UTF-8|etc. or the first line of the file should contain that like //!Encoding: ANSI Regards, Nahon
Nov 17 2006
Nahon wrote:Marcin Kuszczak wrote:http://www.digitalmars.com/d/lex.html look for BOM However, I don't known how to put in a BOM.I think that one thing which is missed in phobos right now is string class which encapsulates utf-8/utf-16/utf-32 handling and issues connected with utf-8 strings e.g.: char[] foo = "hög"; assert(foo.length == 3); // Sorry UTF-8, this is == 4 assert(foo[1] == 'ö'); // Not a chance!My Win version doesn't even start to parse the source file if an ASCII >127 character is present even if it is in a comment! If I create an a.d (ö is #f6): void main() { //hög } And then run: $ dmd a The result is: a.d(3): invalid UTF-8 sequence I think that would be nice to somehow tell the parser which format is the source file. It could be a command line parameter -encoding:ANSI|UTF-8|etc. or the first line of the file should contain that like //!Encoding: ANSI Regards, Nahon
Nov 17 2006
BCS wrote:... However, I don't known how to put in a BOM.You can use Notepad to do it. Yes, the crappy old Notepad that comes with Windows. When you go File -> Save As, make sure to set the encoding as appropriate. I'm still very annoyed that Notepad has better Unicode support than GVim_<.<2¢> Also, I think this whole discussion is highlighting a misunderstanding on how strings work in D. Some people seem to be looking at D's string support and thinking "Oh, it looks just like a scripting language, so <X> should work the same; what the?! It doesn't?! Must be broken!" They don't seem to understand *why* we have char, wchar and dchar. I think it's time we had an article either in a D manual (do we even, strictly speaking, HAVE a manual for D?[1]) or somewhere on the website so we can say: "No, it's not broken; it's just different. Go here and all shall become clear." </2¢> -- Daniel -- Unlike Knuth, I have neither proven or tried the above; it may not even make sense. v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Nov 17 2006
Daniel Keep wrote:Also, I think this whole discussion is highlighting a misunderstanding on how strings work in D. Some people seem to be looking at D's string support and thinking "Oh, it looks just like a scripting language, so <X> should work the same; what the?! It doesn't?! Must be broken!" They don't seem to understand *why* we have char, wchar and dchar. I think it's time we had an article either in a D manual (do we even, strictly speaking, HAVE a manual for D?[1]) or somewhere on the website so we can say: "No, it's not broken; it's just different. Go here and all shall become clear."Yes, I think you're right. Once one has a good handle on what UTF-8 is (and UTF-16 and UCS-4), it all makes sense. D provides several different ways of looking at characters (and strings) and none of them are quite like C++ (which essentially has no support for international characters) or like scripting languages (which hide all the details, making them inefficient). I've thought more than once about writing an article about it, but got distracted by other things.
Nov 17 2006
Walter Bright wrote:Daniel Keep wrote:Also, I think this whole discussion is highlighting a misunderstanding on how strings work in D. Some people seem to be looking at D's string support and thinking "Oh, it looks just like a scripting language, so <X> should work the same; what the?! It doesn't?! Must be broken!" They don't seem to understand *why* we have char, wchar and dchar. I think it's time we had an article either in a D manual (do we even, strictly speaking, HAVE a manual for D?[1]) or somewhere on the website so we can say: "No, it's not broken; it's just different. Go here and all shall become clear."Yes, I think you're right. Once one has a good handle on what UTF-8 is (and UTF-16 and UCS-4), it all makes sense. D provides several different ways of looking at characters (and strings) and none of them are quite like C++ (which essentially has no support for international characters) or like scripting languages (which hide all the details, making them inefficient).I've thought more than once about writing an article about it, but got distracted by other things.I would like to try to use dchar[] as my standard string type, however it doesn't seem to be supported as well by the compiler and library as char[] is. For instance std.string has basically nothing for dchar[]s. And there doesn't seem to be a dchar string literal syntax. At least I couldn't find it. The section on StringLiterals linked to from the expressions page is non-existant. --bb
Nov 17 2006
Bill Baxter wrote:And there doesn't seem to be a dchar string literal syntax."foo"d cast(dchar)"foo" both work.
Nov 17 2006
Walter Bright wrote:Bill Baxter wrote:Ok. Can you fix the link to StringLiterals on http://www.digitalmars.com/d/expression.html There's a link there in the PrimaryExpressions overview right in between CharacterLiteral and ArrayLiteral, but the target does not exist, and the docs jump straight from CharacterLiteral to ArrayLiteral. --bbAnd there doesn't seem to be a dchar string literal syntax."foo"d cast(dchar)"foo" both work.
Nov 17 2006
Maybe this is interesting for you: http://www.dprogramming.com/dstring.php Alex Bill Baxter wrote:Walter Bright wrote:Daniel Keep wrote:Also, I think this whole discussion is highlighting a misunderstanding on how strings work in D. Some people seem to be looking at D's string support and thinking "Oh, it looks just like a scripting language, so <X> should work the same; what the?! It doesn't?! Must be broken!" They don't seem to understand *why* we have char, wchar and dchar. I think it's time we had an article either in a D manual (do we even, strictly speaking, HAVE a manual for D?[1]) or somewhere on the website so we can say: "No, it's not broken; it's just different. Go here and all shall become clear."Yes, I think you're right. Once one has a good handle on what UTF-8 is (and UTF-16 and UCS-4), it all makes sense. D provides several different ways of looking at characters (and strings) and none of them are quite like C++ (which essentially has no support for international characters) or like scripting languages (which hide all the details, making them inefficient).I've thought more than once about writing an article about it, but got distracted by other things.I would like to try to use dchar[] as my standard string type, however it doesn't seem to be supported as well by the compiler and library as char[] is. For instance std.string has basically nothing for dchar[]s. And there doesn't seem to be a dchar string literal syntax. At least I couldn't find it. The section on StringLiterals linked to from the expressions page is non-existant. --bb
Nov 18 2006
Daniel Keep wrote:BCS wrote:How so? I've never had any problems getting GVim probably setup for Unicode. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi... However, I don't known how to put in a BOM.You can use Notepad to do it. Yes, the crappy old Notepad that comes with Windows. When you go File -> Save As, make sure to set the encoding as appropriate. I'm still very annoyed that Notepad has better Unicode support than GVim
Nov 19 2006
Lars Ivar Igesund wrote:Daniel Keep wrote:It's basically a font problem. GVim allows you to select exactly two fonts: a "normal" monospace font, and a "wide" font (which is used for things like kanji.) The problem is that once you've picked those fonts, GVim will never use anything else. This is a pain because you end up with heaps of unknown Unicode characters. For example, none of the weird characters I used in the examples for my article on text in D show up in GVim (except for the hiragana since I have a Japanese font installed) but they all show up in Notepad which falls over to other fonts if the one it's using doesn't have that character. There appear to be options for selecting a set of fonts to use, but they don't work on Windows. -- Daniel -- Unlike Knuth, I have neither proven or tried the above; it may not even make sense. v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/BCS wrote:How so? I've never had any problems getting GVim probably setup for Unicode.... However, I don't known how to put in a BOM.You can use Notepad to do it. Yes, the crappy old Notepad that comes with Windows. When you go File -> Save As, make sure to set the encoding as appropriate. I'm still very annoyed that Notepad has better Unicode support than GVim
Nov 19 2006
Daniel Keep wrote:Lars Ivar Igesund wrote:Right, that is a usecase I've not needed to test :/ -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsiviDaniel Keep wrote:It's basically a font problem. GVim allows you to select exactly two fonts: a "normal" monospace font, and a "wide" font (which is used for things like kanji.) The problem is that once you've picked those fonts, GVim will never use anything else. This is a pain because you end up with heaps of unknown Unicode characters. For example, none of the weird characters I used in the examples for my article on text in D show up in GVim (except for the hiragana since I have a Japanese font installed) but they all show up in Notepad which falls over to other fonts if the one it's using doesn't have that character. There appear to be options for selecting a set of fonts to use, but they don't work on Windows. -- DanielBCS wrote:How so? I've never had any problems getting GVim probably setup for Unicode.... However, I don't known how to put in a BOM.You can use Notepad to do it. Yes, the crappy old Notepad that comes with Windows. When you go File -> Save As, make sure to set the encoding as appropriate. I'm still very annoyed that Notepad has better Unicode support than GVim
Nov 19 2006
BCS wrote:However, I don't known how to put in a BOM.One way is with Notepad - "Save As" and pick UTF-8.
Nov 17 2006
Walter Bright wrote:I highly recommend *not* using a BOM with UTF-8, and instead only use it with UTF-16 and UTF-32... There are several Unix tools that choke on the BOM, adding it will make those fail for no added value ? I think the OP was using a non-Unicode text format, and as we know that isn't supported at all by D... More entries for the "D future features not planned": Q: Will D support non-UTF text editors or consoles ? A: No. Nein. Non. Nej. いいえ. --andersHowever, I don't known how to put in a BOM.One way is with Notepad - "Save As" and pick UTF-8.
Nov 18 2006
Anders F Björklund wrote:Walter Bright wrote:The added value appears when using tools that default to Latin1 unless they see a BOM.One way is with Notepad - "Save As" and pick UTF-8.I highly recommend *not* using a BOM with UTF-8, and instead only use it with UTF-16 and UTF-32... There are several Unix tools that choke on the BOM, adding it will make those fail for no added value ?
Nov 18 2006
Marcin Kuszczak wrote:But if Walter is not happy enough with this implementation now maybe there should be at least added alias in object.d: alias char[] string;I'm not an expert on these things, but while reading Daniel Keep's excellent article on text in D, I got an idea about the alias declaration. Why not have something like this in either object.d or std.string? version(UTF8) { alias char[] string; } version(UTF16) { alias wchar[] string; } version(UTF32) { alias dchar[] string; } It would default to UTF8, if not defined on command line. This way everyone could use the version their application requires. Am I way out of line here? As I said I'm not an expert and don't know if that just creates more problems. O.
Nov 20 2006
Olli Aalto wrote:Marcin Kuszczak wrote:Imagine you compile the standard library with -version=UTF8. Let's take the following function:But if Walter is not happy enough with this implementation now maybe there should be at least added alias in object.d: alias char[] string;I'm not an expert on these things, but while reading Daniel Keep's excellent article on text in D, I got an idea about the alias declaration. Why not have something like this in either object.d or std.string? version(UTF8) { alias char[] string; } version(UTF16) { alias wchar[] string; } version(UTF32) { alias dchar[] string; } It would default to UTF8, if not defined on command line. This way everyone could use the version their application requires. Am I way out of line here? As I said I'm not an expert and don't know if that just creates more problems. O.int find(string s, dchar c) { ... }This would be compiled as:int find(char[] s, dchar c) { ... }You then write some code to use that:... string attr = "key:value"; ... auto pos = find(attr, ':'); ...For whatever reason, your program will run optimally using UTF-32.dmd -version=UTF32 app.dBut that means that in the standard library, "string" is really "char[]", and in your program it's "dchar[]". You try to link against the standard library, and the linker barfs (quite correctly) since the function you're using doesn't exist. It's a nice idea, but with the current object formats, and the way conditional compilation works, I don't think it's actually possible. -- Daniel P.S. See sig. -- Unlike Knuth, I have neither proven or tried the above; it may not even make sense. v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Nov 20 2006
Daniel Keep wrote:Imagine you compile the standard library with -version=UTF8. Let's take the following function:How about if the standard library didn't use string? So it would still have 3 versions of find for example?Something like this: int find(char[], char c) { ... } int find(wchar[], wchar c) { ... } int find(dchar[], dchar c) { ... } void foo() { string attr = "key:value"; ... auto pos = find(attr, ':'); ... } Wouldn't that link properly? Hmm... Probably not good enough. This whole idea is based on the assumption that the application writer knows the environment where and how his/her application will be used. If the application was compiled as UTF-8 and it gets a UTF-32 character as input, it would not be very good? Would the coder be required to put all the input through std.utf.toUTF8()? Or is that something that should be done even now? Well, you all seem to be smart people so I'm content to wait for whatever you come up with. :)int find(string s, dchar c) { ... }This would be compiled as:int find(char[] s, dchar c) { ... }You then write some code to use that:... string attr = "key:value"; ... auto pos = find(attr, ':'); ...For whatever reason, your program will run optimally using UTF-32.Yes, I got the feeling that it was a little too simple. :) Personally I think I'll stick mostly to dchar[]s in real applications and char[]s in test programs. Memory is cheap enough these days that it doesn't matter to me right now. O.dmd -version=UTF32 app.dBut that means that in the standard library, "string" is really "char[]", and in your program it's "dchar[]". You try to link against the standard library, and the linker barfs (quite correctly) since the function you're using doesn't exist. It's a nice idea, but with the current object formats, and the way conditional compilation works, I don't think it's actually possible.
Nov 20 2006
Something similar is done in the C world using #define UNICODE. It looks like a good idea, but it's awful. Applications just don't want to be *all* UNICODE or *no* UNICODE. Most want to be mixed.
Nov 20 2006
Walter Bright wrote:Something similar is done in the C world using #define UNICODE. It looks like a good idea, but it's awful. Applications just don't want to be *all* UNICODE or *no* UNICODE. Most want to be mixed.I always thought that in D it was whether to use char[] or wchar_t[] ? In wxD there will be two versions: version(ANSI) means that it will use char[] in D and char* in C++ and version(UNICODE) means that it will use wchar_t[] in D and wchar_t* in C++ - for the wxString class. At least that's needed for the implementation, unsure about public API. All the wx methods are using "string" parameters now, which is an alias for the default char[] type in D. This might change to "dstring" later, if that struct wrapper has merits to unify code better on the D side... I really don't want to do two functions for each string-using method ? --anders PS. wchar_t is an alias which is wchar in Windows and dchar in Unix.
Nov 20 2006
Bill Baxter wrote:So, what's left on everyone's lists for D1.0 must-have features?For a language that has unheard of features like variadic template support (!) one thing that seems oddly immature to me is support for static initializers. Things like: * No way to initialize a static array without counting elements static byte[???] imageData = [...]; // i hope you like counting! * No way to initialize a dynamic array with a known length byte[] imageData; imageData.length = 5; // two steps - meh * No way to initialize array of strings char[][] list = ["eggs","bacon","milk","break"]; //uh uh * No way to initialize non-static struct Point p = { x:1.0, y:2.0 }; // nope...not static * No way to initialize associative array char[int] strTable = {"hello":5, "hi":2, "greetings":9}; // no way I know things have gotten much better since the old days, when there weren't even array literals (yikes!), but it still looks pretty primitive in some ways compared to C. --bb
Nov 17 2006
Bill Baxter wrote:Bill Baxter wrote:I agree this has been in the past and still is a weak point.So, what's left on everyone's lists for D1.0 must-have features?For a language that has unheard of features like variadic template support (!) one thing that seems oddly immature to me is support for static initializers. Things like: * No way to initialize a static array without counting elements static byte[???] imageData = [...]; // i hope you like counting! * No way to initialize a dynamic array with a known length byte[] imageData; imageData.length = 5; // two steps - meh * No way to initialize array of strings char[][] list = ["eggs","bacon","milk","break"]; //uh uh * No way to initialize non-static struct Point p = { x:1.0, y:2.0 }; // nope...not static * No way to initialize associative array char[int] strTable = {"hello":5, "hi":2, "greetings":9}; // no way I know things have gotten much better since the old days, when there weren't even array literals (yikes!), but it still looks pretty primitive in some ways compared to C. --bb
Nov 17 2006
Bill Baxter wrote:For a language that has unheard of features like variadic template support (!) one thing that seems oddly immature to me is support for static initializers. Things like: * No way to initialize a static array without counting elements static byte[???] imageData = [...]; // i hope you like counting! * No way to initialize a dynamic array with a known length byte[] imageData; imageData.length = 5; // two steps - meh * No way to initialize array of strings char[][] list = ["eggs","bacon","milk","break"]; //uh uh * No way to initialize non-static struct Point p = { x:1.0, y:2.0 }; // nope...not static * No way to initialize associative array char[int] strTable = {"hello":5, "hi":2, "greetings":9}; // no way I know things have gotten much better since the old days, when there weren't even array literals (yikes!), but it still looks pretty primitive in some ways compared to C.C can't do any of those things.
Nov 17 2006
Walter Bright wrote:C can't do any of those things.Sure it can.C has no problem with this. I do it all the time: static const unsigned char[] = { 1,2,3,4,5,6,7, 255 };* No way to initialize a static array without counting elements static byte[???] imageData = [...]; // i hope you like counting!C has no problem with this (using malloc, its own concept of "dynamic arrays"): byte* imageData = (byte*)malloc(5*sizeof(byte)); A better comparison is C++, which has no problem with it's std library vector class: vector<int> imageData(5);* No way to initialize a dynamic array with a known length byte[] imageData; imageData.length = 5; // two steps - mehC can do this: char *list[] = { "eggs","bacon","milk","break" };* No way to initialize array of strings char[][] list = ["eggs","bacon","milk","break"]; //uh uhC has no problem with that either: struct Point { float x, y; }; void foo() { Point p = {1.0,2.0}; } (and C99 can do it with the x: y: syntax too, I think)* No way to initialize non-static struct Point p = { x:1.0, y:2.0 }; // nope...not staticWell you got me there. C can't do that.* No way to initialize associative array char[int] strTable = {"hello":5, "hi":2, "greetings":9}; // no way--bbI know things have gotten much better since the old days, when there weren't even array literals (yikes!), but it still looks pretty primitive in some ways compared to C.
Nov 17 2006
Bill Baxter wrote:Walter Bright wrote: > C can't do any of those things. Sure it can.True, but that's only because C doesn't have dynamic arrays. In D, const char[] c = [ 1,2,3,4,5,6,7, 255 ]; works fine, though it's a dynamic array.C has no problem with this. I do it all the time: static const unsigned char[] = { 1,2,3,4,5,6,7, 255 };* No way to initialize a static array without counting elements static byte[???] imageData = [...]; // i hope you like counting!D: auto imageData = new byte[5];C has no problem with this (using malloc, its own concept of "dynamic arrays"): byte* imageData = (byte*)malloc(5*sizeof(byte));* No way to initialize a dynamic array with a known length byte[] imageData; imageData.length = 5; // two steps - mehA better comparison is C++, which has no problem with it's std library vector class: vector<int> imageData(5);Yah got me there, C++ is one character shorter.So can D: char *list[] = [ "eggs","bacon","milk","break" ]; char[] list[] = [ "eggs","bacon","milk","break" ];C can do this: char *list[] = { "eggs","bacon","milk","break" };* No way to initialize array of strings char[][] list = ["eggs","bacon","milk","break"]; //uh uhTrue. I forgot it could (replacing "Point" with "struct Point").C has no problem with that either: struct Point { float x, y; }; void foo() { Point p = {1.0,2.0}; }* No way to initialize non-static struct Point p = { x:1.0, y:2.0 }; // nope...not static
Nov 17 2006
Ok, after reading this thread and testing some code it's obvious that I need to read again the D documentation, and after that, read it again ;-) Probably, for most of us, there are lots of hidden little gems in D ... and the docs need some update and/or extension to show this properly. Maybe for v1.0 we could organize a collaborative project for 'The D Tutorial' ... Samuel. Walter Bright escribi:Bill Baxter wrote:Walter Bright wrote: > C can't do any of those things. Sure it can.True, but that's only because C doesn't have dynamic arrays. In D, const char[] c = [ 1,2,3,4,5,6,7, 255 ]; works fine, though it's a dynamic array.C has no problem with this. I do it all the time: static const unsigned char[] = { 1,2,3,4,5,6,7, 255 };* No way to initialize a static array without counting elements static byte[???] imageData = [...]; // i hope you like counting!D: auto imageData = new byte[5];C has no problem with this (using malloc, its own concept of "dynamic arrays"): byte* imageData = (byte*)malloc(5*sizeof(byte));* No way to initialize a dynamic array with a known length byte[] imageData; imageData.length = 5; // two steps - mehA better comparison is C++, which has no problem with it's std library vector class: vector<int> imageData(5);Yah got me there, C++ is one character shorter.So can D: char *list[] = [ "eggs","bacon","milk","break" ]; char[] list[] = [ "eggs","bacon","milk","break" ];C can do this: char *list[] = { "eggs","bacon","milk","break" };* No way to initialize array of strings char[][] list = ["eggs","bacon","milk","break"]; //uh uhTrue. I forgot it could (replacing "Point" with "struct Point").C has no problem with that either: struct Point { float x, y; }; void foo() { Point p = {1.0,2.0}; }* No way to initialize non-static struct Point p = { x:1.0, y:2.0 }; // nope...not static
Nov 18 2006
Walter Bright wrote:That is not C, that is C++, and gives a compiler error: "error: `Point' undeclared (first use in this function)" In C you need the usual typedef-on-the-go workaround: typedef struct Point { float x, y; } Point; --andersC has no problem with that either: struct Point { float x, y; }; void foo() { Point p = {1.0,2.0}; }True. I forgot it could (replacing "Point" with "struct Point").
Nov 18 2006
Walter Bright wrote:Bill Baxter wrote:Yep it's great that D has built-in dynamic arrays, but the point is that the syntax for dynamic arrays is getting in the way of static arrays, making something that's simple in C become hard in D. If you want a static array you have no choice right now but to count up the elements, or deliberately use the wrong length to trigger compiler errors that will tell you the right length. If D has some other convenient and portable way to embed data like icons and images into one's exe, then I'd be interested in hearing about it, but for right now it seems to me like working with static data is a pain in D. Anyway, this one thing has actually been the biggest annoyance I've run across in trying to port C++ code to D. Most things become easier, but this one thing is harder in D.Walter Bright wrote: > C can't do any of those things. Sure it can.True, but that's only because C doesn't have dynamic arrays. In D, const char[] c = [ 1,2,3,4,5,6,7, 255 ]; works fine, though it's a dynamic array.C has no problem with this. I do it all the time: static const unsigned char[] = { 1,2,3,4,5,6,7, 255 };* No way to initialize a static array without counting elements static byte[???] imageData = [...]; // i hope you like counting!Ok, that's good enough for that one. Thanks. I didn't realize new'ing an array like that was allowed (and compatible with setting .length).D: auto imageData = new byte[5];C has no problem with this (using malloc, its own concept of "dynamic arrays"): byte* imageData = (byte*)malloc(5*sizeof(byte));* No way to initialize a dynamic array with a known length byte[] imageData; imageData.length = 5; // two steps - mehNope, D cannot: dchar.d(12): Error: cannot implicitly convert expression ("bacon") of type char[5] to char[4] As someone pointed out though, you can make it work by making everything dynamic: char[] list[] = [ "eggs"[],"bacon","milk","break" ]; But, then you're making everything dynamic when it should be static. Correct me if I'm wrong, but in the C/C++ version of this above, basically everything is static. The strings will be embedded into the exe, and the array will just consist of pointers directly to those strings in the data segment. But in the D version you'll have that same data in the data segment, and then you'll also make dynamic copies of all the data onto the heap at runtime. I don't want two copies of all my static data, especially if one of those copies requires runtime heap allocations.So can D: char *list[] = [ "eggs","bacon","milk","break" ]; char[] list[] = [ "eggs","bacon","milk","break" ];C can do this: char *list[] = { "eggs","bacon","milk","break" };* No way to initialize array of strings char[][] list = ["eggs","bacon","milk","break"]; //uh uhRight -- struct Point. It's been ages since I had to deal with C's "typedef struct foo { } foo;" sillyness. --bbTrue. I forgot it could (replacing "Point" with "struct Point").C has no problem with that either: struct Point { float x, y; }; void foo() { Point p = {1.0,2.0}; }* No way to initialize non-static struct Point p = { x:1.0, y:2.0 }; // nope...not static
Nov 18 2006
Bill Baxter wrote:Walter Bright wrote:I thought this would work but apparently it does not (what is the type of an array literal?) //begin code static foo=[cast(ubyte)1,2,3,4,5]; void main() { printf("%d\n",foo.sizeof); } //end code I get this error johan Dragon:~$ dmd test.d test.d(4): Error: cannot infer type from initializer which feels strange as i thought array literals defaulted to fixed size arrays.Bill Baxter wrote:Yep it's great that D has built-in dynamic arrays, but the point is that the syntax for dynamic arrays is getting in the way of static arrays, making something that's simple in C become hard in D. If you want a static array you have no choice right now but to count up the elements, or deliberately use the wrong length to trigger compiler errors that will tell you the right length. If D has some other convenient and portable way to embed data like icons and images into one's exe, then I'd be interested in hearing about it, but for right now it seems to me like working with static data is a pain in D. Anyway, this one thing has actually been the biggest annoyance I've run across in trying to port C++ code to D. Most things become easier, but this one thing is harder in D.Walter Bright wrote: > C can't do any of those things. Sure it can.True, but that's only because C doesn't have dynamic arrays. In D, const char[] c = [ 1,2,3,4,5,6,7, 255 ]; works fine, though it's a dynamic array.C has no problem with this. I do it all the time: static const unsigned char[] = { 1,2,3,4,5,6,7, 255 };* No way to initialize a static array without counting elements static byte[???] imageData = [...]; // i hope you like counting!
Nov 18 2006
Bill Baxter wrote:Walter Bright wrote:If you want an array put into the static data segment, static const char[] c = [ 1,2,3,4,5,6,7, 255 ]; will do it.const char[] c = [ 1,2,3,4,5,6,7, 255 ]; works fine, though it's a dynamic array.Yep it's great that D has built-in dynamic arrays, but the point is that the syntax for dynamic arrays is getting in the way of static arrays, making something that's simple in C become hard in D. If you want a static array you have no choice right now but to count up the elements, or deliberately use the wrong length to trigger compiler errors that will tell you the right length.The following D program: ------------------ char *list[] = [ "eggs","bacon","milk","break" ]; char[] list2[] = [ "eggs","bacon","milk","break" ]; ------------------ compiles without error.So can D: char *list[] = [ "eggs","bacon","milk","break" ];> char[] list[] = [ "eggs","bacon","milk","break" ]; Nope, D cannot: dchar.d(12): Error: cannot implicitly convert expression ("bacon") of type char[5] to char[4]But, then you're making everything dynamic when it should be static. Correct me if I'm wrong, but in the C/C++ version of this above, basically everything is static. The strings will be embedded into the exe, and the array will just consist of pointers directly to those strings in the data segment. But in the D version you'll have that same data in the data segment, and then you'll also make dynamic copies of all the data onto the heap at runtime. I don't want two copies of all my static data, especially if one of those copies requires runtime heap allocations.In the above D program, everything is put into the static data segment. Here's an excerpt from the object file: _DATA segment db 065h,067h,067h,073h,000h,062h,061h,063h db 06fh,06eh,000h,06dh,069h,06ch,06bh,000h db 062h,072h,065h,061h,06bh,000h,000h,000h dd offset FLAT:_DATA dd offset FLAT:_DATA[5] dd offset FLAT:_DATA[0Bh] dd offset FLAT:_DATA[010h] _D4test4listAPa: db 004h,000h,000h,000h dd offset FLAT:_DATA[018h] db 065h,067h,067h,073h,000h,062h,061h,063h db 06fh,06eh,000h,06dh,069h,06ch,06bh,000h db 062h,072h,065h,061h,06bh,000h,000h,000h db 004h,000h,000h,000h dd offset FLAT:_D4test4listAPa[8] db 005h,000h,000h,000h dd offset FLAT:_D4test4listAPa[0Dh] db 004h,000h,000h,000h dd offset FLAT:_D4test4listAPa[013h] db 005h,000h,000h,000h dd offset FLAT:_D4test4listAPa[018h] _D4test5list2AAa: db 004h,000h,000h,000h dd offset FLAT:_D4test4listAPa[020h]
Nov 18 2006
Thanks for the reply. So in short, are you saying that static const char[] c = [1,2,3,4,5,6]; really does not cause any heap allocations? If so then that's exactly what I want. However, if that is the case then this should work: static const ubyte[] icon1 = [1,2,3,4,5]; static const ubyte[] icon2 = [1,2,3,4,5]; static const ubyte[] icon3 = [1,2,3,4,5]; static const ubyte*[] all_icons = [&icon1[0], &icon2[0], &icon3[0] ]; But it gives errors like: staticdata.d(7): Error: non-constant expression cast(ubyte*)(icon1) This, however, works: static const ubyte[5] icon1 = [1,2,3,4,5]; static const ubyte[5] icon2 = [1,2,3,4,5]; static const ubyte[5] icon3 = [1,2,3,4,5]; static const ubyte*[] all_icons = [&icon1[0], &icon2[0], &icon3[0] ]; The error messages are the main thing that led me to believe that the former must be doing dynamic heap allocations. So is this whole issue really just a bug with deducing what's const and what's not? --bb Walter Bright wrote:Bill Baxter wrote:Walter Bright wrote:If you want an array put into the static data segment, static const char[] c = [ 1,2,3,4,5,6,7, 255 ]; will do it.const char[] c = [ 1,2,3,4,5,6,7, 255 ]; works fine, though it's a dynamic array.Yep it's great that D has built-in dynamic arrays, but the point is that the syntax for dynamic arrays is getting in the way of static arrays, making something that's simple in C become hard in D. If you want a static array you have no choice right now but to count up the elements, or deliberately use the wrong length to trigger compiler errors that will tell you the right length.The following D program: ------------------ char *list[] = [ "eggs","bacon","milk","break" ]; char[] list2[] = [ "eggs","bacon","milk","break" ]; ------------------ compiles without error.So can D: char *list[] = [ "eggs","bacon","milk","break" ];> char[] list[] = [ "eggs","bacon","milk","break" ]; Nope, D cannot: dchar.d(12): Error: cannot implicitly convert expression ("bacon") of type char[5] to char[4]But, then you're making everything dynamic when it should be static. Correct me if I'm wrong, but in the C/C++ version of this above, basically everything is static. The strings will be embedded into the exe, and the array will just consist of pointers directly to those strings in the data segment. But in the D version you'll have that same data in the data segment, and then you'll also make dynamic copies of all the data onto the heap at runtime. I don't want two copies of all my static data, especially if one of those copies requires runtime heap allocations.In the above D program, everything is put into the static data segment. Here's an excerpt from the object file: _DATA segment db 065h,067h,067h,073h,000h,062h,061h,063h db 06fh,06eh,000h,06dh,069h,06ch,06bh,000h db 062h,072h,065h,061h,06bh,000h,000h,000h dd offset FLAT:_DATA dd offset FLAT:_DATA[5] dd offset FLAT:_DATA[0Bh] dd offset FLAT:_DATA[010h] _D4test4listAPa: db 004h,000h,000h,000h dd offset FLAT:_DATA[018h] db 065h,067h,067h,073h,000h,062h,061h,063h db 06fh,06eh,000h,06dh,069h,06ch,06bh,000h db 062h,072h,065h,061h,06bh,000h,000h,000h db 004h,000h,000h,000h dd offset FLAT:_D4test4listAPa[8] db 005h,000h,000h,000h dd offset FLAT:_D4test4listAPa[0Dh] db 004h,000h,000h,000h dd offset FLAT:_D4test4listAPa[013h] db 005h,000h,000h,000h dd offset FLAT:_D4test4listAPa[018h] _D4test5list2AAa: db 004h,000h,000h,000h dd offset FLAT:_D4test4listAPa[020h]
Nov 19 2006
Bill Baxter wrote:So is this whole issue really just a bug with deducing what's const and what's not?Possibly.
Nov 22 2006
Bill Baxter wrote:Walter Bright wrote: > C can't do any of those things. Sure it can.I think C++ 0x *might* be able to do this. They've added initializer lists for vectors, but I can't remember offhand if they will work for maps as well. SeanC has no problem with this. I do it all the time: static const unsigned char[] = { 1,2,3,4,5,6,7, 255 };* No way to initialize a static array without counting elements static byte[???] imageData = [...]; // i hope you like counting!C has no problem with this (using malloc, its own concept of "dynamic arrays"): byte* imageData = (byte*)malloc(5*sizeof(byte)); A better comparison is C++, which has no problem with it's std library vector class: vector<int> imageData(5);* No way to initialize a dynamic array with a known length byte[] imageData; imageData.length = 5; // two steps - mehC can do this: char *list[] = { "eggs","bacon","milk","break" };* No way to initialize array of strings char[][] list = ["eggs","bacon","milk","break"]; //uh uhC has no problem with that either: struct Point { float x, y; }; void foo() { Point p = {1.0,2.0}; } (and C99 can do it with the x: y: syntax too, I think)* No way to initialize non-static struct Point p = { x:1.0, y:2.0 }; // nope...not staticWell you got me there. C can't do that.* No way to initialize associative array char[int] strTable = {"hello":5, "hi":2, "greetings":9}; // no way
Nov 18 2006
On Fri, 17 Nov 2006 23:45:59 -0500, Bill Baxter = <dnewsgroup billbaxter.com> wrote:Bill Baxter wrote:* No way to initialize a static array without counting elements static byte[???] imageData =3D [...]; // i hope you like counti=ng! Perhaps specifying 0 should be the convenient syntax: static byte[0] imageData =3D [...]; // real length replaced* No way to initialize a dynamic array with a known length byte[] imageData; imageData.length =3D 5; // two steps - mehauto imageData =3D new byte[5];* No way to initialize array of strings char[][] list =3D ["eggs","bacon","milk","break"]; //uh uhThis is a weird one but here is a workaround: char[][] list =3D ["eggs"[],"bacon","milk","break"]; but since static and const array initializers can get by without this = workaround, so should initializers for other arrays.* No way to initialize non-static struct Point p =3D { x:1.0, y:2.0 }; // nope...not staticAgreed; workaround is to use a const dummy: const Point p_init =3D { x:1.0, y:2.0 }; Point p =3D p_init;* No way to initialize associative array char[int] strTable =3D {"hello":5, "hi":2, "greetings":9}; // no =way I'd be OK if this were a 2.0 thing.
Nov 17 2006
Bill Baxter wrote:Bill Baxter wrote:Agreed. No idea off the top of my head, though, except maybe allowing something like:So, what's left on everyone's lists for D1.0 must-have features?For a language that has unheard of features like variadic template support (!) one thing that seems oddly immature to me is support for static initializers. Things like: * No way to initialize a static array without counting elements static byte[???] imageData = [...]; // i hope you like counting!* No way to initialize a dynamic array with a known length byte[] imageData; imageData.length = 5; // two steps - mehWorks right now.* No way to initialize array of strings char[][] list = ["eggs","bacon","milk","break"]; //uh uhThere are two ways to do it, right now... but I do still agree they aren't particulary* No way to initialize non-static struct Point p = { x:1.0, y:2.0 }; // nope...not staticThis has annoyed me as well. We can get a tuple of a struct now, for goodness sakes; surely we can accomplish a simple little initializer!* No way to initialize associative array char[int] strTable = {"hello":5, "hi":2, "greetings":9}; // no wayDitto. The closest I can offer is Cashew again: I made the thing, and yet even I cringe.I know things have gotten much better since the old days, when there weren't even array literals (yikes!), but it still looks pretty primitive in some ways compared to C. --bbIts the paradox/irony of D, it seems. Hopefully these things get taken care of in the next month or so, before its "too late"! -- Chris Nicholson-Sauls
Nov 18 2006
Bill Baxter wrote:Bill Baxter wrote:Maybe: static imageData = [cast(byte) ...];So, what's left on everyone's lists for D1.0 must-have features?For a language that has unheard of features like variadic template support (!) one thing that seems oddly immature to me is support for static initializers. Things like: * No way to initialize a static array without counting elements static byte[???] imageData = [...]; // i hope you like counting!* No way to initialize a dynamic array with a known length byte[] imageData; imageData.length = 5; // two steps - mehbyte[] imageData = new byte[5];* No way to initialize array of strings char[][] list = ["eggs","bacon","milk","break"]; //uh uh * No way to initialize non-static struct Point p = { x:1.0, y:2.0 }; // nope...not static * No way to initialize associative array char[int] strTable = {"hello":5, "hi":2, "greetings":9}; // no wayThe rest would be nice to have, though. Sean
Nov 18 2006
Bill Baxter wrote:So, what's left on everyone's lists for D1.0 must-have features? I glanced over the "Pending Peeves" list, but none of those things seems particularly serious to me. What about the iterators? Mostly that can be a library thing that comes after the 1.0 release, but it would be nice if foreach at least had the smarts built-in to use an iterator once the method names are decided upon. --bbThere is no way to differentiate between function overloads. int foo(){ return 0;} int foo(int i){ return 0;} int bob() { // foo() or foo(int)? auto fn = &foo; auto tmp = TemplateTakingFn!(foo); }
Nov 19 2006
BCS wrote:Bill Baxter wrote:That should probably be an "error: ambiguous" if it isn't already, but anyway can't you do 'int function() fn = &foo' to get the one you want? --bbSo, what's left on everyone's lists for D1.0 must-have features? I glanced over the "Pending Peeves" list, but none of those things seems particularly serious to me. What about the iterators? Mostly that can be a library thing that comes after the 1.0 release, but it would be nice if foreach at least had the smarts built-in to use an iterator once the method names are decided upon. --bbThere is no way to differentiate between function overloads. int foo(){ return 0;} int foo(int i){ return 0;} int bob() { // foo() or foo(int)? auto fn = &foo; auto tmp = TemplateTakingFn!(foo); }
Nov 19 2006
Bill Baxter wrote:BCS wrote:I've played with just about every permutation of this problem during the course of writing Pyd. int foo() { return 0; } int foo(int i) { return 0; } void main() { auto fn = &foo; // Uses the lexically first function static assert(is(typeof(fn) == int function())); fn(); //fn(12); // Error: expected 0 arguments, not 1 int function(int) fn2 = &foo; // Works fn2(12); } In writing Pyd, I've come to the conclusion that if you have a template that accepts an arbitrary function as an alias parameter (and then does anything involving the type of that function), you should always have a second parameter representing the type of the function. (And you can easily make this second parameter have a default value of typeof(&fn).) In this way the user can be sure the template is getting the proper overload of the function. -- Kirk McDonald Pyd: Wrapping Python with D http://pyd.dsource.orgThere is no way to differentiate between function overloads. int foo(){ return 0;} int foo(int i){ return 0;} int bob() { // foo() or foo(int)? auto fn = &foo; auto tmp = TemplateTakingFn!(foo); }That should probably be an "error: ambiguous" if it isn't already, but anyway can't you do 'int function() fn = &foo' to get the one you want? --bb
Nov 19 2006
Kirk McDonald wrote:Bill Baxter wrote:Ugh. I just hit this using my flexible signals and slots wrapper. widget.value_changed.fconnect(&other_widget.value); Doh! I really don't want writing a gui to involve gobs of code like: widget.value_changed.fconnect!( typeof(&other_widget.value))(&other_widget.value); Now I really wish I had a tool to find property-like methods in my source code so I can at least make sure they are in the right lexical ordering. :-( Has there been any bug/enhancement filed on this that I can keep a watch on? For my case I'm not even sure what would be the right thing for it to do. What I really need to happen is for fconnect to prefer methods with non-trivial argument lists, but I can't rule out the possibility someone actually wants to connect up a no-argument slot like "updateGui()" to a signal. Maybe we need to be able to optionally specify the arguments when taking a delegates, like: connect(&obj.value(int)); -bbBCS wrote:I've played with just about every permutation of this problem during the course of writing Pyd. int foo() { return 0; } int foo(int i) { return 0; } void main() { auto fn = &foo; // Uses the lexically first function static assert(is(typeof(fn) == int function())); fn(); //fn(12); // Error: expected 0 arguments, not 1 int function(int) fn2 = &foo; // Works fn2(12); } In writing Pyd, I've come to the conclusion that if you have a template that accepts an arbitrary function as an alias parameter (and then does anything involving the type of that function), you should always have a second parameter representing the type of the function. (And you can easily make this second parameter have a default value of typeof(&fn).) In this way the user can be sure the template is getting the proper overload of the function.There is no way to differentiate between function overloads. int foo(){ return 0;} int foo(int i){ return 0;} int bob() { // foo() or foo(int)? auto fn = &foo; auto tmp = TemplateTakingFn!(foo); }That should probably be an "error: ambiguous" if it isn't already, but anyway can't you do 'int function() fn = &foo' to get the one you want? --bb
Nov 23 2006
Kirk McDonald wrote:Bill Baxter wrote:If you had some extra condition like "I want to match the version with the most arguments" can you think of some way to make that work with the current D? --bbBCS wrote:I've played with just about every permutation of this problem during the course of writing Pyd. int foo() { return 0; } int foo(int i) { return 0; } void main() { auto fn = &foo; // Uses the lexically first function static assert(is(typeof(fn) == int function())); fn(); //fn(12); // Error: expected 0 arguments, not 1 int function(int) fn2 = &foo; // Works fn2(12); } In writing Pyd, I've come to the conclusion that if you have a template that accepts an arbitrary function as an alias parameter (and then does anything involving the type of that function), you should always have a second parameter representing the type of the function. (And you can easily make this second parameter have a default value of typeof(&fn).) In this way the user can be sure the template is getting the proper overload of the function.There is no way to differentiate between function overloads. int foo(){ return 0;} int foo(int i){ return 0;} int bob() { // foo() or foo(int)? auto fn = &foo; auto tmp = TemplateTakingFn!(foo); }That should probably be an "error: ambiguous" if it isn't already, but anyway can't you do 'int function() fn = &foo' to get the one you want? --bb
Nov 28 2006
Bill Baxter wrote:Kirk McDonald wrote:No, because there is no way to get another overload of a function beyond the first without knowing the type of the overload. -- Kirk McDonald Pyd: Wrapping Python with D http://pyd.dsource.orgIn writing Pyd, I've come to the conclusion that if you have a template that accepts an arbitrary function as an alias parameter (and then does anything involving the type of that function), you should always have a second parameter representing the type of the function. (And you can easily make this second parameter have a default value of typeof(&fn).) In this way the user can be sure the template is getting the proper overload of the function.If you had some extra condition like "I want to match the version with the most arguments" can you think of some way to make that work with the current D? --bb
Nov 28 2006
Kirk McDonald wrote:Bill Baxter wrote:Hmm, I was hoping maybe there's a way to use a series of templates like void set_function(Ret,A1,A2,A3)(Ret delegate(A1,A2,A3) dg) { ... } void set_function(Ret,A1,A2)(Ret delegate(A1,A2) dg) { ... } void set_function(Ret,A1)(Ret delegate(A1) dg) { ... } void set_function(Ret)(Ret delegate() dg) { ... } where ifti would prefer the one with more arguments to one with fewer. Of course if that were the solution it would take us right back into the bad old days before TypeTuples. --bbKirk McDonald wrote:No, because there is no way to get another overload of a function beyond the first without knowing the type of the overload.In writing Pyd, I've come to the conclusion that if you have a template that accepts an arbitrary function as an alias parameter (and then does anything involving the type of that function), you should always have a second parameter representing the type of the function. (And you can easily make this second parameter have a default value of typeof(&fn).) In this way the user can be sure the template is getting the proper overload of the function.If you had some extra condition like "I want to match the version with the most arguments" can you think of some way to make that work with the current D? --bb
Nov 28 2006
Bill Baxter wrote:Kirk McDonald wrote:.. And it doesn't work. Just gives you the lexical ordering again: import std.stdio : writefln; void func(int a, float b) { writefln("func(int, float)"); } void func(int a) { writefln("func(int)"); } void func() { writefln("func()"); } void do_it(A1,A2)(void function(A1, A2) f) { f(1,2.0); } void do_it(A1)(void function(A1) f) { f(3); } void do_it()(void function() f) { f(); } void main() { // no dice, still you get the func that's lexically first do_it(&func); } Your solution of passing the parameters for the version you want to the template is ok, except with the way IFTI works it's a headache when there are other parameters that could otherwise be guessed by IFTI that suddenly have to be specified too. --bbBill Baxter wrote:Hmm, I was hoping maybe there's a way to use a series of templates like void set_function(Ret,A1,A2,A3)(Ret delegate(A1,A2,A3) dg) { ... } void set_function(Ret,A1,A2)(Ret delegate(A1,A2) dg) { ... } void set_function(Ret,A1)(Ret delegate(A1) dg) { ... } void set_function(Ret)(Ret delegate() dg) { ... } where ifti would prefer the one with more arguments to one with fewer. Of course if that were the solution it would take us right back into the bad old days before TypeTuples. --bbKirk McDonald wrote:No, because there is no way to get another overload of a function beyond the first without knowing the type of the overload.In writing Pyd, I've come to the conclusion that if you have a template that accepts an arbitrary function as an alias parameter (and then does anything involving the type of that function), you should always have a second parameter representing the type of the function. (And you can easily make this second parameter have a default value of typeof(&fn).) In this way the user can be sure the template is getting the proper overload of the function.If you had some extra condition like "I want to match the version with the most arguments" can you think of some way to make that work with the current D? --bb
Nov 28 2006
Bill Baxter wrote:BCS wrote:I can indeed. And indeed, trying to autotype such a thing should certainly be an error. http://d.puremagic.com/issues/show_bug.cgi?id=52 Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.Bill Baxter wrote:That should probably be an "error: ambiguous" if it isn't already, but anyway can't you do 'int function() fn = &foo' to get the one you want?So, what's left on everyone's lists for D1.0 must-have features? I glanced over the "Pending Peeves" list, but none of those things seems particularly serious to me. What about the iterators? Mostly that can be a library thing that comes after the 1.0 release, but it would be nice if foreach at least had the smarts built-in to use an iterator once the method names are decided upon. --bbThere is no way to differentiate between function overloads. int foo(){ return 0;} int foo(int i){ return 0;} int bob() { // foo() or foo(int)? auto fn = &foo; auto tmp = TemplateTakingFn!(foo); }
Nov 28 2006