On 11/03/2010 04:38 PM, Don wrote:
Most development of Phobos is done with the last released version of
DMD, not the version under development. So you'll almost never see
Phobos using features from the compiler it is released with.
Doesn't that seem a bit sub-optimal to you?
On Friday, November 05, 2010 17:10:57 Jeff Nowakowski wrote:
On 11/03/2010 04:38 PM, Don wrote:
Most development of Phobos is done with the last released version of
DMD, not the version under development. So you'll almost never see
Phobos using features from the compiler it is released
bearophile Wrote:
Plus a nice Microsoft site that allows you to try it in interactive way, this
is very good:
http://www.rise4fun.com/SpecSharp
D can do that too. We had those interactive versions in the newsrgoup. We saw
no value in them.
Spec# adds only few things to C# 2.0:
-
Gary Whatmore:
I know myself when my pointer is null.
You are unusual then:
http://lambda-the-ultimate.org/node/3186
Bye,
bearophile
On 11/05/2010 12:43 PM, Gary Whatmore wrote:
bearophile Wrote:
- A way to list what attributes are modified in a method (similar to my @outer).
The compiler should do this itself.
Doesn't make sense.
My reference issue:
http://d.puremagic.com/issues/show_bug.cgi?id=4571
Walter, please
bearophile Wrote:
Spec# adds only few things to C# 2.0:
- Non-nullable types;
It's hard to tell, whether they fix anything. When you cast nullable to
non-nullable, you get your runtime exception as usual, if you if out access to
nullable (e.g. in delayed method), you get your runtime
Pelle Månsson Wrote:
On 11/05/2010 12:43 PM, Gary Whatmore wrote:
bearophile Wrote:
- A way to list what attributes are modified in a method (similar to my
@outer).
The compiler should do this itself.
Doesn't make sense.
My reference issue:
On 11/05/2010 02:39 PM, Kagamin wrote:
bearophile Wrote:
Spec# adds only few things to C# 2.0:
- Non-nullable types;
It's hard to tell, whether they fix anything. When you cast nullable to
non-nullable, you get your runtime exception as usual, if you if out access to
nullable (e.g. in
bearophile Wrote:
Ellery Newcomer:
hey, cool
stumbled on sing# a while ago and thought it was intriguing, or at least
the fact that ms was using it to write an OS kernel
It contains a ton of new computer science ideas :-) So it's interesting
regardless its applications. (If you
Pelle Månsson Wrote:
On 11/05/2010 02:39 PM, Kagamin wrote:
bearophile Wrote:
Spec# adds only few things to C# 2.0:
- Non-nullable types;
It's hard to tell, whether they fix anything. When you cast nullable to
non-nullable, you get your runtime exception as usual, if you if out
On 11/05/2010 02:48 PM, Gary Whatmore wrote:
Pelle Månsson Wrote:
On 11/05/2010 12:43 PM, Gary Whatmore wrote:
bearophile Wrote:
- A way to list what attributes are modified in a method (similar to my @outer).
The compiler should do this itself.
Doesn't make sense.
My reference issue:
On 2010-11-05 09:51:07 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
FWIW, I got word that nullable types are considered failure in C#'s
design team. They were added in a haste and now the designers regret
that.
But did they refer to nullable pointers or the ability to make
Pelle Månsson Wrote:
Getting the error early is actually a lot better than getting the error
late.
OK, but it doesn't reduce the number of bugs. You had an error with nullables
and you still has error with non-nullables.
On 11/05/2010 03:04 PM, Kagamin wrote:
Pelle Månsson Wrote:
Getting the error early is actually a lot better than getting the error
late.
OK, but it doesn't reduce the number of bugs. You had an error with nullables
and you still has error with non-nullables.
But in the non-nullable
On 11/05/2010 02:56 PM, Gary Whatmore wrote:
Pelle Månsson Wrote:
On 11/05/2010 02:39 PM, Kagamin wrote:
bearophile Wrote:
Spec# adds only few things to C# 2.0:
- Non-nullable types;
It's hard to tell, whether they fix anything. When you cast nullable to
non-nullable, you get your
Pelle Månsson wrote:
On 11/05/2010 03:04 PM, Kagamin wrote:
Pelle Månsson Wrote:
Getting the error early is actually a lot better than getting the error
late.
OK, but it doesn't reduce the number of bugs. You had an error with
nullables and you still has error with non-nullables.
But in
Am 05.11.2010 15:27, schrieb Don:
Pelle Månsson wrote:
On 11/05/2010 03:04 PM, Kagamin wrote:
Pelle Månsson Wrote:
Getting the error early is actually a lot better than getting the error
late.
OK, but it doesn't reduce the number of bugs. You had an error with
nullables and you still
On Thu, 04 Nov 2010 21:52:04 +0100
Tomek Sowiński j...@ask.me wrote:
Good idea. I must say it was fun writing scripts in D. They could use
community sandblasting before publishing.
This list is a great source of D idioms for newcomers. Thank you very much
(I'll keep it for reference.)
On Fri, 05 Nov 2010 09:48:50 -0400
Gary Whatmore n...@spam.sp wrote:
Pelle Månsson Wrote:
How, exactly, do you know when your references are null? Without
runtime checks, of course.
Good code design makes the null pointer exceptions go away. I carefully
ponder what code goes where.
On Thu, 04 Nov 2010 17:13:12 -0400
bearophile bearophileh...@lycos.com wrote:
Thank you for your work. Even if such little programs look simple and
obvious, they aren't for a D newbie. I may even suggest to put them in the D
examples or in the D wiki, etc
+++
Denis
-- -- -- -- -- -- --
Gary Whatmore wrote:
bearophile Wrote:
Plus a nice Microsoft site that allows you to try it in interactive way, this
is very good:
http://www.rise4fun.com/SpecSharp
D can do that too. We had those interactive versions in the newsrgoup. We saw
no value in them.
Here it is:
bearophile wrote:
Gary Whatmore:
I know myself when my pointer is null.
You are unusual then:
http://lambda-the-ultimate.org/node/3186
The $10 billion mistake was C's conversion of arrays to pointers when passing to
a function.
Walter Bright Wrote:
Gary Whatmore wrote:
bearophile Wrote:
Plus a nice Microsoft site that allows you to try it in interactive way,
this is very good:
http://www.rise4fun.com/SpecSharp
D can do that too. We had those interactive versions in the newsrgoup. We
saw no value in
Walter Bright:
The $10 billion mistake was C's conversion of arrays to pointers when passing
to
a function.
http://www.drdobbs.com/blog/archives/2009/12/cs_biggest_mist.html
Sadly, there's an ongoing failure to recognize this, as it is never addressed
in
any of the revisions to the
Walter:
Here it is:
http://codepad.org/
It's been around a while, and nobody cares. Such a capability is marketing
puffery, and not useful.
There are two sites that allow to compile D code online: codepad (D1) and
ideone (D2).
Even if ideone site is just marketing puffery for D,
Walter Bright:
Checked exceptions are one of those ideas that look great on paper but are an
utter failure in practice. As Bruce Eckel pointed out, they are *worse* than
useless and *cause* bugs to be inserted into the code.
(Just to avoid possible misunderstandings: I have never suggested
On 11/5/10 10:36 AM, bearophile wrote:
What I have suggested in another post is not to put a online demo window in the
D site, but to just add a *link* to ideone and codepad in the D home page, so
people may try D online.
When I started the redesign of the D site, one of my first ideas was
David Gileadi:
Later I decided that this might not have as much value as I thought,
since many of the snippets depended on command-line arguments and I
didn't see a way to provide them.
ideone allows you to give command line arguments/input too to D programs (but
you can't change
Gary Whatmore:
Are you saying that Walter Bright or anyone else here isn't as productive as
you are because we haven't read about the latest language research done
between 1980 and 2010?
I have found that I need to play with some new (*) CS ideas new and then, if
I want to keep my mind
What determines whether the function name or just the address will be printed
out when a stack trace is printed on Linux? I'm trying to debug an error and
all I'm getting is hex addresses. I have no idea why. With other programs I
get full function names.
dsimcha schrieb:
What determines whether the function name or just the address will be printed
out when a stack trace is printed on Linux? I'm trying to debug an error and
all I'm getting is hex addresses. I have no idea why. With other programs I
get full function names.
I'm not sure, but
@disable provides the ability to prevent a function from being called at
compile time. Due to inheritance and the ability to assign references to base
class objects, it is possible to execute code that has been disabled.
class A {
void hello() {
}
}
class B : A {
@disable override void
Daniel Gibson Wrote:
dsimcha schrieb:
What determines whether the function name or just the address will be
printed
out when a stack trace is printed on Linux? I'm trying to debug an error
and
all I'm getting is hex addresses. I have no idea why. With other programs
I
get
Walter Bright schrieb:
bearophile wrote:
Walter Bright:
The $10 billion mistake was C's conversion of arrays to pointers when
passing to a function.
http://www.drdobbs.com/blog/archives/2009/12/cs_biggest_mist.html
Sadly, there's an ongoing failure to recognize this, as it is never
On 11/05/2010 01:39 PM, Walter Bright wrote:
It's infinitely worse. Null pointers do not result in memory corruption,
buffer overflows, and security breaches.
Not true. Null pointer dereference exploits are difficult, but very real.
bearophile wrote:
Walter Bright:
Checked exceptions are one of those ideas that look great on paper but are
an utter failure in practice. As Bruce Eckel pointed out, they are *worse*
than useless and *cause* bugs to be inserted into the code.
(Just to avoid possible misunderstandings: I have
Gary Whatmore wrote:
Pelle M�nsson Wrote:
On 11/05/2010 12:43 PM, Gary Whatmore wrote:
bearophile Wrote:
- A way to list what attributes are modified in a method (similar to my
@outer).
The compiler should do this itself.
Doesn't make sense.
My reference issue:
bearophile wrote:
If you take a look at the Go site you see a way to try code:
http://golang.org/
Yes, I know about that site and the accolades heaped on Go for having it.
Meanwhile, codepad has had it for years, and comeaucomputing has had it for at
least 20 years now (for Comeau C++), and
Fri, 05 Nov 2010 13:36:18 -0400, bearophile wrote:
Walter:
http://codepad.org/
It's been around a while, and nobody cares. Such a capability is
marketing puffery, and not useful.
If you go take a visit to the IRC #D channel you see an tool based on
codepad that allows to try snippets of
dsimcha wrote:
What determines whether the function name or just the address will be printed
out when a stack trace is printed on Linux? I'm trying to debug an error and
all I'm getting is hex addresses. I have no idea why. With other programs I
get full function names.
IIRC with
Fri, 05 Nov 2010 13:40:59 -0400, bearophile wrote:
Walter Bright:
The $10 billion mistake was C's conversion of arrays to pointers when
passing to a function.
http://www.drdobbs.com/blog/archives/2009/12/cs_biggest_mist.html
Sadly, there's an ongoing failure to recognize this, as it is
Ellery Newcomer wrote:
On 11/05/2010 01:39 PM, Walter Bright wrote:
It's infinitely worse. Null pointers do not result in memory corruption,
buffer overflows, and security breaches.
Not true. Null pointer dereference exploits are difficult, but very real.
Is that like worrying that an
Daniel Gibson wrote:
Walter Bright schrieb:
It's infinitely worse. Null pointers do not result in memory
corruption, buffer overflows, and security breaches.
Not entirely true: Null Pointer dereferences *have* been used for
security breaches, see for example:
Denis Koroskin:
Is anyone FORCING you to use non-nullable references?
What's the big deal?
If non-nullables are introduced in D3, then Phobos will start to use them. So
probably you can't avoid using some of them.
Bye,
bearophile
Kagamin:
It's hard to tell, whether they fix anything. When you cast nullable to
non-nullable, you get your runtime exception as usual, if you if out access
to nullable (e.g. in delayed method), you get your runtime exception again or
rather logical bug.
I think you are missing about half
Walter Bright Wrote:
I think you misunderstand why checked exceptions are such a bad idea. It's
not
just that they are inconvenient and annoying. They decrease security by
*hiding*
bugs. That is the opposite of what you'd want in a high security language.
Not only is swallowing the
bearophile wrote:
I think you are missing about half of the ideas tied to this nonnullable
discussion. I suggest you to read the linked article about Spec#.
The current version of the Spec# program verifier does not check for arithmetic
overflow.
Oh well!
Fri, 05 Nov 2010 09:53:50 -0400, Gary Whatmore wrote:
bearophile Wrote:
Ellery Newcomer:
hey, cool
stumbled on sing# a while ago and thought it was intriguing, or at
least the fact that ms was using it to write an OS kernel
It contains a ton of new computer science ideas :-) So
On 11/05/2010 02:24 PM, Walter Bright wrote:
Ellery Newcomer wrote:
On 11/05/2010 01:39 PM, Walter Bright wrote:
It's infinitely worse. Null pointers do not result in memory corruption,
buffer overflows, and security breaches.
Not true. Null pointer dereference exploits are difficult, but
Walter Bright:
The current version of the Spec# program verifier does not check for
arithmetic
overflow.
Oh well!
Spec# comes from C# that I think has arithmetic overflows at runtime. So I
think Spec# has runtime overflows. What that note about Spec# says is that
Spec# is not yet able
bearophile wrote:
Walter, instead of poking and teasing me as a ten year old does, why we don't
start talking about serious things? Like, for example if we want nonnull
references/pointers in D3. If you aren't interested in this feature we can
stop wasting my time. It's not a necessary feature,
Walter Bright:
I've explained my position and rationale on null many, many times here.
You are right. And sorry for losing my temper a little :-)
Thank you for your answer.
Bye,
bearophile
bearophile wrote:
Anyway, the topic of this whole tread is about non-nullable types in D,
I read your first post as arguing that Spec# in general was a language well
designed for security - Spec# looks very well designed and thought out
copying from the very good implementation of Spec#
Walter:
I read your first post as arguing that Spec# in general was a language well
designed for security - Spec# looks very well designed and thought out
From that tutorial is looks well though-out, in general (but it's not complete
yet). I suggest to take a look at how Spec# implements
bearophile wrote:
From that tutorial is looks well though-out, in general (but it's not
complete yet). I suggest to take a look at how Spec# implements design by
contract (ignoring the fact it enforces those contracts statically), because
this may give good insights about how to improve D DbC.
On Fri, 05 Nov 2010 23:44:58 +0300, Walter Bright
newshou...@digitalmars.com wrote:
To eliminate null pointers is the same as shooting the canary in your
coal mine because its twitter annoys you.
I'm tired of pointing out that NO ONE is talking about eliminating null
pointers, but rather
On Fri, Nov 5, 2010 at 4:31 PM, Denis Koroskin 2kor...@gmail.com wrote:
On Fri, 05 Nov 2010 23:44:58 +0300, Walter Bright
newshou...@digitalmars.com wrote:
To eliminate null pointers is the same as shooting the canary in your coal
mine because its twitter annoys you.
I'm tired of
On 11/5/10 4:31 PM, Denis Koroskin wrote:
On Fri, 05 Nov 2010 23:44:58 +0300, Walter Bright
newshou...@digitalmars.com wrote:
To eliminate null pointers is the same as shooting the canary in your
coal mine because its twitter annoys you.
I'm tired of pointing out that NO ONE is talking about
Walter Bright:
From what I recall of Eiffel, a considerably older language (1985), Spec#'s
DbC
design is almost a direct copy.
I am not expert about Eiffel, but I have read several documents about Spec#, I
have written about thirty little/snippets programs in it, and from what I've
seen,
Daniel Gibson, el 5 de noviembre a las 19:52 me escribiste:
Walter Bright schrieb:
bearophile wrote:
Walter Bright:
The $10 billion mistake was C's conversion of arrays to pointers when
passing to a function.
http://www.drdobbs.com/blog/archives/2009/12/cs_biggest_mist.html
Sadly,
On 11/5/10 4:12 PM, Leandro Lucarella wrote:
Daniel Gibson, el 5 de noviembre a las 19:52 me escribiste:
Walter Bright schrieb:
bearophile wrote:
Walter Bright:
The $10 billion mistake was C's conversion of arrays to pointers when
passing to a function.
Leandro Lucarella Wrote:
And then, you can corrupt memory with something like:
struct S {
int[1_000_000_000] data;
int far_data;
}
S* s = null;
s.far_data = 5;
If you are unlucky enough to end up in a valid address. That might not
be a practical example, of course, but
Denis Koroskin:
I'm tired of pointing out that NO ONE is talking about eliminating null
pointers, but rather extending an existing type system to support
non-nulls. Your hate towards non-nullables comes from misunderstanding of
the concept.
The nullables/nonnullables topic is not basic
Andrei Alexandrescu wrote:
The language may limit the static size of object. That's what Java does
- it limits the size of any class to 64KB, and then every VM
implementation guarantees that the first 64KB are made verboten one way
or another.
I've meant to do that in D, but haven't gotten
Denis Koroskin wrote:
On Fri, 05 Nov 2010 23:44:58 +0300, Walter Bright
newshou...@digitalmars.com wrote:
To eliminate null pointers is the same as shooting the canary in your
coal mine because its twitter annoys you.
I'm tired of pointing out that NO ONE is talking about eliminating null
On 2010-11-05 19:27:03 -0400, Walter Bright newshou...@digitalmars.com said:
Andrei Alexandrescu wrote:
The language may limit the static size of object. That's what Java does
- it limits the size of any class to 64KB, and then every VM
implementation guarantees that the first 64KB are made
On 11/05/2010 08:30 PM, bearophile wrote:
Denis Koroskin:
Is anyone FORCING you to use non-nullable references?
What's the big deal?
If non-nullables are introduced in D3, then Phobos will start to use them. So
probably you can't avoid using some of them.
Bye,
bearophile
If we're still
Michel Fortin wrote:
On 2010-11-05 19:27:03 -0400, Walter Bright newshou...@digitalmars.com
said:
Andrei Alexandrescu wrote:
The language may limit the static size of object. That's what Java
does - it limits the size of any class to 64KB, and then every VM
implementation guarantees that
A non-nullable type is basically just:
struct NotNull(T) {
T _payload;
alias _payload this;
invariant() {
assert(_payload !is null);
}
}
If we could disable the default constructor, this approach might just work.
Sure,
the checks here would be at runtime, but you'd have them
On 11/5/2010 10:27 AM, Don wrote:
Pelle Månsson wrote:
On 11/05/2010 03:04 PM, Kagamin wrote:
Pelle Månsson Wrote:
Getting the error early is actually a lot better than getting the error
late.
OK, but it doesn't reduce the number of bugs. You had an error with
nullables and you still has
Walter Bright wrote:
Denis Koroskin wrote:
On Fri, 05 Nov 2010 23:44:58 +0300, Walter Bright
newshou...@digitalmars.com wrote:
To eliminate null pointers is the same as shooting the canary in your
coal mine because its twitter annoys you.
I'm tired of pointing out that NO ONE is talking
On Friday, November 05, 2010 16:41:25 Walter Bright wrote:
Denis Koroskin wrote:
On Fri, 05 Nov 2010 23:44:58 +0300, Walter Bright
newshou...@digitalmars.com wrote:
To eliminate null pointers is the same as shooting the canary in your
coal mine because its twitter annoys you.
I'm
Jesse Phillips jessekphillip...@gmail.com wrote:
Should the compiler not compile the class saying something to the effect
of:
Can not disable method hello in base class A from B.
I think this is the best solution.
Cannot @disable overriding functions, I'd say.
--
Simen
Adam D. Ruppe wrote:
A non-nullable type is basically just:
struct NotNull(T) {
T _payload;
alias _payload this;
invariant() {
assert(_payload !is null);
}
}
If we could disable the default constructor, this approach might just work.
Sure,
the checks here would be at
On 11/5/10 6:27 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
The language may limit the static size of object. That's what Java
does - it limits the size of any class to 64KB, and then every VM
implementation guarantees that the first 64KB are made verboten one
way or another.
I've
On 2010-11-05 20:04:11 -0400, Walter Bright newshou...@digitalmars.com said:
Michel Fortin wrote:
On 32-bit OS X, that limit is 4 KB.
That's good to know.
Well, you should already know. I posted this on the Phobos mailing list
in August and you posted a reply. :-)
And what happens if I
On 11/5/10 6:54 PM, Michel Fortin wrote:
On 2010-11-05 19:27:03 -0400, Walter Bright newshou...@digitalmars.com
said:
Andrei Alexandrescu wrote:
The language may limit the static size of object. That's what Java
does - it limits the size of any class to 64KB, and then every VM
implementation
All that does is reinvent the null pointer seg fault.
The hardware does this for you for free.
The difference is that the hardware tells you when you use it,
whereas the assert tells you when you try to save it.
Let me give you an example from my real world code. I have an xml dom class
that
Walter Bright newshou...@digitalmars.com wrote:
Adam D. Ruppe wrote:
A non-nullable type is basically just:
struct NotNull(T) {
T _payload;
alias _payload this;
invariant() {
assert(_payload !is null);
}
}
If we could disable the default constructor, this approach might
On Sat, 06 Nov 2010 02:41:25 +0300, Walter Bright
newshou...@digitalmars.com wrote:
Denis Koroskin wrote:
On Fri, 05 Nov 2010 23:44:58 +0300, Walter Bright
newshou...@digitalmars.com wrote:
To eliminate null pointers is the same as shooting the canary in your
coal mine because its
On 11/5/2010 8:51 PM, Adam D. Ruppe wrote:
All that does is reinvent the null pointer seg fault.
The hardware does this for you for free.
The difference is that the hardware tells you when you use it,
whereas the assert tells you when you try to save it.
Let me give you an example from my
Pure functions are allowed to read immutable global variables.
Currently, this even includes globals which are initialized from inside
'static this()'.
Here's an example of how this can be a problem:
immutable int unstable;
pure int buggy() { return unstable; }
static this() {
// fails
Denis Koroskin wrote:
On Fri, 05 Nov 2010 23:44:58 +0300, Walter Bright
newshou...@digitalmars.com wrote:
To eliminate null pointers is the same as shooting the canary in your
coal mine because its twitter annoys you.
I'm tired of pointing out that NO ONE is talking about eliminating null
On Friday 05 November 2010 18:32:47 Don wrote:
Pure functions are allowed to read immutable global variables.
Currently, this even includes globals which are initialized from inside
'static this()'.
Here's an example of how this can be a problem:
immutable int unstable;
pure int buggy()
Michel Fortin wrote:
On 2010-11-05 20:04:11 -0400, Walter Bright newshou...@digitalmars.com
said:
Michel Fortin wrote:
On 32-bit OS X, that limit is 4 KB.
That's good to know.
Well, you should already know. I posted this on the Phobos mailing list
in August and you posted a reply. :-)
On Fri, 05 Nov 2010 16:41:25 -0700
Walter Bright newshou...@digitalmars.com wrote:
Consider non-nullable type T:
T[] a = new T[4];
... time goes by ...
T[1] = foo;
T[3] = bar;
... more time goes by ...
bar(T[2]);
In other words, I create an array that I mean to fill
On Sat, 6 Nov 2010 05:01:26 +0100
spir denis.s...@gmail.com wrote:
Just wanted to add 2 notes.
In general, for a non-nullable type, how would I mark an instance as not
having
meaningful data?
For example, an int is a non-nullable type. But there's no int value that
means
no
I'm proposing a possible new module for phobos which would be called
std.unittests. The code and DDoc file can be found here: http://is.gd/gLH9Q
Or you can look at the code here directly (though it has poor highlighting):
http://ideone.com/EOlod
The module contains a set of helper functions
Walter Bright:
Yeah, well, my brain is full. In order to learn new facts, I must discard an
equivalent number of existing ones. I've had to discard everything I ever
learned about chemistry, for example.
As a human brain gets older, its ability to quickly retain new information
decreases.
On Fri, 05 Nov 2010 16:41:25 -0700
Walter Bright newshou...@digitalmars.com wrote:
In general, for a non-nullable type, how would I mark an instance as not
having
meaningful data?
For example, an int is a non-nullable type. But there's no int value that
means
no meaningful value, and
On 2010-11-05 23:27:28 -0400, Walter Bright newshou...@digitalmars.com said:
Michel Fortin wrote:
There's nothing out of the array's bounds in this case. Here's what I meant:
byte[66000]* arrayPtr = null;
byte b = (*arrayPtr)[66000-1];
I'm in the array's bounds here, the problem is
On 11/5/2010 17:41, Walter Bright wrote:
In other words, I create an array that I mean to fill in later, because
I don't have meaningful data for it in advance.
That's a faulty idiom. A data structure that exists but contains no
valid data is a bug waiting to happen - no, it /is/ a bug, even
Thank you for this post Walter, because here you actually discuss with me/us
about the topic (regardless what the final decisions will be).
Non-null types aren't a fully tidy and simple idea, they have some complexities
and special situations. And probably some problems need to be improved
Rainer Deyke Wrote:
That's a faulty idiom. A data structure that exists but contains no
valid data is a bug waiting to happen - no, it /is/ a bug, even if it
does not yet manifest as incorrect observable behavior. (Or at best,
it's an unsafe optimization technique that should be wrapped up
Thanks Lars. Makes sense. I included redundant questions to make sure you're
not a bot. :)
On 11/6/2010 2:10 AM, Dmitry Olshansky wrote:
On 05.11.2010 18:25, Tyro[a.c.edwards] wrote:
On 11/5/2010 10:51 PM, Kagamin wrote:
Tyro[a.c.edwards] Wrote:
Hello,
What is the proper way to read a directory such that file names are not
garbled? Here is the example I borrowed form the std.file
http://d.puremagic.com/issues/show_bug.cgi?id=5149
John Mandeville jema...@earthlink.net changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=2464
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=4329
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||jmin...@gmail.com
---
http://d.puremagic.com/issues/show_bug.cgi?id=3832
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Status|NEW |RESOLVED
1 - 100 of 124 matches
Mail list logo
