yaneurao <yaneurao_member pathlink.com> writes:

I want empty property in char[].


string s;
if ( !s || s.length == 0) { .. }
// or 
if ( !s !! s!=String.Empty) { .. }

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

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

"Ben Hinkle" <bhinkle4 juno.com> writes:

 if ( s.length = 0 ) { .. }


I assume that should be ==

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

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 == "" ) { .. }

All three are equivalent in D.

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.

"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 == "" ) { .. }

All three are equivalent in D.

 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

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.

"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

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.

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

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.

"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


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.

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

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.

"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

boolean,
 one should code as if it were.

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

boolean,
 one should code as if it were.

"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


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

"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,

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


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


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

"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,


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.

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 

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.

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

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.

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 == "" ) { .. }

All three are equivalent in D.

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.

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
http://www.digitalmars.com/drn-bin/wwwnews?D/21817

three ways are not the same.

yaneurao.

Ilya Minkov <minkov cs.tum.edu> writes:

yaneurao wrote:

 http://www.digitalmars.com/drn-bin/wwwnews?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

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.

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.

The Lone Haranguer <The_member pathlink.com> writes:

s cound be *not* null and length == 0 at the same time.

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

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.

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

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.

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>

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!
  

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

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>
  

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.

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

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.

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

"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

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

is.)

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

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

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

is.)

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

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

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.
    


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

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.
    


<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!
  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
http://www.digitalmars.com/drn-bin/wwwnews?D/22137

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

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

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.

"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.... ??

"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

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.

You are a fool man! YOU DIDN'T EVEN CHECK!

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

 You are a fool man! YOU DIDN'T EVEN CHECK!

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

 You are a fool man! YOU DIDN'T EVEN CHECK!

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.
 

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.
http://www.digitalmars.com/drn-bin/wwwnews?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.

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!

</snip>

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.
 http://www.digitalmars.com/drn-bin/wwwnews?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.
 
 

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

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

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

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

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

 You are a fool man! YOU DIDN'T EVEN CHECK!

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

"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 == "" ) { .. }

All three are equivalent in D.

 No. All three are not equivalent in D.

 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

than:
 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>.

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 :
http://www.digitalmars.com/drn-bin/wwwnews?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.

"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

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.

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

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

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

Maybe thats what it prints but after

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

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.

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

 Maybe thats what it prints but after

 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

 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.