www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's left for 1.0?

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
next sibling parent reply Andre Osterhues <osterhues crypto.rub.de> writes:
== Quote from Bill Baxter (dnewsgroup billbaxter.com)'s article
 So, 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
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Andre Osterhues wrote:
 == Quote from Bill Baxter (dnewsgroup billbaxter.com)'s article
 So, 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.

Can 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? --bb
Nov 17 2006
prev sibling next sibling parent reply "Craig Black" <cblack ara.com> writes:
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
next sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
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
parent reply "Craig Black" <cblack ara.com> writes:
"Pragma" <ericanderton yahoo.removeme.com> wrote in message 
news:eji7vs$2cla$1 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.

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?

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. -Craig
Nov 16 2006
parent reply "Craig Black" <cblack ara.com> writes:
"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...
 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?

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.

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. -Craig
Nov 16 2006
parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Craig Black wrote:
 "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...
 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.

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?

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.


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.
 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
parent reply "Craig Black" <cblack ara.com> writes:
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...
 "Pragma" <ericanderton yahoo.removeme.com> wrote in message 
 news:eji7vs$2cla$1 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.

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?

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.


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.
 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
parent reply Pragma <ericanderton yahoo.removeme.com> writes:
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
parent reply genie <sgenie maxnet.co.nz> writes:
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
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
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.
 
 Gene

A 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
parent genie <sgenie maxnet.co.nz> writes:
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
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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
parent reply "Craig Black" <cblack ara.com> writes:
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
parent reply Walter Bright <newshound digitalmars.com> writes:
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
parent reply "Craig Black" <cblack ara.com> writes:
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
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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
parent reply "Craig Black" <cblack ara.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ejl0st$2rd9$1 digitaldaemon.com...
 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.

Outstanding!
 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.

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.. -Craig
Nov 17 2006
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Craig Black wrote:
 ...
 Also, is there a utility in phobos to load a DLL at run-time?

in C for Windows, calling the same functions.

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.. -Craig

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/
Nov 17 2006
prev sibling parent "John Reimer" <terminal.node gmail.com> writes:
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...
 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.)


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. -JJR
Nov 17 2006
prev sibling parent bobef <be lessequal_dontspam.com> writes:
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
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
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. In C#, which does allow pointers, certain blocks of code are marked as 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
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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.
 
 --benji

You 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
parent Jeff <jeffrparsons optusnet.com.au> writes:
Though I don't really have anything interesting to add, I'll second 
this, since it's important to me.
Nov 20 2006
prev sibling next sibling parent reply Marcin Kuszczak <aarti interia.pl> writes:
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
next sibling parent reply Aarti_pl <aarti interia.pl> writes:
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
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
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
next sibling parent Samuel MV <samuel jxdesigner.com> writes:
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
prev sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Bill Baxter wrote:

 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.

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 ? --anders
Nov 17 2006
prev sibling parent reply Samuel MV <samuel jxdesigner.com> writes:
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. Best regards, Samuel. Aarti_pl escribió:
 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
parent reply Bill Baxter <wbaxter gmail.com> writes:
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
next sibling parent Samuel MV <samuel jxdesigner.com> writes:
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
prev sibling parent reply Aarti_pl <aarti interia.pl> writes:
Bill Baxter napisał(a):
 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

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 Kuszczak
Nov 17 2006
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
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
parent reply Aarti_pl <aarti interia.pl> writes:
Anders F Björklund napisał(a):
 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

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 Kuszczak
Nov 17 2006
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Aarti_pl wrote:

 char 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?

Sure: import std.stdio; void main() { char[] text="Łóżko"; foreach(wchar c; text) { writefln(c); } } --anders
Nov 17 2006
parent reply Aarti_pl <aarti interia.pl> writes:
Anders F Björklund napisał(a):
 Aarti_pl wrote:
 
 char 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?

Sure: import std.stdio; void main() { char[] text="Łóżko"; foreach(wchar c; text) { writefln(c); } } --anders

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: # void main() { # string text="Łóżko"; // string class which uses ubyte/ushort/char for different internal representation; string could optimize texts for speed or memory consumption # foreach(char c; text) { // char is always unicode 4 bytes # writefln(c); # } # } Regards Marcin Kuszczak
Nov 17 2006
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
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
parent reply Marcin Kuszczak <aarti interia.pl> writes:
Anders F Björklund wrote:

 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)

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...
 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
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
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.
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...

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. --anders
Nov 18 2006
prev sibling next sibling parent reply Nahon <nahon t-online.hu> writes:
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 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
parent reply BCS <BCS pathlink.com> writes:
Nahon wrote:
 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 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

http://www.digitalmars.com/d/lex.html look for BOM However, I don't known how to put in a BOM.
Nov 17 2006
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 And there doesn't seem to be a dchar string literal syntax.

"foo"d cast(dchar)"foo" both work.

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. --bb
Nov 17 2006
prev sibling parent Alexander Panek <a.panek brainsware.org> writes:
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
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Daniel Keep wrote:

 
 
 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

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
Nov 19 2006
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Lars Ivar Igesund wrote:
 Daniel Keep wrote:
 
 BCS wrote:
 ...
 However, I don't known how to put in a BOM.

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

How so? I've never had any problems getting GVim probably setup for Unicode.

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/
Nov 19 2006
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Daniel Keep wrote:

 
 
 Lars Ivar Igesund wrote:
 Daniel Keep wrote:
 
 BCS wrote:
 ...
 However, I don't known how to put in a BOM.

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

How so? I've never had any problems getting GVim probably setup for Unicode.

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

Right, that is a usecase I've not needed to test :/ -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Nov 19 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Walter Bright wrote:

 However, I don't known how to put in 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 ? 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. いいえ. --anders
Nov 18 2006
parent =?UTF-8?B?SnVsaW8gQ8Opc2FyIENhcnJhc2NhbCBVcnF1aWpv?= writes:
Anders F Björklund wrote:
 Walter Bright wrote:
 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 ?

The added value appears when using tools that default to Latin1 unless they see a BOM.
Nov 18 2006
prev sibling parent reply Olli Aalto <oaalto gmail.com> writes:
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
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Olli Aalto wrote:
 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.

Imagine you compile the standard library with -version=UTF8. Let's take the following function:
 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.d

But 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
parent Olli Aalto <oaalto gmail.com> writes:
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?
 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, ':');
 ...


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. :)
 For whatever reason, your program will run optimally using UTF-32.
 
 dmd -version=UTF32 app.d

But 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.

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.
Nov 20 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
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
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Bill Baxter wrote:
 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

I agree this has been in the past and still is a weak point.
Nov 17 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 C can't do any of those things.

Sure it can.
 * No way to initialize a static array without counting elements
     static byte[???] imageData = [...];   // i hope you like counting!


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 dynamic array with a known length
     byte[] imageData;  imageData.length = 5;  // two steps - meh


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 array of strings
     char[][] list = ["eggs","bacon","milk","break"];  //uh uh


C can do this: char *list[] = { "eggs","bacon","milk","break" };
 * No way to initialize non-static struct
     Point p = { x:1.0, y:2.0 };  // nope...not static


C 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 associative array
     char[int] strTable = {"hello":5, "hi":2, "greetings":9}; // no way


Well you got me there. C can't do that.
 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
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:
 Walter Bright wrote:
  > C can't do any of those things.
 
 Sure it can.
 
 * No way to initialize a static array without counting elements
     static byte[???] imageData = [...];   // i hope you like counting!


C has no problem with this. I do it all the time: static const unsigned char[] = { 1,2,3,4,5,6,7, 255 };

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.
 * No way to initialize a dynamic array with a known length
     byte[] imageData;  imageData.length = 5;  // two steps - meh


C has no problem with this (using malloc, its own concept of "dynamic arrays"): byte* imageData = (byte*)malloc(5*sizeof(byte));

D: auto imageData = new byte[5];
 A 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.
 * No way to initialize array of strings
     char[][] list = ["eggs","bacon","milk","break"];  //uh uh


C can do this: char *list[] = { "eggs","bacon","milk","break" };

So can D: char *list[] = [ "eggs","bacon","milk","break" ]; char[] list[] = [ "eggs","bacon","milk","break" ];
 * No way to initialize non-static struct
     Point p = { x:1.0, y:2.0 };  // nope...not static


C 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 17 2006
next sibling parent Samuel MV <samuel jxdesigner.com> writes:
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.

 * No way to initialize a static array without counting elements
     static byte[???] imageData = [...];   // i hope you like counting!


C has no problem with this. I do it all the time: static const unsigned char[] = { 1,2,3,4,5,6,7, 255 };

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.
 * No way to initialize a dynamic array with a known length
     byte[] imageData;  imageData.length = 5;  // two steps - meh


C has no problem with this (using malloc, its own concept of "dynamic arrays"): byte* imageData = (byte*)malloc(5*sizeof(byte));

D: auto imageData = new byte[5];
 A 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.
 * No way to initialize array of strings
     char[][] list = ["eggs","bacon","milk","break"];  //uh uh


C can do this: char *list[] = { "eggs","bacon","milk","break" };

So can D: char *list[] = [ "eggs","bacon","milk","break" ]; char[] list[] = [ "eggs","bacon","milk","break" ];
 * No way to initialize non-static struct
     Point p = { x:1.0, y:2.0 };  // nope...not static


C 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
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:

 C 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").

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; --anders
Nov 18 2006
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 Walter Bright wrote:
  > C can't do any of those things.

 Sure it can.

 * No way to initialize a static array without counting elements
     static byte[???] imageData = [...];   // i hope you like counting!


C has no problem with this. I do it all the time: static const unsigned char[] = { 1,2,3,4,5,6,7, 255 };

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.

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.
 * No way to initialize a dynamic array with a known length
     byte[] imageData;  imageData.length = 5;  // two steps - meh


C has no problem with this (using malloc, its own concept of "dynamic arrays"): byte* imageData = (byte*)malloc(5*sizeof(byte));

D: auto imageData = new byte[5];

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).
 * No way to initialize array of strings
     char[][] list = ["eggs","bacon","milk","break"];  //uh uh


C can do this: char *list[] = { "eggs","bacon","milk","break" };

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] 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.
 * No way to initialize non-static struct
     Point p = { x:1.0, y:2.0 };  // nope...not static


C 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").

Right -- struct Point. It's been ages since I had to deal with C's "typedef struct foo { } foo;" sillyness. --bb
Nov 18 2006
next sibling parent Johan Granberg <lijat.meREM OVE.gmail.com> writes:
Bill Baxter wrote:

 Walter Bright wrote:
 Bill Baxter wrote:
 Walter Bright wrote:
  > C can't do any of those things.

 Sure it can.

 * No way to initialize a static array without counting elements
     static byte[???] imageData = [...];   // i hope you like counting!


C has no problem with this. I do it all the time: static const unsigned char[] = { 1,2,3,4,5,6,7, 255 };

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.

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.

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.
Nov 18 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:
 Walter Bright wrote:
 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.

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.
 So can D:
 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]

The following D program: ------------------ char *list[] = [ "eggs","bacon","milk","break" ]; char[] list2[] = [ "eggs","bacon","milk","break" ]; ------------------ compiles without error.
 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
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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:
 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.

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.
 So can D:
 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]

The following D program: ------------------ char *list[] = [ "eggs","bacon","milk","break" ]; char[] list2[] = [ "eggs","bacon","milk","break" ]; ------------------ compiles without error.
 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
parent Walter Bright <newshound digitalmars.com> writes:
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
prev sibling parent Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:
 Walter Bright wrote:
  > C can't do any of those things.
 
 Sure it can.
 
 * No way to initialize a static array without counting elements
     static byte[???] imageData = [...];   // i hope you like counting!


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 dynamic array with a known length
     byte[] imageData;  imageData.length = 5;  // two steps - meh


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 array of strings
     char[][] list = ["eggs","bacon","milk","break"];  //uh uh


C can do this: char *list[] = { "eggs","bacon","milk","break" };
 * No way to initialize non-static struct
     Point p = { x:1.0, y:2.0 };  // nope...not static


C 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 associative array
     char[int] strTable = {"hello":5, "hi":2, "greetings":9}; // no way


Well you got me there. C can't do that.

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. Sean
Nov 18 2006
prev sibling next sibling parent "Chris Miller" <chris dprogramming.com> writes:
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=

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 - meh

auto imageData =3D new byte[5];
 * No way to initialize array of strings
      char[][] list =3D ["eggs","bacon","milk","break"];  //uh uh

This 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 static

Agreed; 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 =

I'd be OK if this were a 2.0 thing.
Nov 17 2006
prev sibling next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Bill Baxter wrote:
 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!

Agreed. No idea off the top of my head, though, except maybe allowing something like: # static byte[$] imageData = [...];
 * No way to initialize a dynamic array with a known length
     byte[] imageData;  imageData.length = 5;  // two steps - meh

# byte[] imageData = new byte[5]; Works right now.
 * No way to initialize array of strings
     char[][] list = ["eggs","bacon","milk","break"];  //uh uh

There are two ways to do it, right now... but I do still agree they aren't particulary elegant. Way #1: # char[][] list = [cast(char[]) "eggs", "bacon", "milk"]; Way #2: # import cashew .utils .array ; # # auto list = array!(char[])("eggs", "bacon", "milk");
 * No way to initialize non-static struct
     Point p = { x:1.0, y:2.0 };  // nope...not static

This 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 way

Ditto. The closest I can offer is Cashew again: # import cashew .utils .array ; # # auto strTable = assoc!(int, char)( # [5 , 2 , 9 ], # ["hello", "hi", "greetings"] # ); 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.
 
 --bb

Its 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
prev sibling parent Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:
 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!

Maybe: static imageData = [cast(byte) ...];
 * No way to initialize a dynamic array with a known length
     byte[] imageData;  imageData.length = 5;  // two steps - meh

byte[] 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 way

The rest would be nice to have, though. Sean
Nov 18 2006
prev sibling parent reply BCS <BCS pathilink.com> writes:
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.
 
 --bb

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); }
Nov 19 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
BCS wrote:
 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.

 --bb

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 19 2006
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bill Baxter wrote:
 BCS wrote:
 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

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.org
Nov 19 2006
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Kirk McDonald wrote:
 Bill Baxter wrote:
 BCS wrote:
 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

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.

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)); -bb
Nov 23 2006
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Kirk McDonald wrote:
 Bill Baxter wrote:
 BCS wrote:
 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

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.

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
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bill Baxter wrote:
 Kirk McDonald wrote:
 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

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.org
Nov 28 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Kirk McDonald wrote:
 Bill Baxter wrote:
 Kirk McDonald wrote:
 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

No, because there is no way to get another overload of a function beyond the first without knowing the type of the overload.

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. --bb
Nov 28 2006
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bill Baxter wrote:
 Kirk McDonald wrote:
 Bill Baxter wrote:
 Kirk McDonald wrote:
 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

No, because there is no way to get another overload of a function beyond the first without knowing the type of the overload.

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. --bb

.. 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. --bb
Nov 28 2006
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Bill Baxter wrote:
 BCS wrote:
 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.

 --bb

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?

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.
Nov 28 2006