www.digitalmars.com         C & C++   DMDScript  

D - how to check char[ ] is empty

reply yaneurao <yaneurao_member pathlink.com> writes:
I want empty property in char[].

C# style:
string s;
if ( !s || s.length == 0) { .. }
// or 
if ( !s !! s!=String.Empty) { .. }
// Note in C# when we access length property for nullReffernce ,
// throw NullReferenceException.

D style:
char[] s;
if ( !s || s.length == 0) { .. }
// or simplifying this :
if ( s.length == 0 ) { .. }

but someone might mistake to write
if ( s.length = 0 ) { .. }
if ( !s ) { .. }

if ( s == "" ) { .. }
// this is right. but _adeq is called , so not good code , I think.

So , char [] had better have empty property like this:
if ( s.empty ) { .. }
It should be equivalent to :
if ( s.length == 0 ) { .. }

yaneurao.
Jan 14 2004
parent reply "Walter" <walter digitalmars.com> writes:
"yaneurao" <yaneurao_member pathlink.com> wrote in message
news:bu5gub$13kh$1 digitaldaemon.com...
 but someone might mistake to write
 if ( s.length = 0 ) { .. }
 if ( !s ) { .. }
 if ( s == "" ) { .. }

All three are equivalent in D.
Jan 15 2004
next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
 if ( s.length = 0 ) { .. }


I assume that should be ==
Jan 15 2004
parent "Walter" <walter digitalmars.com> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:bu65i1$24l6$1 digitaldaemon.com...
 if ( s.length = 0 ) { .. }


I assume that should be ==

yes.
Jan 16 2004
prev sibling next sibling parent reply yaneurao <yaneurao_member pathlink.com> writes:
In article <bu5n0g$1eju$2 digitaldaemon.com>, Walter says...
 but someone might mistake to write
 if ( s.length = 0 ) { .. }
 if ( !s ) { .. }
 if ( s == "" ) { .. }


No. All three are not equivalent in D. first case , he uses '=' for '==' by mistake. second case , s would not be empty but null. eg. char[] s = "ABC"; s.length = 0; if ( !s ) { ... } // s is empty but not null so , 'if ( !s )' is wrong for checking whether s is empty or not. third case , even if s is null , it goes well. eg. char[] s = "ABC"; s.length = 0; if ( s=="" ) { ... } but third case , compiler generates string comparing code. it's slower than: if ( s.length == 0 ) so , 'if ( s.length == 0 )' should be used , I think. but everybody doesn't understand this. that's why I want '.empty' property for char[] or array. yaneurao.
Jan 15 2004
next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
"yaneurao" <yaneurao_member pathlink.com> wrote in message
news:bu68jk$29oc$1 digitaldaemon.com...
 In article <bu5n0g$1eju$2 digitaldaemon.com>, Walter says...
 but someone might mistake to write
 if ( s.length = 0 ) { .. }
 if ( !s ) { .. }
 if ( s == "" ) { .. }


No. All three are not equivalent in D.

How about making s.length = 0; set the data pointer to null? That way the three will be equivalent since it would be impossible to have a non-null pointer and 0 length. The performance hit would just be a single 0 test when changing lengths.
 first case , he uses '=' for '==' by mistake.
 second case , s would not be empty but null.

 eg.
 char[] s = "ABC";
 s.length = 0;
 if ( !s ) { ... } // s is empty but not null

 so , 'if ( !s )' is wrong for checking whether s is empty or not.

 third case , even if s is null , it goes well.

 eg.
 char[] s = "ABC";
 s.length = 0;
 if ( s=="" ) { ... }

 but third case , compiler generates string comparing code. it's slower

 if ( s.length == 0 )

 so , 'if ( s.length == 0 )' should be used , I think.
 but everybody doesn't understand this.
 that's why I want '.empty' property for char[] or array.

 yaneurao.

Jan 15 2004
next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
 How about making
  s.length = 0;
 set the data pointer to null? That way the three will be equivalent since

 would be impossible to have a non-null pointer and 0 length. The

 hit would just be a single 0 test when changing lengths.

looking at the source file src/phobos/internal/gc/gc.d the function _d_arraysetlength already does this so apparently I'm confused about why those three tests are different (modulo the part about the first test having = instead of ==). -Ben
Jan 15 2004
parent reply yaneurao <yaneurao_member pathlink.com> writes:
In article <bu6cj5$2gh8$1 digitaldaemon.com>, Ben Hinkle says...
looking at the source file src/phobos/internal/gc/gc.d the function
_d_arraysetlength already does this so apparently I'm confused about why
those three tests are different (modulo the part about the first test having
= instead of ==).

char[](or array) could be not null and empty easily like this: eg. char s = "ABC"; s = ""; // s is not null but empty(length==0) so null-checking is not equal to empty-checking. by this reason , if you want to check whether char[] is empty , you should type 'if ( s.length == 0 )' , not 'if ( !s )'. thus , it is necessary for char[](or array) to have a '.empty' property. yaneurao.
Jan 15 2004
next sibling parent "Ben Hinkle" <bhinkle4 juno.com> writes:
"yaneurao" <yaneurao_member pathlink.com> wrote in message
news:bu6mgl$3131$1 digitaldaemon.com...
 In article <bu6cj5$2gh8$1 digitaldaemon.com>, Ben Hinkle says...
looking at the source file src/phobos/internal/gc/gc.d the function
_d_arraysetlength already does this so apparently I'm confused about why
those three tests are different (modulo the part about the first test


= instead of ==).

char[](or array) could be not null and empty easily like this: eg. char s = "ABC"; s = ""; // s is not null but empty(length==0) so null-checking is not equal to empty-checking.

Hmm. I see. I wonder if it would make life easier to make "" have 0 length and null pointer. I guess that would be un-C-like since there "" is a pointer to a 0 byte and that would cause problems with things like printf(""); I'm leaning towards keeping things the way they are and just making sure to use .length to test for empty strings since there are different ways of being empty. (deep, eh?) If your code needs to cast to a non-null char* then use the pointer test. Which one to use depends on the context. -Ben
Jan 15 2004
prev sibling parent reply The Lone Haranguer <The_member pathlink.com> writes:
Well, 'if ( !s )' is poor style anyway and should be avoided. Use 'if ( s ==
null )' it's clearer. Plus, even though D still doesn't strongly-type boolean,
one should code as if it were.

In article <bu6mgl$3131$1 digitaldaemon.com>, yaneurao says...
In article <bu6cj5$2gh8$1 digitaldaemon.com>, Ben Hinkle says...
looking at the source file src/phobos/internal/gc/gc.d the function
_d_arraysetlength already does this so apparently I'm confused about why
those three tests are different (modulo the part about the first test having
= instead of ==).

char[](or array) could be not null and empty easily like this: eg. char s = "ABC"; s = ""; // s is not null but empty(length==0) so null-checking is not equal to empty-checking. by this reason , if you want to check whether char[] is empty , you should type 'if ( s.length == 0 )' , not 'if ( !s )'. thus , it is necessary for char[](or array) to have a '.empty' property. yaneurao.

Jan 15 2004
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Bah.

Usability in a boolean sense is a desirable property for some objects,
especially for basic types in a C-derived language.  I prefer if (!s)
because it's shorter, which means we all can read it quicker (fewer
characters == fewer potential bugs, as whitespace and comments cannot
possibly be bugs), thus all else being equal between two pieces of code,
less code is always better.

Coding defensively can be good, up to a point, I guess.  But not if it gets
in my way too much.  There's little enough time in the day without typing 3
times as much as you have to.

Sean

"The Lone Haranguer" <The_member pathlink.com> wrote in message
news:bu6u6e$e5n$1 digitaldaemon.com...
 Well, 'if ( !s )' is poor style anyway and should be avoided. Use 'if ( s

 null )' it's clearer. Plus, even though D still doesn't strongly-type

 one should code as if it were.

Jan 20 2004
next sibling parent reply The Lone Haranguer <The_member pathlink.com> writes:
I hope I never have to read your code.

In article <bul827$2i19$1 digitaldaemon.com>, Sean L. Palmer says...
Bah.

Usability in a boolean sense is a desirable property for some objects,
especially for basic types in a C-derived language.  I prefer if (!s)
because it's shorter, which means we all can read it quicker (fewer
characters == fewer potential bugs, as whitespace and comments cannot
possibly be bugs), thus all else being equal between two pieces of code,
less code is always better.

Coding defensively can be good, up to a point, I guess.  But not if it gets
in my way too much.  There's little enough time in the day without typing 3
times as much as you have to.

Sean

"The Lone Haranguer" <The_member pathlink.com> wrote in message
news:bu6u6e$e5n$1 digitaldaemon.com...
 Well, 'if ( !s )' is poor style anyway and should be avoided. Use 'if ( s

 null )' it's clearer. Plus, even though D still doesn't strongly-type

 one should code as if it were.


Jan 20 2004
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
I feel sorry for you if you can't, because I think it's quite readable.  ;)

In turn, I hope I never have to read your code.  It would take too long, I'd
have to sift through all kinds of unnecessary clutter probably.

Sean

"The Lone Haranguer" <The_member pathlink.com> wrote in message
news:bul8ja$2ikm$1 digitaldaemon.com...
 I hope I never have to read your code.

 In article <bul827$2i19$1 digitaldaemon.com>, Sean L. Palmer says...
Bah.

Usability in a boolean sense is a desirable property for some objects,
especially for basic types in a C-derived language.  I prefer if (!s)
because it's shorter, which means we all can read it quicker (fewer
characters == fewer potential bugs, as whitespace and comments cannot
possibly be bugs), thus all else being equal between two pieces of code,
less code is always better.

Coding defensively can be good, up to a point, I guess.  But not if it


in my way too much.  There's little enough time in the day without typing


times as much as you have to.

Sean


Jan 22 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
jeepers creepers, you two.

If we are to have a jousting competition, at least get your lances out.

In other words, let's have the two of you post your code, and we can vote on
who's is the most smegworthy.

:)

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:buppp8$q8j$1 digitaldaemon.com...
 I feel sorry for you if you can't, because I think it's quite readable.

 In turn, I hope I never have to read your code.  It would take too long,

 have to sift through all kinds of unnecessary clutter probably.

 Sean

 "The Lone Haranguer" <The_member pathlink.com> wrote in message
 news:bul8ja$2ikm$1 digitaldaemon.com...
 I hope I never have to read your code.

 In article <bul827$2i19$1 digitaldaemon.com>, Sean L. Palmer says...
Bah.

Usability in a boolean sense is a desirable property for some objects,
especially for basic types in a C-derived language.  I prefer if (!s)
because it's shorter, which means we all can read it quicker (fewer
characters == fewer potential bugs, as whitespace and comments cannot
possibly be bugs), thus all else being equal between two pieces of



less code is always better.

Coding defensively can be good, up to a point, I guess.  But not if it


in my way too much.  There's little enough time in the day without



 3
times as much as you have to.

Sean



Jan 22 2004
prev sibling parent reply The Lone Haranguer <The_member pathlink.com> writes:
Are comments clutter? Are they necessary clutter?

In article <buppp8$q8j$1 digitaldaemon.com>, Sean L. Palmer says...
I feel sorry for you if you can't, because I think it's quite readable.  ;)

In turn, I hope I never have to read your code.  It would take too long, I'd
have to sift through all kinds of unnecessary clutter probably.

Sean

"The Lone Haranguer" <The_member pathlink.com> wrote in message
news:bul8ja$2ikm$1 digitaldaemon.com...
 I hope I never have to read your code.

 In article <bul827$2i19$1 digitaldaemon.com>, Sean L. Palmer says...
Bah.

Usability in a boolean sense is a desirable property for some objects,
especially for basic types in a C-derived language.  I prefer if (!s)
because it's shorter, which means we all can read it quicker (fewer
characters == fewer potential bugs, as whitespace and comments cannot
possibly be bugs), thus all else being equal between two pieces of code,
less code is always better.

Coding defensively can be good, up to a point, I guess.  But not if it


in my way too much.  There's little enough time in the day without typing


times as much as you have to.

Sean



Jan 22 2004
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Comments are fine.  I can ignore them until they are necessary.  ;)

I *do* comment my code, but I usually do not attempt to translate the code
into English, but merely support the code with the "why" and "this is
written this way because if you change it to the more obvious method, it'll
break for this reason" kind of comments.  More of a high-level overview, a
sense of the purpose of the code.  My naming conventions make most other
comments largely unnecessary.  Comments of the sort "float parameter1,  //
the first parameter, of type float" and "++x;  // set x to whatever it used
to be, plus one" and "class Foo  // a class called Foo that represents foo"
just piss me off.  Those truly are noise.  Large automatically generated
comment blocks are also suspect, as you've probably read elsewhere.  A 3
page comment block to describe a one page function, that actually contains
only a few lines of useful information, is a waste, and should be reduced to
just those few lines.  In projects of mine where I find such comments, I
actively delete them.  I also change things like "Function(MyBoolean!=FALSE
? FALSE : TRUE);"  to  "Function(!MyBoolean)", and yeah, I'll do that in an
if statement as well.  I find that inexperienced programmers tend to write
very longwinded, roundabout code because they aren't used to simplifying
logic.  Once it's simplified, they can actually read it a lot easier, but
they can't write it simplified in the first place.  I also actively refactor
common code, another common newbie coding problem that actually has serious
maintenance ramifications.

Anyway, this is religious war material, and we should probably just agree to
disagree.   My point is that the language should not force us to write
longer code than is necessary... then again it shouldn't force us to write
shorter code than is necessary either.  If it did, we wouldn't have anything
to argue about, but it wouldn't succeed in the market.

Sean

"The Lone Haranguer" <The_member pathlink.com> wrote in message
news:buqc2p$1om8$1 digitaldaemon.com...
 Are comments clutter? Are they necessary clutter?

 In article <buppp8$q8j$1 digitaldaemon.com>, Sean L. Palmer says...
I feel sorry for you if you can't, because I think it's quite readable.


In turn, I hope I never have to read your code.  It would take too long,


have to sift through all kinds of unnecessary clutter probably.

Sean

"The Lone Haranguer" <The_member pathlink.com> wrote in message
news:bul8ja$2ikm$1 digitaldaemon.com...
 I hope I never have to read your code.

 In article <bul827$2i19$1 digitaldaemon.com>, Sean L. Palmer says...
Bah.




Jan 23 2004
parent Georg Wrede <Georg_member pathlink.com> writes:
In article <burr37$15l5$1 digitaldaemon.com>, Sean L. Palmer says...
Comments are fine.  I can ignore them until they are necessary.  ;)

I *do* comment my code, but I usually do not attempt to translate the code
into English, but merely support the code with the "why" and "this is
written this way because if you change it to the more obvious method, it'll
break for this reason" kind of comments.  More of a high-level overview, a
sense of the purpose of the code.  My naming conventions make most other
comments largely unnecessary.  Comments of the sort "float parameter1,  //
the first parameter, of type float" and "++x;  // set x to whatever it used
to be, plus one" and "class Foo  // a class called Foo that represents foo"
just piss me off.  Those truly are noise.  Large automatically generated
comment blocks are also suspect, as you've probably read elsewhere.  A 3
page comment block to describe a one page function, that actually contains
only a few lines of useful information, is a waste, and should be reduced to
just those few lines.  In projects of mine where I find such comments, I
actively delete them.  I also change things like "Function(MyBoolean!=FALSE
? FALSE : TRUE);"  to  "Function(!MyBoolean)", and yeah, I'll do that in an
if statement as well.  I find that inexperienced programmers tend to write
very longwinded, roundabout code because they aren't used to simplifying
logic.  Once it's simplified, they can actually read it a lot easier, but
they can't write it simplified in the first place.  I also actively refactor
common code, another common newbie coding problem that actually has serious
maintenance ramifications.

Without taking sides in this conversation (it's between the two of you), I just have to say, PLEASE, all newbies, try to read the above, and plaster it on your wall. Personally, I feel that the kind of comments a job seeking programmer's previous code contains tells me as much about his thinking as his code. And, unfortunately, a small difference in thinking makes an enormous difference in productivity for the company. Sean is right, the code itself has to be so clear that no comments are needed to explain what's going on! Comments should only be used to show the unobvious: as above, what's going to break if you change this, why we had to do it this way, or why this is coded so that at first glance it looks non-optimal. BUT NEVER what the code does. That should be readable from the code itself. And if it isn't, you should change it. Variable names (#1 goof of newbies), lengty expressions doing something that could be said in one sentence, structure of the code, etc. ( An amazingly common misconception with newbies learning their first language is that the same overall structure you have in your home assignments will just expand when you "then later, when you're this Professional doing these 100,000 lines apps", is going to stay the same. That is, 50% of code lines in main(), the rest divided between "obligatory BS", obvious subroutines, etc. What most newbies just cannot fathom, is that even 1M lines apps really have as short functions and procedures as typical home assignments. _They_ don't grow in length. There just are more of them. And the layers (levels of subroutines from the top level to the level that does the actual work) just keep increasing. My first revelation as a young guy came when I got a hold of Borland source code for the runtime libraries. Boy was I amazed when I realized that all procedures and functions were less than a screenful (at that time 24 lines!). At first this looked awkward, inefficient, and "so hard to follow the program logic". ) And, that code can never be clear unless it is refactored. Few programmers, (that I know of, (with 2 exceptions)) write code Right from the start. Everybody else, (especially I) do have to refactor after the first successful test run. Being too lazy to do that even afterwards, only gives _yourself_ cumulatively more work. This refactoring increases readability (for the pros, at least). It also makes the code _way_ easier to maintain! For yourself. Having said that, I do understand why new programmers (especially those writing their first programming language) do make the kind of comments they do. It arises from the fact that when you write your first lines of code, you have to comment it so you yourself understand what's going on. "This bit of code doubles the input variable, returning the square of it." Now, depending on the individual, you transcend this stage in a couple of months, or a couple of _decades_. (Trust me, I've seen enough.) With a lot of coaching and personal training, you can get _anybody_ above this level, but in the real life that's a wasted effort. So, to threat kicking all newbies' butt: the sooner you learn to comment what Sean asks for and not what newbies do, the sooner you'll be considered Programmers. And those who don't make it "soon", ought to consider changing to marketing. No offence.
Jan 23 2004
prev sibling parent "davepermen" <davepermen hotmail.com> writes:
 fewer potential bugs, as whitespace and comments cannot
 possibly be bugs

uhm, except outdated comments that state invalid stuff. you should learn perl. there you can really write your way (the shorter, the better).
Jan 20 2004
prev sibling parent yaneurao <yaneurao_member pathlink.com> writes:
In article <bu6c41$2fpc$1 digitaldaemon.com>, Ben Hinkle says...
How about making
 s.length = 0;
set the data pointer to null?

I guess it is not realistic. when copying array , assigning array or some changing array , GC needs to detect whether length == 0 or not ? eg. char [] s1 = "ABC"; char [] s2 = s1[1..1]; // here , s2 is empty though not null. s2 could be not null and empty(length == 0) easily. I don't know where it is a bug or not. but every time changing array , should GC detect length == 0 and set the data pointer to null? it is not realistic implementation, I think. yaneurao.
Jan 15 2004
prev sibling next sibling parent reply The Lone Haranguer <The_member pathlink.com> writes:
So Walter has kindly given you _three_ ways to do the same thing and you still
want _more_ ways?

If sharability of code is a major goal in modern programming, then there should
be _fewer_ ways of doing a particular thing (while still allowing
expressiveness).

How usefull is a language that allows so much obfuscation?  ... Wait, don't
answer that.



In article <bu68jk$29oc$1 digitaldaemon.com>, yaneurao says...
In article <bu5n0g$1eju$2 digitaldaemon.com>, Walter says...
 but someone might mistake to write
 if ( s.length = 0 ) { .. }
 if ( !s ) { .. }
 if ( s == "" ) { .. }


No. All three are not equivalent in D. first case , he uses '=' for '==' by mistake. second case , s would not be empty but null. eg. char[] s = "ABC"; s.length = 0; if ( !s ) { ... } // s is empty but not null so , 'if ( !s )' is wrong for checking whether s is empty or not. third case , even if s is null , it goes well. eg. char[] s = "ABC"; s.length = 0; if ( s=="" ) { ... } but third case , compiler generates string comparing code. it's slower than: if ( s.length == 0 ) so , 'if ( s.length == 0 )' should be used , I think. but everybody doesn't understand this. that's why I want '.empty' property for char[] or array. yaneurao.

Jan 15 2004
parent reply yaneurao <yaneurao_member pathlink.com> writes:
In article <bu6jnn$2sdc$1 digitaldaemon.com>, The Lone Haranguer says...
So Walter has kindly given you _three_ ways to do the same thing and you still
want _more_ ways?

please read D/21817 three ways are not the same. yaneurao.
Jan 15 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
yaneurao wrote:

 D/21817
 
 three ways are not the same.
 
 yaneurao.

Then WHY THE HELL does this run? int main() { char[] s = "ABC"; s.length = 0; assert(!s); return 0; } -eye
Jan 15 2004
parent reply yaneurao <yaneurao_member pathlink.com> writes:
In article <bu6usn$f8s$2 digitaldaemon.com>, Ilya Minkov says...

Then WHY THE HELL does this run?
int main() {
	char[] s = "ABC";
	s.length = 0;
	assert(!s);
	return 0;
}

I mistook it. try this code. int main() { char[] s = ""; assert(s); assert(s.length == 0); return 0; } s could be null and length == 0 at the same time. yaneurao.
Jan 15 2004
parent reply yaneurao <yaneurao_member pathlink.com> writes:
In article <bu71mq$k8b$1 digitaldaemon.com>, yaneurao says...
int main() {
char[] s = "";
assert(s);
assert(s.length == 0);
return 0;
}
s could be null and length == 0 at the same time.

sorry i mistook to write. s cound be *not* null and length == 0 at the same time. eg. 1) char[] s = ""; 2) char[] s2 = "ABC"; char[] s = s2[0..0]; and so on. my english is very poor , sorry... yaneurao.
Jan 15 2004
parent reply The Lone Haranguer <The_member pathlink.com> writes:
s cound be *not* null and length == 0 at the same time.

.. aaaand your point issss.... ??
Jan 15 2004
next sibling parent reply yaneurao <yaneurao_member pathlink.com> writes:
In article <bu7hri$1gir$1 digitaldaemon.com>, The Lone Haranguer says...
s cound be *not* null and length == 0 at the same time.


at first I thought the emptiness of char[] should be checked by 'if (s.length == 0)' , not ' if (!s)' because I knew the situation s.length == 0 and not null. but Mr.Walter said that 'if (s.length == 0)' is equivalent to 'if (!s)'. if D is designed such , following examples seem to be compiler's bug. eg.1 char[] s = ""; eg.2 char[] s2 = "A"; char[] s1 = s2[0..0]; yaneurao.
Jan 15 2004
parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <bu7l1d$1lk1$1 digitaldaemon.com>, yaneurao says...
but Mr.Walter said that 'if (s.length == 0)' is equivalent to 'if (!s)'.
if D is designed such , following examples seem to be compiler's bug.

Hmm. This made me write a puzzle for everyone interested: <code> char[] w = "kkkkskkskksksk"; so.printf("w='%.*s' w.length=%d\n",w,w.length); // I've removed this line. Figure out what this line was! char[] v = w; so.printf("v='%.*s' v.length=%d\n",v,v.length); </code> <output> w='kkkkskkskksksk' w.length=14 v='kkkkskkskksksk' v.length=55 </output>
Jan 16 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Georg Wrede wrote:

In article <bu7l1d$1lk1$1 digitaldaemon.com>, yaneurao says...
  

but Mr.Walter said that 'if (s.length == 0)' is equivalent to 'if (!s)'.
if D is designed such , following examples seem to be compiler's bug.
    

Hmm. This made me write a puzzle for everyone interested: <code> char[] w = "kkkkskkskksksk"; so.printf("w='%.*s' w.length=%d\n",w,w.length); // I've removed this line. Figure out what this line was!

char[] v = w;
so.printf("v='%.*s' v.length=%d\n",v,v.length);
</code>
<output>
w='kkkkskkskksksk' w.length=14
v='kkkkskkskksksk' v.length=55
</output>
  

Jan 16 2004
parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <bu8pmf$i6a$1 digitaldaemon.com>, J Anderson says...
Georg Wrede wrote:

 Hmm. This made me write a puzzle for everyone interested:


 Can we answer here?  It's really very simple.

Well, I wish nobody would publish the answer for a couple of days. Let people think about this at home during the weekend, and then, on Monday we could have some educated opinions about what the implications of this are! And whether we should change something in D.
Jan 16 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <bu8uhv$q7e$1 digitaldaemon.com>, Georg Wrede says...
In article <bu8pmf$i6a$1 digitaldaemon.com>, J Anderson says...
Georg Wrede wrote:

 Hmm. This made me write a puzzle for everyone interested:


 Can we answer here?  It's really very simple.

Well, I wish nobody would publish the answer for a couple of days. Let people think about this at home during the weekend, and then, on Monday we could have some educated opinions about what the implications of this are!

A couple of days? weekend? think about this at home? With that kind of efford by some people from here we could finish DUI by then! both linux and windows... ;) Ant
Jan 16 2004
parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <bu9071$sro$1 digitaldaemon.com>, Ant says...
Let people think about this at home during the
weekend, and then, on Monday we could have some educated
opinions about what the implications of this are!

A couple of days? weekend? think about this at home? With that kind of efford by some people from here we could finish DUI by then! both linux and windows...

LOL! The solution to the puzzle is obvious, of course. But more time should be used to consider if, and what we might want to cange in D because of this. There are many possibilities (of course starting with not changing anything), and I'd like the discussion to be a bit more profound on Monday.
Jan 16 2004
parent reply The Lone Haranguer <The_member pathlink.com> writes:
In article <bu94ps$1470$1 digitaldaemon.com>, Georg Wrede says...
In article <bu9071$sro$1 digitaldaemon.com>, Ant says...
Let people think about this at home during the
weekend, and then, on Monday we could have some educated
opinions about what the implications of this are!

A couple of days? weekend? think about this at home? With that kind of efford by some people from here we could finish DUI by then! both linux and windows...

LOL! The solution to the puzzle is obvious, of course. But more time should be used to consider if, and what we might want to cange in D because of this. There are many possibilities (of course starting with not changing anything), and I'd like the discussion to be a bit more profound on Monday.

Monday's a holiday, I'll be in Palm Springs sipping margaritas by the pool. There will be no profond discussion from me that day. (As if there ever is.)
Jan 16 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"The Lone Haranguer" <The_member pathlink.com> wrote in message
news:bu9c04$1g2i$1 digitaldaemon.com...
 In article <bu94ps$1470$1 digitaldaemon.com>, Georg Wrede says...
In article <bu9071$sro$1 digitaldaemon.com>, Ant says...
Let people think about this at home during the
weekend, and then, on Monday we could have some educated
opinions about what the implications of this are!

A couple of days? weekend? think about this at home? With that kind of efford by some people from here we could finish DUI by then! both linux and windows...

LOL! The solution to the puzzle is obvious, of course. But more time should be used to consider if, and what we might want to cange in D because of this. There are many possibilities (of course starting with not changing anything), and I'd like the discussion to be a bit more profound on Monday.

Monday's a holiday, I'll be in Palm Springs sipping margaritas by the

 There will be no profond discussion from me that day. (As if there ever

But, if you ingest sufficient margaritas there may be a "profond-ling" discussion, eh? :)
Jan 16 2004
parent reply The Lone Haranguer <The_member pathlink.com> writes:
Hopefully there will be a bit of fondling on Sat and sun nights, yes.

 Monday's a holiday, I'll be in Palm Springs sipping margaritas by the

 There will be no profond discussion from me that day. (As if there ever

But, if you ingest sufficient margaritas there may be a "profond-ling" discussion, eh? :)

Jan 16 2004
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Ok, nobody ever answered this.

"The Lone Haranguer" <The_member pathlink.com> wrote in message
news:bua90q$30ub$1 digitaldaemon.com...
 Hopefully there will be a bit of fondling on Sat and sun nights, yes.

Jan 20 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Sean L. Palmer wrote:

Ok, nobody ever answered this.

"The Lone Haranguer" <The_member pathlink.com> wrote in message
news:bua90q$30ub$1 digitaldaemon.com...
  

Hopefully there will be a bit of fondling on Sat and sun nights, yes.
    


char[] w = "kkkkskkskksksk"; so.printf("w='%.*s' w.length=%d\n",w,w.length); // I've removed this line. Figure out what this line was! w.length = 55; char[] v = w; so.printf("v='%.*s' v.length=%d\n",v,v.length); </code> <output> w='kkkkskkskksksk' w.length=14 v='kkkkskkskksksk' v.length=55 </output>
Jan 21 2004
parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <bulc6l$2opi$1 digitaldaemon.com>, J Anderson says...
Sean L. Palmer wrote:

Ok, nobody ever answered this.

"The Lone Haranguer" <The_member pathlink.com> wrote in message
news:bua90q$30ub$1 digitaldaemon.com...
  

Hopefully there will be a bit of fondling on Sat and sun nights, yes.
    


char[] w = "kkkkskkskksksk"; so.printf("w='%.*s' w.length=%d\n",w,w.length); // I've removed this line. Figure out what this line was! w.length = 55; char[] v = w; so.printf("v='%.*s' v.length=%d\n",v,v.length); </code> <output> w='kkkkskkskksksk' w.length=14 v='kkkkskkskksksk' v.length=55 </output>

Yes, exactly. More in D/22137
Jan 21 2004
parent reply Ant <Ant_member pathlink.com> writes:
someone post a puzzle.

Once on a uni quiz one question was:
How do you measure the height of a building 
with a barometer (the atmosferic thing).
One guy answered:
"drop the thing from the roof
and time it until it smashes on the ground"
he didn't get credit for that answer so he
complain. They allowd him to reanswer the question
and he said:
"tie a string to the thing, hang it from the roof,
measure the string"
and another answer:
"go to the building superviser and say 'look how nice this
thing is, it's your's if you tell me the height of the building'".

That's what I think of these puzzles.

:)

Ant
Jan 21 2004
next sibling parent Georg Wrede <Georg_member pathlink.com> writes:
In article <bum8c2$13dn$1 digitaldaemon.com>, Ant says...
someone post a puzzle.

Once on a uni quiz one question was:
How do you measure the height of a building 
with a barometer (the atmosferic thing).
One guy answered:
"drop the thing from the roof
and time it until it smashes on the ground"
he didn't get credit for that answer so he
complain. They allowd him to reanswer the question
and he said:
"tie a string to the thing, hang it from the roof,
measure the string"
and another answer:
"go to the building superviser and say 'look how nice this
thing is, it's your's if you tell me the height of the building'".

I once went to this job test, where they asked questions of that kind. And you were _supposed_ to come up with as many answers as you could in 2 minutes. It's so wrong: first you spend all your life trying to learn which of the possible answers your parents, your teachers, your bosses, and your spouse wants -- and then these job folks slap you for 'not being creative'. My Dad has the same experience: he was on a job interview, and they said "if it takes 5 guys 30 days to build a boat, how many days would it take 30 guys?" He answered "30 days". The questioner got angry, and asked why. "Well, there's going to be so much talking and twisting about how to make the boat."
Jan 21 2004
prev sibling parent Georg Wrede <Georg_member pathlink.com> writes:
In article <bum8c2$13dn$1 digitaldaemon.com>, Ant says...
someone post a puzzle.

Once on a uni quiz one question was:
How do you measure the height of a building 
with a barometer (the atmosferic thing).
One guy answered:
"drop the thing from the roof
and time it until it smashes on the ground"
he didn't get credit for that answer

Come to think of it, the guy had the right answer, and not the physics teacher. Barometers are so inaccurate they don't show anything for a 10- story building.
Jan 21 2004
prev sibling parent reply "Robert" <no spam.ne.jp> writes:
Walter said there are three ways to check a string is empty.

(1) s.length == 0
(2) s == null
(3) s == ""

But, (2) is wrong in such a case as:

    import std.c.stdio;

    class A {
        private char[] m_str;
        this(char[] str) { m_str = str; }
        char[] sub(int i, int j) {
            return m_str[i..j];
        }
    }

    char[] getSub(A a) {
        int begin, length;
        scanf("%d%d", &begin, &length);
        return a.sub(begin, begin + length);
    }

    int main() {
        A a = new A("foo");
        char[] sub = getSub(a);
        if(sub == null) {
            printf("nothing");
        } else {
            printf("substring: %.*s\n", sub);
        }
        return 0;
    }

In this case, else branch is always performed
(i.e. sub == null is always false),
even if sub is empty string.


OTOH (3) is a stupid way to check empty.
Because it is not effective.
In C, It is as:

    strcnmp(s, "", s_length) == 0

It's waste.
Furthermore, this way cannot be used in case of int[].


So, (1) is the best way to check whether string is empty in D at present.
It is effecient, works always correctly, and can be used for int[].

But, he says that .empty property is better than (1), as STL.
.empty property helps for us *not* to use any *magic numbers* even 0
and we can grasp the meaning easily.
I think so, too.


"The Lone Haranguer" <The_member pathlink.com> wrote in message
news:bu7hri$1gir$1 digitaldaemon.com...
s cound be *not* null and length == 0 at the same time.

.. aaaand your point issss.... ??

Jan 15 2004
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Anyone want to wager on whether

(s == "")

will, in the *next* version of DMD, generate the same code as

A)      (!strcmp(s,""))

or

B)      s.length == 0

?

My money is on B  ;)

Sean

"Robert" <no spam.ne.jp> wrote in message
news:bu7mo8$1orm$1 digitaldaemon.com...
 (3) s == ""

 OTOH (3) is a stupid way to check empty.
 Because it is not effective.
 In C, It is as:

     strcnmp(s, "", s_length) == 0

 It's waste.
 Furthermore, this way cannot be used in case of int[].

But what if we could do this: int[] x; if (x) { ... } or even: if (x == {}) { ... } or if (x == int[]()) { ... } or if (x == int[0]) { ... } hehehe
 So, (1) is the best way to check whether string is empty in D at present.
 It is effecient, works always correctly, and can be used for int[].

 But, he says that .empty property is better than (1), as STL.
 .empty property helps for us *not* to use any *magic numbers* even 0
 and we can grasp the meaning easily.

Good point. Sean
Jan 20 2004
prev sibling next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
yaneurao wrote:

 No. All three are not equivalent in D.
 
 first case , he uses '=' for '==' by mistake.

True. But the compiler would not allow it.
 second case , s would not be empty but null. 

STOP TALKING SHIT!
 eg.
 char[] s = "ABC";
 s.length = 0;
 if ( !s ) { ... } // s is empty but not null

int main() { char[] s = "ABC"; s.length = 0; assert(!s); return 0; } Compiles and runs without failure.
 so , 'if ( !s )' is wrong for checking whether s is empty or not.

Jan 15 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Ilya

Just tone it down a bit, will you?

There's no need to be that aggressive.


"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bu6ur8$f8s$1 digitaldaemon.com...
 yaneurao wrote:

 No. All three are not equivalent in D.

 first case , he uses '=' for '==' by mistake.

True. But the compiler would not allow it.
 second case , s would not be empty but null.

STOP TALKING SHIT!
 eg.
 char[] s = "ABC";
 s.length = 0;
 if ( !s ) { ... } // s is empty but not null

int main() { char[] s = "ABC"; s.length = 0; assert(!s); return 0; } Compiles and runs without failure.
 so , 'if ( !s )' is wrong for checking whether s is empty or not.


Jan 15 2004
prev sibling next sibling parent reply "Robert" <no spam.ne.jp> writes:
He made a mistake then.
Use
    s = "";
instead of
    s.length = 0;
Then AssertError will be thrown.


"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bu6ur8$f8s$1 digitaldaemon.com...
 yaneurao wrote:

 No. All three are not equivalent in D.

 first case , he uses '=' for '==' by mistake.

True. But the compiler would not allow it.
 second case , s would not be empty but null.

STOP TALKING SHIT!
 eg.
 char[] s = "ABC";
 s.length = 0;
 if ( !s ) { ... } // s is empty but not null

int main() { char[] s = "ABC"; s.length = 0; assert(!s); return 0; } Compiles and runs without failure.
 so , 'if ( !s )' is wrong for checking whether s is empty or not.


Jan 15 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Sorry for the insults.

This would be a bug then, i believe.

.length property of an array doesn't set pointer to 0. Or a zero-length 
array should always convert to false when comverted to boolean.

-eye


Robert wrote:
 He made a mistake then.
 Use
     s = "";
 instead of
     s.length = 0;
 Then AssertError will be thrown.
 

Jan 20 2004
parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <bukc2g$1650$1 digitaldaemon.com>, Ilya Minkov says...
.length property of an array doesn't set pointer to 0. Or a zero-length 
array should always convert to false when comverted to boolean.

This is actually what made me post the String Puzzle here on Friday. D/21905 I'm really unhappy about the unobvious semantics of our current "strings" (i.e. char[]). While it is good to have character arrays, I think we should have a separate type for strings. That type would be used for everything where an explicit array of characters is not needed. This would let us equate the null pointer with the empty string. Append (~) null to foo should give foo. Length of cast(string)null should be zero. Nobody should ever be bitten by the natural mistake of taking the length of what he believes to be a string, and find out the value be different than the actual contents of the string. That is, the length property should behave differently than for character arrays, where it returns the allocation length (which most of the time is irrelevant to the string user anyway, and therefore getting the allocation length of a string should, at the most, be an intrinsic function). Changing a string's length by assigning to length should be illegal! There should be a method for it. And that method should only allow making the string shorter! To make a string longer, you can always append spaces to it. Oh yes, and the string shortening method should return a new string! This leads to the following: - string slices should return new strings - char[] slices should return references - strings should be immutable - strings should have value (not reference) semantics - string slice as lvalue should operate on copy - char[] slice as lvalue should operate on the original If we want to keep the implicit string to char* conversion, then probably strings should _both_ have a length property _and_ still internally be represented with a \0 at the end? The cost of this \0 in copying and other operations is negligible. Then we could pass a D string to any C function, just like that. (The \0 at the end should be an implementation thing, and you should not be able to access it (by indexed access or slices or whatever.) Since strings would not anymore be equal to character arrays, this would pave the way for new things. E.g. string slices could be considered to return characters. This is important for i18n. I hope at least some of these thoughts see their way to D.
Jan 20 2004
next sibling parent Juan C. <Juan_member pathlink.com> writes:
Hear hear!

<snip>
While it is good to have character arrays, I think we should have
a separate type for strings. That type would be used for everything
where an explicit array of characters is not needed. 

This would let us equate the null pointer with the empty string.
Append (~) null to foo should give foo. Length of cast(string)null 
should be zero. 

Nobody should ever be bitten by the natural mistake of taking the
length of what he believes to be a string, and find out the value
be different than the actual contents of the string. That is,
the length property should behave differently than for character
arrays, where it returns the allocation length (which most of
the time is irrelevant to the string user anyway, and therefore
getting the allocation length of a string should, at the most, 
be an intrinsic function).

Changing a string's length by assigning to length should be 
illegal! There should be a method for it. And that method should
only allow making the string shorter! To make a string longer,
you can always append spaces to it. Oh yes, and the string
shortening method should return a new string!

Jan 20 2004
prev sibling next sibling parent reply Vathix <vathix dprogramming.com> writes:
Georg Wrede wrote:
 In article <bukc2g$1650$1 digitaldaemon.com>, Ilya Minkov says...
 
.length property of an array doesn't set pointer to 0. Or a zero-length 
array should always convert to false when comverted to boolean.

This is actually what made me post the String Puzzle here on Friday. D/21905 I'm really unhappy about the unobvious semantics of our current "strings" (i.e. char[]). While it is good to have character arrays, I think we should have a separate type for strings. That type would be used for everything where an explicit array of characters is not needed.

I could go either way.
 This would let us equate the null pointer with the empty string.
 Append (~) null to foo should give foo. Length of cast(string)null 
 should be zero. 

Why is a null character so special? it's just another character. It was special in C for a reason, that's how C strings are.
 Nobody should ever be bitten by the natural mistake of taking the
 length of what he believes to be a string, and find out the value
 be different than the actual contents of the string. That is,
 the length property should behave differently than for character
 arrays, where it returns the allocation length (which most of
 the time is irrelevant to the string user anyway, and therefore
 getting the allocation length of a string should, at the most, 
 be an intrinsic function).
 
 Changing a string's length by assigning to length should be 
 illegal! There should be a method for it. And that method should
 only allow making the string shorter! To make a string longer,
 you can always append spaces to it. Oh yes, and the string
 shortening method should return a new string!

I disagree; it's a convenience.
 This leads to the following:
 
 - string slices should return new strings
 - char[] slices should return references
 - strings should be immutable
 - strings should have value (not reference) semantics
 - string slice as lvalue should operate on copy
 - char[] slice as lvalue should operate on the original

Sounds OK. I've wanted to have a "supplied buffer" function for each char[] function, so you can tell it to save the new string in a certain buffer instead of having it create a new one.
 If we want to keep the implicit string to char* conversion, then
 probably strings should _both_ have a length property _and_ still
 internally be represented with a \0 at the end? The cost of this
 \0 in copying and other operations is negligible. Then we could
 pass a D string to any C function, just like that. (The \0 at
 the end should be an implementation thing, and you should not
 be able to access it (by indexed access or slices or whatever.)

For a string type that isn't char[], I'd agree. I'd prefer that it only append the \0 at the time of casting to char*, cast overloads are good for this; I wonder why they aren't in D.
 Since strings would not anymore be equal to character arrays,
 this would pave the way for new things. E.g. string slices could
 be considered to return characters. This is important for i18n.
 
 I hope at least some of these thoughts see their way to D.
 
 

Jan 20 2004
next sibling parent Georg Wrede <Georg_member pathlink.com> writes:
In article <bukk58$1ip1$1 digitaldaemon.com>, Vathix says...
Georg Wrede wrote:

 This would let us equate the null pointer with the empty string.
 Append (~) null to foo should give foo. Length of cast(string)null 
 should be zero. 

Why is a null character so special? it's just another character. It was special in C for a reason, that's how C strings are.

Sorry for ambiguous text. I meant that appending the null pointer should be a null-op. Example: dString foo, bar, baz; foo = bar ~ baz; where baz happens to be unassigned, then foo should just simply get the value of bar. (I didn't mean that foo should be appended a \0.)
Jan 20 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Vathix" <vathix dprogramming.com> wrote in message
news:bukk58$1ip1$1 digitaldaemon.com...
 I'd prefer that it only
 append the \0 at the time of casting to char*, cast overloads are good
 for this; I wonder why they aren't in D.

There are many times in C where char*'s are not necessarilly 0 terminated, it's just a convention. By forcing this issue in D, unexpected strange bugs can crop up when interoperating with C. Unfortunately, when dealing with C APIs, one always needs to carefully check the documentation for it to see how to correctly pass strings. Win32 APIs are certainly NOT consistent about it.
Jun 03 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
I think *all* interaction with any native C APIs should be done through thin
layers
that handle all issues of char[] <-> char*. std.recls.d has examples of these,
although I'd be the first to acknowledge that they may not be perfect.

"Walter" <newshound digitalmars.com> wrote in message
news:c9ole4$1m0s$1 digitaldaemon.com...
 "Vathix" <vathix dprogramming.com> wrote in message
 news:bukk58$1ip1$1 digitaldaemon.com...
 I'd prefer that it only
 append the \0 at the time of casting to char*, cast overloads are good
 for this; I wonder why they aren't in D.

There are many times in C where char*'s are not necessarilly 0 terminated, it's just a convention. By forcing this issue in D, unexpected strange bugs can crop up when interoperating with C. Unfortunately, when dealing with C APIs, one always needs to carefully check the documentation for it to see how to correctly pass strings. Win32 APIs are certainly NOT consistent about it.

Jun 03 2004
prev sibling parent Andy Friesen <andy ikagames.com> writes:
Georg Wrede wrote:
 *snip*

We could just get the hell away from using 0 terminated strings. D doesn't need the 0 terminator, unlike C. -- andy
Jan 20 2004
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Calm down, Ilya!

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bu6ur8$f8s$1 digitaldaemon.com...
 yaneurao wrote:

 No. All three are not equivalent in D.

 first case , he uses '=' for '==' by mistake.

True. But the compiler would not allow it.
 second case , s would not be empty but null.

STOP TALKING SHIT!
 eg.
 char[] s = "ABC";
 s.length = 0;
 if ( !s ) { ... } // s is empty but not null

int main() { char[] s = "ABC"; s.length = 0; assert(!s); return 0; } Compiles and runs without failure.
 so , 'if ( !s )' is wrong for checking whether s is empty or not.


Jan 20 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
Sean L. Palmer wrote:
 Calm down, Ilya!

I'm sorry, I excuse myself. However, walter had already said prior to this discussion that a zero-length array is a null array. This appears to be the D semantics, and if it doesn't work like that, a bug is to be filed instead of explaining how wrong all that Walter says is. -eye
Jan 23 2004
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"yaneurao" <yaneurao_member pathlink.com> wrote in message
news:bu68jk$29oc$1 digitaldaemon.com...
 In article <bu5n0g$1eju$2 digitaldaemon.com>, Walter says...
 but someone might mistake to write
 if ( s.length = 0 ) { .. }
 if ( !s ) { .. }
 if ( s == "" ) { .. }


first case , he uses '=' for '==' by mistake.

I assumed == was meant.
 second case , s would not be empty but null.

 eg.
 char[] s = "ABC";
 s.length = 0;
 if ( !s ) { ... } // s is empty but not null

It's the same thing. It's a compiler bug that it doesn't give the same result.
 so , 'if ( !s )' is wrong for checking whether s is empty or not.

 third case , even if s is null , it goes well.

 eg.
 char[] s = "ABC";
 s.length = 0;
 if ( s=="" ) { ... }

 but third case , compiler generates string comparing code. it's slower

 if ( s.length == 0 )

Slower, but equivalent. A future compiler should optimize this better.
 so , 'if ( s.length == 0 )' should be used , I think.
 but everybody doesn't understand this.
 that's why I want '.empty' property for char[] or array.

I'd rather fix the compiler problems <g>.
Jan 16 2004
parent yaneurao <yaneurao_member pathlink.com> writes:
In article <bu8c3r$2ssk$2 digitaldaemon.com>, Walter says...
 eg.
 char[] s = "ABC";
 s.length = 0;
 if ( !s ) { ... } // s is empty but not null

It's the same thing. It's a compiler bug that it doesn't give the same result.

I see! I wrote some situation about this in this article : D/21871 eg.1 char[] s = ""; // s set to not null though s.length == 0 eg.2 char[] s2 = "A"; char[] s1 = s2[0..0]; // s1 set to not null though s1.length == 0 it seems to be compiler's bug. yaneurao.
Jan 16 2004
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"yaneurao" <yaneurao_member pathlink.com> wrote in message
news:bu68jk$29oc$1 digitaldaemon.com...
 but third case , compiler generates string comparing code. it's slower

 if ( s.length == 0 )

 so , 'if ( s.length == 0 )' should be used , I think.
 but everybody doesn't understand this.
 that's why I want '.empty' property for char[] or array.

In STL, they have container::empty() in order to allow containers that have a bad (linear) time for obtaining size(), can provide a "cheap" test for empty(). You can implement empty() even if you do not go and obtain the size. To see the difference, understand how stdin.empty() would return false immediately unless it's at eof, and stdin.length() would not return until you hit Ctrl-Z on the keyboard or whatever. Yes, D arrays are almost mandated to store the length somewhere easily accessible, but it wouldn't hurt to consider other types of data structures when designing the standard D container interface. In other words, I agree with you. ;) Sean
Jan 20 2004
prev sibling parent reply "Robert" <no spam.ne.jp> writes:
It seems s.length = 0 is equivalent s = null, since

    char[] s = new char[256];
    s.length = 0;
    printf("%d %p\n", s);

outputs 0 00000000.

But, for effectiveness, I sometimes want to allocate memory block in
advance.
For example,

    char[] str = new char[2048];
    str.length = 0;  // It assumes that the pointer is kept.
    str~= "foo";
    ...

It's effective when it is expected that str.length almost always reaches to
near or above 2048.
But at present, it becomes waste because str.length = 0 is equivalent str =
null.



"Walter" <walter digitalmars.com> wrote in message
news:bu5n0g$1eju$2 digitaldaemon.com...
 "yaneurao" <yaneurao_member pathlink.com> wrote in message
 news:bu5gub$13kh$1 digitaldaemon.com...
 but someone might mistake to write
 if ( s.length == 0 ) { .. }
 if ( !s ) { .. }
 if ( s == "" ) { .. }

All three are equivalent in D.

Jan 15 2004
parent reply "Phill" <phill pacific.net.au> writes:
"Robert" <no spam.ne.jp> wrote in message
news:bu7plm$1tfs$1 digitaldaemon.com...
 It seems s.length = 0 is equivalent s = null, since

     char[] s = new char[256];
     s.length = 0;
     printf("%d %p\n", s);

 outputs 0 00000000.

char[] s = new char[256]; shouldnt s.length = 256 ? even if the indexes are empty. makes more sense to me. Phill.
 But, for effectiveness, I sometimes want to allocate memory block in
 advance.
 For example,

     char[] str = new char[2048];
     str.length = 0;  // It assumes that the pointer is kept.
     str~= "foo";
     ...

 It's effective when it is expected that str.length almost always reaches

 near or above 2048.
 But at present, it becomes waste because str.length = 0 is equivalent str

 null.



 "Walter" <walter digitalmars.com> wrote in message
 news:bu5n0g$1eju$2 digitaldaemon.com...
 "yaneurao" <yaneurao_member pathlink.com> wrote in message
 news:bu5gub$13kh$1 digitaldaemon.com...
 but someone might mistake to write
 if ( s.length == 0 ) { .. }
 if ( !s ) { .. }
 if ( s == "" ) { .. }

All three are equivalent in D.


Jan 15 2004
parent "Robert" <no spam.ne.jp> writes:
    char[] s = new char[256];
and
    char[] s;
    s.length = 256;
are almost equivalent.
You can use which you like.

And, indeed
    char[] s;
    s.length = 4;
    printf("[%.*s]", s);
outputs "[]".
However,
    char[] s;
    s.length = 4;
    s ~= "A";
    printf("[%.*s]", s);
outputs "[]", too; i.e. s is "\0\0\0\0A" and s.length == 5.
This is not what I want.
What I want is "A\0\0\0" with s.length == 1.



"Phill" <phill pacific.net.au> wrote in message
news:bu7r5m$20dl$1 digitaldaemon.com...
 "Robert" <no spam.ne.jp> wrote in message
 news:bu7plm$1tfs$1 digitaldaemon.com...
 It seems s.length = 0 is equivalent s = null, since

     char[] s = new char[256];
     s.length = 0;
     printf("%d %p\n", s);

 outputs 0 00000000.

char[] s = new char[256]; shouldnt s.length = 256 ? even if the indexes are empty. makes more sense to me. Phill.
 But, for effectiveness, I sometimes want to allocate memory block in
 advance.
 For example,

     char[] str = new char[2048];
     str.length = 0;  // It assumes that the pointer is kept.
     str~= "foo";
     ...

 It's effective when it is expected that str.length almost always reaches

 near or above 2048.
 But at present, it becomes waste because str.length = 0 is equivalent


 =
 null.



 "Walter" <walter digitalmars.com> wrote in message
 news:bu5n0g$1eju$2 digitaldaemon.com...
 "yaneurao" <yaneurao_member pathlink.com> wrote in message
 news:bu5gub$13kh$1 digitaldaemon.com...
 but someone might mistake to write
 if ( s.length == 0 ) { .. }
 if ( !s ) { .. }
 if ( s == "" ) { .. }

All three are equivalent in D.



Jan 15 2004