We can crack or emulate any protection type: Dongle,
Hardlock, Hasp, Serial, Password, Hasp4, Flexlm, Sentinel,
Wibu, Eutron Smartkey, Hasphl, Proteq, All the Protections!!
email = yshows...@???
email = yshowsoft at gmail.com
ecm2001 titanium download
ecm2001 titanium rapidshare
titanium
Andrei Alexandrescu schrieb:
...(such as length in array index expressions) ...
finally yay!
Andrei Alexandrescu
Link?
If you do a search with Google with:
switch bug missing break
Or:
switch bug fall through
Or:
switch most common programming bugs
You will see a ton of pages.
Wikipedia says this is a common bug:
http://en.wikipedia.org/wiki/Switch_statement
A bug in Python:
On Sun, 15 Nov 2009 15:53:08 -0500, BLS windev...@hotmail.de wrote:
==
Now : Sorry for my ignorance ... but Why the heck :
struct RBNode(V)
instead of :
struct RBNode(K, V)
It was my way of providing the exact same implementation for TreeMap,
TreeSet, and TreeMultiSet (same deal
Walter Bright, el 15 de noviembre a las 12:13 me escribiste:
Don wrote:
And looking at how rarely it's actually used by someone who thinks
he uses it a lot, convinces me that intentional use of
fall-through is much less common than bugs introduced by leaving
out a break statement.
Except
On 16/11/2009 00:16, Steven Schveighoffer wrote:
On Sun, 15 Nov 2009 15:53:08 -0500, BLS windev...@hotmail.de wrote:
==
Now : Sorry for my ignorance ... but Why the heck :
struct RBNode(V)
instead of :
struct RBNode(K, V)
It was my way of providing the exact same implementation for
bearophile wrote:
A bug in Python:
http://bugs.python.org/issue4772
That is the only one I checked, and it was not a case fall-through bug.
It was failure to provide a default.
Bartosz Milewski wrote:
I read Andrei's chapter on arrays and there's one thing that concerns me. When
a slice is extended, the decision to re-allocate, and therefore to cut its
connection to other slices, is non-deterministic. How does that influence
program testing and can it be exploited
Walter Bright wrote:
Don wrote:
I think the GNU stuff is a bit different, because the GPL is an
aggressive license -- the FSF intends to defend the license, taking
offenders to court. Legal battles are expected, and having a single
legal entity makes it easier to win the case.
By contrast,
Walter Bright newshou...@digitalmars.com wrote in message
news:hdqea8$2mt...@digitalmars.com...
Bartosz Milewski wrote:
I read Andrei's chapter on arrays and there's one thing that concerns
me. When a slice is extended, the decision to re-allocate, and
therefore to cut its connection to other
Don wrote:
I think the GNU stuff is a bit different, because the GPL is an
aggressive license -- the FSF intends to defend the license, taking
offenders to court. Legal battles are expected, and having a single
legal entity makes it easier to win the case.
By contrast, the Boost license exists
Bartosz Milewski wrote:
I read Andrei's chapter on arrays and there's one thing that concerns
me. When a slice is extended, the decision to re-allocate, and
therefore to cut its connection to other slices, is
non-deterministic.
It is not non-deterministic. Try it - you'll get the same results
Walter Bright, el 15 de noviembre a las 18:27 me escribiste:
Don wrote:
I think the GNU stuff is a bit different, because the GPL is an
aggressive license -- the FSF intends to defend the license,
taking offenders to court. Legal battles are expected, and having
a single legal entity makes it
Walter Bright, el 15 de noviembre a las 18:10 me escribiste:
Ellery Newcomer wrote:
Just did a quick scan of phobos1. Found 5 instances of fallthrough, not
including one around line 182, format.d
case Mangle.Tdchar:
ti = typeid(dchar);
default:
ti = null;
I have a
On 2009-11-15 16:03:39 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
Walter Bright wrote:
Don wrote:
And looking at how rarely it's actually used by someone who thinks he
uses it a lot, convinces me that intentional use of fall-through is
much less common than bugs
Nick Sabalausky wrote:
Deterministic? Only in the same sense that resize or realloc upon
appending is deterministic.
It's deterministic in the sense that if you run the program again with
the same inputs, you will get the same result. This is a highly useful
attribute for testing and
Tim Matthews, el 16 de noviembre a las 15:05 me escribiste:
Isn't the new kind of arrays created to fix this already? See T[new].
T[new] is gone.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG
I read Andrei's chapter on arrays and there's one thing that concerns me. When
a slice is extended, the decision to re-allocate, and therefore to cut its
connection to other slices, is non-deterministic. How does that influence
program testing and can it be exploited to attack a buggy system?
On Mon, 16 Nov 2009 02:16:09 +0300, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sun, 15 Nov 2009 15:53:08 -0500, BLS windev...@hotmail.de wrote:
==
Now : Sorry for my ignorance ... but Why the heck :
struct RBNode(V)
instead of :
struct RBNode(K, V)
It was my way of providing
On Mon, 16 Nov 2009 09:24:13 +0300, Walter Bright
newshou...@digitalmars.com wrote:
Nick Sabalausky wrote:
Deterministic? Only in the same sense that resize or realloc upon
appending is deterministic.
It's deterministic in the sense that if you run the program again with
the same
Denis Koroskin wrote:
It is *non*-deterministic. The decision to reallocate depends (or will
depend) on LRU and it may be cleared by another thread (e.g. another
thread may reset it manually or via a GC cycle run).
The LRU is thread local.
Walter Bright wrote:
Safe? Fuck no.
It's safe as in memory safe. This is as opposed to undefined-behavior,
which is not memory safe. A buffer overflow is an example of
undefined-behavior.
Even if it's memory safe, it could cause a bug. Look at Bartosz example
again; if the memory block
Walter Bright:
That is the only one I checked, and it was not a case fall-through bug.
It was failure to provide a default.
Sorry...
Most of those bugs seem about the missing break, but indeed it seems that the
missing default is an even more common bug, that's why I have said It's not
the
On Sun, Nov 15, 2009 at 1:16 PM, Chad J
chadj...@__spam.is.bad__gmail.com wrote:
Walter Bright wrote:
Don wrote:
And looking at how rarely it's actually used by someone who thinks he
uses it a lot, convinces me that intentional use of fall-through is
much less common than bugs introduced by
On Sun, Nov 15, 2009 at 1:03 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Walter Bright wrote:
Don wrote:
And looking at how rarely it's actually used by someone who thinks he
uses it a lot, convinces me that intentional use of fall-through is much
less common than bugs
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
Chad J wrote:
So, switch-case statements are a frequent source of nasty bugs. Fixing
them (well) requires breaking backwards compatibility.
Any chance this will happen for D2?
(This is intended as more of a reminder and
grauzone wrote:
Even if it's memory safe, it could cause a bug. Look at Bartosz example
again; if the memory block gets copied really depends from the input
data length.
Yes, it could cause a bug. But it isn't undefined-behavior, it isn't
memory corruption, and it isn't non-deterministic.
Walter Bright wrote:
Ellery Newcomer wrote:
Just did a quick scan of phobos1. Found 5 instances of fallthrough, not
including one around line 182, format.d
case Mangle.Tdchar:
ti = typeid(dchar);
default:
ti = null;
I have a hard time believing that was intentional,
I'd like to raise 2 issues for a discussion.
First, Phobos makes calls to different functions, based on the OS we are
running on (e.g. CreateFileA vs. CreateFileW) and I wonder if it's
*really* necessary, since Microsoft has a Unicode Layer for those
Operating Systems.
All an application
Bartosz Milewski Wrote:
I read Andrei's chapter on arrays and there's one thing that concerns me.
I tried to voice the same concern earlier, but my voice is not loud yet. ;)
When a slice is extended, the decision to re-allocate, and therefore to cut
its connection to other slices, is
Denis Koroskin wrote:
I'd like to raise 2 issues for a discussion.
First, Phobos makes calls to different functions, based on the OS we are
running on (e.g. CreateFileA vs. CreateFileW) and I wonder if it's
*really* necessary, since Microsoft has a Unicode Layer for those
Operating Systems.
Walter Bright wrote:
It's deterministic in the sense that if you run the program again with
the same inputs, you will get the same result. This is a highly useful
attribute for testing and debugging.
On the same platform, with the same compiler, compiler settings, and
standard library
On 11/16/2009 02:49 AM, Chad J wrote:
So, switch-case statements are a frequent source of nasty bugs. Fixing
them (well) requires breaking backwards compatibility.
Any chance this will happen for D2?
If I remember correctly, one of D's design policies is
that a D code that looks like C code
On Mon, 16 Nov 2009 11:56:24 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Denis Koroskin wrote:
I'd like to raise 2 issues for a discussion.
First, Phobos makes calls to different functions, based on the OS we
are running on (e.g. CreateFileA vs. CreateFileW) and I
Ali Cehreli wrote:
Bartosz Milewski Wrote:
I read Andrei's chapter on arrays and there's one thing that concerns me.
I tried to voice the same concern earlier, but my voice is not loud yet. ;)
When a slice is extended, the decision to re-allocate, and therefore to cut
its connection to
On Mon, 16 Nov 2009 11:56:24 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Denis Koroskin wrote:
I'd like to raise 2 issues for a discussion.
First, Phobos makes calls to different functions, based on the OS we
are running on (e.g. CreateFileA vs. CreateFileW) and I wonder
On Mon, 16 Nov 2009 11:58:44 +0300, MIURA Masahiro echocham...@gmail.com
wrote:
On 11/16/2009 02:49 AM, Chad J wrote:
So, switch-case statements are a frequent source of nasty bugs. Fixing
them (well) requires breaking backwards compatibility.
Any chance this will happen for D2?
If I
C standard library alloca function has an undefined behavior when
requested size is large enough to cause a stack overflow, but many (good)
implementations return null instead. So does DMD, for example. I believe
it would be even better to go ahead and enforce D implementation to return
a
Denis Koroskin wrote:
I'd like to raise 2 issues for a discussion.
First, Phobos makes calls to different functions, based on the OS we are
running on (e.g. CreateFileA vs. CreateFileW) and I wonder if it's
*really* necessary, since Microsoft has a Unicode Layer for those
Operating Systems.
Rainer Deyke wrote:
Walter Bright wrote:
It's deterministic in the sense that if you run the program again with
the same inputs, you will get the same result. This is a highly useful
attribute for testing and debugging.
On the same platform, with the same compiler, compiler settings, and
On 11/16/2009 06:16 PM, Denis Koroskin wrote:
If I remember correctly, one of D's design policies is
that a D code that looks like C code should behave like C.
Are we giving up that policy?
Correction: either behave like C, or raise a compile-time error.
Yes. I should have written a valid D
Tim Matthews wrote:
AJ wrote:
Is D about to go commercial?
D is not intended as a scam for someones profit
Oh? Is it the current direction. Oh, yeah, bill gates is stupid (I think
so).
I hate being smart.
Andrei Alexandrescu wrote:
I was hoping the lesson learned would be to fix switch as was suggested.
I checked, because it wasn't written in the way I usually write things,
and sure enough it wasn't code I wrote :-)
From the changelog for D 0.129: Incorporated Ben Hinkle's new
std.format
On Mon, 16 Nov 2009 12:48:09 +0300, MIURA Masahiro echocham...@gmail.com
wrote:
On 11/16/2009 06:16 PM, Denis Koroskin wrote:
If I remember correctly, one of D's design policies is
that a D code that looks like C code should behave like C.
Are we giving up that policy?
Correction: either
Leandro Lucarella wrote:
Walter Bright, el 12 de noviembre a las 19:35 me escribiste:
Andrei Alexandrescu wrote:
I think this is an environment issue. I like Eclipse's approach.
Java unnecessary imports are underlined with a wavy red line.
I agree. I would find it very annoying to have to
On Nov 16, 09 17:48, MIURA Masahiro wrote:
On 11/16/2009 06:16 PM, Denis Koroskin wrote:
If I remember correctly, one of D's design policies is
that a D code that looks like C code should behave like C.
Are we giving up that policy?
Correction: either behave like C, or raise a compile-time
Don wrote:
I frequently use fall-through myself, but having looked at this sample,
I bet I don't use it nearly as much as I thought: again, frequently
probably means about 1% of the time. But I *know* I've had bugs from
leaving out 'break'.
I poked through the optimizer code, gloop.c and
On 11/16/2009 06:55 PM, Denis Koroskin wrote:
Either I don't know C, or it breaks the switch, not the for-loop. In
both languages. Before *and* after the proposed change.
Arrrgh, please don't mind. My mistake. I'm sorry.
On 11/16/2009 07:05 PM, KennyTM~ wrote:
Check with you compiler. In C the inner break doesn't break the for loop.
Yes that's right. My mistake.
Denis Koroskin wrote:
C standard library alloca function has an undefined behavior when
requested size is large enough to cause a stack overflow, but many
(good) implementations return null instead. So does DMD, for example. I
believe it would be even better to go ahead and enforce D
On Sun, 15 Nov 2009 15:03:39 -0600, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Walter Bright wrote:
Don wrote:
And looking at how rarely it's actually used by someone who thinks he
uses it a lot, convinces me that intentional use of fall-through is
much less common than bugs
Walter Bright:
A person using alloca is expecting stack allocation, and
that it goes away after the function exits. Switching arbitrarily to the
gc will not be detected and may hide a programming error (asking for a
gigantic piece of memory is not anticipated for alloca, and could be
KennyTM~:
switch (x) {
case 2:
doSomething();
// At this point:
// Compiles fine in C.
// Falls through to the next (irrelevant) branch.
// Compile-time error in D (missing break; or goto case 3;)
case 3:
doSomeTotallyDifferentThing(x,
On Mon, 16 Nov 2009 01:36:30 -0800, Walter Bright
newshou...@digitalmars.com wrote:
Denis Koroskin wrote:
I'd like to raise 2 issues for a discussion.
First, Phobos makes calls to different functions, based on the OS we are
running on (e.g. CreateFileA vs. CreateFileW) and I wonder if it's
Walter Bright wrote:
Don wrote:
I frequently use fall-through myself, but having looked at this
sample, I bet I don't use it nearly as much as I thought: again,
frequently probably means about 1% of the time. But I *know* I've
had bugs from leaving out 'break'.
I poked through the optimizer
On Mon, 16 Nov 2009 12:36:30 +0300, Walter Bright
newshou...@digitalmars.com wrote:
Denis Koroskin wrote:
I'd like to raise 2 issues for a discussion.
First, Phobos makes calls to different functions, based on the OS we
are running on (e.g. CreateFileA vs. CreateFileW) and I wonder if
On Mon, 16 Nov 2009 02:07:47 -0500, Denis Koroskin 2kor...@gmail.com
wrote:
On Mon, 16 Nov 2009 02:16:09 +0300, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sun, 15 Nov 2009 15:53:08 -0500, BLS windev...@hotmail.de wrote:
==
Now : Sorry for my ignorance ... but Why the heck :
On Mon, 16 Nov 2009 03:27:22 -0500, Don nos...@nospam.com wrote:
Requiring 'goto' to implement fall-through would run into the prejudice
against 'goto'. It's necessary to persuade managers that goto case
XXX; isn't a bad, evil goto that eats babies. I have no idea if that's
difficult or
Don:
That's not fall-through, one case is *inside* the 'if' clause of another
one!! Wow. Do you really want to encourage that sort of thing?
I don't understand that piece of code, is that valid code? It needs a
reformatting, a rewriting, and then another reformatting.
Bye,
bearophile
Don:
(providing that empty fall-through case statements remain valid;
disallowing them would be really annoying).
What's bad about forcing people to write:
case A, B, C:
Instead of:
case A:
case B:
case C:
?
Bye,
bearophile
bearophile wrote:
Don:
(providing that empty fall-through case statements remain valid;
disallowing them would be really annoying).
What's bad about forcing people to write:
case A, B, C:
Instead of:
case A:
case B:
case C:
?
Bye,
bearophile
I don't know about forcing people to write
Max Samukha schrieb:
You so readily abandon support for Mac OS X 10.5 but keep catering for
the convenience of users of the outdated Windows 9x. Don't you see
anything wrong with this approach?
OWNED.
There's no point in supporting Win9x. Win98 support is already dropped
by M$ (maybe even
On Mon, 16 Nov 2009 15:48:16 +0300, Justin Johansson n...@spam.com wrote:
bearophile wrote:
Don:
(providing that empty fall-through case statements remain valid;
disallowing them would be really annoying).
What's bad about forcing people to write:
case A, B, C:
Instead of:
case A:
case
On Mon, 16 Nov 2009 16:20:15 +0300, Trass3r mrmoc...@gmx.de wrote:
Max Samukha schrieb:
You so readily abandon support for Mac OS X 10.5 but keep catering for
the convenience of users of the outdated Windows 9x. Don't you see
anything wrong with this approach?
OWNED.
There's no point in
bearophile wrote:
Don:
(providing that empty fall-through case statements remain valid;
disallowing them would be really annoying).
What's bad about forcing people to write:
case A, B, C:
Instead of:
case A:
case B:
case C:
?
Bye,
bearophile
(1) case A, B, C: implies a relationship
On Sun, 15 Nov 2009 14:47:23 -0500, dsimcha dsim...@yahoo.com wrote:
I was playing around with dcollections today and it reminded me of a
subtle
unresolved issue. This has been brought up here before, but always
buried
deep in some other thread. I think it deserves its own thread for some
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Denis Koroskin wrote:
C standard library alloca function has an undefined behavior when
requested size is large enough to cause a stack overflow, but many
(good) implementations return null instead. So does DMD, for example.
== Quote from Bartosz Milewski (bartosz-nos...@relisoft.com)'s article
I read Andrei's chapter on arrays and there's one thing that concerns me.
When a
slice is extended, the decision to re-allocate, and therefore to cut its
connection to other slices, is non-deterministic. How does that
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
On Sun, 15 Nov 2009 14:47:23 -0500, dsimcha dsim...@yahoo.com wrote:
I was playing around with dcollections today and it reminded me of a
subtle
unresolved issue. This has been brought up here before, but always
buried
I've updated my bindings to Rev. 9283 2009-10-14.
if anybody wants to play around with it: http://ul.to/jjwlyg
tell me when you find errors.
Sean Kelly wrote:
Andrei Alexandrescu Wrote:
I have two more that compliment that. Some people think there writing
complement and they're correctly but they aren't.
I see what you did there!
It peeked my interest, but it was a mute point.
On Mon, 16 Nov 2009 09:12:52 -0500, dsimcha dsim...@yahoo.com wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
My Tree implementation iterates over all the
elements without recursion.
Yes, but looking at your implementation, you have parent pointers, which
are
On Mon, 16 Nov 2009 17:01:32 +0300, dsimcha dsim...@yahoo.com wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Denis Koroskin wrote:
C standard library alloca function has an undefined behavior when
requested size is large enough to cause a stack overflow, but many
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
On Mon, 16 Nov 2009 17:01:32 +0300, dsimcha dsim...@yahoo.com wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Denis Koroskin wrote:
C standard library alloca function has an undefined behavior when
On Mon, Nov 16, 2009 at 5:20 AM, Trass3r mrmoc...@gmx.de wrote:
Max Samukha schrieb:
You so readily abandon support for Mac OS X 10.5 but keep catering for
the convenience of users of the outdated Windows 9x. Don't you see
anything wrong with this approach?
OWNED.
There's no point in
dsimcha schrieb:
Yes, but it stops the program in such a way that it's very hard to figure out
why/where it died. The solution, which I've wanted for a while and I think
others
have proposed, is for DMD to implicitly assert that every pointer is non-null
before dereferencing it when in
Bill Baxter schrieb:
The OS may not be supported in the sense of being able to get
technical support, but you can still build programs that run on Win98
using Visual Studio 2010.
Yeah, but the whole point of creating D has been to get rid of any kind
of legacy that unnecessarily complicates
Don Wrote:
Before TDPL is published, I think we should finally get rid of C-style
declarations. Supporting two styles of declarations just causes
confusion, and AFAIK it doesn't have any benefits -- for example, it
doesn't significantly help in porting code from C. D declarations are
Don wrote:
Sean Kelly wrote:
Andrei Alexandrescu Wrote:
I have two more that compliment that. Some people think there writing
complement and they're correctly but they aren't.
I see what you did there!
It peeked my interest, but it was a mute point.
You mean a moo point, shurely.
Denis Koroskin Wrote:
LPCSTR currently resolves to char*/const(char)*, but it could be better
for it to be an alias to ubyte*/const(ubyte)* so that user couldn't pass
unicode string to an API that doesn't expect one. The same is applicable
to other APIs, too, for example, how does C
Don schrieb:
Before TDPL is published, I think we should finally get rid of C-style
declarations. Supporting two styles of declarations just causes
confusion, and AFAIK it doesn't have any benefits -- for example, it
doesn't significantly help in porting code from C. D declarations are
just
struct inheritance never make it into D, for a good reason: structs are
not supposed to be polymorphic and inheritance is very tied to
polymorphism. But struct inheritance is sometimes very useful for
composition, avoid an extra member when accessing to the composed type
members.
Example:
struct
On Mon, 16 Nov 2009 10:32:31 -0500, Leandro Lucarella llu...@gmail.com
wrote:
What if one could use a struct directly with mixin?
This is a very good idea. BTW, I think conflicts should be a compile-time
error.
-Steve
Reminds me of an older thread:
http://www.digitalmars.com/d/archives/digitalmars/D/Implicit_castable_structs_64764.html
On Mon, 16 Nov 2009 18:58:42 +0300, Frank Benoit
keinfarb...@googlemail.com wrote:
Reminds me of an older thread:
http://www.digitalmars.com/d/archives/digitalmars/D/Implicit_castable_structs_64764.html
I recall it, but I still think alias this is the way to go:
struct GtkWidget{ /* data
Walter Bright wrote:
Andrei Alexandrescu wrote:
I was hoping the lesson learned would be to fix switch as was suggested.
I checked, because it wasn't written in the way I usually write things,
and sure enough it wasn't code I wrote :-)
From the changelog for D 0.129: Incorporated Ben
bearophile wrote:
Walter Bright:
A person using alloca is expecting stack allocation, and
that it goes away after the function exits. Switching arbitrarily to the
gc will not be detected and may hide a programming error (asking for a
gigantic piece of memory is not anticipated for alloca,
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
bearophile wrote:
Walter Bright:
A person using alloca is expecting stack allocation, and
that it goes away after the function exits. Switching arbitrarily to the
gc will not be detected and may hide a
On Mon, 16 Nov 2009 19:27:41 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
bearophile wrote:
Walter Bright:
A person using alloca is expecting stack allocation, and that it goes
away after the function exits. Switching arbitrarily to the gc will
not be detected and may
On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
I was hoping the lesson learned would be to fix switch as was suggested.
I checked, because it wasn't written in the way I usually write things,
and
On Nov 17, 09 01:12, Bill Baxter wrote:
On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
I was hoping the lesson learned would be to fix switch as was suggested.
I checked, because it wasn't written
Why not? ;)
I know you might want to hit me for bringing just another feature request
inspired in Google's Go, but please do read it without preconceptions,
because I think the features I'm suggesting are mostly already in D, but
in a less convenient way.
With ranges, D is already using some
Frank Benoit, el 16 de noviembre a las 16:58 me escribiste:
Reminds me of an older thread:
http://www.digitalmars.com/d/archives/digitalmars/D/Implicit_castable_structs_64764.html
I think mixin can mix very well with that proposal, when the compiler sees
a struct mixin, it can automatically
Denis Koroskin wrote:
On Mon, 16 Nov 2009 19:27:41 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
bearophile wrote:
Walter Bright:
A person using alloca is expecting stack allocation, and that it
goes away after the function exits. Switching arbitrarily to the gc
will not
Bill Baxter wrote:
On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
I was hoping the lesson learned would be to fix switch as was suggested.
I checked, because it wasn't written in the way I usually
Andrei Alexandrescu:
Can't be written. Try it.
Thank you for being gentle with me still :-)
Almost every day I say something stupid in this newsgroup...
Bye,
bearophile
On Mon, Nov 16, 2009 at 9:30 AM, KennyTM~ kenn...@gmail.com wrote:
On Nov 17, 09 01:12, Bill Baxter wrote:
On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
I was hoping the lesson learned would be
Leandro Lucarella schrieb:
What do you think?
I like it.
Don:
(1) case A, B, C: implies a relationship between A, B, and C, which
might not exist. They may have nothing in common.
It's just a list of things, it's a syntax people adapts too. Here too there's
no relationship between x and foo:
int x, foo;
(2) it's an extremely common coding style
Bill Baxter:
Could this get into difficult-to-verify territory? And therefore be
difficult to implement?
It looks like the exact same problem as enforcing that all code paths
return a value, which is something I think D doesn't currently enforce
because it's too hard. So you run into
1 - 100 of 260 matches
Mail list logo
