February 05, 2002 Re: Death to C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to D | D wrote:
> Russell Borogove <kaleja@estarcion.com> wrote in message
>
>>That well known brain-damaged CPU architecture called x86 has
>>had hardware bounds-checking available since the 286. Let me
>>ask you, when writing in assembly, do you check the index
>>every time you do an indexed memory access?
>>
>
> Segments do not provide adequate bounds checking limits since segmetns are
> typically very large. So essentially there is no effective bounds checking
> on pointer operations.
I'm speaking of the BOUND instruction (if I'm remembering
rightly), not segmentation.
As for the rest of your response, your mind appears to be
made up, so I see little point in debate.
-Russell B
|
February 05, 2002 Re: Death to C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to user | > > C/C++ are among the worst languages ever written. > > > > I recommend immediate replacement. <user@domain.invalid> wrote in message news:3C5FAD72.4030201@domain.invalid... > So, were is _YOUR_ language and compiler???? I am reluctant to write one, because I don't think I can write a langauge alone that optimizes as well as existing compilers. The really sad part about this is that C compilers are very poor optimizers and typically produce code that is 2-4 times larger and 2-4 times slower than can be produced by hand. Truly unfortunate. |
February 05, 2002 Re: Death to C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to Pavel Minayev | Pavel Minayev <evilone@omen.ru> wrote in message news:a3oda2$2lf1$1@digitaldaemon.com... > Write programs in full-screen text mode. It's the way all true coders do this - and so do I =) Sorry that just isn't in the cares with an IDE. Teletype coding went out with the virtual abandonment of crap command line operating systems like Unix and DOS. I've done my share of terminal mode programming. Writing windowing applications in terminal mode is very much like knitting using boxing gloves. You can do it, But no one in thier right mind would consider it. |
February 05, 2002 Re: Death to C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russell Borogove | Russell Borogove <kaleja@estarcion.com> wrote in message news:3C6010F5.2070908@estarcion.com... > I'm speaking of the BOUND instruction (if I'm remembering > rightly), not segmentation. > > As for the rest of your response, your mind appears to be made up, so I see little point in debate. Ah, well there is a bound instruction. But the bound instruction is a separate instruction, that must be executed independently of pointer operations. It is certainly better than performing both upper and lower bounding tests separately, but it does not represent a bounded pointer type. It can be used to synthasize one a lower than normal level though. The syntax for the Bound statement is BOUND OP1,*BoundStruct If OP1 is a 16 bit register, then Boundstruct dw lowerlimit dw upperlimit If Op1 is a 32 bit register, then Boundstruct dq lowerlimit dq upperlimit Bound treates OP1 as a "signed" index. so problems arrise if the address resides in the upper half of the 4 GB address space. A 32 bit bounded pointer could be synthasized as follows ptra dq 0 dq 0 dq 1000*4 count : xor eax,eax ; Clear sum mov cx,1000 ; Get size of array for loop omov esi, ptra ; si = ptr to array cntlop: lodzx ebx,[esi] ; load value to add add eax,ebx ; add element to sum add esi,2 ; bump ptr bound ptra+4 ; compare ptr against bounds loop cntlop ; proces entire array ret However for true bounded ptr you would have count : xor eax,eax ; Clear sum mov cx,1000 ; Get size of array for loop omovbp esi, ptra ; si = ptr to array cntlop: lodzx ebx[esi] ; load value to add add eax,ebx ; add element to sum add esi,2 ; bump ptr loop cntlop ; proces entire array ret |
February 14, 2002 Re: Death to C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to D | I know this was posted a while ago, but I can't help myself =) D wrote: > Consider that C omits block typing. Those structured languages that don't > descend from C, typically identify different kinds of blocks with different > bracketing keywords. Do/While, If/Endif, Repeat/Until etc. > > When reading a block typed program, if the programmer sees the word "until", > he/she knows that the statement ends a "repeat" block. > > With C on the other hand the same delimiters are used for all blocks. The > bracket that ends a C block could be the end of an if block or any other > kind of block. The programmer is forced when reading the code, to search > back through the program to find which block is being closed. For > convenience the strategy to combat this language failing is to progressively > indent blocks so that the start of a block can easily be identified. And of > course sicne C is a free format language, we immediately run into the > problem of people having different indention styles that typically make > following code written by another person difficult. > > The indent requirement is utter lunacy. No language should be able to have > it's meaning be made essentially human unreadable through a simple loss of > indentation. > > Insanity! #define then { #define endif } if( i_am_insane ) then exit( EXIT_FAILURE ); endif |
February 15, 2002 Re: Death to C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tom Howard | "Tom Howard" <thoward@tibco.com> wrote in message news:3C6B25BD.7040908@tibco.com... > #define then { > #define endif } > > if( i_am_insane ) then > exit( EXIT_FAILURE ); > endif void (helloWorld) then printf("Hello World!\n"); endif Salutaciones, JCAB http://www.JCABs-Rumblings.com |
March 04, 2002 Re: Death to C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to Juan Carlos Arevalo Baeza | A foolish nonsolution since the redefinition is not part of the standard language and has side effects. Juan Carlos Arevalo Baeza <jcab@JCABs-Rumblings.com> wrote in message news:a4ig8q$1dti$1@digitaldaemon.com... > "Tom Howard" <thoward@tibco.com> wrote in message news:3C6B25BD.7040908@tibco.com... > > > #define then { > > #define endif } > > > > if( i_am_insane ) then > > exit( EXIT_FAILURE ); > > endif > > void (helloWorld) then > printf("Hello World!\n"); > endif > > Salutaciones, > JCAB > http://www.JCABs-Rumblings.com > > > |
December 29, 2005 Re: Death to C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to d | As someone who has had to "port" code through various versions of DOS and Windows -- without of course ever making a deliberate choice to change OS's, I wholeheartedly agree that it's moronic that 'C' defines an 'int' depending on the CPU type. Something like the following types are the only logical answer: int8 (unsigned 8 bit) Sint8 (Signed 8 bit) int16 (unsigned 16 bit) sint16 (signed 16 bit) int32 (unsigned 32 bits) sint32 (Signed 32 bits) int64 (unsigned 64 bits) sint64 (Signed 64 bits) int128 (Unsigned 128 bits) sint128 (Signed 128 bits) The same with floats: float16, float32, float64. I'm too busy programming to have to remember how many bits are in a 'long double word float' Clay |
Copyright © 1999-2021 by the D Language Foundation