Walter Bright schrieb am 2006-02-27:
>
> "Thomas Kuehne" <thomas-dloop@kuehne.cn> wrote in message news:0fo9d3-mb8.ln1@birke.kuehne.cn...
>> # import std.stdio;
>> #
>> # int main(){
>> # int i = 3;
>> # bool a = true;
>
> The next line goes around the type system completely, invalidates any invariants on the contents, and so any "surprising" results should be unsurprising:
>
>> # bool b = *(cast(bool*)cast(void*) &i);

I was sure there was another way to subvert without casting though can't find it right now.

related suggestion:

a) if( a == b ) { ... }
b) if( a != b ) { ... }

If, after constant folding, the lines above results in

a) if( a == true ) { ... }
b) if( a != true ) { ... }

then the the code

a) if( a != false ) { ... }
b) if( a == false ) { ... }

is generated.


consequences:
1) no changes in the D documentation are required

2) no runtime overhead

3) the code is a bit more robust against casting and bools returned
from external sources (e.g. C code)

Thomas

I did't find a way to do either of these with the current meta stuff.

Sean Kelly wrote:
> Anders F Björklund wrote:
> 
>> Derek Parnell wrote:
>>
>>> And I remember somebody writing ..
>>>
>>>   #define forever for(;;)
>>>
>>>   . . .
>>>
>>>   forever{
>>>       . . .
>>>      }
>>
>>
>> I'm pretty sure that I saw a :
>>
>> #define EVER ;;
>>
>> As in: for (EVER) { young() }
> 
> 
> LOL
> 
> 
> Sean

Tom wrote:
> In article <du187e$14bk$4@digitaldaemon.com>, Walter Bright says...
> 
>>"Derek Parnell" <derek@psych.ward> wrote in message 
>>
>>>[snip]
> 
> 
>>As far as I'm concerned, arguing about it is like arguing over if the { goes on the same line or the next :-)
> 
> 
> No no no, excuse me, nobody argues that because everybody knows that '{' and '}'
> goes in the next line, NEVER IN THE SAME!! :P
> 
> Sorry, I couldn't resist! :D
> 
> Tom;

Gosh I couldn't stand looking at all those wasted lines.  C# default style is the worst, luckily I can change it in VS.Net 2003.

My vertical screen space is limited; I'd prefer getting as big a picture as I can get on the screen at once, especially seeing as how my sight is surely going and my fonts are getting bigger.

And spaces for indentation?  Oh please, this is what we have tab characters for.  And why the hell do they want to stay at 8 characters wide?  Sure this works for C code, but now we've got many more coding practices and constructs for langauges that *require* more nesting of branches, hence more tabs, and hence a more horizontal exspanse of code.  Nothing is wrong with your code and you simply shouldn't have to break things up into functions.  2 is too small, 8 is too big -- 4 is just right :)  3?  Who invited you? =P

-- 
Regards,
James Dunne

Derek Parnell wrote:
> On Wed, 01 Mar 2006 04:23:00 +1100, Sean Kelly <sean@f4.ca> wrote:
> 
>> Walter Bright wrote:
>>
>>>  What I especially think is bad style, however, are things like:
>>>      const int forever = 1;
>>>     ...
>>>     while (forever) ...
>>>  I don't see them too often, but it does happen.
>>
>>
>> It perhaps sidesteps the issue, but I use "for(;;)" in these cases,  mostly because it avoids a constant conditional warning in VC++ :-p  "while(true)" is probably a bit more meaningful however as it's not a  counting loop.
> 
> 
> And I remember somebody writing ..
> 
>   #define forever for(;;)
> 
>   . . .
> 
>   forever{
>       . . .
>      }
> 

It's called "Better C"

http://thedailywtf.com/forums/60255/ShowPost.aspx

/*
 * BETTER_C.H
 * Language refinements for C.
 */
#ifndef BETTER_C_H
#define BETTER_C_H

/* logical/comparison operators */
#define NE  !=
#define EQ  ==
#define GT  >
#define LT  <
#define GE  >=
#define LE  <=
#define AND &&
#define OR  ||
#define NOT !

/* bitwise operators */
#define bNOT ~
#define bAND &
#define bOR  |
#define bXOR ^

/* arithmetic operators */
#define MOD   %

/* control constructs */
#define repeat    do
#define until(p)  while(NOT (p))
#define forever   while(1)
#define untilbreak  forever
#define untilreturn forever
#define unless(p) if(NOT (p))
#define ifnot(p)  if(NOT (p))
#define do_nothing
#define then

...

#endif


-- 
Regards,
James Dunne

"Thomas Kuehne" <thomas-dloop@kuehne.cn> wrote in message news:2t3fd3-hm9.ln1@birke.kuehne.cn...
> 3) the code is a bit more robust against casting and bools returned
> from external sources (e.g. C code)

That's true, but I disagree with the intent. When interfacing with C, or doing casting, it's up to you to get the right results into the variable to satisfy the constraints of the type. Having the compiler essentially hide bugs of this sort doesn't make it robust, it just defers the problem to cropping up somewhere else.

Georg Wrede wrote:
> I did't find a way to do either of these with the current meta stuff.

Fortunately not. You can't do this, either (from the original Bourne shell):

http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/sh/blok.c.html

Or
// Introduce a really unexpected, hard-to-track down bug.
// Put it <stdio.h> or something included by windows.h.
inline bool rarelyfalse() { static int x=0; ++x; return (x&0x7FF) !=0x315; }
#define true (rarelyfalse())

<g>

Seriously, I think the restrictions are generally a good thing. The main time when I've wished I had a #define is when I wanted to create variable argument lists. (I made an efficient, typesafe printf, which detects errors in the format string, at compile time).


> Sean Kelly wrote:
>> Anders F Björklund wrote:
>>
>>> Derek Parnell wrote:
>>>
>>>> And I remember somebody writing ..
>>>>
>>>>   #define forever for(;;)
>>>>
>>>>   . . .
>>>>
>>>>   forever{
>>>>       . . .
>>>>      }
>>>
>>>
>>> I'm pretty sure that I saw a :
>>>
>>> #define EVER ;;
>>>
>>> As in: for (EVER) { young() }
>>
>>
>> LOL
>>
>>
>> Sean

In article <du19j7$15r9$2@digitaldaemon.com>, Walter Bright says...
>
>
>Pascal didn't have implicit type conversions. That meant that typical Pascal code was littered with casts. It was ugly, and I'd argue that casting reduces type safety, rather than enhancing it.

This is untrue. Pascal is a strong-typed language for application programming,
so you won't need a single cast (something in Pascal doesn't exist).
Pascal was not born for system programming, for this at the time people used
assembly (O.S. themselves were writeen in assembly).

>Pascal played catchup ever since, adopting features of C. Then Pascal++ (i.e. Modula 2) came out, which was promptly buried by C++.

This is pathethic.

When ISO Pascal standard was issued, there wasn't an ISO C.
The first ANSI C is from 1989, six years after the Pascal standard.
And ANSI-C was a very different language from pre-ANSI-C, for example
introducing function prototypes, and changing the function argument passing
behaviour, among the other things. So it' *C that has adopted features of
Pascal* not the reverse.

It's funny that you say that Modula-2 took something from C++, that is not the
case.
D took modules from Modula-2, instead, and better than the loosy C++ namespace
thing.

Ciao

P.S.: A little time table:

1970 The first Pascal compiler is released
1973 The first Unix kernel is written in C (with the first C compiler available)
1974 The book "PASCAL - User Manual and Report" is published
1978 The book "The C Programming Language" by K&R is published
1980 The first Modula-2 compiler is released
1982 The book "Programming in Modula-2" is published
1983 The ISO Pascal standard is approved
1985 The first edition of "The C++ Programming Language" and the first C++
compiler are released
1989 The ANSI/ISO C standard is approved
1996 The ISO Modula-2 standard is approved
1998 The ISO C++ standard is approved

As you can see the first Pascal compiler predates the first C compiler, the first Modula-2 compiler predates the first C++ compiler, Pascal predates C and Modula-2 predates C++.

References: http://en.wikipedia.org/wiki/Pascal_programming_language http://en.wikipedia.org/wiki/Modula-2 http://www.cs.inf.ethz.ch/~wirth/

http://en.wikipedia.org/wiki/C_language http://cm.bell-labs.com/cm/cs/who/dmr/chist.html http://en.wikipedia.org/wiki/C%2B%2B

In article <du3vu2$6ng$1@digitaldaemon.com>, Roberto Mariottini says...
>In article <du19j7$15r9$2@digitaldaemon.com>, Walter Bright says...

>>Pascal played catchup ever since, adopting features of C. Then Pascal++ (i.e. Modula 2) came out, which was promptly buried by C++.

>It's funny that you say that Modula-2 took something from C++, that is not the case.

Mmmh? Or I'm totally wasted or Walter didn't say that?

Tom;
"Pure Boolean Rules!" :D

Derek Parnell wrote:
> And I remember somebody writing ..
> 
>   #define forever for(;;)
> 
>   . . .
> 
>   forever{
>       . . .
>      }
> 

Hey, I still think it's fun to do like I did in my early C coding days (a few
years back) and

#define EVER (;;)

and then loop

for EVER {
}

Walter Bright wrote:
> "Tom" <Tom_member@pathlink.com> wrote in message news:du049t$2uv2$1@digitaldaemon.com...
>> Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I shut my
>> mouth forever!
> 
> One should be very careful about stepping away from C's implicit promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.
> 

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you meant by "C's implicit promotion rules" (as C doesn't even have a bool). But ok, nevermind, let's pause for a moment, and get our facts straight.

What exactly is it in bools that you Walter, want and not want?
I already know that the ability to write 'while(1)' as the same as 'while(true)' is one of them, but, anything more?
Is the behaviour of having an "implicit promotion" something you want too?
If so, promotion from where, from int to bool, or from bool to int?
Do you want or not want bool numeric operations to be an error (like boolA / boolB*2) ?

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."