Board index » delphi » REPORTED TO ISP

REPORTED TO ISP

NumberOfSpammers := NumberOfSpammers - 1; <g>

=======================================
Message-ID: <edd59f09e6d944503fed8ed1a0e781e1@spamfreenews.com>
Date: 22 Nov 2001 10:58:50 -0800
Organization: http://www.TeraNews.com - FREE NNTP Access
Lines: 32
X-Abuse-Report: Send abuse reports to ab...@teranews.com
Path:
news.be.uu.net!lnewshfeed00.lnd.ops.eu.uu.net!master.news.eu.uu.net!lnewsife
ed03.lnd.ops.eu.uu.net!lnewspeer00.lnd.ops.eu.uu.net!emea.uu.net!newsfeed01.
sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!news-spur1.maxwell.sy
r.edu!news.maxwell.syr.edu!hub1.nntpserver.com!news.1usenet.com
=======================================

 

Re:REPORTED TO ISP


On Thu, 22 Nov 2001 21:27:32 +0100, "Dirk Claessens"
<will.bou...@back.com> waffled on about something:

Quote
>NumberOfSpammers := NumberOfSpammers - 1; <g>

Surely you mean

dec(numberofspammers);

Or maybe

numberofspammers--;

:o)

Good work anyway!

Re:REPORTED TO ISP


In article <0dsqvts38v79489u0tsmdji63fkua97...@4ax.com>, Dodgy

Quote
<Do...@earth.planet.universe> wrote:
> On Thu, 22 Nov 2001 21:27:32 +0100, "Dirk Claessens"
> <will.bou...@back.com> waffled on about something:

> >NumberOfSpammers := NumberOfSpammers - 1; <g>

> Surely you mean

> dec(numberofspammers);

Either is fine, but considering this was posted to only Pascalish NGs,
this...

Quote
> Or maybe

> numberofspammers--;

> :o)

> Good work anyway!

...is just wrong.

Re:REPORTED TO ISP


In article <221120011716099729%gwestonREM...@CAPShome.com>, Greg Weston

Quote
<gwestonREM...@CAPShome.com> wrote:
>In article <0dsqvts38v79489u0tsmdji63fkua97...@4ax.com>, Dodgy
><Do...@earth.planet.universe> wrote:

>> On Thu, 22 Nov 2001 21:27:32 +0100, "Dirk Claessens"
>> <will.bou...@back.com> waffled on about something:

>> >NumberOfSpammers := NumberOfSpammers - 1; <g>

>> Surely you mean

>> dec(numberofspammers);

>Either is fine...

Which reminds me: what IS this inc() and dec() business with Delphi?
Quite frankly, I find it just too cutesy-poo for words to replace good-old
  i := i + 1;
with
  inc(i)

ARE there good reasons for using the latter?  (Apart from fewer
keystrokes, that is -- almost never a good reason, IMHO)
--
Esther Michaels
Please respond to newsgroup; I don't check my mail account

Re:REPORTED TO ISP


Quote
Esther Michaels wrote:

> Quite frankly, I find it just too cutesy-poo for words to replace good-old
>   i := i + 1;
> with
>   inc(i)

> ARE there good reasons for using the latter?  (Apart from fewer
> keystrokes, that is -- almost never a good reason, IMHO)

Yes! According to Delphi Help, Inc() and Dec() produce far tighter code
and recommends using it in loops instead of using i := i + 1.

Probable difference is stack vs. register operation.

-- Erwin Dokter
   mailto:edok...@home.nl
   http://members.home.nl/edokter

Re:REPORTED TO ISP


Hi Esther,

Quote
>Which reminds me: what IS this inc() and dec() business with Delphi?
>Quite frankly, I find it just too cutesy-poo for words to replace good-old
>  i := i + 1;
>with
>  inc(i)

/==== [ from the Delphi Help ]
|  Category
|    ordinal routines
|  procedure Inc(var X [ ; N: Longint ] );
|  
|  Description
|  The Inc procedure adds one or N to the variable X.
|  X is a variable of an ordinal type (including Int64), or of type PChar
|  if the extended syntax is enabled, and N is an integer-type expression.
|  Inc can be used on enumerated types or on pointer variables.
\====

I use it to kinda unify the look of the source code.

Cheers,
   Udo
--
Homepage: http://www.nesshoever.de/         [No mails please. Reply here.]
Delphi: W2K.sp2, D4Pro.sp3, D6Pro.sp1

Re:REPORTED TO ISP


Quote
"Udo Nesshoever" <newsgroup.re...@gmx.net> wrote in message

news:9tlk4g.sk.2@com.nesshoever.net...

Quote
> Hi Esther,

> >Which reminds me: what IS this inc() and dec() business with
Delphi?
> >Quite frankly, I find it just too cutesy-poo for words to replace
good-old
> >  i := i + 1;
> >with
> >  inc(i)

> /==== [ from the Delphi Help ]
> |  Category
> |    ordinal routines
> |  procedure Inc(var X [ ; N: Longint ] );
> |
> |  Description
> |  The Inc procedure adds one or N to the variable X.
> |  X is a variable of an ordinal type (including Int64), or of type
PChar
> |  if the extended syntax is enabled, and N is an integer-type
expression.
> |  Inc can be used on enumerated types or on pointer variables.
> \====

> I use it to kinda unify the look of the source code.

Doesn't just work on PChars, works on other pointers too! Works out
the size of what the pointer points to and all. Example at the bottom.

It's kind of interesting. This was discovered in TurboPascal 6, by
accident. But it was undocumented. And as far as I know it is still
undocumented, but it works - even though the compiler is now
completely different. If it was a compiler bug I could understand it
working up to Delphi 1, but I would have expected it to disappear or
be a documented feature in Delphi 2, because it must have taken work
for this feature to have been coded up in the new compiler.

FP

Here's the example program for using Inc() to step a pointer variable
through an array:

{$apptype console}
Type
  t = Record
        I:Integer;
        S:String;
      end;
  pt = ^t;

Const
  a : Array[1..5] of t = (
    (i:2; s:'First record'),
    (i:4; s:'Second record'),
    (i:6; s:'Third record'),
    (i:8; s:'Fourth record'),
    (i:0; s:'Fifth record')
  );

Var
  p : pt;
  i : Integer;
Begin
  p := @a[1];
  For i := 1 to 5 do
  begin
    Writeln('Record ',i,': I=',p^.i,'; S=',p^.s);
    inc(p);
  end;
end.

Re:REPORTED TO ISP


Quote
"Frank Peelo" <fpe...@eircom.net> wrote in message

news:9tlpvq$v38$1@kermit.esat.net...

Quote

> "Udo Nesshoever" <newsgroup.re...@gmx.net> wrote in message
> news:9tlk4g.sk.2@com.nesshoever.net...
> > Hi Esther,

> > >Which reminds me: what IS this inc() and dec() business with
> Delphi?
> > >Quite frankly, I find it just too cutesy-poo for words to replace
> good-old
> > >  i := i + 1;
> > >with
> > >  inc(i)

> > /==== [ from the Delphi Help ]
> > |  Category
> > |    ordinal routines
> > |  procedure Inc(var X [ ; N: Longint ] );
> > |
> > |  Description
> > |  The Inc procedure adds one or N to the variable X.
> > |  X is a variable of an ordinal type (including Int64), or of type
> PChar
> > |  if the extended syntax is enabled, and N is an integer-type
> expression.
> > |  Inc can be used on enumerated types or on pointer variables.
> > \====

> > I use it to kinda unify the look of the source code.

> Doesn't just work on PChars, works on other pointers too! Works out
> the size of what the pointer points to and all. Example at the bottom.

> It's kind of interesting. This was discovered in TurboPascal 6, by
> accident. But it was undocumented. And as far as I know it is still
> undocumented, but it works - even though the compiler is now
> completely different. If it was a compiler bug I could understand it
> working up to Delphi 1, but I would have expected it to disappear or
> be a documented feature in Delphi 2, because it must have taken work
> for this feature to have been coded up in the new compiler.

> FP

> Here's the example program for using Inc() to step a pointer variable
> through an array:

> {$apptype console}
> Type
>   t = Record
>         I:Integer;
>         S:String;
>       end;
>   pt = ^t;

> Const
>   a : Array[1..5] of t = (
>     (i:2; s:'First record'),
>     (i:4; s:'Second record'),
>     (i:6; s:'Third record'),
>     (i:8; s:'Fourth record'),
>     (i:0; s:'Fifth record')
>   );

> Var
>   p : pt;
>   i : Integer;
> Begin
>   p := @a[1];
>   For i := 1 to 5 do
>   begin
>     Writeln('Record ',i,': I=',p^.i,'; S=',p^.s);
>     inc(p);
>   end;
> end.

I'm just starting to learn a little Assembler. So, this is only a guess, but
it may be right.

the i:=i+1 is an Assembler Add command whereas
inc(i) is associated with the Assember's Inc command i.e. it's a dammed
sight faster!!!!!

also because it's a memory item that's being Inc'ed it has the side effects
that Franks talked about.

Re:REPORTED TO ISP


Quote
"Colin Dawson" <N...@cdawson.tele2.co.uk> wrote in message

news:tvsrch1kivc6a2@corp.supernews.com...
Quote

> "Frank Peelo" <fpe...@eircom.net> wrote in message
> news:9tlpvq$v38$1@kermit.esat.net...

> > "Udo Nesshoever" <newsgroup.re...@gmx.net> wrote in message
> > news:9tlk4g.sk.2@com.nesshoever.net...
> > > Hi Esther,

> > > >Which reminds me: what IS this inc() and dec() business with
> > Delphi?
> > > >Quite frankly, I find it just too cutesy-poo for words to
replace
> > good-old
> > > >  i := i + 1;
> > > >with
> > > >  inc(i)
...
> > > |  The Inc procedure adds one or N to the variable X.
> > > |  X is a variable of an ordinal type (including Int64), or of
type
> > PChar
> > > |  if the extended syntax is enabled, and N is an integer-type
> > expression.
> > > |  Inc can be used on enumerated types or on pointer variables.
> > > \====

> > > I use it to kinda unify the look of the source code.

> > Doesn't just work on PChars, works on other pointers too! Works
out
> > the size of what the pointer points to and all. Example at the

bottom.
...

Quote

> I'm just starting to learn a little Assembler. So, this is only a
guess, but
> it may be right.

> the i:=i+1 is an Assembler Add command whereas
> inc(i) is associated with the Assember's Inc command i.e. it's a
dammed
> sight faster!!!!!

It was certainly faster when it came out. Especially if you're using
an array reference or something like that:

  a[x*x+2] := a[x*x+2]+1;
would calculate (x*x+2) * sizeof(whatever type a's elements are) and
add that to the address of a, to get the value to be incremented. Then
it would add 1, and do the whole x*x+2blablabla thing again to find
out where to store the result. Maybe Delphi's optimiser is cleverer, I
don't know.

Quote
> also because it's a memory item that's being Inc'ed it has the side
effects
> that Franks talked about.

No, I don't think so. In the example I gave, you're incrementing a
pointer through an array. So you don't just add 1 to the pointer, the
compiler has to find out (at compile time) what the size of an element
in the array is, and add that amount. That's why I believe it wouldn't
have happened by accident. If it was accidental the pointer would be
incremented by 1 and would then be invalid - unless it was a pointer
to one-byte objects, like PChar. The documentation says only PChar can
be inc()ed like that, suggesting that it is an addition of 1, but
that's not how the program behaves.

FP

- Show quoted text -

Quote

Re:REPORTED TO ISP


On Fri, 23 Nov 2001 15:34:59 -0000, "Colin Dawson"

Quote
<N...@cdawson.tele2.co.uk> wrote:

<snip>

Quote

>I'm just starting to learn a little Assembler. So, this is only a guess, but
>it may be right.

>the i:=i+1 is an Assembler Add command whereas
>inc(i) is associated with the Assember's Inc command i.e. it's a dammed
>sight faster!!!!!

No, I doubt it -  
INC AX  is an assembler command and it simply adds 1 to AX

DEC AX  simply subtracts 1 from AX

What Frank is talking about is something that surprizes me - he is
saying that it adds an entire record length to a PChar

Realistically Delphi produces optimized ASM - and given some of the
tricks it gets up to with (the old chestnut) For loops - it would be
utterly amazing if a simple
    N:=N+1  
   did not translate into Inc( N )
   or INC N
after all antique BASIC compilers were doing that in 1982

The other variation of Inc is :  Inc( N, 5 )
now why the compiler should produce better code than : N := N + 5
is pretty confusing ( well it is not - it is just pretty unlikely )

I personally reckon that Inc( N ) was produced as a substitute for ++N

The stuff that Fran Peelo pointed out has made me wholeheartedly agree
with Esther - but on additional grounds - it is not just 'cute' but
damn obscure.

Actually downright dangerous.

BTW - ASM does not run much faster than well written Delphi - actually
well written ASM runs substantially slower than well written Delphi -
this is because of the RISC stuff introduced with the .486  -  'noddy'
ASM uses masses of 'small' instructions which is far faster than hand
crafted things using stuff like REPNE SCASB

A real bore.

Quote

>also because it's a memory item that's being Inc'ed it has the side effects
>that Franks talked about.

Re:REPORTED TO ISP


Quote
"J French" <je...@iss.u-net.com> wrote in message

news:3bfe7367.2180576@news.u-net.com...

Quote
> On Fri, 23 Nov 2001 15:34:59 -0000, "Colin Dawson"
> <N...@cdawson.tele2.co.uk> wrote:

> <snip>

> >I'm just starting to learn a little Assembler. So, this is only a
guess, but
> >it may be right.

> >the i:=i+1 is an Assembler Add command whereas
> >inc(i) is associated with the Assember's Inc command i.e. it's a
dammed
> >sight faster!!!!!

> No, I doubt it -
> INC AX  is an assembler command and it simply adds 1 to AX

> DEC AX  simply subtracts 1 from AX

> What Frank is talking about is something that surprizes me - he is
> saying that it adds an entire record length to a PChar

No, not to a pchar. To a pointer that points at something bigger than
what pchar points at.

If you inc() a pchar it points to the next char in the array. You'd
expect that. It just means adding 1 to the pointer. The amazing thing
is that if you inc() a pointer to something bigger, it works out how
much bigger and increments the pointer by that amount - so it will
step other pointer types through arrays as well. Not just pchar. But
pchar is the only one that is documented. The big surprise is that
DELPHI GETS IT RIGHT although the documentation suggests that it
shouldn't even compile.

Inc(x) increments x. If x involves complex addressing it can improve
readability. (In one of the worse examples I saw, the 'x' was an
expression in which an array element was used as a parameter to a
method which returned a pointer to the value to be incremented. It
wasn't exactly obvious at first sight that the value being set to x+1
was the same variable as x in the first place.)

Personally, I think inc(x); is more readable than x := x+1, but you
don't notice with trivial examples. For ugly values of x, the
difference can become noticable.

- Show quoted text -

Quote
> Realistically Delphi produces optimized ASM - and given some of the
> tricks it gets up to with (the old chestnut) For loops - it would be
> utterly amazing if a simple
>     N:=N+1
>    did not translate into Inc( N )
>    or INC N
> after all antique BASIC compilers were doing that in 1982

> The other variation of Inc is :  Inc( N, 5 )
> now why the compiler should produce better code than : N := N + 5
> is pretty confusing ( well it is not - it is just pretty unlikely )

> I personally reckon that Inc( N ) was produced as a substitute for
++N

> The stuff that Fran Peelo pointed out has made me wholeheartedly
agree
> with Esther - but on additional grounds - it is not just 'cute' but
> damn obscure.

> Actually downright dangerous.

I'd have to disagree. It does what it says on the tin. But it also
does other stuff.

You're right, it is ++N, but also p++ for stepping pointers through
arrays.

FP

Re:REPORTED TO ISP


On Fri, 23 Nov 2001 22:13:07 +1300, e_...@my-deja.com (Esther

Quote
Michaels) wrote:
>In article <221120011716099729%gwestonREM...@CAPShome.com>, Greg Weston
><gwestonREM...@CAPShome.com> wrote:

>>In article <0dsqvts38v79489u0tsmdji63fkua97...@4ax.com>, Dodgy
>><Do...@earth.planet.universe> wrote:

>>> On Thu, 22 Nov 2001 21:27:32 +0100, "Dirk Claessens"
>>> <will.bou...@back.com> waffled on about something:

>>> >NumberOfSpammers := NumberOfSpammers - 1; <g>

>>> Surely you mean

>>> dec(numberofspammers);

>>Either is fine...

>Which reminds me: what IS this inc() and dec() business with Delphi?

I believe it's Pascal, not Delphi.

Quote
>Quite frankly, I find it just too cutesy-poo for words to replace good-old
>  i := i + 1;
>with
>  inc(i)

>ARE there good reasons for using the latter?

Not so clear how much difference it makes these days
with optimizing compilers. But in the old days the
point was (and possibly still is) that inc increments
the variable "in place", as opposed to i:= i + 1,
which reads the value of i from somewhere to somewhere,
adds 1 to the value, and then writes the result back
to i. inc should be more efficient (again, it certainly
was more efficient years ago, how much it matters these
days is not clear.)

Quote
> (Apart from fewer
>keystrokes, that is -- almost never a good reason, IMHO)
>--
>Esther Michaels
>Please respond to newsgroup; I don't check my mail account

David C. Ullrich
Go to page: [1] [2]

Other Threads