Tomas Lindquist Olsen wrote:
And besides this is not in the spec, it might be implied, somehow, but
it's not in the spec.
It never occurred to me that this might be necessary, but it obviously is.
Daniel Keep wrote:
I think it was around the time that the mail service guaranteed that
they wouldn't leave a dead cat in your mailbox on every alternate Wednesday.
So that's why my mailbox stinks!
The idea is to make writing garbage more work than doing it right. But
not make it impossible.
Lutger wrote:
if not not actived then if not defined no debugging then do stuff
Ain't nobody doing nothing around here! Not no how, not no way! No sirree!
grauzone wrote:
> Walter Bright wrote:
>> Bill Baxter wrote:
>>> On Tue, Jul 14, 2009 at 5:13 PM, Walter
>>> Bright wrote:
Why do C and C++ (and D) make it difficult to do:
char *p;
p |= 1;
? There's no implementation difficulty in accepting such and generating
>>
The interesting question is is the construct itself the cause or the
effect of incoherence and bugginess?
Maybe. But the real problem is, that you can't force the user to specify
either a "yes" or "no" for a specific version/define identifier. He
still could just forget about it.
Of course,
On Wed, Jul 15, 2009 at 12:24 PM, Daniel
Keep wrote:
>
> Tomas Lindquist Olsen wrote:
>> On Wed, Jul 15, 2009 at 2:18 AM, Walter
>> Bright wrote:
>>> Don wrote:
In this case you may have a long function, with only a single instruction
right in the middle which needs to be changed.
>>> voi
Tomas Lindquist Olsen wrote:
> On Wed, Jul 15, 2009 at 2:18 AM, Walter
> Bright wrote:
>> Don wrote:
>>> In this case you may have a long function, with only a single instruction
>>> right in the middle which needs to be changed.
>> void foo()
>> {
>>asm
>>{
>>mov EAX,EAX;
>>
On Wed, Jul 15, 2009 at 2:18 AM, Walter
Bright wrote:
> Don wrote:
>>
>> In this case you may have a long function, with only a single instruction
>> right in the middle which needs to be changed.
>
> void foo()
> {
> asm
> {
> mov EAX,EAX;
> ... lots more instructions ...
>
grauzone wrote:
The #ifndef NO_DEBUGGING causes the code to be compiled in debugging
mode, if it isn't explicitly deactivated.
"You, sir, are employing a double negative." -- Mr. Spock
It's not that it's impossible to figure out, it's that it's execrable
style. In my experience, such construc
Walter Bright wrote:
Bill Baxter wrote:
On Tue, Jul 14, 2009 at 5:13 PM, Walter
Bright wrote:
Why do C and C++ (and D) make it difficult to do:
char *p;
p |= 1;
? There's no implementation difficulty in accepting such and generating
correct code for it. It's purely a matter of making what
Walter Bright wrote:
Don wrote:
In this case you may have a long function, with only a single
instruction right in the middle which needs to be changed.
void foo()
{
asm
{
mov EAX,EAX;
... lots more instructions ...
}
version (bar) asm
{
mov EAX,EAX;
Walter Bright, el 14 de julio a las 14:52 me escribiste:
> Leandro Lucarella wrote:
> >The same goes for version (!X) ..., I think it should be available, there
> >are cases when the use is valid and you have to do artificial hacks like
> >version (X) else It's like Java not having functions o
Trass3r wrote:
Man, it's so obvious, yet I wouldn't have hit on that ;)
Most obvious things are obvious only in hindsight .
Walter Bright schrieb:
Don wrote:
In this case you may have a long function, with only a single
instruction right in the middle which needs to be changed.
void foo()
{
asm
{
mov EAX,EAX;
... lots more instructions ...
}
version (bar) asm
{
mov EAX,EAX;
Walter Bright:
> Using the bottom two bits as flags (because the pointers were aligned)
> is not all that uncommon. I've seen it done by major companies on some
> major, very successful projects.
That's done often enough, one or two bits in tagged pointers are useful to
implement various data s
Bill Baxter wrote:
On Tue, Jul 14, 2009 at 5:13 PM, Walter
Bright wrote:
Why do C and C++ (and D) make it difficult to do:
char *p;
p |= 1;
? There's no implementation difficulty in accepting such and generating
correct code for it. It's purely a matter of making what is generally
consider
On Tue, Jul 14, 2009 at 5:13 PM, Walter
Bright wrote:
> Rainer Deyke wrote:
>>
>> Walter Bright wrote:
>>>
>>> It's not about protecting idiots. It's about making the better way to do
>>> things the easier and more natural way, and making the worse more
>>> difficult.
>>
>> Making the better way ea
Don wrote:
In this case you may have a long function, with only a single
instruction right in the middle which needs to be changed.
void foo()
{
asm
{
mov EAX,EAX;
... lots more instructions ...
}
version (bar) asm
{
mov EAX,EAX;
}
asm
{
On Tue, Jul 14, 2009 at 5:02 PM, Walter
Bright wrote:
> Bill Baxter wrote:
>>
>> You do realize you're being patronizing, right? "I have so much
>> experience with these things, and I know the right way to write code,
>> and you don't, so I'm not going to give you this thing you request
>> because
Rainer Deyke wrote:
Walter Bright wrote:
It's not about protecting idiots. It's about making the better way to do
things the easier and more natural way, and making the worse more
difficult.
Making the better way easy is a worthwhile goal. Making the worse way
more difficult is not. A progra
Bill Baxter wrote:
You do realize you're being patronizing, right? "I have so much
experience with these things, and I know the right way to write code,
and you don't, so I'm not going to give you this thing you request
because it's not good for you".
Sure. There's some of that in every langua
Walter Bright wrote:
> It's not about protecting idiots. It's about making the better way to do
> things the easier and more natural way, and making the worse more
> difficult.
Making the better way easy is a worthwhile goal. Making the worse way
more difficult is not. A programming language sho
On Tue, Jul 14, 2009 at 2:52 PM, Walter
Bright wrote:
> Leandro Lucarella wrote:
>>
>> The same goes for version (!X) ..., I think it should be available, there
>> are cases when the use is valid and you have to do artificial hacks like
>> version (X) else It's like Java not having functions o
Leandro Lucarella wrote:
The same goes for version (!X) ..., I think it should be available, there
are cases when the use is valid and you have to do artificial hacks like
version (X) else It's like Java not having functions or global
variable. You're just annoying people that know what they
Walter Bright, el 14 de julio a las 10:01 me escribiste:
> Bill Baxter wrote:
> >But from where I sit it looked like Walter didn't really convince
> >anyone. To me this seems like a point where D is overly patronizing,
> >to use the phrase from a recent post.
>
> You could argue that, but it also
On Tue, Jul 14, 2009 at 12:04 PM, Walter
Bright wrote:
> Bill Baxter wrote:
>>
>> I do think you make a convincing argument that in general lots of
>> micro ifdefs everywhere is not the right approach.
>> But I remain unconvinced that potential for abuse is a good reason to
>> disallow finer scale
Andrei Alexandrescu wrote:
1. It's pretty clear what is happening for each system.
Not clear to me. It's happened to me more than once to fix a function
without knowing that it's version()ed (your fault: you didn't indent it)
and that there's a corresponding Windows function some miles away.
Walter Bright wrote:
Andrei Alexandrescu wrote:
In my approach they are laid as you see them, which I find very
well-organized.
There is no duplication in:
[snip]
I said there's either duplication or complication.
But there's no hard and fast rule here, and since you are doing the
actual
Julian Salazar wrote:
My final question is just about how I would go about contributing to the
Inline Assembler specification. I found that you generate the language
spec from the trunk/docsrc folder on the Phobos SVN repo on dsource.org.
So, am I right to think that I could just download the d
Bill Baxter wrote:
I do think you make a convincing argument that in general lots of
micro ifdefs everywhere is not the right approach.
But I remain unconvinced that potential for abuse is a good reason to
disallow finer scale version() statements.
It's where the line between micro and fine is
Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
Then I have the function right there with all versioned
implementations. To me that seems better than Phobos' existing style
of version'ing large portions of code, which inevitably results in
duplicating a lot of the f
On Tue, Jul 14, 2009 at 10:01 AM, Walter
Bright wrote:
> Bill Baxter wrote:
>>
>> But from where I sit it looked like Walter didn't really convince
>> anyone. To me this seems like a point where D is overly patronizing,
>> to use the phrase from a recent post.
>
> You could argue that, but it also
Walter Bright wrote:
Andrei Alexandrescu wrote:
Then I have the function right there with all versioned
implementations. To me that seems better than Phobos' existing style
of version'ing large portions of code, which inevitably results in
duplicating a lot of the functionality in two places.
Andrei Alexandrescu wrote:
Then I have the function right there with all versioned implementations.
To me that seems better than Phobos' existing style of version'ing large
portions of code, which inevitably results in duplicating a lot of the
functionality in two places.
I wouldn't consider
Bill Baxter wrote:
But from where I sit it looked like Walter didn't really convince
anyone. To me this seems like a point where D is overly patronizing,
to use the phrase from a recent post.
You could argue that, but it also took a long time to convince many
about the merit of const and immu
I appreciate the reply, and I guess that your point about separating
dependencies into different modules is a good form of version management.
I'll still be using the version(x86) asm {...} else version(x86_64) asm
{...} syntax for a while though. But I'm done arguing that point.
My final ques
Bill Baxter wrote:
On Mon, Jul 13, 2009 at 10:05 PM, Walter
Bright wrote:
Julian Salazar wrote:
It's been rehashed here several times (not to rag on you, just to point out
that it isn't something that's been overlooked). To sum up, I've worked a
lot with both styles - #ifdef, and separating depe
On Mon, Jul 13, 2009 at 8:24 PM, Walter
Bright wrote:
> Julian Salazar wrote:
>>
>> Hi, I'm new here to the community but I've been using D for a while now,
>> and I have to say that it's a great programming language. I'd like to get
>> involved in this community and help shape this language.
>
> W
On Mon, Jul 13, 2009 at 10:05 PM, Walter
Bright wrote:
> Julian Salazar wrote:
> It's been rehashed here several times (not to rag on you, just to point out
> that it isn't something that's been overlooked). To sum up, I've worked a
> lot with both styles - #ifdef, and separating dependencies into
Julian Salazar wrote:
Hi, I'm new here to the community but I've been using D for a while now,
and I have to say that it's a great programming language. I'd like to
get involved in this community and help shape this language.
Welcome!
I'm just wondering about a minor issue: why are conditiona
Julian Salazar wrote:
Maybe it's time for some maintenance? Or a rewrite in a certain
higher-level language? ;)
Yes, but to rewrite it requires understanding it, and that means obj2asm.
So, in essence, the idea is to push conditional compilation to higher
levels, not lower levels. Ideally, ve
"Walter Bright" wrote in message
news:h3fu36$22h...@digitalmars.com...
Welcome!
A welcome from the guy who actually created the D language - thanks!
The request to do it for enums has been thrashed about before.
Essentially, version works at the declaration and statement level, not at
the e
Walter Bright:
> The first approximation to the definition is to use the Intel asm syntax
> as outlined in their processor data sheets. I haven't written a spec
> more detailed than that because it's a lot of work and I'm lazy, and
> such work is not terribly exciting. But if you'd like to help
Julian Salazar wrote:
Hi, I'm new here to the community but I've been using D for a while now,
and I have to say that it's a great programming language. I'd like to
get involved in this community and help shape this language.
Welcome!
I'm just wondering about a minor issue: why are condition
Julian Salazar wrote:
Hi, I'm new here to the community but I've been using D for a while now,
and I have to say that it's a great programming language. I'd like to
get involved in this community and help shape this language.
[snip]
Great! This is the place to effect that, and the improvement
On Mon, Jul 13, 2009 at 11:15 AM, Julian Salazar wrote:
> Hi, I'm new here to the community but I've been using D for a while now, and
> I have to say that it's a great programming language. I'd like to get
> involved in this community and help shape this language.
Man, so would I ;)
> I'm just w
Hi, I'm new here to the community but I've been using D for a while now, and
I have to say that it's a great programming language. I'd like to get
involved in this community and help shape this language.
I'm just wondering about a minor issue: why are conditional blocks invalid
within expressi
48 matches
Mail list logo
