www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Various D language matters

reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
Hi people!

I have just started using D after finding it two weeks ago, and I emailed
Walter today. He has encouraged me to post my email here, and so I will do
(slightly altered) - plus I will add to it some things that have come up
after my spending the day reading the D newsgroups (I went back as far as
January - whew! a lot of stuff there!)

Let me briefly introduce myself.

I'm a programmer, I have roughly a decade of programming experience, and
I've used about a dozen languages and have working knowledge of maybe
another dozen (I really can't be bothered to try and count!). Most of that
experience is in 'C-like' languages - I have, from time to time, played with
things like Forth and Smalltalk, but I don't really like them too much.
Anyway, I'm also a web developer and designer (I guess I'm one of those
apparently few people who have a gift for both coding and design) and in the
past couple of years I have been mainly writing in web languages such as
PHP.

Because of this, my skills in C/C++ have gotten slightly rusty, but that's
partly because I've always hated some aspects of C, and so having the
opportunity to write primarily in other languages such as PHP, Perl, Python,
Ruby etc. has been quite welcome, because I can concentrate more on doing
the task and less on making sure that every single little thing is handled
correctly (not to mention the other benefits of such languages!).

So, why did I bother to introduce myself? Well, I want you to realise I am
not a newbie at programming. From some of the things I have read about D, it
appears that the 'anti-D' camp often try to use the argument that 'they know
more about C and so what's the point of D' - that kind of thing. I notice
that a lot of D supporters are actually very highly skilled and experienced,
in many different languages, and undoubtably far above my own level. But I
just wanted to point out that I enter this as someone who already knows
enough about C to make a proper decision about D.

Ok, I hope you got what I was on about there :)

I have a couple of projects on at the moment that are going to require the
use of a more 'C-style' language. One specific, critical requirement is
performance. Indeed, that aspect alone is enough to force me to use C (or
C++ - I tend to write 'C' to cover both) if I have to, but I am loath to do
so if there is a more suitable alternative. Another requirement is that the
language must be compilable, and another is that it must be pretty much
cross-platform. Finally, the language features. Because I have already ruled
out so many nice languages with the requirements I have already stated, I'm
left begging for whatever features I can, really. Things like dynamic typing
are nice, but to be honest I generally prefer static typing. String and
array handling is very important - the nearer the language is to PHP, Ruby
etc. in this respect, the better.

So:

 PHP: nowhere near fast enough; not compilable. However, it is


except it isn't strict enough.
 Ruby: getting better - a lot faster than PHP, and although not strictly


love the way everything is OO, but the speed and fiddly wrapping means it doesn't qualify.
 Python: not even worth considering. I don't really like the language, and


better choice.
 Perl: faster than PHP, but worse language-wise; for me, at least. Again,


 C/C++: very fast, obviously compilable, and cross-platform. Perfect? NO!


for things that I could use natively in other languages. I dislike the STL; quite often I personally find the implementation of certain features still has to be tweaked a lot to fit what I want to do, and so I often end up writing from scratch something that I could arguably use the STL for, but I end up with something smaller and not as hacked together as it would be if I altered an existing module. I hate the way strings and arrays are dealt with in C/C++, I hate the way C++ deals with objects... gah! so many things about C that I hate, no wonder I haven't used it much in the last couple of years :)
 Smalltalk: quite fast, compilable, and the language supports much of what


trouble finding what I need on it, plus I really don't like the language.
 Forth, Ada, similar friends: similar to my comments on Smalltalk. Some do


mainstream use, and hence the lack of enough material, plus my dislike of the languages, rules them out.
 Basic and Pascal derivatives? ...nothing I know of fits the bill, really.


 Lua: a very interesting option, this one. Lua is a beautiful language,


Wrappable, more like. There is still the problem of having to write the Lua, interface the Lua with some C, and so on. I would end up with what would essentially be a small C program loading an embedded Lua interpreter, and bootstrapping a Lua program stored as a C string. That pretty much rules out Lua, which is a shame, because if it was properly compilable, it might even win. So much so, that I spent quite a while playing around with it to see if it would in fact be suitable. Ah well.
 Java: Many people (probably Java lovers!) would have immediately touted


language. Fast - or so they will say. Compilable - again, so they will say. And it does everything I want to do, doesn't it? Not really. I have a strong dislike of Java. I actually taught it for a while, but no more recently than three years ago, because I decided not to continue using it. I think I would rather use C++ than Java. Sure, Java has got better OO, lots more features... but it is pretty slow (or at least I think so) and isn't really compilable. Not in the way that I want. So Java is also ruled out. There are plenty more languages, but I picked those out for a reason, plus I can't be bothered to waste my time and yours by listing every single language out there. You will probably notice the focus on PHP - that is partly because one of my projects is writing some PHP extensions, and partly because I use it every day, and like it immensely. So that brings me to D. I'm glad I found your site - I had never heard of D before, and to be honest, although I was impressed by the features etc. I was also wondering if this language would live up to the hype you give it. After all, everyone does that with their own stuff - myself included. (I've actually written a language; PTPScript, used in my template engine, PTP. I personally think it's the best thing since sliced bread, but not everyone will agree. So I'm used to own-trumpet-blowing!) After reading things like the discussion at comp.lang.c++ [1], I realised that many of the people who dislike D are simply being picky. I read through the first hundred messages of that discussion, and failed to see anything of use (such as real-world performance tests or in-depth language feature analysis) - instead, far too much time was spent simply arguing about whether you should have used '+' instead of '~' and similar rubbish. I personally don't care - you designed and wrote the language, that's more than they did, surely it's up to you to write it how you want. So long as it's semantically coherent, I can simply learn the syntax, as I have to do with any other language in any case. So I decided to try out D for myself. I figured I'd use the word count program that you have on your site, and do some tests. First, I downloaded D and installed it on both my Windows XP system (worked fine) and my RedHat Linux server (again, worked fine). I was unable to get it to work under Cygwin - shame really. I then altered the C++ and D code slightly so that both produced exactly the same output (you may not have noticed, but the formatting is different, and as I was doing a difference comparison on the produced output in order to check for success, I needed them to match). I also found a small bug in your D code - line 1 and line 18: 'file' should be 'std.file'. I compiled the programs on my Linux system, using the standard method (no extra flags or anything), and then stripped them. I was a bit disappointed that the D executable was 110Kb (75kb after stripping) whereas the C++ program was only 36Kb (21Kb after stripping). I'm not sure why the compiled D program is so much larger than the C one [2], but never mind. That alone is not really a bad thing, as file size is generally not a critical requirement these days. I then grabbed a copy of the alice text, and created 4 test files. The first was simply alice, the second had the same text 10 times, the third, 100, and the fourth, 1000. That gave me file sizes of 163Kb, 1.63Mb, 16.3Mb, and 163Mb. Next, I simply ran the C program and then the D program with each file, outputting to a log file. Times for the C++ program: ~0.5s, 2s, 15s, 155s. Note that these are by no means pin-point accuracy, as I was simply counting the seconds on my watch ;) Times for the D program: ~0.1s, ~0.5s, ~1s, 15s. Wow! Pretty impressive! :) The results clearly show to me that the compiled D program was approximately 10x faster than the compiled C++ program [3]. Now, in fairness, I have not actually gone through all the code in each program to compare the methods, so I guess it's possible that you used a more efficient method. However it mentioned on the site that it was supposed to be a direct translation, plus plenty of people have read that page and discussed it, so I figured that if the method itself was giving an advantage then someone would have kicked up a fuss by now :D The conclusion I have come to, as what I would call an informed outsider, is that D seems to be a lot 'better' than C or C++. I like your features; I don't think all your comparisons between C/C++ and D as quite as fair as maybe they could be, but I can see that you are saying is true. I very much like the fact that D seems to be faster than C, and therefore those things to me constitute an acceptable definition of 'better' :) In case you haven't guessed... the purpose of this email (and post) is primarily to encourage you. I thought it might be useful in some way to hear how D has been selected as the development language of choice for some real-world projects, based on criteria that actually matter, when put side-by-side with pretty much every other language out there. In particular I was wondering if you would like me to take the speed testing thing further, and maybe do some detailed analysis (when I have the time) on different aspects and their realisations. It would certainly be interesting, and may help attract some more attention. I am about to start using D quite extensively, and also I will include it as a supported language on my forums (I provide coding help for people). If you need any assistance with anything then please drop me a line, as I have resources, skills, and contacts, and can probably lend a hand with many things, if need be. Thankyou for developing this language, and for the time you have poured into it. Dan ------------------------------------------------------------ To the newsgroup readers: that's pretty much the email that I sent to Walter. Here are some footnotes: [1] http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=ww3_a.9531%24BC2.1823%40newsread2.news.atl.earthlink.net&prev=/groups%3Fq%3Dg:thl953709878d%26dq%3D%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dbjacrl%25244un%252401%25241%2540news.t-online.com&as_drrb=b&as_maxd=12&as_maxm=8&as_maxy=2003&as_mind=29&as_minm=3&as_miny=1995 [2] From reading the newsgroups, I realise that the extra file size is because the Phobos code has to be compiled into the executable, whereas for the C program, the common code is already installed as libraries. More about that in a minute. [3] Just in case anyone asks - no, the difference in results is nothing to do with file caching or anything similar. I repeated the tests to make sure that this was not affecting it in any way. ------------------------------------------------------------ Ok, and now for some things that I haven't had answered by searching and reading, plus some general comments. First, if any of you can point me to anything relating to the possibility of coding PHP extensions in D, that would be very much appreciated! ;) Now, I notice that there has been a lot of discussion about arrays, mostly about the definition of what I would call multi-dimensional fixed arrays, or something like that, but people seem to like calling them rectangular despite the fact that when you go above two dimensions you get a cuboid and then some strange n-dimensional shape ;) All I can say about that type of array is that I agree with the proposal put forward by Norbert Nemec - has any of that been implemented yet? Is it going to be? I was unable to find that out. Responding to some of the suggestions I have read, I personally would prefer the int[a, b, c] method over the int[a][b][c] method, but I'm really not that fussed, and I would be happy with either one so long as the methodology and syntax was clearly defined with no room for ambiguity. While on the subject on arrays, I have a question. Is it possible to create D arrays with mixed types? i.e. like PHP arrays ;) I notice that I can use non-mumeric keys, which is great, but I have not been able to ascertain whether there is the ability to mix data types in the array elements and also in the keys (maybe in the DTL?). My suspicion is "no", because of the definition method - therefore, my next question is, what would people recommend as the best method to do such a thing? I have such a structure created in some C++ code that I was writing some way back, but I would obviously prefer a solution that is native to the language. Maybe I could suggest a Visual Basic-style data type of variant, or similar? That's just speculating, and I guess someone is gonna shoot that down as 'bad' for so many reasons, but although I like strong typing, I can see advantages to bringing in a variant data type too, so long as the memory management was done properly (shouldn't be too hard?). My final question on arrays is the methodology behind them. I figure the D implementation is probably what I think is the best solution; i.e. that arrays are actually arrays of pointers to variable-length data. Is this correct? In which case, I would like to see things like a built-in swap method, e.g. myArray.swap(index_a, index_b) or whatever syntax you like. I haven't noticed that feature available, but hopefully the benefits will be apparent. When sorting etc. you don't want to be moving the actual array element data around in memory, just the pointers. I haven't seen if there are any built-in sort functions, but it doesn't matter - a swap method is all you need for a lot of things, not just sort. If one is available, please point me to it! Plus, if this is not included and not going to be, I assume that it is still possible to swap the pointers in some way, seeing as we can manipulate pointers directly with D, like in C/C++? Please correct me if any of that is misunderstood. The next thing on my list is the Big Cast Discussion. So many methods were brought up! And the subject kept resurfacing. I'm not gonna say a lot about it, because I don't really care that much, but out of the methods; I like "cast(type) expression" - i.e. the one that has been implemented. I didn't much like "x.cast(type)" because that doesn't adequately deal with x being an expression. The only advantage is when x is simply a variable, and the current method handles both just fine. I don't like "cast(type, expression)" at all, because I don't feel that's as comfortable. It has some semantic advantages, however the cast method is a pretty familiar one, and "cast(int) expression" is just fine. "cast type expression" was a bit shaky I thought. I liked the possibility of specific casting methods such as "int(expression)", however I'm not sure they are really necessary, as I am never convinced of the value of providing too many ways of doing the same thing. Likewise with something like "x.int()" although that might be useful. So my basic summary of cast is that I am fine with the way it is :) The only other thing about casting is I think maybe it should be possible to do something like "int a = b" - is this possible? But then, that could lead to "a = int b" as another method, which I guess is getting close to the "a = int(b)" or "a = cast int b" kind of thing, which I don't like too much. I noticed some talk about the way D programs have Phobos code compiled into them, and the situation seems to be that the equivalent doesn't happen in C, because the libraries are usually already available. Talk was made of turning off the incluusion of the Phobos code, however surely the better option is to simply build some static Phobos libraries, and put these in somewhere like /usr/lib, or even /lib (or wherever appropriate on Windows for dlls) so that they are globally available? Isn't that what GCC and friends do? That would then mean that the common code would not have to be recompiled every time, and neither would it have to be included in every D program. My apologies if this suggestion, which seems so obvious to me, has already been covered! Finally, I was concerned about what I read regarding garbage collection and things like Object.toHash(). I'm simply going to voice my opinion and say that I do not think the GC method should be changed until other areas like Object.toHash() are stable and ready enough to cope with the change. Oh yeah and that whole argument about bits and bools... lol... the way it has been done, is the correct way I feel, even if it admittedly doesn't have everything down pat yet. A bool should indeed be the same as a bit, but you should be able to use the bits/bools exactly the same way that you can use anything else, like passing in and out of functions, for example (I read that apparently you can't use a bit in an inout in the same way as you can an int? Hence this comment). Also, because bits are bits, it seems only natural that an array of 5 bits should return length or size of 5, because the unit of measurement being used is that of a bit. Pretty much everything else uses bytes as the unit of measurement, but that does not, IMHO, mean that bits should use bytes to measure. That's just crazy talk ;) ------------------------------------------------------------ Right, so, sorry about the long post, but it's the result of hanging back and reading quite a bit first. Most of my questions were answered already by reading the online material, and the newsgroup posts. If someone could answer my questions about arrays and stuff, I would be very happy :) Cheers, and happy D-ing Dan
Jun 29 2004
next sibling parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Sorry for not going into all the different points of your mail. It really
was interesting to read.

Just the one detail that affects me directly:

 All I can say about that type of array is that I agree with the proposal
 put forward by Norbert Nemec - has any of that been implemented yet?

The proposal is still high up in the air. The ultimate implementation that the proposal in its current form is aimed for is directly in the language, and it will take some time until it is fit for that. Until then, one might try to do a demonstration as a library, but as of yet, it would probably not be possible to really "implement" the proposal as a library. First, of course, the syntax could not be the same I proposed for the language feature. Then - for the partial indexing/partial slicing: I have a very clear idea how the compiler should handle this, but I still have no idea, how opSlice should be generalized to first handle multiple dimensions, and then handle a mixture of slicing and indexing in one expression. So, in general, there is a long way to go, and I have very little time to spend on this right now. I once hoped that multidimensional arrays could get into D 1.0 already, since they might actually collide with some details of the current specs for onedimensional arrays, but by now, I strongly doubt that this is realistic at all. Ciao, Nobbi
Jun 29 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
news:cbskjv$2u3i$1 digitaldaemon.com...
 So that brings me to D. I'm glad I found your site - I had never heard of

 before, and to be honest, although I was impressed by the features etc. I
 was also wondering if this language would live up to the hype you give it.

Hype? What hype? <g>
 After reading things like
 the discussion at comp.lang.c++ [1], I realised that many of the people

 dislike D are simply being picky. I read through the first hundred

 of that discussion, and failed to see anything of use (such as real-world
 performance tests or in-depth language feature analysis) - instead, far

 much time was spent simply arguing about whether you should have used '+'
 instead of '~' and similar rubbish.

I suspect people who latch on to something like that are ones who haven't read the spec. There's lots of legitimate things to criticise D on, but ~ isn't one of them.
 I was a bit disappointed that the D executable was 110Kb (75kb after
 stripping) whereas the C++ program was only 36Kb (21Kb after stripping).

 not sure why the compiled D program is so much larger than the C one [2],
 but never mind. That alone is not really a bad thing, as file size is
 generally not a critical requirement these days.

The D runtime library includes the garbage collector, which adds a chunk of code not present in a C++ executable. This chunk is a fixed overhead, though, and does not suggest that D compiled code is any larger.
 Wow! Pretty impressive! :) The results clearly show to me that the

 D program was approximately 10x faster than the compiled C++ program [3].

The reason for the speedup is D doesn't need to do memory allocation for its strings, whereas C++ does.
 Now, in fairness, I have not actually gone through all the code in each
 program to compare the methods, so I guess it's possible that you used a
 more efficient method. However it mentioned on the site that it was

 to be a direct translation, plus plenty of people have read that page and
 discussed it, so I figured that if the method itself was giving an

 then someone would have kicked up a fuss by now :D

The inefficiency in the C++ comes from, when you boil it down, not supporting garbage collection, so C++'s std.string constantly is allocating and copying strings around. wc is a stellar example of why gc'd programs can run far faster than explicitly managed programs, despite the myth that gc programs are slower.
 The conclusion I have come to, as what I would call an informed outsider,

 that D seems to be a lot 'better' than C or C++. I like your features; I
 don't think all your comparisons between C/C++ and D as quite as fair as
 maybe they could be, but I can see that you are saying is true. I very

 like the fact that D seems to be faster than C, and therefore those things
 to me constitute an acceptable definition of 'better' :)

I think that once you get used to D, the comparisons to C++ are actually rather biased towards C++ <g>.
 In case you haven't guessed... the purpose of this email (and post) is
 primarily to encourage you.

Thanks!
 I thought it might be useful in some way to hear
 how D has been selected as the development language of choice for some
 real-world projects, based on criteria that actually matter, when put
 side-by-side with pretty much every other language out there. In

 I was wondering if you would like me to take the speed testing thing
 further, and maybe do some detailed analysis (when I have the time) on
 different aspects and their realisations. It would certainly be

 and may help attract some more attention.

D does need some testimonials from using it in significant projects.
 All I can say about that type of array is that I agree with the proposal

 forward by Norbert Nemec - has any of that been implemented yet? Is it

 to be?

It's a good candidate for 2.0. But right now, one can emulate such arrays using structs and operator overloading.
 While on the subject on arrays, I have a question. Is it possible to

 D arrays with mixed types?

No, D is statically typed. But you can use templates to do the equivalent, or you can define a 'variant' type and create an array of those instead (which is what most dynamically typed scripting languages do under the hood anyway).
 My final question on arrays is the methodology behind them. I figure the D
 implementation is probably what I think is the best solution; i.e. that
 arrays are actually arrays of pointers to variable-length data. Is this
 correct?

No. A D array is a pair of two items, the number of elements in the array and a pointer to the array data.
 In which case, I would like to see things like a built-in swap
 method, e.g. myArray.swap(index_a, index_b) or whatever syntax you like. I
 haven't noticed that feature available, but hopefully the benefits will be
 apparent. When sorting etc. you don't want to be moving the actual array
 element data around in memory, just the pointers. I haven't seen if there
 are any built-in sort functions, but it doesn't matter - a swap method is
 all you need for a lot of things, not just sort. If one is available,

 point me to it! Plus, if this is not included and not going to be, I

 that it is still possible to swap the pointers in some way, seeing as we

 manipulate pointers directly with D, like in C/C++? Please correct me if

 of that is misunderstood.

There is a built-in sort property for arrays, but not swap.
 I noticed some talk about the way D programs have Phobos code compiled

 them, and the situation seems to be that the equivalent doesn't happen in

 because the libraries are usually already available. Talk was made of
 turning off the incluusion of the Phobos code, however surely the better
 option is to simply build some static Phobos libraries, and put these in
 somewhere like /usr/lib, or even /lib (or wherever appropriate on Windows
 for dlls) so that they are globally available? Isn't that what GCC and
 friends do? That would then mean that the common code would not have to be
 recompiled every time, and neither would it have to be included in every D
 program. My apologies if this suggestion, which seems so obvious to me,

 already been covered!

What you're talking about are DLLs in Windows and shared libraries under linux. Right now, I prefer things to be statically linked in because that avoids "DLL hell" where versions get mismatched.
Jun 29 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <cbsq23$46i$1 digitaldaemon.com>, Walter says...
"Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
news:cbskjv$2u3i$1 digitaldaemon.com...

 Wow! Pretty impressive! :) The results clearly show to me that the

 D program was approximately 10x faster than the compiled C++ program [3].

The reason for the speedup is D doesn't need to do memory allocation for its strings, whereas C++ does.

I haven't looked at the code, but it sounds like you were running a word counter? If so, pick a sample set containing words no longer than 16 characters. The Small String Optimization present in C++ should keep any memory allocations from occurring and thus run much faster. It may be a more useful benchmark vs. D. Sean
Jun 29 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cbsquv$5ca$1 digitaldaemon.com...
 In article <cbsq23$46i$1 digitaldaemon.com>, Walter says...
"Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
news:cbskjv$2u3i$1 digitaldaemon.com...

 Wow! Pretty impressive! :) The results clearly show to me that the

 D program was approximately 10x faster than the compiled C++ program



The reason for the speedup is D doesn't need to do memory allocation for


strings, whereas C++ does.

I haven't looked at the code, but it sounds like you were running a word counter? If so, pick a sample set containing words no longer than 16 characters. The Small String Optimization present in C++ should keep any

 allocations from occurring and thus run much faster.  It may be a more

 benchmark vs. D.

The sample set is the full text of "Alice in Wonderland", in which most words are far less than 16 characters. But even with SSO, C++ std::string *still* needs to copy the strings. I didn't tune the input data, nor did I tune the C++ code to look bad. In fact, I didn't even write the C++ version because I'm sure I'd have been accused of sabotaging C++ if I had <g>. The C++ version was written by some C++ folks who were (I believe) trying to show that std::string was better than D strings. The C++ version has some bugs in it (lack of error handling) that I didn't bother to point out to its author(s).
Jun 29 2004
parent "Dan Williams" <dnews ithium.NOSPAM.net> writes:
Heheh, yes I noticed you didn't write the C++ version ;)

In fact, that was one of the motivating factors for my using it in the test
:D



"Walter" <newshound digitalmars.com> wrote in message
news:cbss5n$70s$1 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message
 news:cbsquv$5ca$1 digitaldaemon.com...
 In article <cbsq23$46i$1 digitaldaemon.com>, Walter says...
"Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
news:cbskjv$2u3i$1 digitaldaemon.com...

 Wow! Pretty impressive! :) The results clearly show to me that the

 D program was approximately 10x faster than the compiled C++ program



The reason for the speedup is D doesn't need to do memory allocation



 its
strings, whereas C++ does.

I haven't looked at the code, but it sounds like you were running a word counter? If so, pick a sample set containing words no longer than 16 characters. The Small String Optimization present in C++ should keep


 memory
 allocations from occurring and thus run much faster.  It may be a more

 benchmark vs. D.

The sample set is the full text of "Alice in Wonderland", in which most words are far less than 16 characters. But even with SSO, C++ std::string *still* needs to copy the strings. I didn't tune the input data, nor did I tune the C++ code to look bad. In fact, I didn't even write the C++ version because I'm sure I'd have been accused of sabotaging C++ if I had <g>. The C++ version was written by

 C++ folks who were (I believe) trying to show that std::string was better
 than D strings. The C++ version has some bugs in it (lack of error

 that I didn't bother to point out to its author(s).

Jun 29 2004
prev sibling parent "Dan Williams" <dnews ithium.NOSPAM.net> writes:
Yes, that's correct, I used the word count programs given on the D site,
with only very minor modifications.

As for the word length... I believe the "alice" text is a good test, because
most words will be under 10 characters in length, and I very much doubt that
any will be over 16 characters.

So... perhaps if I try the test again with long (say, > 20 chars) words,
there may be an even greater performance distinction...



"Sean Kelly" <sean f4.ca> wrote in message
news:cbsquv$5ca$1 digitaldaemon.com...
 In article <cbsq23$46i$1 digitaldaemon.com>, Walter says...
"Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
news:cbskjv$2u3i$1 digitaldaemon.com...

 Wow! Pretty impressive! :) The results clearly show to me that the

 D program was approximately 10x faster than the compiled C++ program



The reason for the speedup is D doesn't need to do memory allocation for


strings, whereas C++ does.

I haven't looked at the code, but it sounds like you were running a word counter? If so, pick a sample set containing words no longer than 16 characters. The Small String Optimization present in C++ should keep any

 allocations from occurring and thus run much faster.  It may be a more

 benchmark vs. D.


 Sean

Jun 29 2004
prev sibling next sibling parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Walter" <newshound digitalmars.com> skrev i en meddelelse
news:cbsq23$46i$1 digitaldaemon.com...
 There is a built-in sort property for arrays, but not swap.

It reminds me - I think it should be documented if the sort is guaranteed to be stable or not. Regards, Martin
Jun 29 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message
news:cbsu2o$9r4$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> skrev i en meddelelse
 news:cbsq23$46i$1 digitaldaemon.com...
 There is a built-in sort property for arrays, but not swap.

It reminds me - I think it should be documented if the sort is guaranteed

 be stable or not.

What does 'stable' mean applied to sorts?
Jun 29 2004
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 29 Jun 2004 18:20:29 -0700, Walter wrote:

 "Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message
 news:cbsu2o$9r4$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> skrev i en meddelelse
 news:cbsq23$46i$1 digitaldaemon.com...
 There is a built-in sort property for arrays, but not swap.

It reminds me - I think it should be documented if the sort is guaranteed

 be stable or not.

What does 'stable' mean applied to sorts?

If two items with the same sort key are adjacent in the unsorted array, they will appear in the exact same sequence in the sorted array. eg. Unsorted... E:Eggplant B:Banana C:Carrot C:Cabbage O:Orange A:Apple Sorted: (Key is first character). A:Apple B:Banana C:Carrot C:Cabbage E:Eggplant O:Orange -- Derek Melbourne, Australia 30/Jun/04 11:54:55 AM
Jun 29 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:cbt6u2$m41$1 digitaldaemon.com...
 On Tue, 29 Jun 2004 18:20:29 -0700, Walter wrote:

 "Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message
 news:cbsu2o$9r4$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> skrev i en meddelelse
 news:cbsq23$46i$1 digitaldaemon.com...
 There is a built-in sort property for arrays, but not swap.

It reminds me - I think it should be documented if the sort is



 to
 be stable or not.

What does 'stable' mean applied to sorts?

If two items with the same sort key are adjacent in the unsorted array, they will appear in the exact same sequence in the sorted array. eg. Unsorted... E:Eggplant B:Banana C:Carrot C:Cabbage O:Orange A:Apple Sorted: (Key is first character). A:Apple B:Banana C:Carrot C:Cabbage E:Eggplant O:Orange

Ok, I understand. But I don't know if qsort has that property or not.
Jun 29 2004
parent reply Oskar Linde <d98-oliRE.MO.VE nada.kth.se> writes:
Walter wrote:

 Ok, I understand. But I don't know if qsort has that property or not.

No, quicksort is not stable. /Oskar
Jun 30 2004
parent "Walter" <newshound digitalmars.com> writes:
"Oskar Linde" <d98-oliRE.MO.VE nada.kth.se> wrote in message
news:cbu0k9$26ul$1 digitaldaemon.com...
 Walter wrote:

 Ok, I understand. But I don't know if qsort has that property or not.

No, quicksort is not stable.

Then .sort is not stable. <g>
Jun 30 2004
prev sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
Walter wrote:

 
 "Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message
 news:cbsu2o$9r4$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> skrev i en meddelelse
 news:cbsq23$46i$1 digitaldaemon.com...
 There is a built-in sort property for arrays, but not swap.

It reminds me - I think it should be documented if the sort is guaranteed

 be stable or not.

What does 'stable' mean applied to sorts?

that is doesn't swap things that compare equal - though personally I think that usually means the definition of "equal" for that class is sortof flaky (so to speak).
Jun 29 2004
prev sibling parent reply Jesus <Jesus_member pathlink.com> writes:
In article <cbsu2o$9r4$1 digitaldaemon.com>, Martin M. Pedersen 
says...
"Walter" <newshound digitalmars.com> skrev i en meddelelse
news:cbsq23$46i$1 digitaldaemon.com...
 There is a built-in sort property for arrays, but not swap.

It reminds me - I think it should be documented if the sort is guaranteed

be stable or not.

Regards,
Martin

It would be nice to have a few sorting methods to provide different sorting algorithms. For example if you know quickSort is going to perform badly for your array you might decide to call mergeSort instead.
Jun 30 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
Indeed, this is why I was hoping for a built-in swap method, so that we
could write our own sort algorithms and simply call swap().


"Jesus" <Jesus_member pathlink.com> wrote in message
news:cbuf8e$5ko$1 digitaldaemon.com...
 In article <cbsu2o$9r4$1 digitaldaemon.com>, Martin M. Pedersen
 says...
"Walter" <newshound digitalmars.com> skrev i en meddelelse
news:cbsq23$46i$1 digitaldaemon.com...
 There is a built-in sort property for arrays, but not swap.

It reminds me - I think it should be documented if the sort is guaranteed

be stable or not.

Regards,
Martin

It would be nice to have a few sorting methods to provide different

 algorithms. For example if you know quickSort is going to perform badly
 for your array you might decide to call mergeSort instead.

Jun 30 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Dan Williams wrote:

 Indeed, this is why I was hoping for a built-in swap method, so that we
 could write our own sort algorithms and simply call swap().

Where is the problem of using a temporary and doing the three assignments as usual? Of course, swap is more convenient, but that alone not a good enough reason to make it a language feature.
Jun 30 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
Yes, it's mainly due to convenience, but not just syntactical convenience.
With D, it would appear that pointers only rarely have to be used, and so a
swap method would mean that people would not have to access the pointers
directly in this scenario.


"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:cbuneo$hpk$2 digitaldaemon.com...
 Dan Williams wrote:

 Indeed, this is why I was hoping for a built-in swap method, so that we
 could write our own sort algorithms and simply call swap().

Where is the problem of using a temporary and doing the three assignments

 usual? Of course, swap is more convenient, but that alone not a good

 reason to make it a language feature.

Jun 30 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
news:cbuol1$jrb$1 digitaldaemon.com...
 With D, it would appear that pointers only rarely have to be used, and so

 swap method would mean that people would not have to access the pointers
 directly in this scenario.

Why not this: T[] foo; void swap(inout T e1, inout T e2) { T tmp = e1; e1 = e2; e2 = tmp; } ... swap(foo[i], foo[j]);
Jun 30 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cbuutj$sm8$1 digitaldaemon.com...
 "Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
 news:cbuol1$jrb$1 digitaldaemon.com...
 With D, it would appear that pointers only rarely have to be used, and


 a
 swap method would mean that people would not have to access the pointers
 directly in this scenario.

Why not this: T[] foo; void swap(inout T e1, inout T e2) { T tmp = e1; e1 = e2; e2 = tmp; } ... swap(foo[i], foo[j]);

Well, unless I'm mistaken, doesn't that do exactly what I described and copy the actual data around memory? Imagine that e1 and e2 are 1Kb each, or 1Mb each, or whatever. Then imagine that your function has to perform, say, 1000 of these swaps. Surely you are going to be copying *far* more data around than is necessary?
Jun 30 2004
next sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
news:cbv00u$uc2$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:cbuutj$sm8$1 digitaldaemon.com...
 "Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
 news:cbuol1$jrb$1 digitaldaemon.com...
 With D, it would appear that pointers only rarely have to be used, and


 a
 swap method would mean that people would not have to access the



 directly in this scenario.

Why not this: T[] foo; void swap(inout T e1, inout T e2) { T tmp = e1; e1 = e2; e2 = tmp; } ... swap(foo[i], foo[j]);

Well, unless I'm mistaken, doesn't that do exactly what I described and

 the actual data around memory?

 Imagine that e1 and e2 are 1Kb each, or 1Mb each, or whatever. Then

 that your function has to perform, say, 1000 of these swaps. Surely you

 going to be copying *far* more data around than is necessary?

Copying is not going to happen if T is a class because then e1 and e2 are references to objects and not the actual objects.

Jun 30 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:cbvaqc$1e7n$1 digitaldaemon.com...
 "Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
 news:cbv00u$uc2$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:cbuutj$sm8$1 digitaldaemon.com...
 "Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
 news:cbuol1$jrb$1 digitaldaemon.com...
 With D, it would appear that pointers only rarely have to be used,




 so
 a
 swap method would mean that people would not have to access the



 directly in this scenario.

Why not this: T[] foo; void swap(inout T e1, inout T e2) { T tmp = e1; e1 = e2; e2 = tmp; } ... swap(foo[i], foo[j]);

Well, unless I'm mistaken, doesn't that do exactly what I described and

 the actual data around memory?

 Imagine that e1 and e2 are 1Kb each, or 1Mb each, or whatever. Then

 that your function has to perform, say, 1000 of these swaps. Surely you

 going to be copying *far* more data around than is necessary?

Copying is not going to happen if T is a class because then e1 and e2 are references to objects and not the actual objects.

I think you'll find you are mistaken... in my previous ramblings I described a situation with an array of large strings. Note carefully what is happening here: // an array exists called myArray // it has n elements // we want to swap indices 5 and 9 // let's say myArray[5] = "hello" // let's say myArray[9] = "goodbye" // so, we have: // myArray[5] = "hello" // myArray[9] = "goodbye" // temp = uninitialised temp = myArray[5]; // we now have: // myArray[5] = "hello" // myArray[9] = "goodbye" // temp = "hello" myArray[5] = myArray[9]; // we now have: // myArray[5] = "goodbye" // myArray[9] = "goodbye" // temp = "hello" myArray[9] = temp; // we now have: // myArray[5] = "goodbye" // myArray[9] = "hello" // temp = "hello" // finally we can clear up the temp value or whatever Notice that in doing this, the actual data has been swapped. I used short strings. I ask you to imagine the unneccessary data copying that would take place with multiple swaps of large strings. That is why it is obviously best to swap the pointers rather than the data itself. References to objects has nothing to do with it if you are copying the objects - and in any case, that's not really applicable because we are discussing the swapping of array elements. I'm more than slightly puzzled and disappointed that this elementary and fundamental technique is apparently meeting with such incomprehension. Initially I was a little embarrassed in case I appeared stupid in asking about the swapping (fully expecting someone to say, "there is such a swapping method here", or, "to swap the pointers, do this") but I am now feeling embarrassed in a different way because I feel that I am having to explain basic programming theory that surely most D users already know. Walter, the example you posted appears to do exactly what I have outlined step-by-step above, and swaps the actual data in memory. Can no-one see why that is a "bad thing"? Does no-one understand what I am asking? If I have somehow misunderstood then I apologise in advance for my stupidity, however I find it hard to believe that the method you gave would swap the pointers rather than the data, because if that were the case then they would all end up with the same value.
Jun 30 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 30 Jun 2004 23:38:47 +0100, Dan Williams <dnews ithium.NOSPAM.net> 
wrote:

 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:cbvaqc$1e7n$1 digitaldaemon.com...
 "Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
 news:cbv00u$uc2$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:cbuutj$sm8$1 digitaldaemon.com...
 "Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
 news:cbuol1$jrb$1 digitaldaemon.com...
 With D, it would appear that pointers only rarely have to be used,




 so
 a
 swap method would mean that people would not have to access the



 directly in this scenario.

Why not this: T[] foo; void swap(inout T e1, inout T e2) { T tmp = e1; e1 = e2; e2 = tmp; } ... swap(foo[i], foo[j]);

Well, unless I'm mistaken, doesn't that do exactly what I described

copy
 the actual data around memory?

 Imagine that e1 and e2 are 1Kb each, or 1Mb each, or whatever. Then

 that your function has to perform, say, 1000 of these swaps. Surely 

are
 going to be copying *far* more data around than is necessary?

Copying is not going to happen if T is a class because then e1 and e2 are references to objects and not the actual objects.

I think you'll find you are mistaken...

No, it is you who are mistaken (I think) :) Pls see my other response on this topic, in another thread. Basically a string as you have below *is* an array, and an array *is* a reference type like so: struct { int length; void *data; } the thing you are copying around is the above struct, *not* the data pointed to by the void *data in that struct. I wrote a test case D program to proove this. I could be wrong, if so, forgive me. Regan
 in my previous ramblings I described
 a situation with an array of large strings.

 Note carefully what is happening here:

 // an array exists called myArray
 // it has n elements
 // we want to swap indices 5 and 9
 // let's say myArray[5] = "hello"
 // let's say myArray[9] = "goodbye"
 // so, we have:
 //   myArray[5] = "hello"
 //   myArray[9] = "goodbye"
 //   temp       = uninitialised

 temp = myArray[5];

 // we now have:
 //   myArray[5] = "hello"
 //   myArray[9] = "goodbye"
 //   temp       = "hello"

 myArray[5] = myArray[9];

 // we now have:
 //   myArray[5] = "goodbye"
 //   myArray[9] = "goodbye"
 //   temp       = "hello"

 myArray[9] = temp;

 // we now have:
 //   myArray[5] = "goodbye"
 //   myArray[9] = "hello"
 //   temp       = "hello"
 // finally we can clear up the temp value or whatever

 Notice that in doing this, the actual data has been swapped. I used short
 strings. I ask you to imagine the unneccessary data copying that would 
 take
 place with multiple swaps of large strings.

 That is why it is obviously best to swap the pointers rather than the 
 data
 itself. References to objects has nothing to do with it if you are 
 copying
 the objects - and in any case, that's not really applicable because we 
 are
 discussing the swapping of array elements.

 I'm more than slightly puzzled and disappointed that this elementary and
 fundamental technique is apparently meeting with such incomprehension.
 Initially I was a little embarrassed in case I appeared stupid in asking
 about the swapping (fully expecting someone to say, "there is such a
 swapping method here", or, "to swap the pointers, do this") but I am now
 feeling embarrassed in a different way because I feel that I am having to
 explain basic programming theory that surely most D users already know.

 Walter, the example you posted appears to do exactly what I have outlined
 step-by-step above, and swaps the actual data in memory. Can no-one see 
 why
 that is a "bad thing"? Does no-one understand what I am asking? If I have
 somehow misunderstood then I apologise in advance for my stupidity, 
 however
 I find it hard to believe that the method you gave would swap the 
 pointers
 rather than the data, because if that were the case then they would all 
 end
 up with the same value.

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 30 2004
parent "Dan Williams" <dnews ithium.NOSPAM.net> writes:
Seems like the same thing is now being debated in multiple branches of this
thread, so I will concentrate on the other ones (where I have just answered
you!) ;)


"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsafl26ir5a2sq9 digitalmars.com...
 On Wed, 30 Jun 2004 23:38:47 +0100, Dan Williams <dnews ithium.NOSPAM.net>
 wrote:

 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:cbvaqc$1e7n$1 digitaldaemon.com...
 "Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
 news:cbv00u$uc2$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:cbuutj$sm8$1 digitaldaemon.com...
 "Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
 news:cbuol1$jrb$1 digitaldaemon.com...
 With D, it would appear that pointers only rarely have to be






 and
 so
 a
 swap method would mean that people would not have to access the



 directly in this scenario.

Why not this: T[] foo; void swap(inout T e1, inout T e2) { T tmp = e1; e1 = e2; e2 = tmp; } ... swap(foo[i], foo[j]);

Well, unless I'm mistaken, doesn't that do exactly what I described

copy
 the actual data around memory?

 Imagine that e1 and e2 are 1Kb each, or 1Mb each, or whatever. Then

 that your function has to perform, say, 1000 of these swaps. Surely

are
 going to be copying *far* more data around than is necessary?

Copying is not going to happen if T is a class because then e1 and e2 are references to objects and not the actual objects.

I think you'll find you are mistaken...

No, it is you who are mistaken (I think) :) Pls see my other response on this topic, in another thread. Basically a string as you have below *is* an array, and an array *is* a reference type like so: struct { int length; void *data; } the thing you are copying around is the above struct, *not* the data pointed to by the void *data in that struct. I wrote a test case D program to proove this. I could be wrong, if so, forgive me. Regan
 in my previous ramblings I described
 a situation with an array of large strings.

 Note carefully what is happening here:

 // an array exists called myArray
 // it has n elements
 // we want to swap indices 5 and 9
 // let's say myArray[5] = "hello"
 // let's say myArray[9] = "goodbye"
 // so, we have:
 //   myArray[5] = "hello"
 //   myArray[9] = "goodbye"
 //   temp       = uninitialised

 temp = myArray[5];

 // we now have:
 //   myArray[5] = "hello"
 //   myArray[9] = "goodbye"
 //   temp       = "hello"

 myArray[5] = myArray[9];

 // we now have:
 //   myArray[5] = "goodbye"
 //   myArray[9] = "goodbye"
 //   temp       = "hello"

 myArray[9] = temp;

 // we now have:
 //   myArray[5] = "goodbye"
 //   myArray[9] = "hello"
 //   temp       = "hello"
 // finally we can clear up the temp value or whatever

 Notice that in doing this, the actual data has been swapped. I used


 strings. I ask you to imagine the unneccessary data copying that would
 take
 place with multiple swaps of large strings.

 That is why it is obviously best to swap the pointers rather than the
 data
 itself. References to objects has nothing to do with it if you are
 copying
 the objects - and in any case, that's not really applicable because we
 are
 discussing the swapping of array elements.

 I'm more than slightly puzzled and disappointed that this elementary and
 fundamental technique is apparently meeting with such incomprehension.
 Initially I was a little embarrassed in case I appeared stupid in asking
 about the swapping (fully expecting someone to say, "there is such a
 swapping method here", or, "to swap the pointers, do this") but I am now
 feeling embarrassed in a different way because I feel that I am having


 explain basic programming theory that surely most D users already know.

 Walter, the example you posted appears to do exactly what I have


 step-by-step above, and swaps the actual data in memory. Can no-one see
 why
 that is a "bad thing"? Does no-one understand what I am asking? If I


 somehow misunderstood then I apologise in advance for my stupidity,
 however
 I find it hard to believe that the method you gave would swap the
 pointers
 rather than the data, because if that were the case then they would all
 end
 up with the same value.

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Jun 30 2004
prev sibling parent reply Sam McCall <tunah.d tunah.net> writes:
Dan Williams wrote:

 "Walter" <newshound digitalmars.com> wrote in message
 news:cbuutj$sm8$1 digitaldaemon.com...
 
"Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
news:cbuol1$jrb$1 digitaldaemon.com...

With D, it would appear that pointers only rarely have to be used, and


so
a

swap method would mean that people would not have to access the pointers
directly in this scenario.

Why not this: T[] foo; void swap(inout T e1, inout T e2) { T tmp = e1; e1 = e2; e2 = tmp; } ... swap(foo[i], foo[j]);

Well, unless I'm mistaken, doesn't that do exactly what I described and copy the actual data around memory? Imagine that e1 and e2 are 1Kb each, or 1Mb each, or whatever. Then imagine that your function has to perform, say, 1000 of these swaps. Surely you are going to be copying *far* more data around than is necessary?

If they're value types, sure. (The only value types that could be that big I know of are structs and maybe static arrays?). If you're determined to swap them, and not pointers to them, how do you expect the compiler to get the value of e2 into e1 and the value of e1 into e2 without doing a lot of copying? Sam
Jul 01 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Sam McCall" <tunah.d tunah.net> wrote in message
news:cc0pu0$lak$1 digitaldaemon.com...
 Dan Williams wrote:

 "Walter" <newshound digitalmars.com> wrote in message
 news:cbuutj$sm8$1 digitaldaemon.com...

"Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
news:cbuol1$jrb$1 digitaldaemon.com...

With D, it would appear that pointers only rarely have to be used, and


so
a

swap method would mean that people would not have to access the




directly in this scenario.

Why not this: T[] foo; void swap(inout T e1, inout T e2) { T tmp = e1; e1 = e2; e2 = tmp; } ... swap(foo[i], foo[j]);

Well, unless I'm mistaken, doesn't that do exactly what I described and


 the actual data around memory?

 Imagine that e1 and e2 are 1Kb each, or 1Mb each, or whatever. Then


 that your function has to perform, say, 1000 of these swaps. Surely you


 going to be copying *far* more data around than is necessary?

If they're value types, sure. (The only value types that could be that big I know of are structs and maybe static arrays?). If you're determined to swap them, and not pointers to them, how do you expect the compiler to get the value of e2 into e1 and the value of e1 into e2 without doing a lot of copying?

No no no, the point was that I wanted to swap the pointers and not the values :) I misunderstood how D did these things (and hence I'm currently wearing the Dunce cap for the next few days. The fact that the cap has D on it is poetic irony! <g>)
Jul 01 2004
parent ardita <erza_13 zbavitu.net> writes:
Dan Williams Wrote:

 
 "Sam McCall" <tunah.d tunah.net> wrote in message
 news:cc0pu0$lak$1 digitaldaemon.com...
 Dan Williams wrote:

 "Walter" <newshound digitalmars.com> wrote in message
 news:cbuutj$sm8$1 digitaldaemon.com...

"Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
news:cbuol1$jrb$1 digitaldaemon.com...

With D, it would appear that pointers only rarely have to be used, and


so
a

swap method would mean that people would not have to access the




directly in this scenario.

Why not this: T[] foo; void swap(inout T e1, inout T e2) { T tmp = e1; e1 = e2; e2 = tmp; } ... swap(foo[i], foo[j]);

Well, unless I'm mistaken, doesn't that do exactly what I described and


 the actual data around memory?

 Imagine that e1 and e2 are 1Kb each, or 1Mb each, or whatever. Then


 that your function has to perform, say, 1000 of these swaps. Surely you


 going to be copying *far* more data around than is necessary?

If they're value types, sure. (The only value types that could be that big I know of are structs and maybe static arrays?). If you're determined to swap them, and not pointers to them, how do you expect the compiler to get the value of e2 into e1 and the value of e1 into e2 without doing a lot of copying?

No no no, the point was that I wanted to swap the pointers and not the values :) I misunderstood how D did these things (and hence I'm currently wearing the Dunce cap for the next few days. The fact that the cap has D on it is poetic irony! <g>)

May 12 2009
prev sibling next sibling parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
Thanks for the reply :) Comments below...


"Walter" <newshound digitalmars.com> wrote in message
news:cbsq23$46i$1 digitaldaemon.com...
 After reading things like
 the discussion at comp.lang.c++ [1], I realised that many of the people

 dislike D are simply being picky. I read through the first hundred

 of that discussion, and failed to see anything of use (such as


 performance tests or in-depth language feature analysis) - instead, far

 much time was spent simply arguing about whether you should have used


 instead of '~' and similar rubbish.

I suspect people who latch on to something like that are ones who haven't read the spec. There's lots of legitimate things to criticise D on, but ~ isn't one of them.

Indeed :)
 I was a bit disappointed that the D executable was 110Kb (75kb after
 stripping) whereas the C++ program was only 36Kb (21Kb after stripping).

 not sure why the compiled D program is so much larger than the C one


 but never mind. That alone is not really a bad thing, as file size is
 generally not a critical requirement these days.

The D runtime library includes the garbage collector, which adds a chunk

 code not present  in a C++ executable. This chunk is a fixed overhead,
 though, and does not suggest that D compiled code is any larger.

Ahhh, yes that would explain some of the overhead. Very much worth it though!
 Wow! Pretty impressive! :) The results clearly show to me that the

 D program was approximately 10x faster than the compiled C++ program


 The reason for the speedup is D doesn't need to do memory allocation for

 strings, whereas C++ does.

 The inefficiency in the C++ comes from, when you boil it down, not
 supporting garbage collection, so C++'s std.string constantly is

 and copying strings around. wc is a stellar example of why gc'd programs

 run far faster than explicitly managed programs, despite the myth that gc
 programs are slower.

Again, that makes sense. I like the way that pointers are not needed for most of the things that they are in C++, but are still there if you need them... seems like D really does have benefits that are backed up by sound theory, and it wasn't just a fluke in my testing ;) <g>
 All I can say about that type of array is that I agree with the proposal

 forward by Norbert Nemec - has any of that been implemented yet? Is it

 to be?

It's a good candidate for 2.0. But right now, one can emulate such arrays using structs and operator overloading.

Any chance you (or anyone else) can point me toward something that already exists? In the DTL for example? (No idea where to get that from!) Or will I have to code it myself... in which case I'll post it on the newsgroup.
 While on the subject on arrays, I have a question. Is it possible to

 D arrays with mixed types?

No, D is statically typed. But you can use templates to do the equivalent, or you can define a 'variant' type and create an array of those instead (which is what most dynamically typed scripting languages do under the

 anyway).

Again, are there any examples of this around, or would I have to do it myself? I figure that people are going to need these things at some point, so if no-one else has written this stuff, I may as well do it. Do you think you will ever introduce a variant data type in D? And which method would you personally recommend - templating, or variant? I think I would go for variant.
 My final question on arrays is the methodology behind them. I figure the


 implementation is probably what I think is the best solution; i.e. that
 arrays are actually arrays of pointers to variable-length data. Is this
 correct?

No. A D array is a pair of two items, the number of elements in the array and a pointer to the array data.

Hmmmmm... Does that mean that the length of each array element is fixed? Surely I must be misunderstanding something here. Also, in such a case, surely when array keys are deleted you either get memory fragmentation which cannot easily be rectified, or else you have to move the data around upon the deletion itself? Neither of which would appeal to me. Surely there are pointers to the actual elements somewhere? Or are you using a method that I am simply not thinking of right now... (gone 2am, tired!)
 In which case, I would like to see things like a built-in swap
 method, e.g. myArray.swap(index_a, index_b) or whatever syntax you like.


 haven't noticed that feature available, but hopefully the benefits will


 apparent. When sorting etc. you don't want to be moving the actual array
 element data around in memory, just the pointers. I haven't seen if


 are any built-in sort functions, but it doesn't matter - a swap method


 all you need for a lot of things, not just sort. If one is available,

 point me to it! Plus, if this is not included and not going to be, I

 that it is still possible to swap the pointers in some way, seeing as we

 manipulate pointers directly with D, like in C/C++? Please correct me if

 of that is misunderstood.

There is a built-in sort property for arrays, but not swap.

In light of my above comments about the way that array data is stored, would there be an advantage in adding a swap method, or is it pointless?
 I noticed some talk about the way D programs have Phobos code compiled

 them, and the situation seems to be that the equivalent doesn't happen


 C,
 because the libraries are usually already available. Talk was made of
 turning off the incluusion of the Phobos code, however surely the better
 option is to simply build some static Phobos libraries, and put these in
 somewhere like /usr/lib, or even /lib (or wherever appropriate on


 for dlls) so that they are globally available? Isn't that what GCC and
 friends do? That would then mean that the common code would not have to


 recompiled every time, and neither would it have to be included in every


 program. My apologies if this suggestion, which seems so obvious to me,

 already been covered!

What you're talking about are DLLs in Windows and shared libraries under linux. Right now, I prefer things to be statically linked in because that avoids "DLL hell" where versions get mismatched.

Indeed, that is what I am on about. I figure it would be nice to compile a .so separately to the individual D programs. Perhaps this is something that will be introduced after v1.0? Once more, thankyou for your time :) Dan
Jun 29 2004
next sibling parent reply "Chr. Grade" <tickle everymail.net> writes:
There's someone in this newsgroup who gets paid by the amount of smileys 
  put in a posting. And that particular person surely is a rich man.

Dan Williams wrote:

 Thanks for the reply :) Comments below...
 
 
 "Walter" <newshound digitalmars.com> wrote in message
 news:cbsq23$46i$1 digitaldaemon.com...
 
After reading things like
the discussion at comp.lang.c++ [1], I realised that many of the people

who
dislike D are simply being picky. I read through the first hundred

messages
of that discussion, and failed to see anything of use (such as


real-world
performance tests or in-depth language feature analysis) - instead, far

too
much time was spent simply arguing about whether you should have used


'+'
instead of '~' and similar rubbish.

I suspect people who latch on to something like that are ones who haven't read the spec. There's lots of legitimate things to criticise D on, but ~ isn't one of them.

Indeed :)
I was a bit disappointed that the D executable was 110Kb (75kb after
stripping) whereas the C++ program was only 36Kb (21Kb after stripping).

I'm
not sure why the compiled D program is so much larger than the C one


[2],
but never mind. That alone is not really a bad thing, as file size is
generally not a critical requirement these days.

The D runtime library includes the garbage collector, which adds a chunk

of
code not present  in a C++ executable. This chunk is a fixed overhead,
though, and does not suggest that D compiled code is any larger.

Ahhh, yes that would explain some of the overhead. Very much worth it though!
Wow! Pretty impressive! :) The results clearly show to me that the

compiled
D program was approximately 10x faster than the compiled C++ program


[3].
The reason for the speedup is D doesn't need to do memory allocation for

its
strings, whereas C++ does.

The inefficiency in the C++ comes from, when you boil it down, not
supporting garbage collection, so C++'s std.string constantly is

allocating
and copying strings around. wc is a stellar example of why gc'd programs

can
run far faster than explicitly managed programs, despite the myth that gc
programs are slower.

Again, that makes sense. I like the way that pointers are not needed for most of the things that they are in C++, but are still there if you need them... seems like D really does have benefits that are backed up by sound theory, and it wasn't just a fluke in my testing ;) <g>
All I can say about that type of array is that I agree with the proposal

put
forward by Norbert Nemec - has any of that been implemented yet? Is it

going
to be?

It's a good candidate for 2.0. But right now, one can emulate such arrays using structs and operator overloading.

Any chance you (or anyone else) can point me toward something that already exists? In the DTL for example? (No idea where to get that from!) Or will I have to code it myself... in which case I'll post it on the newsgroup.
While on the subject on arrays, I have a question. Is it possible to

create
D arrays with mixed types?

No, D is statically typed. But you can use templates to do the equivalent, or you can define a 'variant' type and create an array of those instead (which is what most dynamically typed scripting languages do under the

hood
anyway).

Again, are there any examples of this around, or would I have to do it myself? I figure that people are going to need these things at some point, so if no-one else has written this stuff, I may as well do it. Do you think you will ever introduce a variant data type in D? And which method would you personally recommend - templating, or variant? I think I would go for variant.
My final question on arrays is the methodology behind them. I figure the


D
implementation is probably what I think is the best solution; i.e. that
arrays are actually arrays of pointers to variable-length data. Is this
correct?

No. A D array is a pair of two items, the number of elements in the array and a pointer to the array data.

Hmmmmm... Does that mean that the length of each array element is fixed? Surely I must be misunderstanding something here. Also, in such a case, surely when array keys are deleted you either get memory fragmentation which cannot easily be rectified, or else you have to move the data around upon the deletion itself? Neither of which would appeal to me. Surely there are pointers to the actual elements somewhere? Or are you using a method that I am simply not thinking of right now... (gone 2am, tired!)
In which case, I would like to see things like a built-in swap
method, e.g. myArray.swap(index_a, index_b) or whatever syntax you like.


I
haven't noticed that feature available, but hopefully the benefits will


be
apparent. When sorting etc. you don't want to be moving the actual array
element data around in memory, just the pointers. I haven't seen if


there
are any built-in sort functions, but it doesn't matter - a swap method


is
all you need for a lot of things, not just sort. If one is available,

please
point me to it! Plus, if this is not included and not going to be, I

assume
that it is still possible to swap the pointers in some way, seeing as we

can
manipulate pointers directly with D, like in C/C++? Please correct me if

any
of that is misunderstood.

There is a built-in sort property for arrays, but not swap.

In light of my above comments about the way that array data is stored, would there be an advantage in adding a swap method, or is it pointless?
I noticed some talk about the way D programs have Phobos code compiled

into
them, and the situation seems to be that the equivalent doesn't happen


in
C,

because the libraries are usually already available. Talk was made of
turning off the incluusion of the Phobos code, however surely the better
option is to simply build some static Phobos libraries, and put these in
somewhere like /usr/lib, or even /lib (or wherever appropriate on


Windows
for dlls) so that they are globally available? Isn't that what GCC and
friends do? That would then mean that the common code would not have to


be
recompiled every time, and neither would it have to be included in every


D
program. My apologies if this suggestion, which seems so obvious to me,

has
already been covered!

What you're talking about are DLLs in Windows and shared libraries under linux. Right now, I prefer things to be statically linked in because that avoids "DLL hell" where versions get mismatched.

Indeed, that is what I am on about. I figure it would be nice to compile a .so separately to the individual D programs. Perhaps this is something that will be introduced after v1.0? Once more, thankyou for your time :) Dan

Jun 30 2004
parent "Dan Williams" <dnews ithium.NOSPAM.net> writes:
I wish :) :D :P ;)


"Chr. Grade" <tickle everymail.net> wrote in message
news:cbt7ik$n3v$1 digitaldaemon.com...
 There's someone in this newsgroup who gets paid by the amount of smileys
   put in a posting. And that particular person surely is a rich man.

Jun 30 2004
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Dan Williams wrote:
...
 Any chance you (or anyone else) can point me toward something that already
 exists? In the DTL for example? (No idea where to get that from!) Or will I
 have to code it myself... in which case I'll post it on the newsgroup.

DTL hasn't been released yet. Matthew Wilson is working on it, but he's been distracted by his career as an author. You can read more here: digitalmars.D.dtl/57
 
 
 
While on the subject on arrays, I have a question. Is it possible to

create
D arrays with mixed types?

No, D is statically typed. But you can use templates to do the equivalent, or you can define a 'variant' type and create an array of those instead (which is what most dynamically typed scripting languages do under the

hood
anyway).


I'd love to see a variant type built into the language.


-- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Jun 29 2004
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 29 Jun 2004 23:16:54 -0500, J C Calvarese wrote:

 Dan Williams wrote:
 ...
 Any chance you (or anyone else) can point me toward something that already
 exists? In the DTL for example? (No idea where to get that from!) Or will I
 have to code it myself... in which case I'll post it on the newsgroup.

DTL hasn't been released yet. Matthew Wilson is working on it, but he's been distracted by his career as an author. You can read more here: digitalmars.D.dtl/57
 
While on the subject on arrays, I have a question. Is it possible to

create
D arrays with mixed types?

No, D is statically typed. But you can use templates to do the equivalent, or you can define a 'variant' type and create an array of those instead (which is what most dynamically typed scripting languages do under the

hood
anyway).


I'd love to see a variant type built into the language.



Hear! Hear! Long live the VARIANT type. <PLUG type="shameless"> Actually I'm spoilt because I use Euphoria as my main coding language and it's type system is so simple - it only has two data types: Numbers and Vectors. Numbers are IEEE 64-bit floats but are optimised for integers (up to 31-bits). Vectors are dynamic and each element can be either a number or a vector, and they are changeable at runtime. It also has something called an Object but that is just a variant placeholder for any data type. Even though its an interpreted language with garbage collection built-in, Euphoria is frighteningly fast! I'm looking towards D as my choice of compiled language. </PLUG> -- Derek Melbourne, Australia 30/Jun/04 2:46:55 PM
Jun 29 2004
next sibling parent Derek Parnell <derek psych.ward> writes:
Content-type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Wed, 30 Jun 2004 14:56:17 +1000, Derek Parnell wrote:


[snip]
 
 Hear! Hear! Long live the VARIANT type. 
 
 <PLUG type="shameless">
 Actually I'm spoilt because I use Euphoria as my main coding language and
 it's type system is so simple - it only has two data types: Numbers and
 Vectors. Numbers are IEEE 64-bit floats but are optimised for integers (up
 to 31-bits). Vectors are dynamic and each element can be either a number or
 a vector, and they are changeable at runtime. It also has something called
 an Object but that is just a variant placeholder for any data type.
 
 Even though its an interpreted language with garbage collection built-in,
 Euphoria is frighteningly fast! I'm looking towards D as my choice of
 compiled language.
 </PLUG>

I just did a quick speed comparision using the wc.d sample and its equivalent Euphoria program (attached if you're interested). Using a 36.7MB text file... Compiled D (wc.exe) took 1.15 seconds. Interpreted Euphoria (wc.ex) took 4.51 seconds. Not too sloppy for an interpreter! -- Derek Melbourne, Australia 30/Jun/04 4:48:47 PM
Jun 29 2004
prev sibling parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:cbth5j$15ml$1 digitaldaemon.com...
 On Tue, 29 Jun 2004 23:16:54 -0500, J C Calvarese wrote:

 Dan Williams wrote:
 ...

 I'd love to see a variant type built into the language.




Hear! Hear! Long live the VARIANT type.

Glad to see that I'm not the only one who would find a variant data type useful! :D
Jun 30 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 30 Jun 2004 10:32:24 +0100, Dan Williams <dnews ithium.NOSPAM.net> 
wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:cbth5j$15ml$1 digitaldaemon.com...
 On Tue, 29 Jun 2004 23:16:54 -0500, J C Calvarese wrote:

 Dan Williams wrote:
 ...

 I'd love to see a variant type built into the language.




Hear! Hear! Long live the VARIANT type.

Glad to see that I'm not the only one who would find a variant data type useful! :D

What exactly is a variant type? Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 30 2004
parent reply Derek <derek psyc.ward> writes:
On Thu, 01 Jul 2004 11:11:05 +1200, Regan Heath wrote:

 On Wed, 30 Jun 2004 10:32:24 +0100, Dan Williams <dnews ithium.NOSPAM.net> 
 wrote:
 
 "Derek Parnell" <derek psych.ward> wrote in message
 news:cbth5j$15ml$1 digitaldaemon.com...
 On Tue, 29 Jun 2004 23:16:54 -0500, J C Calvarese wrote:

 Dan Williams wrote:
 ...

 I'd love to see a variant type built into the language.




Hear! Hear! Long live the VARIANT type.

Glad to see that I'm not the only one who would find a variant data type useful! :D

What exactly is a variant type? Regan.

Let's pretend a bit... variant A; int B = 5; float C = 1.1; char[] D = "a string"; A = B; // ok A = C; // ok A = D; // ok No casts involved. -- Derek Melbourne, Australia
Jun 30 2004
next sibling parent "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Derek" <derek psyc.ward> wrote in message
news:zp1piricvp4s.1lgdnwwty0ip6$.dlg 40tude.net...
 On Thu, 01 Jul 2004 11:11:05 +1200, Regan Heath wrote:

 On Wed, 30 Jun 2004 10:32:24 +0100, Dan Williams


 wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:cbth5j$15ml$1 digitaldaemon.com...
 On Tue, 29 Jun 2004 23:16:54 -0500, J C Calvarese wrote:

 Dan Williams wrote:
 ...

 I'd love to see a variant type built into the language.




Hear! Hear! Long live the VARIANT type.

Glad to see that I'm not the only one who would find a variant data



 useful! :D

What exactly is a variant type? Regan.

Let's pretend a bit... variant A; int B = 5; float C = 1.1; char[] D = "a string"; A = B; // ok A = C; // ok A = D; // ok No casts involved.

...which is exactly why I am keen to see a variant data type included in the core of the D language ;)
Jun 30 2004
prev sibling parent Regan Heath <regan netwin.co.nz> writes:
On Thu, 1 Jul 2004 09:41:51 +1000, Derek <derek psyc.ward> wrote:

 On Thu, 01 Jul 2004 11:11:05 +1200, Regan Heath wrote:

 On Wed, 30 Jun 2004 10:32:24 +0100, Dan Williams 
 <dnews ithium.NOSPAM.net>
 wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:cbth5j$15ml$1 digitaldaemon.com...
 On Tue, 29 Jun 2004 23:16:54 -0500, J C Calvarese wrote:

 Dan Williams wrote:
 ...

 I'd love to see a variant type built into the language.




Hear! Hear! Long live the VARIANT type.

Glad to see that I'm not the only one who would find a variant data type useful! :D

What exactly is a variant type? Regan.

Let's pretend a bit... variant A; int B = 5; float C = 1.1; char[] D = "a string"; A = B; // ok A = C; // ok A = D; // ok No casts involved.

Cool.. If everything (even primitives) were derived from Object you could simply use that. Classes are, so you can go: class A { } class B : A { } void main() { A a = new A(); B b = new B(); Object v; v = a; v = b; a = b; } Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 30 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
news:cbt4et$ihd$1 digitaldaemon.com...
 The D runtime library includes the garbage collector, which adds a chunk

 code not present  in a C++ executable. This chunk is a fixed overhead,
 though, and does not suggest that D compiled code is any larger.

though!

I forgot to add that gc code can also be incrementally smaller, because the logic to keep track of who owns the memory is no longer needed.
 Any chance you (or anyone else) can point me toward something that already
 exists? In the DTL for example? (No idea where to get that from!) Or will

 have to code it myself... in which case I'll post it on the newsgroup.

As far as I know, it hasn't been implemented by anyone yet.
 While on the subject on arrays, I have a question. Is it possible to

 D arrays with mixed types?



 or you can define a 'variant' type and create an array of those instead
 (which is what most dynamically typed scripting languages do under the

 anyway).

myself? I figure that people are going to need these things at some point, so if no-one else has written this stuff, I may as well do it.

You might as well give it a whirl <g>.
 Do you think you will ever introduce a variant data type in D? And which
 method would you personally recommend - templating, or variant? I think I
 would go for variant.

Each has their strengths and weaknesses. Templating is part of the language, but variant can simply be part of the library.
 No. A D array is a pair of two items, the number of elements in the


 and a pointer to the array data.

Surely I must be misunderstanding something here.

Think of an array as: struct { int length; void *data; }; You can change either or both members as required to do various things.
 Also, in such a case,
 surely when array keys are deleted you either get memory fragmentation

 cannot easily be rectified, or else you have to move the data around upon
 the deletion itself?

You're thinking of associative arrays, which are different from linear arrays?
 Neither of which would appeal to me. Surely there are
 pointers to the actual elements somewhere? Or are you using a method that

 am simply not thinking of right now... (gone 2am, tired!)

The data member points to the elements. They are stored sequentially in memory.
 There is a built-in sort property for arrays, but not swap.


 there be an advantage in adding a swap method, or is it pointless?

There's some utility for it, but not a whole lot.
 What you're talking about are DLLs in Windows and shared libraries under
 linux. Right now, I prefer things to be statically linked in because


 avoids "DLL hell" where versions get mismatched.

.so separately to the individual D programs. Perhaps this is something

 will be introduced after v1.0?

after 1.0
Jun 29 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cbtj75$18ub$1 digitaldaemon.com...
 "Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
 news:cbt4et$ihd$1 digitaldaemon.com...
 D is statically typed. But you can use templates to do the


 or you can define a 'variant' type and create an array of those



 (which is what most dynamically typed scripting languages do under the

 anyway).

myself?

You might as well give it a whirl <g>.

Ok, fair enough :) I'll try to find some time over the next few weeks to do so.
 Do you think you will ever introduce a variant data type in D? And which
 method would you personally recommend - templating, or variant? I think


 would go for variant.

Each has their strengths and weaknesses. Templating is part of the

 but variant can simply be part of the library.

To risk annoyance by repetition: Do you think you will ever introduce a variant data type in D? For instance if I wrote such a thing, would you include it as part of D?
 A D array is a pair of two items, the number of elements in the


 and a pointer to the array data.

Surely I must be misunderstanding something here.

Think of an array as: struct { int length; void *data; }; You can change either or both members as required to do various things.
 Also, in such a case,
 surely when array keys are deleted you either get memory fragmentation

 cannot easily be rectified, or else you have to move the data around


 the deletion itself?

You're thinking of associative arrays, which are different from linear arrays?
 Surely there are pointers to the actual elements somewhere? Or are you
 using a method that I am simply not thinking of right now...
 (gone 2am, tired!)

The data member points to the elements. They are stored sequentially in memory.

I think I see what you mean. An array itself is a struct with length n where n is both the count of the elements and also the amount of memory used by the sequentially-stored pointers to element data, yes? And each element then holds its own data with its own data properties. Ok, that makes sense, and this is essentially the way I would handle it in C++. The place that I came unstuck is in asking about element swapping. Let me explain that one further, so that you'll have a clearer idea of my question. Take an array with 100 elements, where each element is a variable-length string. When it comes to sort the array, obviously the best method is to swap the data pointers after a comparison, rather than swap the data itself. Now, this is why I asked about a swap method - there are several things that I would need to utilise a swap for, and obviously I want to be confident that I am swapping the pointers and not the data! As there is no swap method, how would I directly access the array index's data pointers in order to swap them? Imagine that elements 5 and 9 need swapping, and are around about 1Kb each. If I say, temp = myArray[5]; myArray[5] = myArray[9]; myArray[9] = temp; then I am needlessly copying 1Kb blocks around in memory, right? So I need to be able to swap the pointers and therefore temp needs to be a pointer, but while this is straightforward in C++, I don't know how I would do this in D. Therefore my ignorance when it comes to D has prompted what has undoubtably appeared to be a rather stupid question <g>
Jun 30 2004
next sibling parent reply Jesus <Jesus_member pathlink.com> writes:
In article <cbu32g$2cf0$1 digitaldaemon.com>, Dan Williams says...

I think I see what you mean. An array itself is a struct with length n where
n is both the count of the elements and also the amount of memory used 

the sequentially-stored pointers to element data, yes? And each element 

holds its own data with its own data properties. Ok, that makes sense, 

this is essentially the way I would handle it in C++. The place that I came
unstuck is in asking about element swapping. Let me explain that one
further, so that you'll have a clearer idea of my question.

Take an array with 100 elements, where each element is a 

string. When it comes to sort the array, obviously the best method is to
swap the data pointers after a comparison, rather than swap the data 

Now, this is why I asked about a swap method - there are several things 

I would need to utilise a swap for, and obviously I want to be confident
that I am swapping the pointers and not the data!

As there is no swap method, how would I directly access the array 

data pointers in order to swap them? Imagine that elements 5 and 9 

swapping, and are around about 1Kb each. If I say, temp = myArray[5];
myArray[5] = myArray[9]; myArray[9] = temp; then I am needlessly copying 

blocks around in memory, right? So I need to be able to swap the 

and therefore temp needs to be a pointer, but while this is 

in C++, I don't know how I would do this in D. Therefore my ignorance 

it comes to D has prompted what has undoubtably appeared to be a 

stupid question <g>

You appear to have a misunderstanding about the structure of arrays; allow me to clear this up. In an array you have data stored sequentially in memory. Imagine an array of bytes stored at, for the sake of argument, 0x10. byte[0] is stored at 0x10, byte[1] is stored at 0x11 etc. Since the elements are sequential you don't need a pointer to each element, just a single pointer to the first element, which can then be incremented by sizeof(<datatype>) to access subsequent elements. This is what an array in C is. byte[3] is the equivalent of *byte + 3. The problem with this is that you must either use static arrays so the compiler can check every access to make sure you don't try to access past the end of the array, or risk indexing garbage. D improves this by having each array store its length so you can check bounds at run time. You can have an array of pointers if you declare it as such, but if you declare an array of primitives you access them through increments of the base pointer. This is also why you can't mix types; array elements must be the same size so the program knows how many bytes to increment the pointer by. If you want to mix types you can always exploit polymorphism and have arrays of Objects. This, however, means you can't mix primitives unless you wrap them in classes (which is why Java has classes of Integer, Float etc). It would be nice if you can have arrays of "generic pointer" which is what some languages do, and is probably why you're confused. Scheme (LISP dialect) comes to mind as an "everything is a pointer" weakly typed language.
Jun 30 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Jesus" <Jesus_member pathlink.com> wrote in message
news:cbuh1n$89l$1 digitaldaemon.com...
 In article <cbu32g$2cf0$1 digitaldaemon.com>, Dan Williams says...

I think I see what you mean. An array itself is a struct with length n


n is both the count of the elements and also the amount of memory used

the sequentially-stored pointers to element data, yes? And each element

holds its own data with its own data properties. Ok, that makes sense,

this is essentially the way I would handle it in C++. The place that I


unstuck is in asking about element swapping. Let me explain that one
further, so that you'll have a clearer idea of my question.

Take an array with 100 elements, where each element is a

string. When it comes to sort the array, obviously the best method is to
swap the data pointers after a comparison, rather than swap the data

Now, this is why I asked about a swap method - there are several things

I would need to utilise a swap for, and obviously I want to be confident
that I am swapping the pointers and not the data!

As there is no swap method, how would I directly access the array

data pointers in order to swap them? Imagine that elements 5 and 9

swapping, and are around about 1Kb each. If I say, temp = myArray[5];
myArray[5] = myArray[9]; myArray[9] = temp; then I am needlessly copying

blocks around in memory, right? So I need to be able to swap the

and therefore temp needs to be a pointer, but while this is

in C++, I don't know how I would do this in D. Therefore my ignorance

it comes to D has prompted what has undoubtably appeared to be a

stupid question <g>

You appear to have a misunderstanding about the structure of arrays; allow me to clear this up.

Not arrays in general... just how D deals with them; specifically arrays with variable-length elements and also associative arrays.
 In an array you have data stored sequentially in memory. Imagine an array
 of bytes stored at, for the sake of argument, 0x10. byte[0] is stored at

 byte[1] is stored at 0x11 etc.

 Since the elements are sequential you don't need a pointer to each
 element, just a single pointer to the first element, which can then be
 incremented by sizeof(<datatype>) to access subsequent elements. This
 is what an array in C is. byte[3] is the equivalent of *byte + 3.

That works fine for arrays with fixed-length elements, such as arrays of type int, or arrays of pointers to other arrays.
 The problem with this is that you must either use static arrays so the
 compiler can check every access to make sure you don't try to access
 past the end of the array, or risk indexing garbage.

 D improves this by having each array store its length so you can check
 bounds at run time.

 You can have an array of pointers if you declare it as such, but if you
 declare an array of primitives you access them through increments of the
 base pointer. This is also why you can't mix types; array elements must be
 the same size so the program knows how many bytes to increment the
 pointer by.

But this is the problem that I am asking about. If you notice, my question was directed not at arrays with fixed-length elements, but those with variable-length elements. Ten years or so ago I remember a similar problem with database filesystems. The whole sequential access versus random access thing (boy that takes me back!). In some ways this is the same - it's fine to have a fixed-size entity stored in the way you describe, because simple calculations will tell you where every element in the array starts and ends. However, it soon falls apart when you have a variable-length entity. For instance, let's say I want to store two strings; one is 10 bytes long and the other is 1000 bytes long. Right at the start I have a problem here because I don't personally know how D would store that. From what I can gather, because strings are dealt with as character arrays in D (similar to but better than C++) the main array would not "store" the complete string, but a reference to the character array, which of course in turn references its own elements. Is this correct?
 If you want to mix types you can always exploit polymorphism and have
 arrays of Objects. This, however, means you can't mix primitives unless
 you wrap them in classes (which is why Java has classes of Integer, Float
 etc). It would be nice if you can have arrays of "generic pointer" which

 what some languages do, and is probably why you're confused. Scheme
 (LISP dialect) comes to mind as an "everything is a pointer" weakly typed
 language.

I think what is wrong here is that we are both missing what the other is saying, to some extent. Believe me, I understand all about arrays :) I've written code using what must surely be just about every array-type structure out there in the past ten years, and in various languages. My questions were badly explained, due to my ignorance of how D has been written. In the description of D's various features, I see things that make me think, "oh, is D doing that this way or that way?" and so I ask the question... and then someone doesn't quite understand what I am asking, because I am not sure how to ask :) If all D arrays are simply the same as C++ arrays but with length etc. built in (i.e. if the storage mechanism is, for the purpose of our needs, the same) then I have at least some familiar ground on which to stand. I guess maybe I should have experimented a bit before asking, however I wasn't even sure how to test to determine the method in use! Perhaps I should just have assumed that D arrays were stored in the way you describe, but I was always taught to ask questions because "assume makes an ass out of u and me" and all that <g> Which brings me back to the point I started rambling about in the first place. I have decided to reiterate it like this: "What happens, data-wise, when two elements in an array are swapped?" If you read what I said about wanting to avoid copying more memory than necessary, you will hopefully be able to pick up on my trail here and see why I was asking these silly questions in the first place. I do have a precedant in asking - I have seen C code written by people that needlessly swaps actual data around in memory rather than the pointers to said data, so I wish to ensure that I don't do the same thing in D by mistake as a result of not inquiring about the underlying mechanism.
Jun 30 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Dan Williams wrote:

 You appear to have a misunderstanding about the structure of arrays;
 allow me to clear this up.

with variable-length elements and also associative arrays.

What you call "arrays with variable-length elements" should rather be called nested array. The array elements themselves always have a fixed size. If you need an array of strings, thats effectively an array holding references to arrays which then hold the individual string data. Just the same as in C. Your example for swapping data already is handling references as it is. Variable-sized data can always only be handled by reference. Just like in C. There is little mystic bahavior in D arrays, just that an array reference does not only keep the pointer, but also the length of the array.
Jun 30 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
Hmmmm...


"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:cbun74$hpk$1 digitaldaemon.com...
 Dan Williams wrote:

 You appear to have a misunderstanding about the structure of arrays;
 allow me to clear this up.

with variable-length elements and also associative arrays.

What you call "arrays with variable-length elements" should rather be

 nested array. The array elements themselves always have a fixed size. If
 you need an array of strings, thats effectively an array holding

 to arrays which then hold the individual string data. Just the same as in
 C.

I believe that is what I went on to describe.
 Your example for swapping data already is handling references as it is.
 Variable-sized data can always only be handled by reference. Just like in
 C.

I think that what you are saying is right, but applied wrongly to my question. Making a copy will make a copy of the data, whether accessed by reference or not. This is precisely what I wish to avoid - I want to only swap the pointers. I do not see how three assignments using a temporary variable will acheive this; rather, it will copy the data itself three times.
 There is little mystic bahavior in D arrays, just that an array reference
 does not only keep the pointer, but also the length of the array.

The first thing I wanted to find out was how D dealt with arrays. It seems I went about my questioning in a confusing way, but I got there in the end! :) The second thing was talking about element swapping, and for some reason it would appear that I'm still not quite being understood on this :( (not sure why, as it is pretty fundamental stuff).
Jun 30 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 30 Jun 2004 17:19:17 +0100, Dan Williams <dnews ithium.NOSPAM.net> 
wrote:

 Hmmmm...


 "Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
 news:cbun74$hpk$1 digitaldaemon.com...
 Dan Williams wrote:

 You appear to have a misunderstanding about the structure of arrays;
 allow me to clear this up.


 with variable-length elements and also associative arrays.

What you call "arrays with variable-length elements" should rather be

 nested array. The array elements themselves always have a fixed size. If
 you need an array of strings, thats effectively an array holding

 to arrays which then hold the individual string data. Just the same as 
 in
 C.

I believe that is what I went on to describe.
 Your example for swapping data already is handling references as it is.
 Variable-sized data can always only be handled by reference. Just like 
 in
 C.

I think that what you are saying is right, but applied wrongly to my question. Making a copy will make a copy of the data, whether accessed by reference or not. This is precisely what I wish to avoid - I want to only swap the pointers. I do not see how three assignments using a temporary variable will acheive this; rather, it will copy the data itself three times.
 There is little mystic bahavior in D arrays, just that an array 
 reference
 does not only keep the pointer, but also the length of the array.

The first thing I wanted to find out was how D dealt with arrays. It seems I went about my questioning in a confusing way, but I got there in the end! :) The second thing was talking about element swapping, and for some reason it would appear that I'm still not quite being understood on this :( (not sure why, as it is pretty fundamental stuff).

I think I have understood you in my last post.. haven't I? Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 30 2004
parent "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsafkzewn5a2sq9 digitalmars.com...
 On Wed, 30 Jun 2004 17:19:17 +0100, Dan Williams <dnews ithium.NOSPAM.net>
 wrote:

 Hmmmm...


 "Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
 news:cbun74$hpk$1 digitaldaemon.com...
 Dan Williams wrote:

 You appear to have a misunderstanding about the structure of arrays;
 allow me to clear this up.


 with variable-length elements and also associative arrays.

What you call "arrays with variable-length elements" should rather be

 nested array. The array elements themselves always have a fixed size.



 you need an array of strings, thats effectively an array holding

 to arrays which then hold the individual string data. Just the same as
 in
 C.

I believe that is what I went on to describe.
 Your example for swapping data already is handling references as it is.
 Variable-sized data can always only be handled by reference. Just like
 in
 C.

I think that what you are saying is right, but applied wrongly to my question. Making a copy will make a copy of the data, whether accessed by reference or not. This is precisely what I wish to avoid - I want to only swap the pointers. I do not see how three assignments using a temporary variable will acheive this; rather, it will copy the data itself three times.
 There is little mystic bahavior in D arrays, just that an array
 reference
 does not only keep the pointer, but also the length of the array.

The first thing I wanted to find out was how D dealt with arrays. It seems I went about my questioning in a confusing way, but I got there in the end! :) The second thing was talking about element swapping, and for some reason it would appear that I'm still not quite being understood on this :( (not sure why, as it is pretty fundamental stuff).

I think I have understood you in my last post.. haven't I? Regan.

...I think so, but for some reason it seems everyone is missing the point of what I am trying to say about swapping. I find that very unnerving! <g>
Jun 30 2004
prev sibling parent reply Derek <derek psyc.ward> writes:
On Wed, 30 Jun 2004 17:19:17 +0100, Dan Williams wrote:

 Hmmmm...
 

[snip]
 The second thing was talking about element swapping, and for some reason it
 would appear that I'm still not quite being understood on this :( (not sure
 why, as it is pretty fundamental stuff).

Okay, I'll have a go at describing D's swap behaviour... #char[] A = "first"; #char[] B = "second"; # #void main() #{ # char[] T; # # T = A; # A = B; # B = T; # # printf("%.*s %.*s\n", A, B); #} Using the code example above... Initially 'A' takes up a single two-32-bit area of RAM. Let's say A is located at RAM Address (RA) 1000. And likewise, B is at 2060. The first 32-bit portion of what makes up A's content has the string length of 5, and B's first 32-bit area contains 6 (the length of 'second'). The second 32-bit area of A contains the address of the bytes that make up the literal 'first'. Let's say this is RA 4016. B's string pointer also points to its data 'second'. Let's say it is at 5012. So summarizing... A --> [5,4016] B --> [6,5012] Now we have T which has no initial values. T is located at 7000 and also has a two-32-bit area. The assignment "T = A" cause T to have the contents [5,4016]. "A = B" cause A to now have the contents [6,5012]. "B = T" causes B to have the contents [5,4016]. So we end up with ... A --> [6,5012] B --> [5,4016] Meanwhile the actual string data has not moved a muscle. Hope this helps. -- Derek Melbourne, Australia
Jun 30 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Derek" <derek psyc.ward> wrote in message
news:1txb3s0xe4h7a$.oc6ijhdctn5l.dlg 40tude.net...
 On Wed, 30 Jun 2004 17:19:17 +0100, Dan Williams wrote:

 Hmmmm...

[snip]
 The second thing was talking about element swapping, and for some reason


 would appear that I'm still not quite being understood on this :( (not


 why, as it is pretty fundamental stuff).

Okay, I'll have a go at describing D's swap behaviour... #char[] A = "first"; #char[] B = "second"; # #void main() #{ # char[] T; # # T = A; # A = B; # B = T; # # printf("%.*s %.*s\n", A, B); #} Using the code example above... Initially 'A' takes up a single two-32-bit area of RAM. Let's say A is located at RAM Address (RA) 1000. And likewise, B is at 2060. The first 32-bit portion of what makes up A's content has the string length of 5,

 B's first 32-bit area contains 6 (the length of 'second'). The second
 32-bit area of A contains the address of the bytes that make up the

 'first'. Let's say this is RA 4016. B's string pointer also points to its
 data 'second'. Let's say it is at 5012.

So far, so good... I understand and agree with that, and it is what I would expect.
 So summarizing...

 A --> [5,4016]
 B --> [6,5012]

 Now we have T which has no initial values. T is located at 7000 and also
 has a two-32-bit area.

Again, agreed.
 The assignment "T = A" cause T to have the contents [5,4016].
 "A = B" cause A to now have the contents [6,5012]. "B = T" causes
 B to have the contents [5,4016]. So we end up with ...

No, no, NO! Gah! ...I'll explain in a minute :D
 A --> [6,5012]
 B --> [5,4016]

 Meanwhile the actual string data has not moved a muscle.

There are two, and only two, methods for this. A) The string data itself is copied B) The pointer is copied Now, B) is the method I want to use... and is also the method you have *described*, but *NOT* the method that would actually take place in the code example you have provided.
 #    T = A;        // T is now "first"
 #    A = B;        // A is now "second"
 #    B = T;        // B is now "first"

This code will copy the string data, not the pointer! Stop, step back, think about it for a minute. What happens if you do this:
 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "first"

OK? Yes? That's the way it should be; all is well. BUT if what you are saying is true:
 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "car"

Uh-oh! Oh dear! Not what we wanted! Why has this happened? Because, in your example:
 The assignment "T = A" cause T to have the contents [5,4016].
 "A = B" cause A to now have the contents [6,5012]. "B = T" causes
 B to have the contents [5,4016].

So, that means that if part way through we change A, even though we already copied A to T, we are still changing T! Obviously this is incorrect and flawed, as that is not what assignment does or is supposed to do. Your example did not have anything in it to specify that a reference should be used, so in that case a copy should be made. Just like passing by reference or by value etc. So... the strings DO move around in memory if you copy in this way - they must do, they have to do so, otherwise the language would not make any sense. If everything was assigned by reference when you do a simple a = b then how would you make copies? I know that one can utilise pointers in D, and I haven't actually looked too deeply into that for two reasons: first, I hate pointers <g> and second, D seems geared up so that you shouldn't really have to use pointers. This is why I started asking about a swap method, although thinking about it, maybe it would be good to have simply as a standalone function and not as a dedicated array method. It's late for me right now (1am) but if I get chance tomorrow, I will look into how D deals with pointers, and write a test case to demonstrate the two different methods.
Jun 30 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 1 Jul 2004 01:03:02 +0100, Dan Williams <dnews ithium.NOSPAM.net> 
wrote:
 There are two, and only two, methods for this.

 A) The string data itself is copied
 B) The pointer is copied

 Now, B) is the method I want to use... and is also the method you have
 *described*, but *NOT* the method that would actually take place in the 
 code
 example you have provided.

B) is the method that *does* actually take place, try my example code... --[test.d]-- struct array { int length; void *data; } void swap(inout char[] A, inout char[] B) { char[] T; T = A; A = B; B = T; } void swapAssign(inout char[] A, inout char[] B, char[] value) { char[] T; T = A; A = value; B = T; } void output(char[] A, char[] label) { array *p = cast(array *)&A; printf("(%.*s) = %08x = (%.*s)\n",label,p.data,p.length,p.data); } void main() { char[] A = "first"; char[] B = "second"; char[] C = "third"; output(A,"A"); output(B,"B"); output(C,"C"); printf("\n"); swapAssign(A,B,"car"); output(A,"A"); output(B,"B"); output(C,"C"); printf("\n"); } it prints: D:\D\src\build\temp>copytest (A) = 0040f098 = (first) (B) = 0040f0a8 = (second) (C) = 0040f0b8 = (third) (A) = 0040f0f8 = (car) (B) = 0040f098 = (first) (C) = 0040f0b8 = (third)
 #    T = A;        // T is now "first"
 #    A = B;        // A is now "second"
 #    B = T;        // B is now "first"

This code will copy the string data, not the pointer! Stop, step back, think about it for a minute. What happens if you do this:
 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "first"

OK? Yes? That's the way it should be; all is well. BUT if what you are saying is true:
 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "car"

Uh-oh! Oh dear! Not what we wanted! Why has this happened? Because, in your example:
 The assignment "T = A" cause T to have the contents [5,4016].
 "A = B" cause A to now have the contents [6,5012]. "B = T" causes
 B to have the contents [5,4016].


This cannot be applied as it does not take the assignment to the new array into account, it should now read... The assignment "T = A" cause T to have the contents [5,4016]. A = "car" cause A to have contents of the new array, say [3,6012]. "B = T" causes B to have the contents [5,4016].
 So, that means that if part way through we change A, even though we 
 already
 copied A to T, we are still changing T! Obviously this is incorrect and
 flawed, as that is not what assignment does or is supposed to do. Your
 example did not have anything in it to specify that a reference should be
 used, so in that case a copy should be made. Just like passing by 
 reference
 or by value etc.

 So... the strings DO move around in memory if you copy in this way

Nope.
 - they
 must do, they have to do so, otherwise the language would not make any
 sense. If everything was assigned by reference when you do a simple a = b
 then how would you make copies?

You call the .dup method on the array.
 I know that one can utilise pointers in D, and I haven't actually looked 
 too
 deeply into that for two reasons: first, I hate pointers <g> and second, 
 D
 seems geared up so that you shouldn't really have to use pointers.

I don't mind pointers, they are powerful, if a little dangerous, that's part of the attraction. I do like that I can get almost the same power in D without them.
 This is
 why I started asking about a swap method, although thinking about it, 
 maybe
 it would be good to have simply as a standalone function and not as a
 dedicated array method.

Or this template: template swap(T) { void swap(inout T a, inout T b) { T c; c = a; a = b; b = c; } } which works for everything, copying memory only if T is a struct of some sort.
 It's late for me right now (1am) but if I get chance tomorrow, I will 
 look
 into how D deals with pointers, and write a test case to demonstrate the 
 two
 different methods.

Try my test case. Let me know where/if it's wrong somehow. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 30 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsafn8xwr5a2sq9 digitalmars.com...
 On Thu, 1 Jul 2004 01:03:02 +0100, Dan Williams <dnews ithium.NOSPAM.net>
 wrote:
 There are two, and only two, methods for this.

 A) The string data itself is copied
 B) The pointer is copied

 Now, B) is the method I want to use... and is also the method you have
 *described*, but *NOT* the method that would actually take place in the
 code
 example you have provided.

B) is the method that *does* actually take place, try my example code... --[test.d]-- struct array { int length; void *data; } void swap(inout char[] A, inout char[] B) { char[] T; T = A; A = B; B = T; } void swapAssign(inout char[] A, inout char[] B, char[] value) { char[] T; T = A; A = value; B = T; } void output(char[] A, char[] label) { array *p = cast(array *)&A; printf("(%.*s) = %08x = (%.*s)\n",label,p.data,p.length,p.data); } void main() { char[] A = "first"; char[] B = "second"; char[] C = "third"; output(A,"A"); output(B,"B"); output(C,"C"); printf("\n"); swapAssign(A,B,"car"); output(A,"A"); output(B,"B"); output(C,"C"); printf("\n"); } it prints: D:\D\src\build\temp>copytest (A) = 0040f098 = (first) (B) = 0040f0a8 = (second) (C) = 0040f0b8 = (third) (A) = 0040f0f8 = (car) (B) = 0040f098 = (first) (C) = 0040f0b8 = (third)
 #    T = A;        // T is now "first"
 #    A = B;        // A is now "second"
 #    B = T;        // B is now "first"

This code will copy the string data, not the pointer! Stop, step back, think about it for a minute. What happens if you do this:
 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "first"

OK? Yes? That's the way it should be; all is well. BUT if what you are saying is true:
 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "car"

Uh-oh! Oh dear! Not what we wanted! Why has this happened? Because, in your example:
 The assignment "T = A" cause T to have the contents [5,4016].
 "A = B" cause A to now have the contents [6,5012]. "B = T" causes
 B to have the contents [5,4016].


This cannot be applied as it does not take the assignment to the new array into account, it should now read... The assignment "T = A" cause T to have the contents [5,4016]. A = "car" cause A to have contents of the new array, say [3,6012]. "B = T" causes B to have the contents [5,4016].
 So, that means that if part way through we change A, even though we
 already
 copied A to T, we are still changing T! Obviously this is incorrect and
 flawed, as that is not what assignment does or is supposed to do. Your
 example did not have anything in it to specify that a reference should


 used, so in that case a copy should be made. Just like passing by
 reference
 or by value etc.

 So... the strings DO move around in memory if you copy in this way

Nope.
 - they
 must do, they have to do so, otherwise the language would not make any
 sense. If everything was assigned by reference when you do a simple a =


 then how would you make copies?

You call the .dup method on the array.
 I know that one can utilise pointers in D, and I haven't actually looked
 too
 deeply into that for two reasons: first, I hate pointers <g> and second,
 D
 seems geared up so that you shouldn't really have to use pointers.

I don't mind pointers, they are powerful, if a little dangerous, that's part of the attraction. I do like that I can get almost the same power in D without them.
 This is
 why I started asking about a swap method, although thinking about it,
 maybe
 it would be good to have simply as a standalone function and not as a
 dedicated array method.

Or this template: template swap(T) { void swap(inout T a, inout T b) { T c; c = a; a = b; b = c; } } which works for everything, copying memory only if T is a struct of some sort.
 It's late for me right now (1am) but if I get chance tomorrow, I will
 look
 into how D deals with pointers, and write a test case to demonstrate the
 two
 different methods.

Try my test case. Let me know where/if it's wrong somehow. Regan --

Hey :) Thanks for doing that... I will look into it in more detail tomorrow. But for now, in the past few minutes I have quickly modified the other code example that you posted, and here it is: import std.random; void main() { char[][10] a; char[] temp; // create 10 random char[] of 10000 chars foreach(inout char[] s; a) { s.length = 10000; for(uint i = 0; i < s.length; i++) { s[i] = 'a' + rand()&25; } } // print the location and address of the elements 5 and 9 printf("\nbefore swap:\n"); printf("%02d. %08x\n",5,&a[5]); printf("%02d. %08x\n",9,&a[9]); // do swap temp = a[5]; a[5] = a[9]; a[9] = temp; // print the location and address of the elements 5 and 9 printf("\nafter swap:\n"); printf("%02d. %08x\n",5,&a[5]); printf("%02d. %08x\n",9,&a[9]); } Interestingly, the results are exactly what I would expect: before swap: 05. 0012ff00 09. 0012ff20 after swap: 05. 0012ff00 09. 0012ff20 The pointers have stayed the same, and the data has moved. I have not had chance to look at your code, or work out why it gets different results, and neither have I had the opportunity to examine my own in detail, so it is quite possible that I have mucked it up somewhere! :) However, I will leave you with that and maybe you can point out what I am doing "wrong" or how I *should* be doing this, etc. etc. etc.
Jun 30 2004
next sibling parent Stephen Waits <steve waits.net> writes:
Dan Williams wrote:
 
 The pointers have stayed the same, and the data has moved.

Pay attention.. the data in the case of a string IS A POINTER (and a length). --Steve
Jun 30 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 1 Jul 2004 01:54:11 +0100, Dan Williams <dnews ithium.NOSPAM.net> 
wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsafn8xwr5a2sq9 digitalmars.com...
 On Thu, 1 Jul 2004 01:03:02 +0100, Dan Williams 
 <dnews ithium.NOSPAM.net>
 wrote:
 There are two, and only two, methods for this.

 A) The string data itself is copied
 B) The pointer is copied

 Now, B) is the method I want to use... and is also the method you have
 *described*, but *NOT* the method that would actually take place in 

 code
 example you have provided.

B) is the method that *does* actually take place, try my example code... --[test.d]-- struct array { int length; void *data; } void swap(inout char[] A, inout char[] B) { char[] T; T = A; A = B; B = T; } void swapAssign(inout char[] A, inout char[] B, char[] value) { char[] T; T = A; A = value; B = T; } void output(char[] A, char[] label) { array *p = cast(array *)&A; printf("(%.*s) = %08x = (%.*s)\n",label,p.data,p.length,p.data); } void main() { char[] A = "first"; char[] B = "second"; char[] C = "third"; output(A,"A"); output(B,"B"); output(C,"C"); printf("\n"); swapAssign(A,B,"car"); output(A,"A"); output(B,"B"); output(C,"C"); printf("\n"); } it prints: D:\D\src\build\temp>copytest (A) = 0040f098 = (first) (B) = 0040f0a8 = (second) (C) = 0040f0b8 = (third) (A) = 0040f0f8 = (car) (B) = 0040f098 = (first) (C) = 0040f0b8 = (third)
 #    T = A;        // T is now "first"
 #    A = B;        // A is now "second"
 #    B = T;        // B is now "first"

This code will copy the string data, not the pointer! Stop, step back, think about it for a minute. What happens if you do this:
 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "first"

OK? Yes? That's the way it should be; all is well. BUT if what you are saying is true:
 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "car"

Uh-oh! Oh dear! Not what we wanted! Why has this happened? Because, in your example:
 The assignment "T = A" cause T to have the contents [5,4016].
 "A = B" cause A to now have the contents [6,5012]. "B = T" causes
 B to have the contents [5,4016].


This cannot be applied as it does not take the assignment to the new array into account, it should now read... The assignment "T = A" cause T to have the contents [5,4016]. A = "car" cause A to have contents of the new array, say [3,6012]. "B = T" causes B to have the contents [5,4016].
 So, that means that if part way through we change A, even though we
 already
 copied A to T, we are still changing T! Obviously this is incorrect 

 flawed, as that is not what assignment does or is supposed to do. Your
 example did not have anything in it to specify that a reference should


 used, so in that case a copy should be made. Just like passing by
 reference
 or by value etc.

 So... the strings DO move around in memory if you copy in this way

Nope.
 - they
 must do, they have to do so, otherwise the language would not make any
 sense. If everything was assigned by reference when you do a simple a 


 then how would you make copies?

You call the .dup method on the array.
 I know that one can utilise pointers in D, and I haven't actually 

 too
 deeply into that for two reasons: first, I hate pointers <g> and 

 D
 seems geared up so that you shouldn't really have to use pointers.

I don't mind pointers, they are powerful, if a little dangerous, that's part of the attraction. I do like that I can get almost the same power in D without them.
 This is
 why I started asking about a swap method, although thinking about it,
 maybe
 it would be good to have simply as a standalone function and not as a
 dedicated array method.

Or this template: template swap(T) { void swap(inout T a, inout T b) { T c; c = a; a = b; b = c; } } which works for everything, copying memory only if T is a struct of some sort.
 It's late for me right now (1am) but if I get chance tomorrow, I will
 look
 into how D deals with pointers, and write a test case to demonstrate 

 two
 different methods.

Try my test case. Let me know where/if it's wrong somehow. Regan --

Hey :) Thanks for doing that... I will look into it in more detail tomorrow. But for now, in the past few minutes I have quickly modified the other code example that you posted, and here it is: import std.random; void main() { char[][10] a; char[] temp; // create 10 random char[] of 10000 chars foreach(inout char[] s; a) { s.length = 10000; for(uint i = 0; i < s.length; i++) { s[i] = 'a' + rand()&25; } } // print the location and address of the elements 5 and 9 printf("\nbefore swap:\n"); printf("%02d. %08x\n",5,&a[5]); printf("%02d. %08x\n",9,&a[9]); // do swap temp = a[5]; a[5] = a[9]; a[9] = temp; // print the location and address of the elements 5 and 9 printf("\nafter swap:\n"); printf("%02d. %08x\n",5,&a[5]); printf("%02d. %08x\n",9,&a[9]); } Interestingly, the results are exactly what I would expect: before swap: 05. 0012ff00 09. 0012ff20 after swap: 05. 0012ff00 09. 0012ff20 The pointers have stayed the same, and the data has moved. I have not had chance to look at your code, or work out why it gets different results, and neither have I had the opportunity to examine my own in detail, so it is quite possible that I have mucked it up somewhere! :) However, I will leave you with that and maybe you can point out what I am doing "wrong" or how I *should* be doing this, etc. etc. etc.

I took your code, compiled and verified, got the same results :) Then I looked closely, and the line: printf("%02d. %08x\n",5,&a[5]); is actually printing the address of the reference at position 5, not the address of the data referenced by that reference, changing it to printf("%02d. %08x\n",5,&(a[5])[0]); prints the address of the first element in the data, recompiling and running gives. D:\D\src\build\temp>dmd sort3.d d:\D\dmd\bin\..\..\dm\bin\link.exe sort3,,,user32+kernel32/noi; D:\D\src\build\temp>sort3 before swap: 05. 007e2000 09. 007ee000 after swap: 05. 007ee000 09. 007e2000 So.. there you have it. If you're still not convinced it is not copying, try this one static uint bytes = 134217728; void main() { char[] A = new char[bytes]; char[] B = new char[bytes]; printf("START (%d)\n",bytes); if (true) { char[] T; T = A; A = B; B = T; } printf("END\n"); } when you run it, it will take a while to print that first line (as it's allocating a large chunk of memory), but it prints the second immediately after it. You could argue flushing to stdout is an issue here, perhaps someone can verify and/or tell us how to ensure it's flushing the lines. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 30 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsafqgl0r5a2sq9 digitalmars.com...
 On Thu, 1 Jul 2004 01:54:11 +0100, Dan Williams <dnews ithium.NOSPAM.net>
 wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsafn8xwr5a2sq9 digitalmars.com...
 On Thu, 1 Jul 2004 01:03:02 +0100, Dan Williams
 <dnews ithium.NOSPAM.net>
 wrote:
 There are two, and only two, methods for this.

 A) The string data itself is copied
 B) The pointer is copied

 Now, B) is the method I want to use... and is also the method you




 *described*, but *NOT* the method that would actually take place in

 code
 example you have provided.

B) is the method that *does* actually take place, try my example



 --[test.d]--
 struct array { int length; void *data; }

 void swap(inout char[] A, inout char[] B)
 {
 char[] T;

 T = A;
 A = B;
 B = T;
 }

 void swapAssign(inout char[] A, inout char[] B, char[] value)
 {
 char[] T;

 T = A;
 A = value;
 B = T;
 }

 void output(char[] A, char[] label)
 {
 array *p = cast(array *)&A;
 printf("(%.*s) = %08x = (%.*s)\n",label,p.data,p.length,p.data);
 }

 void main() {
 char[] A = "first";
 char[] B = "second";
 char[] C = "third";

 output(A,"A");
 output(B,"B");
 output(C,"C");
 printf("\n");

 swapAssign(A,B,"car");

 output(A,"A");
 output(B,"B");
 output(C,"C");
 printf("\n");
 }

 it prints:

 D:\D\src\build\temp>copytest
 (A) = 0040f098 = (first)
 (B) = 0040f0a8 = (second)
 (C) = 0040f0b8 = (third)

 (A) = 0040f0f8 = (car)
 (B) = 0040f098 = (first)
 (C) = 0040f0b8 = (third)

 #    T = A;        // T is now "first"
 #    A = B;        // A is now "second"
 #    B = T;        // B is now "first"

This code will copy the string data, not the pointer! Stop, step




 think
 about it for a minute. What happens if you do this:

 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "first"

OK? Yes? That's the way it should be; all is well. BUT if what you




 saying is true:

 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "car"

Uh-oh! Oh dear! Not what we wanted! Why has this happened? Because,




 your
 example:

 The assignment "T = A" cause T to have the contents [5,4016].
 "A = B" cause A to now have the contents [6,5012]. "B = T" causes
 B to have the contents [5,4016].


This cannot be applied as it does not take the assignment to the new array into account, it should now read... The assignment "T = A" cause T to have the contents [5,4016]. A = "car" cause A to have contents of the new array, say [3,6012]. "B = T" causes B to have the contents [5,4016].
 So, that means that if part way through we change A, even though we
 already
 copied A to T, we are still changing T! Obviously this is incorrect

 flawed, as that is not what assignment does or is supposed to do.




 example did not have anything in it to specify that a reference




 be
 used, so in that case a copy should be made. Just like passing by
 reference
 or by value etc.

 So... the strings DO move around in memory if you copy in this way

Nope.
 - they
 must do, they have to do so, otherwise the language would not make




 sense. If everything was assigned by reference when you do a simple a


 then how would you make copies?

You call the .dup method on the array.
 I know that one can utilise pointers in D, and I haven't actually

 too
 deeply into that for two reasons: first, I hate pointers <g> and

 D
 seems geared up so that you shouldn't really have to use pointers.

I don't mind pointers, they are powerful, if a little dangerous, that's part of the attraction. I do like that I can get almost the same power in D without them.
 This is
 why I started asking about a swap method, although thinking about it,
 maybe
 it would be good to have simply as a standalone function and not as a
 dedicated array method.

Or this template: template swap(T) { void swap(inout T a, inout T b) { T c; c = a; a = b; b = c; } } which works for everything, copying memory only if T is a struct of



 sort.

 It's late for me right now (1am) but if I get chance tomorrow, I will
 look
 into how D deals with pointers, and write a test case to demonstrate

 two
 different methods.

Try my test case. Let me know where/if it's wrong somehow. Regan --

Hey :) Thanks for doing that... I will look into it in more detail tomorrow. But for now, in the past few minutes I have quickly modified the other code example that you posted, and here it is: import std.random; void main() { char[][10] a; char[] temp; // create 10 random char[] of 10000 chars foreach(inout char[] s; a) { s.length = 10000; for(uint i = 0; i < s.length; i++) { s[i] = 'a' + rand()&25; } } // print the location and address of the elements 5 and 9 printf("\nbefore swap:\n"); printf("%02d. %08x\n",5,&a[5]); printf("%02d. %08x\n",9,&a[9]); // do swap temp = a[5]; a[5] = a[9]; a[9] = temp; // print the location and address of the elements 5 and 9 printf("\nafter swap:\n"); printf("%02d. %08x\n",5,&a[5]); printf("%02d. %08x\n",9,&a[9]); } Interestingly, the results are exactly what I would expect: before swap: 05. 0012ff00 09. 0012ff20 after swap: 05. 0012ff00 09. 0012ff20 The pointers have stayed the same, and the data has moved. I have not had chance to look at your code, or work out why it gets different results, and neither have I had the opportunity to examine my own in detail, so it is quite possible that I have mucked it up somewhere!


 However, I will leave you with that and maybe you can point out what I


 doing "wrong" or how I *should* be doing this, etc. etc. etc.

I took your code, compiled and verified, got the same results :) Then I looked closely, and the line: printf("%02d. %08x\n",5,&a[5]); is actually printing the address of the reference at position 5, not the address of the data referenced by that reference, changing it to printf("%02d. %08x\n",5,&(a[5])[0]);

Heh... I had simply altered your code for that bit ;)
 prints the address of the first element in the data, recompiling and
 running gives.

 D:\D\src\build\temp>dmd sort3.d
 d:\D\dmd\bin\..\..\dm\bin\link.exe sort3,,,user32+kernel32/noi;

 D:\D\src\build\temp>sort3

 before swap:
 05. 007e2000
 09. 007ee000

 after swap:
 05. 007ee000
 09. 007e2000

Indeed, I got the same result.
 So.. there you have it. If you're still not convinced it is not copying,
 try this one

 static uint bytes = 134217728;

 void main() {
 char[] A = new char[bytes];
 char[] B = new char[bytes];

 printf("START (%d)\n",bytes);
 if (true) {
 char[] T;
 T = A;
 A = B;
 B = T;
 }
 printf("END\n");
 }

 when you run it, it will take a while to print that first line (as it's
 allocating a large chunk of memory), but it prints the second immediately
 after it.

Yup, that happened.
 You could argue flushing to stdout is an issue here, perhaps someone can
 verify and/or tell us how to ensure it's flushing the lines.

That shouldn't be an issue... changing your code to the following example will prove that: static uint bytes = 134217728; void main() { printf("START\n"); char[] A = new char[bytes]; printf("A\n"); char[] T; T = A; printf("T=A\n"); char[] B = new char[bytes]; printf("B\n"); A = B; printf("A=B\n"); B = T; printf("B=T\n"); printf("END\n"); } The duration of the pauses shows what is happening. So... I was not all that happy. I had to go and carefully step through the "test.d" code you gave at the top of this post, before I was satisfied that I understood what was happening. I think part of my problem was that I did not expect something like A = "car" to work as it does. I understand now that in D, "car" becomes a new character array (can I say an anonymous one in current context?) and A is then pointed at it, rather than the *contents* being altered. This had the effect of making me go back to the start and trying to figure out why I didn't pick up on it in the first place. After all, once it falls into place, it's clear as crystal, logical, and simple. So why did I just "not get it" for so long? Well, if I can try and pass the buck slightly... <g> excessive programming in PHP over the past two years have gotten me used to the way PHP does things like this. I find that every time I go back to C for something, there is a harsh jarring in my head as my brain resets to "C-mode" ;) So I think that because of some of the things D does differently to C/C++, I was kind of expecting some things to be a bit like PHP. My bad. Woopsy! Another issue was that when I read the documentation, I read this: "There are two broad kinds of operations to do on an array - affecting the handle to the array, and affecting the contents of the array. C only has operators to affect the handle. In D, both are accessible." ...and didn't quite realise the scope of what it meant. More careful study reveals, in light of our discussions, the answer that I was looking for waaaaay back at the start of this. Here's my summary: # A = char[]; # B = char[]; # # A = B; // makes A point to B # B = "new"; // makes A point to "new"; B still points to what was A # # A[] = B; // copies B to A # A[] = B[]; // does the same # # A = B[]; // interestingly, makes A point to B just like doing A = B I would love to say that if someone had said at the beginning that "A = B copies by reference whereas to copy the data you need to slice" then I would have been "oh, ok that's great" but although no-one seems to have specifically mentioned slicing to copy, I also realise I just missed that whole thing completely. So... it seems like I started out with a miscomprehension about the way D did this. Because I was uncertain, I asked a question. Because I was ignorant, I asked the question in such a way as to apparently make no sense <g>. Because of that, a debate over methodology evolved, in which both sides were correct about the underlying fundamentals of what was happening, except I was not applying my theory to D correctly because I had no idea how D did it... hence my question in the first place :D Messy! Well, I got there in the end, and I must say, thanks for your time and efforts in enlightening me. I'm sure that I must by now have given you the impression that I'm terribly thick, but I'm kinda used to making blunders by now :) Right, so, to answer my original question: "No swap method is needed, because using a temporary variable will swap the pointers. To make a copy, do so by slicing the array." Now that I have the second part of that answer to join to the first, it makes sense, and I am happy!
Jul 01 2004
next sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Dan Williams" <dnews ithium.NOSPAM.net> escribió en el mensaje
news:cc0oro$kan$1 digitaldaemon.com
|
| ...
|
| Right, so, to answer my original question: "No swap method is needed,
| because using a temporary variable will swap the pointers. To make a copy,
| do so by slicing the array." Now that I have the second part of that
answer
| to join to the first, it makes sense, and I am happy!

Or use the .dup property

-----------------------
Carlos Santander Bernal
Jul 01 2004
prev sibling parent reply James McComb <alan jamesmccomb.id.au> writes:
Dan Williams wrote:

 I think part of my problem was that I did not expect something like A =
 "car" to work as it does. I understand now that in D, "car" becomes a new
 character array (can I say an anonymous one in current context?) and A is
 then pointed at it, rather than the *contents* being altered.

You might have been confused by the fact that in D, we write: str = "dan" Rather than: str = new "dan" /* not real code */ Is this a flaw in the language? I don't know, but you quickly get used to it. James McComb
Jul 01 2004
parent "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"James McComb" <alan jamesmccomb.id.au> wrote in message
news:cc26dl$2u2m$1 digitaldaemon.com...
 Dan Williams wrote:

 I think part of my problem was that I did not expect something like A =
 "car" to work as it does. I understand now that in D, "car" becomes a


 character array (can I say an anonymous one in current context?) and A


 then pointed at it, rather than the *contents* being altered.

You might have been confused by the fact that in D, we write: str = "dan" Rather than: str = new "dan" /* not real code */

That's a good way of putting it actually :)
 Is this a flaw in the language? I don't know, but you quickly get used
 to it.

I don't know whether I would call it a flaw... but I think that maybe the online docs need fleshing out ;)
Jul 01 2004
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 1 Jul 2004 01:03:02 +0100, Dan Williams wrote:

 "Derek" <derek psyc.ward> wrote in message
 news:1txb3s0xe4h7a$.oc6ijhdctn5l.dlg 40tude.net...
 On Wed, 30 Jun 2004 17:19:17 +0100, Dan Williams wrote:

 Hmmmm...

[snip]
 The second thing was talking about element swapping, and for some reason


 would appear that I'm still not quite being understood on this :( (not


 why, as it is pretty fundamental stuff).

Okay, I'll have a go at describing D's swap behaviour... #char[] A = "first"; #char[] B = "second"; # #void main() #{ # char[] T; # # T = A; # A = B; # B = T; # # printf("%.*s %.*s\n", A, B); #} Using the code example above... Initially 'A' takes up a single two-32-bit area of RAM. Let's say A is located at RAM Address (RA) 1000. And likewise, B is at 2060. The first 32-bit portion of what makes up A's content has the string length of 5,

 B's first 32-bit area contains 6 (the length of 'second'). The second
 32-bit area of A contains the address of the bytes that make up the

 'first'. Let's say this is RA 4016. B's string pointer also points to its
 data 'second'. Let's say it is at 5012.

So far, so good... I understand and agree with that, and it is what I would expect.
 So summarizing...

 A --> [5,4016]
 B --> [6,5012]

 Now we have T which has no initial values. T is located at 7000 and also
 has a two-32-bit area.

Again, agreed.
 The assignment "T = A" cause T to have the contents [5,4016].
 "A = B" cause A to now have the contents [6,5012]. "B = T" causes
 B to have the contents [5,4016]. So we end up with ...

No, no, NO! Gah! ...I'll explain in a minute :D
 A --> [6,5012]
 B --> [5,4016]

 Meanwhile the actual string data has not moved a muscle.

There are two, and only two, methods for this. A) The string data itself is copied B) The pointer is copied Now, B) is the method I want to use... and is also the method you have *described*, but *NOT* the method that would actually take place in the code example you have provided.
 #    T = A;        // T is now "first"
 #    A = B;        // A is now "second"
 #    B = T;        // B is now "first"

This code will copy the string data, not the pointer! Stop, step back, think about it for a minute. What happens if you do this:
 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "first"

OK? Yes? That's the way it should be; all is well. BUT if what you are saying is true:
 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "car"

Uh-oh! Oh dear! Not what we wanted! Why has this happened?

You didn't actually try this code out, did you? You are just guessing, I suppose. Okay, here is ACTUAL code that I compiled and ran... #char[] A = "first"; #char[] B = "second"; # #void main() #{ # char[] T = ""; # int i = 0; # # i += 1; printf("%d A='%.*s' B='%.*s' T='%.*s'\n", i, A, B, T); # # T = A; # A = "car"; # B = T; # # i += 1; printf("%d A='%.*s' B='%.*s' T='%.*s'\n", i, A, B, T); #} And here is the results... c:\>dmd test C:\DPARNELL\DMD\BIN\..\..\dm\bin\link.exe test,,,user32+kernel32/noi; c:\>test 1 A='first' B='second' T='' 2 A='car' B='first' T='first' c:\> As you can PLAINLY see, 'B' does not equal "car", but "first" as I suggested would happen.
Because, in your example:
 
 The assignment "T = A" cause T to have the contents [5,4016].
 "A = B" cause A to now have the contents [6,5012]. "B = T" causes
 B to have the contents [5,4016].

So, that means that if part way through we change A, even though we already copied A to T, we are still changing T!

Well that turns out not to be the case, Dan. Let me run through it... # T = A; // T --> [5,4016] --> "first" # A = "car"; // A --> [3,9100] --> "car" # B = T; // B --> [5,4016] --> "first" D is truely copying pointers (and lengths) and not the data being pointed to.
 The assignment "T = A" cause T to have the contents [5,4016].
 "A = B" cause A to now have the contents [6,5012]. "B = T" causes
 B to have the contents [5,4016].


Obviously this is incorrect and
 flawed, as that is not what assignment does or is supposed to do. Your
 example did not have anything in it to specify that a reference should be
 used, so in that case a copy should be made. Just like passing by reference
 or by value etc.

Dan, please try out this in real code. You are presupposing that D behaves a certain way without actually testing your hypothesis. Set up some tests for yourself to see what D is really doing. Have a look at the generated machine code to verify this if you like.
 So... the strings DO move around in memory if you copy in this way - they
 must do, they have to do so, otherwise the language would not make any
 sense. If everything was assigned by reference when you do a simple a = b
 then how would you make copies?

Believe it or not, this is how D works. void main() { char[] A = "test"; char[] B = A; // Both A and B print out as "test" printf("A='%.*s' B='%.*s'\n", A, B); A[2] = 'x'; // Both A and B print out as "text", even though we only 'changed' A! printf("A='%.*s' B='%.*s'\n", A, B); A = "test"; B = A.dup; // <<<<< NOTICE the .dup to make a copy. // Both A and B print out as "test" printf("A='%.*s' B='%.*s'\n", A, B); A[2] = 'x'; // Now A is "text" and B is still "test" printf("A='%.*s' B='%.*s'\n", A, B); }
 I know that one can utilise pointers in D, and I haven't actually looked too
 deeply into that for two reasons: first, I hate pointers <g> and second, D
 seems geared up so that you shouldn't really have to use pointers. This is
 why I started asking about a swap method, although thinking about it, maybe
 it would be good to have simply as a standalone function and not as a
 dedicated array method.
 
 It's late for me right now (1am) but if I get chance tomorrow, I will look
 into how D deals with pointers, and write a test case to demonstrate the two
 different methods.

Hopefully a goodnight's sleep will help. -- Derek Melbourne, Australia 1/Jul/04 10:57:42 AM
Jun 30 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:cbvoiv$21tu$1 digitaldaemon.com...
 On Thu, 1 Jul 2004 01:03:02 +0100, Dan Williams wrote:

 "Derek" <derek psyc.ward> wrote in message
 news:1txb3s0xe4h7a$.oc6ijhdctn5l.dlg 40tude.net...
 On Wed, 30 Jun 2004 17:19:17 +0100, Dan Williams wrote:

 Hmmmm...

[snip]
 The second thing was talking about element swapping, and for some




 it
 would appear that I'm still not quite being understood on this :( (not


 why, as it is pretty fundamental stuff).

Okay, I'll have a go at describing D's swap behaviour... #char[] A = "first"; #char[] B = "second"; # #void main() #{ # char[] T; # # T = A; # A = B; # B = T; # # printf("%.*s %.*s\n", A, B); #} Using the code example above... Initially 'A' takes up a single two-32-bit area of RAM. Let's say A is located at RAM Address (RA) 1000. And likewise, B is at 2060. The first 32-bit portion of what makes up A's content has the string length of 5,

 B's first 32-bit area contains 6 (the length of 'second'). The second
 32-bit area of A contains the address of the bytes that make up the

 'first'. Let's say this is RA 4016. B's string pointer also points to



 data 'second'. Let's say it is at 5012.

So far, so good... I understand and agree with that, and it is what I


 expect.

 So summarizing...

 A --> [5,4016]
 B --> [6,5012]

 Now we have T which has no initial values. T is located at 7000 and



 has a two-32-bit area.

Again, agreed.
 The assignment "T = A" cause T to have the contents [5,4016].
 "A = B" cause A to now have the contents [6,5012]. "B = T" causes
 B to have the contents [5,4016]. So we end up with ...

No, no, NO! Gah! ...I'll explain in a minute :D
 A --> [6,5012]
 B --> [5,4016]

 Meanwhile the actual string data has not moved a muscle.

There are two, and only two, methods for this. A) The string data itself is copied B) The pointer is copied Now, B) is the method I want to use... and is also the method you have *described*, but *NOT* the method that would actually take place in the


 example you have provided.

 #    T = A;        // T is now "first"
 #    A = B;        // A is now "second"
 #    B = T;        // B is now "first"

This code will copy the string data, not the pointer! Stop, step back,


 about it for a minute. What happens if you do this:

 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "first"

OK? Yes? That's the way it should be; all is well. BUT if what you are saying is true:
 #    T = A;        // T is now "first"
 #    A = "car";    // A is now "car"
 #    B = T;        // B is now "car"

Uh-oh! Oh dear! Not what we wanted! Why has this happened?

You didn't actually try this code out, did you? You are just guessing, I suppose. Okay, here is ACTUAL code that I compiled and ran... #char[] A = "first"; #char[] B = "second"; # #void main() #{ # char[] T = ""; # int i = 0; # # i += 1; printf("%d A='%.*s' B='%.*s' T='%.*s'\n", i, A, B, T); # # T = A; # A = "car"; # B = T; # # i += 1; printf("%d A='%.*s' B='%.*s' T='%.*s'\n", i, A, B, T); #} And here is the results... c:\>dmd test C:\DPARNELL\DMD\BIN\..\..\dm\bin\link.exe test,,,user32+kernel32/noi; c:\>test 1 A='first' B='second' T='' 2 A='car' B='first' T='first' c:\> As you can PLAINLY see, 'B' does not equal "car", but "first" as I suggested would happen.
Because, in your example:

 The assignment "T = A" cause T to have the contents [5,4016].
 "A = B" cause A to now have the contents [6,5012]. "B = T" causes
 B to have the contents [5,4016].

So, that means that if part way through we change A, even though we


 copied A to T, we are still changing T!

Well that turns out not to be the case, Dan. Let me run through it... # T = A; // T --> [5,4016] --> "first" # A = "car"; // A --> [3,9100] --> "car" # B = T; // B --> [5,4016] --> "first" D is truely copying pointers (and lengths) and not the data being pointed to.
 The assignment "T = A" cause T to have the contents [5,4016].
 "A = B" cause A to now have the contents [6,5012]. "B = T" causes
 B to have the contents [5,4016].


Obviously this is incorrect and
 flawed, as that is not what assignment does or is supposed to do. Your
 example did not have anything in it to specify that a reference should


 used, so in that case a copy should be made. Just like passing by


 or by value etc.

Dan, please try out this in real code. You are presupposing that D behaves a certain way without actually testing your hypothesis. Set up some tests for yourself to see what D is really doing. Have a look at the generated machine code to verify this if you like.
 So... the strings DO move around in memory if you copy in this way -


 must do, they have to do so, otherwise the language would not make any
 sense. If everything was assigned by reference when you do a simple a =


 then how would you make copies?

Believe it or not, this is how D works. void main() { char[] A = "test"; char[] B = A; // Both A and B print out as "test" printf("A='%.*s' B='%.*s'\n", A, B); A[2] = 'x'; // Both A and B print out as "text", even though we only 'changed' A! printf("A='%.*s' B='%.*s'\n", A, B); A = "test"; B = A.dup; // <<<<< NOTICE the .dup to make a copy. // Both A and B print out as "test" printf("A='%.*s' B='%.*s'\n", A, B); A[2] = 'x'; // Now A is "text" and B is still "test" printf("A='%.*s' B='%.*s'\n", A, B); }
 I know that one can utilise pointers in D, and I haven't actually looked


 deeply into that for two reasons: first, I hate pointers <g> and second,


 seems geared up so that you shouldn't really have to use pointers. This


 why I started asking about a swap method, although thinking about it,


 it would be good to have simply as a standalone function and not as a
 dedicated array method.

 It's late for me right now (1am) but if I get chance tomorrow, I will


 into how D deals with pointers, and write a test case to demonstrate the


 different methods.

Hopefully a goodnight's sleep will help.

It sure did - I carefully went through the code examples this morning, and finally twigged it! :D Although, please have the grace to let me point this out:
 If everything was assigned by reference when you do a simple a = b
 then how would you make copies?

Believe it or not, this is how D works.

If you (or anyone else) had answered me regarding how to make copies in D (by slicing) then chances are that I would have understood a few posts ago :) But as to what those chances are, I would not like to say... <g> Thanks for your patience with this old fool!
Jul 01 2004
parent reply Derek <derek psyc.ward> writes:
On Thu, 1 Jul 2004 11:31:34 +0100, Dan Williams wrote:

[snip]
 Hopefully a goodnight's sleep will help.

It sure did - I carefully went through the code examples this morning, and finally twigged it! :D

G'day, mate. Great news! I too was a bit confused by D's assignment semantics at first. But you eventually get used to it. It's sort of makes sense. In most languages assignment means copying the value of the righthand side expression to the variable on the left hand side. So naturally if we are talking strings (arrays of chars?) we think that the string data is being copied. But of course, D does actually copy the value, but in its case, the value is not the string data, but the string reference. I work with a language that does similar to D, but it does an automatic deep copy if you modify the contents. For example... A = "abc"; B = A; // Copies the string reference A[0] = 'A'; // Recognizes that the base data is being changed // so it copies the data, updates A's reference to // the new copy and then updates the first element. This has overheads that D wishes to avoid, but its nice anyhow.
 Although, please have the grace to let me point this out:
 
 If everything was assigned by reference when you do a simple a = b
 then how would you make copies?

Believe it or not, this is how D works.

If you (or anyone else) had answered me regarding how to make copies in D (by slicing) then chances are that I would have understood a few posts ago :) But as to what those chances are, I would not like to say... <g>

Hmmmm...don't follow you here. What do you mean by copying by slicing? Can you given a code example? Here is what I tried and there was no copying done... #void main() #{ # char[] A = "first"; # char[] T; # T = A[1..3]; # A[0] = 'I'; # printf("A='%.*s' T='%.*s'\n", A, T); #} the results were ... f:\temp>dmd test F:\DMD\BIN\..\..\dm\bin\link.exe test,,,user32+kernel32/noi; f:\temp>test A='fIrst' T='Ir' f:\temp> As you can see, the "T = A[1..3]" did not take a copy of the underlying array, but just made T point into the same RAM block that A was pointing to.
 Thanks for your patience with this old fool!

As a friend keeps reminding me, the only stupid question is one that is never asked. -- Derek Melbourne, Australia
Jul 01 2004
parent "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Derek" <derek psyc.ward> wrote in message
news:10fi5ofl3p0yj.1icwu3beyyn63$.dlg 40tude.net...
 On Thu, 1 Jul 2004 11:31:34 +0100, Dan Williams wrote:

 [snip]
 Hopefully a goodnight's sleep will help.

It sure did - I carefully went through the code examples this morning,


 finally twigged it! :D

G'day, mate. Great news! I too was a bit confused by D's assignment semantics at first. But you eventually get used to it. It's sort of makes sense. In most languages assignment means copying the value of the righthand side expression to the variable on the left hand side. So naturally if we are talking strings (arrays of chars?) we think that the string data is being copied.

Yup, that's were I came unstuck.
 But of course, D does actually copy the value, but in its case, the value
 is not the string data, but the string reference.

 I work with a language that does similar to D, but it does an automatic
 deep copy if you modify the contents. For example...

    A = "abc";
    B = A;  // Copies the string reference
    A[0] = 'A';  // Recognizes that the base data is being changed
                 // so it copies the data, updates A's reference to
                 // the new copy and then updates the first element.

 This has overheads that D wishes to avoid, but its nice anyhow.

 Although, please have the grace to let me point this out:

 If everything was assigned by reference when you do a simple a = b
 then how would you make copies?

Believe it or not, this is how D works.

If you (or anyone else) had answered me regarding how to make copies in


 (by slicing) then chances are that I would have understood a few posts


 :) But as to what those chances are, I would not like to say... <g>

Hmmmm...don't follow you here. What do you mean by copying by slicing? Can you given a code example?

Sure! This is simply copied (no pun intended! <g>) straight from http://www.digitalmars.com/d/arrays.html Array Copying When the slice operator appears as the lvalue of an assignment expression, it means that the contents of the array are the target of the assignment rather than a reference to the array. Array copying happens when the lvalue is a slice, and the rvalue is an array of or pointer to the same type. int[3] s; int[3] t; s[] = t; the 3 elements of t[3] are copied into s[3] s[] = t[]; the 3 elements of t[3] are copied into s[3]
 Here is what I tried and there was no copying done...

 #void main()
 #{
 # char[] A = "first";
 # char[] T;
 # T = A[1..3];
 # A[0] = 'I';
 # printf("A='%.*s' T='%.*s'\n", A, T);
 #}

 the results were ...

 f:\temp>dmd test
 F:\DMD\BIN\..\..\dm\bin\link.exe test,,,user32+kernel32/noi;

 f:\temp>test
 A='fIrst' T='Ir'

 f:\temp>

 As you can see, the "T = A[1..3]" did not take a copy of the underlying
 array, but just made T point into the same RAM block that A was pointing
 to.

Indeed, it would appear (as I think I noted in another post in another branch of this thread) that the array is only copied if the slicing operator is on the left side. So: s = t[]; // points s[] = t; // copies s[] = t[]; // copies So that's what I would guess the problem is with your T = A[1..3] example. Interesting, because I didn't really think about the logical extension of the method, but from what you did it is apparent that: s = t[a..b] // points to the sliced section
 Thanks for your patience with this old fool!

As a friend keeps reminding me, the only stupid question is one that is never asked.

I like the sound of that - it lets me off the hook! ;)
Jul 01 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 30 Jun 2004 11:03:42 +0100, Dan Williams <dnews ithium.NOSPAM.net> 
wrote:
 Surely there are pointers to the actual elements somewhere? Or are you
 using a method that I am simply not thinking of right now...
 (gone 2am, tired!)

The data member points to the elements. They are stored sequentially in memory.

I think I see what you mean. An array itself is a struct with length n where n is both the count of the elements and also the amount of memory used by the sequentially-stored pointers to element data, yes? And each element then holds its own data with its own data properties. Ok, that makes sense, and this is essentially the way I would handle it in C++. The place that I came unstuck is in asking about element swapping. Let me explain that one further, so that you'll have a clearer idea of my question. Take an array with 100 elements, where each element is a variable-length string.

char[][100] list;
 When it comes to sort the array, obviously the best method is to
 swap the data pointers after a comparison, rather than swap the data 
 itself.
 Now, this is why I asked about a swap method - there are several things 
 that
 I would need to utilise a swap for, and obviously I want to be confident
 that I am swapping the pointers and not the data!

 As there is no swap method, how would I directly access the array index's
 data pointers in order to swap them? Imagine that elements 5 and 9 need
 swapping, and are around about 1Kb each. If I say, temp = myArray[5];
 myArray[5] = myArray[9]; myArray[9] = temp; then I am needlessly copying 
 1Kb
 blocks around in memory, right?

It depends on the array. Using the array: char[][100] list; If you swap list[5] with list[9] you're swapping array references, not the data they point to. Here is a test case which prooves this (I believe): import std.random; void main() { char[][100] a; char[] test; //create 100 random char[] of 1000 chars foreach(inout char[] s; a) { s.length = 1000; for(uint i = 0; i < s.length; i++) s[i] = 'a' + rand()&25; } //pick one as a test case test = a[0]; //print the location and address of the first element printf("%02d. %08x\n",0,&test[0]); //sort the array a.sort; //find the test case foreach(uint i, char[] s; a) { if (s == test) { //print the location and address of the first element printf("%02d. %08x\n",i,&s[0]); break; } } } If the array is an array of pointers eg. char*[100] list; then swapping list[5] with list[9] you're swapping pointer, so again you're not swapping 1k of data. But, if you use: Foo[100] list; and Foo is a 1k large structure, then yes, you're swapping 1k of data. The same does not apply if Foo is a 1k class, because classes are handled by reference so you're swaping references to 1k classes, not the 1k classes themselves. Basically if it's a reference type, you're fine, if it's a value type, your swapping (the size of the value type)k each time. Is that clear as mud? If I'm wrong someone pls correct me.
 So I need to be able to swap the pointers
 and therefore temp needs to be a pointer, but while this is 
 straightforward
 in C++, I don't know how I would do this in D. Therefore my ignorance 
 when
 it comes to D has prompted what has undoubtably appeared to be a rather
 stupid question <g>

Whatever you would do in C++ you can still do in D, but, D's arrays give you a better way to do it. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 30 2004
next sibling parent reply Sam McCall <Sam_member pathlink.com> writes:
In article <opsafkvvct5a2sq9 digitalmars.com>, Regan Heath says...
 Take an array with 100 elements, where each element is a variable-length
 string.

char[][100] list;

This does kind of make sense, because it's a hundred of n of char. But then how do you get the 50th string? list[50]? list[][50]? Surely the indexes are in the same order as the dimensions. I thought I understood this :'( Sam
Jun 30 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 30 Jun 2004 23:47:56 +0000 (UTC), Sam McCall 
<Sam_member pathlink.com> wrote:

 In article <opsafkvvct5a2sq9 digitalmars.com>, Regan Heath says...
 Take an array with 100 elements, where each element is a 
 variable-length
 string.

char[][100] list;


I believe so. My test program uses it.
 This does kind of make sense, because it's a hundred of n of char.

I thought so too. :)
 But then how do you get the 50th string? list[50]?

Yep.
 list[][50]?
 Surely the indexes are in the same order as the dimensions.

They are, see the 'catch' below :)
 I thought I understood this :'(

I think the 'catch' here is this.. arrays are defined with "TYPE[] NAME" the TYPE can be an array, in my example above the TYPE is char[]. It can all start to get really, really funky.. char[][char[int]] list; an associative array of char arrays, indexed by an associative array of chars indexed by an int. etc.. and this is a simple example of funky. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 30 2004
parent reply Sam McCall <Sam_member pathlink.com> writes:
In article <opsafm5lh55a2sq9 digitalmars.com>, Regan Heath says...
On Wed, 30 Jun 2004 23:47:56 +0000 (UTC), Sam McCall 
<Sam_member pathlink.com> wrote:

 In article <opsafkvvct5a2sq9 digitalmars.com>, Regan Heath says...
 Take an array with 100 elements, where each element is a 
 variable-length
 string.

char[][100] list;


I believe so. My test program uses it.
 This does kind of make sense, because it's a hundred of n of char.

I thought so too. :)
 But then how do you get the 50th string? list[50]?

Yep.
 list[][50]?
 Surely the indexes are in the same order as the dimensions.

They are, see the 'catch' below :)

If I have a hundred strings, defined as char[][100] list And I want to access the nth one, you say I should use list[n]. So if I want the k-th char of the n-th string, clearly i use list[n][k] So I'm defining with char[number-of-chars][number-of-strings] list And accessing with list[string-number][char-number]. In particular, the range of the first index is determined by the second dimension, and vice versa. This runs counter to my intuition. Sam
Jun 30 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 1 Jul 2004 00:51:24 +0000 (UTC), Sam McCall 
<Sam_member pathlink.com> wrote:

 In article <opsafm5lh55a2sq9 digitalmars.com>, Regan Heath says...
 On Wed, 30 Jun 2004 23:47:56 +0000 (UTC), Sam McCall
 <Sam_member pathlink.com> wrote:

 In article <opsafkvvct5a2sq9 digitalmars.com>, Regan Heath says...
 Take an array with 100 elements, where each element is a
 variable-length
 string.

char[][100] list;


I believe so. My test program uses it.
 This does kind of make sense, because it's a hundred of n of char.

I thought so too. :)
 But then how do you get the 50th string? list[50]?

Yep.
 list[][50]?
 Surely the indexes are in the same order as the dimensions.

They are, see the 'catch' below :)

If I have a hundred strings, defined as char[][100] list And I want to access the nth one, you say I should use list[n].

Yep.
 So if I want the k-th char of the n-th string, clearly i use
 list[n][k]

Yep. You're right they go backwards.
 So I'm defining with
 char[number-of-chars][number-of-strings] list
 And accessing with
 list[string-number][char-number].
 In particular, the range of the first index is determined by the second
 dimension, and vice versa. This runs counter to my intuition.

It makes sense to me, the first index, indexes a char[][] meaning you get a char[] back, the second index indexes a char[] meaning you get a char back. Conceptually I break it up into these steps in my head. given: char[][100] list; char c; c = list[5][9]; I think: char[][100] list; char[] p; char c; p = list[5]; c = p[9]; Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 30 2004
parent reply Sam McCall <tunah.d tunah.net> writes:
Regan Heath wrote:

 On Thu, 1 Jul 2004 00:51:24 +0000 (UTC), Sam McCall 
 <Sam_member pathlink.com> wrote:
 
 In article <opsafm5lh55a2sq9 digitalmars.com>, Regan Heath says...

 On Wed, 30 Jun 2004 23:47:56 +0000 (UTC), Sam McCall
 <Sam_member pathlink.com> wrote:

 In article <opsafkvvct5a2sq9 digitalmars.com>, Regan Heath says...

 Take an array with 100 elements, where each element is a
 variable-length
 string.

char[][100] list;

Really?

I believe so. My test program uses it.
 This does kind of make sense, because it's a hundred of n of char.

I thought so too. :)
 But then how do you get the 50th string? list[50]?

Yep.
 list[][50]?
 Surely the indexes are in the same order as the dimensions.

They are, see the 'catch' below :)

No they're not. If I have a hundred strings, defined as char[][100] list And I want to access the nth one, you say I should use list[n].

Yep.
 So if I want the k-th char of the n-th string, clearly i use
 list[n][k]

Yep. You're right they go backwards.
 So I'm defining with
 char[number-of-chars][number-of-strings] list
 And accessing with
 list[string-number][char-number].
 In particular, the range of the first index is determined by the second
 dimension, and vice versa. This runs counter to my intuition.

It makes sense to me, the first index, indexes a char[][] meaning you get a char[] back, the second index indexes a char[] meaning you get a char back. Conceptually I break it up into these steps in my head.

Java certainly doesn't do it this way, do other languages? Sam
Jul 01 2004
next sibling parent "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Sam McCall" <tunah.d tunah.net> wrote in message
news:cc0qeq$m0u$1 digitaldaemon.com...
 Regan Heath wrote:

 On Thu, 1 Jul 2004 00:51:24 +0000 (UTC), Sam McCall
 <Sam_member pathlink.com> wrote:

 In article <opsafm5lh55a2sq9 digitalmars.com>, Regan Heath says...

 On Wed, 30 Jun 2004 23:47:56 +0000 (UTC), Sam McCall
 <Sam_member pathlink.com> wrote:

 In article <opsafkvvct5a2sq9 digitalmars.com>, Regan Heath says...

 Take an array with 100 elements, where each element is a
 variable-length
 string.

char[][100] list;

Really?

I believe so. My test program uses it.
 This does kind of make sense, because it's a hundred of n of char.

I thought so too. :)
 But then how do you get the 50th string? list[50]?

Yep.
 list[][50]?
 Surely the indexes are in the same order as the dimensions.

They are, see the 'catch' below :)

No they're not. If I have a hundred strings, defined as char[][100] list And I want to access the nth one, you say I should use list[n].

Yep.
 So if I want the k-th char of the n-th string, clearly i use
 list[n][k]

Yep. You're right they go backwards.
 So I'm defining with
 char[number-of-chars][number-of-strings] list
 And accessing with
 list[string-number][char-number].
 In particular, the range of the first index is determined by the second
 dimension, and vice versa. This runs counter to my intuition.

It makes sense to me, the first index, indexes a char[][] meaning you get a char[] back, the second index indexes a char[] meaning you get a char back. Conceptually I break it up into these steps in my head.

Java certainly doesn't do it this way, do other languages? Sam

I'm with Sam on this one... it appears confusing to reverse the order. I certainly would have run into problems with this at some point if his posts had not brought it to my attention.
Jul 01 2004
prev sibling parent Regan Heath <regan netwin.co.nz> writes:
On Thu, 01 Jul 2004 22:56:01 +1200, Sam McCall <tunah.d tunah.net> wrote:

 Regan Heath wrote:

 On Thu, 1 Jul 2004 00:51:24 +0000 (UTC), Sam McCall 
 <Sam_member pathlink.com> wrote:

 In article <opsafm5lh55a2sq9 digitalmars.com>, Regan Heath says...

 On Wed, 30 Jun 2004 23:47:56 +0000 (UTC), Sam McCall
 <Sam_member pathlink.com> wrote:

 In article <opsafkvvct5a2sq9 digitalmars.com>, Regan Heath says...

 Take an array with 100 elements, where each element is a
 variable-length
 string.

char[][100] list;

Really?

I believe so. My test program uses it.
 This does kind of make sense, because it's a hundred of n of char.

I thought so too. :)
 But then how do you get the 50th string? list[50]?

Yep.
 list[][50]?
 Surely the indexes are in the same order as the dimensions.

They are, see the 'catch' below :)

No they're not. If I have a hundred strings, defined as char[][100] list And I want to access the nth one, you say I should use list[n].

Yep.
 So if I want the k-th char of the n-th string, clearly i use
 list[n][k]

Yep. You're right they go backwards.
 So I'm defining with
 char[number-of-chars][number-of-strings] list
 And accessing with
 list[string-number][char-number].
 In particular, the range of the first index is determined by the second
 dimension, and vice versa. This runs counter to my intuition.

It makes sense to me, the first index, indexes a char[][] meaning you get a char[] back, the second index indexes a char[] meaning you get a char back. Conceptually I break it up into these steps in my head.

Java certainly doesn't do it this way, do other languages?

See "Norbert Nemec"'s post. he explains it well. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 01 2004
prev sibling parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Sam McCall wrote:

 In article <opsafkvvct5a2sq9 digitalmars.com>, Regan Heath says...
 Take an array with 100 elements, where each element is a variable-length
 string.

char[][100] list;

This does kind of make sense, because it's a hundred of n of char. But then how do you get the 50th string? list[50]? list[][50]? Surely the indexes are in the same order as the dimensions. I thought I understood this :'( Sam

Careful: in nested arrays, the type declaration looks the other way around from the indexing operator: int[C][R] x; int sum = 0; for(int r=0;r<R;r++) for(int c=0;c<C;c++) sum += x[r][c]; To see the background for this, think of a typedef: typedef int[C] intC; intC[R] x; for(int r=0;r<R;r++) { intC row = x[r]; for(int c=0;c<C;c++) sum += row[c]; } This is a strange quirk that appeared when C-style array specifiers were shuffled from behind the variable name to the variable type: C-style: int x[R][C]; intermediate: int[C] x[R]; D-style: int[C][R] x; The strangeness will be possible to avoid in future by using the multidimensional static arrays (a minor part of the proposal): int[R,C] y; int sum = 0; for(int r=0;r<R;r++) for(int c=0;c<C;c++) sum += x[r,c];
Jul 01 2004
prev sibling parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsafkvvct5a2sq9 digitalmars.com...
 On Wed, 30 Jun 2004 11:03:42 +0100, Dan Williams <dnews ithium.NOSPAM.net>
 wrote:
 Surely there are pointers to the actual elements somewhere? Or are




 using a method that I am simply not thinking of right now...
 (gone 2am, tired!)

The data member points to the elements. They are stored sequentially in memory.

I think I see what you mean. An array itself is a struct with length n where n is both the count of the elements and also the amount of memory used


 the sequentially-stored pointers to element data, yes? And each element
 then
 holds its own data with its own data properties. Ok, that makes sense,
 and
 this is essentially the way I would handle it in C++. The place that I
 came
 unstuck is in asking about element swapping. Let me explain that one
 further, so that you'll have a clearer idea of my question.

 Take an array with 100 elements, where each element is a variable-length
 string.

char[][100] list;
 When it comes to sort the array, obviously the best method is to
 swap the data pointers after a comparison, rather than swap the data
 itself.
 Now, this is why I asked about a swap method - there are several things
 that
 I would need to utilise a swap for, and obviously I want to be confident
 that I am swapping the pointers and not the data!

 As there is no swap method, how would I directly access the array


 data pointers in order to swap them? Imagine that elements 5 and 9 need
 swapping, and are around about 1Kb each. If I say, temp = myArray[5];
 myArray[5] = myArray[9]; myArray[9] = temp; then I am needlessly copying
 1Kb
 blocks around in memory, right?

It depends on the array. Using the array: char[][100] list; If you swap list[5] with list[9] you're swapping array references, not the data they point to. Here is a test case which prooves this (I believe): import std.random; void main() { char[][100] a; char[] test; //create 100 random char[] of 1000 chars foreach(inout char[] s; a) { s.length = 1000; for(uint i = 0; i < s.length; i++) s[i] = 'a' + rand()&25; } //pick one as a test case test = a[0]; //print the location and address of the first element printf("%02d. %08x\n",0,&test[0]); //sort the array a.sort; //find the test case foreach(uint i, char[] s; a) { if (s == test) { //print the location and address of the first element printf("%02d. %08x\n",i,&s[0]); break; } } } If the array is an array of pointers eg. char*[100] list; then swapping list[5] with list[9] you're swapping pointer, so again you're not swapping 1k of data. But, if you use: Foo[100] list; and Foo is a 1k large structure, then yes, you're swapping 1k of data. The same does not apply if Foo is a 1k class, because classes are handled by reference so you're swaping references to 1k classes, not the 1k classes themselves. Basically if it's a reference type, you're fine, if it's a value type, your swapping (the size of the value type)k each time. Is that clear as mud? If I'm wrong someone pls correct me.
 So I need to be able to swap the pointers
 and therefore temp needs to be a pointer, but while this is
 straightforward
 in C++, I don't know how I would do this in D. Therefore my ignorance
 when
 it comes to D has prompted what has undoubtably appeared to be a rather
 stupid question <g>

Whatever you would do in C++ you can still do in D, but, D's arrays give you a better way to do it. Regan

Now THAT is starting to get somewhere :) Looks like you can see what I am on about... I thought I was going mad, out here on my own! <g> Ok, your test case is nice, but it is not very convincing to me. In my view, it simply proves that the *in-built* sort method does what it should do, and swaps the pointers not the data; i.e. the pointer remains the same but has moved to a different position in the array. What you go on to say about the large data structure Foo and also about the array of pointers is, as far as I am concerned, totally correct and totally clear. *BUT* there is still something outstanding! ...how to swap the elements (or, forgetting about arrays, any same-type entities for that matter) and make sure that the pointers are getting swapped and not the data. So, in the case of a normal array (i.e. char[] not char*[]), I would like to know how to correctly swap the pointers, and similarly for large structure Foo I would like to do the same. Finally, from your comments I am not sure what the distinction is (is there is one) between what D assigns by reference and by value. If a and b are of type int, does a = b assign by value? The answer would appear to be obvious: yes. How about class instances A and B though? In this case, are you saying that A = B makes a reference to B and that therefore setting B.z would reflect in A.z? In which case what is the D method to copy a class instance? And surely arrays must be assigned by value just like integers, otherwise: a="x"; b="y"; t=a; a="z"; b=t; would end up with b being "z" and not "x". When I first asked about the swapping, I never thought it would be debated so much! Because I don't know much about D (2 days playing with it so far) I am trying to establish the correct ways to do things in it at the start, rather than discovering at a later date that I had reinvented the wheel or missed something important. Maybe I should go and make a swap function first, and then come back and discuss it further. But that will have to wait until tomorrow; I'll try and find some time to do it then.
Jun 30 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 1 Jul 2004 01:23:38 +0100, Dan Williams <dnews ithium.NOSPAM.net> 
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsafkvvct5a2sq9 digitalmars.com...
 On Wed, 30 Jun 2004 11:03:42 +0100, Dan Williams 
 <dnews ithium.NOSPAM.net>
 wrote:
 Surely there are pointers to the actual elements somewhere? Or are




 using a method that I am simply not thinking of right now...
 (gone 2am, tired!)

The data member points to the elements. They are stored sequentially


 memory.

I think I see what you mean. An array itself is a struct with length n where n is both the count of the elements and also the amount of memory used


 the sequentially-stored pointers to element data, yes? And each 

 then
 holds its own data with its own data properties. Ok, that makes sense,
 and
 this is essentially the way I would handle it in C++. The place that I
 came
 unstuck is in asking about element swapping. Let me explain that one
 further, so that you'll have a clearer idea of my question.

 Take an array with 100 elements, where each element is a 

 string.

char[][100] list;
 When it comes to sort the array, obviously the best method is to
 swap the data pointers after a comparison, rather than swap the data
 itself.
 Now, this is why I asked about a swap method - there are several 

 that
 I would need to utilise a swap for, and obviously I want to be 

 that I am swapping the pointers and not the data!

 As there is no swap method, how would I directly access the array


 data pointers in order to swap them? Imagine that elements 5 and 9 

 swapping, and are around about 1Kb each. If I say, temp = myArray[5];
 myArray[5] = myArray[9]; myArray[9] = temp; then I am needlessly 

 1Kb
 blocks around in memory, right?

It depends on the array. Using the array: char[][100] list; If you swap list[5] with list[9] you're swapping array references, not the data they point to. Here is a test case which prooves this (I believe): import std.random; void main() { char[][100] a; char[] test; //create 100 random char[] of 1000 chars foreach(inout char[] s; a) { s.length = 1000; for(uint i = 0; i < s.length; i++) s[i] = 'a' + rand()&25; } //pick one as a test case test = a[0]; //print the location and address of the first element printf("%02d. %08x\n",0,&test[0]); //sort the array a.sort; //find the test case foreach(uint i, char[] s; a) { if (s == test) { //print the location and address of the first element printf("%02d. %08x\n",i,&s[0]); break; } } } If the array is an array of pointers eg. char*[100] list; then swapping list[5] with list[9] you're swapping pointer, so again you're not swapping 1k of data. But, if you use: Foo[100] list; and Foo is a 1k large structure, then yes, you're swapping 1k of data. The same does not apply if Foo is a 1k class, because classes are handled by reference so you're swaping references to 1k classes, not the 1k classes themselves. Basically if it's a reference type, you're fine, if it's a value type, your swapping (the size of the value type)k each time. Is that clear as mud? If I'm wrong someone pls correct me.
 So I need to be able to swap the pointers
 and therefore temp needs to be a pointer, but while this is
 straightforward
 in C++, I don't know how I would do this in D. Therefore my ignorance
 when
 it comes to D has prompted what has undoubtably appeared to be a 

 stupid question <g>

Whatever you would do in C++ you can still do in D, but, D's arrays give you a better way to do it. Regan

Now THAT is starting to get somewhere :) Looks like you can see what I am on about... I thought I was going mad, out here on my own! <g>

I get that feeling sometimes too.. sometimes I wonder if they do it on purpose.
 Ok, your test case is nice, but it is not very convincing to me. In my 
 view,
 it simply proves that the *in-built* sort method does what it should do, 
 and
 swaps the pointers not the data; i.e. the pointer remains the same but 
 has
 moved to a different position in the array.

 What you go on to say about the large data structure Foo and also about 
 the
 array of pointers is, as far as I am concerned, totally correct and 
 totally
 clear.

Whew.
 *BUT* there is still something outstanding! ...how to swap the elements 
 (or,
 forgetting about arrays, any same-type entities for that matter) and make
 sure that the pointers are getting swapped and not the data. So, in the 
 case
 of a normal array (i.e. char[] not char*[]), I would like to know how to
 correctly swap the pointers, and similarly for large structure Foo I 
 would
 like to do the same.

With char[] I think my latest example prooves the data is not copied.
 Finally, from your comments I am not sure what the distinction is (is 
 there
 is one) between what D assigns by reference and by value. If a and b are 
 of
 type int, does a = b assign by value? The answer would appear to be 
 obvious:
 yes.

Yes.
 How about class instances A and B though? In this case, are you saying
 that A = B makes a reference to B and that therefore setting B.z would
 reflect in A.z?

Yes. Example: class A { this(int _val) { val = _val; } int val; } void main() { A a = new A(1); A b = new A(2); printf("A(%08x)(%d) B(%08x)(%d)\n",&a.val,a.val,&b.val,b.val); b = a; printf("A(%08x)(%d) B(%08x)(%d)\n",&a.val,a.val,&b.val,b.val); b.val = 5; printf("A(%08x)(%d) B(%08x)(%d)\n",&a.val,a.val,&b.val,b.val); b = new A(a.val); printf("A(%08x)(%d) B(%08x)(%d)\n",&a.val,a.val,&b.val,b.val); }
 In which case what is the D method to copy a class instance?

There isn't one, you do it the same as in C++. Either by a copy constructor doing a deep-copy and/or by a method, dup() is a good name for it. eg. class Foo { this(Foo f) { //deep-copy contents of f } Foo dup() { Foo f = new Foo(this); return f; } }
 And surely arrays must be assigned by value just like integers, 
 otherwise:
 a="x"; b="y"; t=a; a="z"; b=t; would end up with b being "z" and not "x".

When you write "z" D creates a char[] array and assigns "z" to the data pointer. So by going a="z" you create a new array and assign a to it by reference. They also have a built-in dup method i.e. char[] a = "regan"; char[] b; b = a.dup; a and b both contain "regan" but they are not the same "regan" but different ones living in different places in memory.
 When I first asked about the swapping, I never thought it would be 
 debated
 so much! Because I don't know much about D (2 days playing with it so 
 far) I
 am trying to establish the correct ways to do things in it at the start,
 rather than discovering at a later date that I had reinvented the wheel 
 or
 missed something important.

This is a wise decision IMO.
 Maybe I should go and make a swap function
 first, and then come back and discuss it further.

I try to try/test everything before I bring it up. It saves time, and potentially embarrassment. That said everyones understanding starts somewhere and IMO you don't learn unless you question.
 But that will have to wait
 until tomorrow; I'll try and find some time to do it then.

I can't wait :) Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 30 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsafrtctm5a2sq9 digitalmars.com...
 On Thu, 1 Jul 2004 01:23:38 +0100, Dan Williams <dnews ithium.NOSPAM.net>
 wrote:
 Now THAT is starting to get somewhere :) Looks like you can see what I
 am on
 about... I thought I was going mad, out here on my own! <g>

I get that feeling sometimes too.. sometimes I wonder if they do it on purpose.

:D so it's not just me then!
 ...what is the D method to copy a class instance?

There isn't one, you do it the same as in C++. Either by a copy constructor doing a deep-copy and/or by a method, dup() is a good name for it.

Should there be a clone() method in the core D language? Kinda like PHP5? Or is that another stupid question? :) (Maybe I should not ask questions for a while!)
 When you write "z" D creates a char[] array and assigns "z" to the data
 pointer.
 So by going a="z" you create a new array and assign a to it by reference.

 They also have a built-in dup method i.e.

 char[] a = "regan";
 char[] b;

 b = a.dup;

 a and b both contain "regan" but they are not the same "regan" but
 different ones living in different places in memory.

Indeed, I finally twigged that. Not sure about the need for dup though... see my other post, doesn't slicing do the same thing? Or does dup do a multi-level copy? (whereas slicing would only copy the outermost array, and subarrays would still point to the same places.) I think I really missed the boat on this one earlier :(
 When I first asked about the swapping, I never thought it would be
 debated
 so much! Because I don't know much about D (2 days playing with it so
 far) I
 am trying to establish the correct ways to do things in it at the start,
 rather than discovering at a later date that I had reinvented the wheel
 or
 missed something important.

This is a wise decision IMO. I try to try/test everything before I bring it up. It saves time, and potentially embarrassment. That said everyones understanding starts somewhere and IMO you don't learn unless you question.

Thankyou... however the decision has to be made whether knowledge at the price of embarrassment of ignorance is worth it compared to not asking, not being embarrassed, but maybe not understanding either. In my case, if there is one thing I have learnt, it is how much I don't know, so I've gotten used to being ignorant by now :)
Jul 01 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Thu, 1 Jul 2004 11:41:46 +0100, Dan Williams <dnews ithium.NOSPAM.net> 
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsafrtctm5a2sq9 digitalmars.com...
 On Thu, 1 Jul 2004 01:23:38 +0100, Dan Williams 
 <dnews ithium.NOSPAM.net>
 wrote:
 Now THAT is starting to get somewhere :) Looks like you can see what I
 am on
 about... I thought I was going mad, out here on my own! <g>

I get that feeling sometimes too.. sometimes I wonder if they do it on purpose.

:D so it's not just me then!
 ...what is the D method to copy a class instance?

There isn't one, you do it the same as in C++. Either by a copy constructor doing a deep-copy and/or by a method, dup() is a good name for it.

Should there be a clone() method in the core D language? Kinda like PHP5?

If there were a way to query a thing for all its members and if every thing had a copy constructor then this would be possible I reckon.
 Or
 is that another stupid question? :) (Maybe I should not ask questions 
 for a
 while!)

Nah.. keep em coming, it gives me something to do when I am dodging work.
 When you write "z" D creates a char[] array and assigns "z" to the data
 pointer.
 So by going a="z" you create a new array and assign a to it by 
 reference.

 They also have a built-in dup method i.e.

 char[] a = "regan";
 char[] b;

 b = a.dup;

 a and b both contain "regan" but they are not the same "regan" but
 different ones living in different places in memory.

Indeed, I finally twigged that. Not sure about the need for dup though... see my other post, doesn't slicing do the same thing?

Yes. dup is the same as b[] = a[] I believe.. but not the same as a partial slice i.e. b[0..5] = a[0..5].
 Or does dup do a
 multi-level copy? (whereas slicing would only copy the outermost array, 
 and
 subarrays would still point to the same places.)

If 'multi-level' is the same as 'deep' copy .. no, dup is only a shallow copy.
 I think I really missed the boat on this one earlier :(

It happens.
 When I first asked about the swapping, I never thought it would be
 debated
 so much! Because I don't know much about D (2 days playing with it so
 far) I
 am trying to establish the correct ways to do things in it at the 

 rather than discovering at a later date that I had reinvented the 

 or
 missed something important.

This is a wise decision IMO. I try to try/test everything before I bring it up. It saves time, and potentially embarrassment. That said everyones understanding starts somewhere and IMO you don't learn unless you question.

Thankyou... however the decision has to be made whether knowledge at the price of embarrassment of ignorance is worth it compared to not asking, not being embarrassed, but maybe not understanding either. In my case, if there is one thing I have learnt, it is how much I don't know, so I've gotten used to being ignorant by now :)

You'll only suffer the embarrassment once, you'll suffer the ignorance forever. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 01 2004
prev sibling next sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <cbsq23$46i$1 digitaldaemon.com>, Walter says...

D does need some testimonials from using it in significant projects.

I think now it's time for a few commercial questions: - When Digital Mars D development toolkit will be available? - Which commercial formula will be used? How about tech help? - Will it be possible to buy the compiler sources, just in case? [..]
What you're talking about are DLLs in Windows and shared libraries under
linux. Right now, I prefer things to be statically linked in because that
avoids "DLL hell" where versions get mismatched.

I see. But what if I want to distribute a bunch of executables forming a complete suite? It would be very useful to have a single shared library with Phobos/Garbage Collector. Ciao
Jun 30 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:cbtq14$1k9r$1 digitaldaemon.com...
 In article <cbsq23$46i$1 digitaldaemon.com>, Walter says...

D does need some testimonials from using it in significant projects.

I think now it's time for a few commercial questions: - When Digital Mars D development toolkit will be available?

You can download it now! That's what dmd.zip is.
 - Which commercial formula will be used? How about tech help?
 - Will it be possible to buy the compiler sources, just in case?

Yes.
 [..]
What you're talking about are DLLs in Windows and shared libraries under
linux. Right now, I prefer things to be statically linked in because that
avoids "DLL hell" where versions get mismatched.

I see. But what if I want to distribute a bunch of executables forming a complete suite? It would be very useful to have a single shared library with Phobos/Garbage Collector.

It would save some disk space, that's it.
Jun 30 2004
next sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <cbttqo$1uio$1 digitaldaemon.com>, Walter says...
"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:cbtq14$1k9r$1 digitaldaemon.com...

 - When Digital Mars D development toolkit will be available?

You can download it now! That's what dmd.zip is.

I think you missed the point, that is in the next question:
 - Which commercial formula will be used? How about tech help?


Sure, I can use the (for now?) freely downloadable tools. But I think that it's easier to persuade my employer to adopt D for a project if behind D there's a company working to solve bugs and improve the toolkit.
 - Will it be possible to buy the compiler sources, just in case?

Yes.

Good. But this can be oly a parachute, I prefer having a working plane ;-) [...]
 I see. But what if I want to distribute a bunch of executables forming a
 complete suite?
 It would be very useful to have a single shared library with
 Phobos/Garbage Collector.

It would save some disk space, that's it.

And load time, and maybe some memory (depending on the O.S.). I think it's worth. Ciao
Jun 30 2004
parent "Walter" <newshound digitalmars.com> writes:
"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:cbu46c$2fq4$1 digitaldaemon.com...
 Sure, I can use the (for now?) freely downloadable tools.
 But I think that it's easier to persuade my employer to adopt D for a

 behind D there's a company working to solve bugs and improve the toolkit.

There is - Digital Mars. It's a real, licensed company, been around for years. We even pay taxes <g>. The track record for tech support is open for all to see in this newsgroup, and the track record of resolving bugs and improving the toolkit is evident in www.digitalmars.com/d/changelog.html
Jun 30 2004
prev sibling parent "Lynn Allan" <l.allan att.net> writes:
 It would be very useful to have a single shared library with
 Phobos/Garbage Collector.

It would save some disk space, that's it.

Shared libraries could be very advantageous to minimize download size for a "suite" of applications. Not everyone has broadband. [And pda development ... for eventual consideration] The only reason I use "hold-your-nose" Visual C++ MFC is that my freeware apps can assume the end-user has mfc40.dll (Win95), mfc42.dll (Win98), and msvcrt.dll. MyAppUpdate.exe (just executable update without fixed data, source, and documentation files) can have significant functionality in well under 100kb, including NSIS installer.
Jul 01 2004
prev sibling parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:cbtq14$1k9r$1 digitaldaemon.com...
 But what if I want to distribute a bunch of executables forming a
 complete suite? It would be very useful to have a single shared library

 Phobos/Garbage Collector.

Indeed... exactly my problem also. In Walter's reply he says: "Walter" <newshound digitalmars.com> wrote in message news:cbttqo$1uio$1 digitaldaemon.com...
 It would save some disk space, that's it.

...however, it's memory space as well really, isn't it? Although it's not the end of the world to compile Phobos and the GC into the executable, we really do need that option. And I mean an option; a compiler flag or whatever - not just simply changed. The default should remain as it is now, with the facility for those that so require to compile the separate shared library. I know you said "after 1.0" Walter, but is that definite? Is there a D roadmap somewhere to show where the language is going, and what things are going to be done at what stages? If not, that would be useful, and save extroneous discussion ;) As you can probably tell, this is an important issue to me <g>
Jun 30 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
news:cbu130$2930$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:cbttqo$1uio$1 digitaldaemon.com...
 It would save some disk space, that's it.


No, not unless the programs are running simultaneously. And even so, how many are you going to have running simultaneously? 3 or 4? That would be an extra 200k on a machine with (likely) 256 megabytes on it. I don't think it would be noticed.
 Although it's not
 the end of the world to compile Phobos and the GC into the executable, we
 really do need that option. And I mean an option; a compiler flag or
 whatever - not just simply changed. The default should remain as it is

 with the facility for those that so require to compile the separate shared
 library.

 I know you said "after 1.0" Walter, but is that definite? Is there a D
 roadmap somewhere to show where the language is going, and what things are
 going to be done at what stages? If not, that would be useful, and save
 extroneous discussion ;)

There isn't a concrete roadmap, we'll just be pushing it in the direction that the D community wants it to go.
 As you can probably tell, this is an important issue to me <g>

I understand it is, but I'm not sure why in these days of incomprehensibly large disk and memory spaces <g>.
Jun 30 2004
parent reply "Dan Williams" <dnews ithium.NOSPAM.net> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cbuuao$rsk$2 digitaldaemon.com...
 "Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
 news:cbu130$2930$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:cbttqo$1uio$1 digitaldaemon.com...
 It would save some disk space, that's it.


No, not unless the programs are running simultaneously. And even so, how many are you going to have running simultaneously? 3 or 4? That would be

 extra 200k on a machine with (likely) 256 megabytes on it. I don't think

 would be noticed.

 As you can probably tell, this is an important issue to me <g>

I understand it is, but I'm not sure why in these days of incomprehensibly large disk and memory spaces <g>.

Heheh... well, I've always preferred to conserve resources wherever possible, and just because there's a lot of disk and memory space doesn't mean we should be inefficient in its usage, surely? ;) There are some valid uses where the space would be very important - such as in embedded software - but I don't write anything like that, so I'm going to drop this one here now and just hope that it gets "fixed" at some point in the future :D
Jun 30 2004
parent "Lynn Allan" <l.allan att.net> writes:
 There are some valid uses where the space would be very important - such

 in embedded software - but I don't write anything like that, so I'm going

 drop this one here now and just hope that it gets "fixed" at some point in
 the future :D

pda development (Palm and Pocket-PC) still have important resource limitations. "D" might be a great language for pda development.
Jun 30 2004
prev sibling parent reply Stephen Waits <steve waits.net> writes:
Walter wrote:

 "Dan Williams" <dnews ithium.NOSPAM.net> wrote in message
 news:cbskjv$2u3i$1 digitaldaemon.com...
 
All I can say about that type of array is that I agree with the proposal put
forward by Norbert Nemec - has any of that been implemented yet? Is it
 going
to be?

It's a good candidate for 2.0. But right now, one can emulate such arrays using structs and operator overloading.

D is a great language, I'm a huge fan, and have been since its earliest days. However... This is quite unfortunate - how can we expect to achieve real-world (i.e. useful) linear algebra performance through such an emulation mechanism? I want to use D in games (I'm a Lead on a PSP title), possibly even in the near future. Others, I'm sure, would love to use D in scientific applications. For these applications, we need some real linear algebra code, and for that, we need (something like) Norbert's stuff to become reality. What say you on this topic??? --Steve PS - Our linear algebra "packages" in C++ are all major hacks - operator overloads galore, super fugly template trickery. Having something IN THE LANGUAGE that makes these things easier, more elegant, and more efficient would be a dream come true for many a coder.
Jun 30 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Stephen Waits" <steve waits.net> wrote in message
news:cbvhur$1on6$1 digitaldaemon.com...
 This is quite unfortunate - how can we expect to achieve real-world
 (i.e. useful) linear algebra performance through such an emulation
 mechanism?

I think you can get much closer in D than you can in C++, because in D you can overload [] to take multiple indices. This is not possible in C++.
 I want to use D in games (I'm a Lead on a PSP title), possibly even in
 the near future.  Others, I'm sure, would love to use D in scientific
 applications.

D has much better *standard* handling of floating point than C++ - for example, behavior is specified to be IEEE 754 conformant. Nans must be handled properly. This is not addressed by C++. Also, D has 80 bit floating point, and built in complex numbers.
 For these applications, we need some real linear algebra code, and for
 that, we need (something like) Norbert's stuff to become reality.

 What say you on this topic???

I'm aware of the importance of this issue. But I'm also painfully aware that D is not stable enough at the moment, and that must be the priority.
 --Steve

 PS - Our linear algebra "packages" in C++ are all major hacks - operator
 overloads galore, super fugly template trickery.  Having something IN
 THE LANGUAGE that makes these things easier, more elegant, and more
 efficient would be a dream come true for many a coder.

Jul 01 2004
parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Walter wrote:

 
 "Stephen Waits" <steve waits.net> wrote in message
 news:cbvhur$1on6$1 digitaldaemon.com...
 This is quite unfortunate - how can we expect to achieve real-world
 (i.e. useful) linear algebra performance through such an emulation
 mechanism?

I think you can get much closer in D than you can in C++, because in D you can overload [] to take multiple indices. This is not possible in C++.

Careful: the multiple index opIndex may help you in writing *comfortable* linalg-libraries. For writing high-performance code, you need completely different means, namely vectorization. C++ offers means for vectorization via expression templates, which are a clumsy, sub-optimal solution. D doesn't offer anything in that direction at all. Array expressions are a small step in that direction. Anyhow, I think the current specs in that direction should not be implemented at all. They are a best a toy-solution for the problem that will get in our way lateron, when we look for a real solution. For some more thoughts on vectorization see my separate post.
Jul 01 2004
prev sibling parent "me" <memsom interalpha.co.uk> writes:
If you're truely after cross platform, the D is probably not at a stage that
would be useful. There's a Windows version, a Linux version, oh and I hacked
together a really out of date version for BeOS and Zeta (lol). All intel
based, all fixed to specific platforms.

 Basic and Pascal derivatives? ...nothing I know of fits the bill,



Try looking at Free Pascal. It does intel, powerpc, arm and 68000. It has a MacOSX, DOS (via Go32v2 dos extender), Windows, Amiga, BeOS (intel), BSD, Linux (including PPC, INTEL and AMD64 is in the works too.) There's probably more platforms - I know PalmOS 68000 was in the works at one point. Classic MacOS (PPC) is also being worked on. It supports a number of Pascal dialects. Borland Turbo Pascal, Borland Delphi, a FPC Hybrid ObjectPascal and also a Mac Pascal dialect in the latest version (not yet avalable for all Platforms.) It seems odd to push for Pascal in a D forum, but I know of quite a few people who actively maintain multiple platform code using Free Pascal. It has all of your major requirements (e.g. OO, dynamic string type, RTTI, etc) and is on a par with D on the Windows platform. Couple this with the Lazarus project, and you have RAD on a number of the available platforms too. http://www.freepascal.org. Matt
Jun 30 2004