Board index » delphi » OOP isn't so hard

OOP isn't so hard

"Bojidar Alexandrov" <b...@kodar.net> wrote

Quote
> Kristofer Skaug wrote:
> > I profiled it using Zprof and found it, on the average, twice as slow
> > (on my P4/1700) as:

> > procedure Swap2(var a, b : integer);
> > var c:integer;
> > begin
> >    c := a;
> >    a := b;
> >    b := c;
> > end;
> > Hmmm. So that's a lot of binary mumbo jumbo *and* slower code... ??
> But 4 bytes fewer memory :))))

Won't that be register only?
 

Re:OOP isn't so hard


Quote
> Beg to differ. I don't mind placing extra paranthesis

I always fully parenthesize, but I'm a little {*word*7}about this.

Quote
> (FileExists(A) = False) Or (FileExists(B))

> looks very clumsy to me and is no clearer than

> (Not FileExists(A)) Or (FileExists(B))

how about:

if  ((FileExists(A) = false) or (FileExists(B) = true)) then

Quote
> Maybe a new language syntax is in order where the compiler will search for
> the substring "NOT" in function calls and negate the result automagically

:)

Not a good idea.

--
Brian Moelk
bmo...@NObrainendeavorSPAM.FORcomME
http://www.brainendeavor.com

Re:OOP isn't so hard


Quote
On Thu, 13 Mar 2003 08:19:21 -0700, Josh P. wrote:
> Maybe a new language syntax is in order where the compiler will search for
> the substring "NOT" in function calls and negate the result automagically :)
> This will instantly double the number of boolean functions in your libraries
> too!

<g>
Either its a simple language, or the compiler needs to know grammar as
well:

FileExists()
must become
FileDoesntExist()

;-)

johannes

Re:OOP isn't so hard


Quote
"Brian Moelk" <bmo...@NObrainendeavorSPAM.FORcomME> wrote in message

news:3e70a3db$1@newsgroups.borland.com...

Quote
> > > Why would I want my Delphi code to be language nuetral?

> > Because the thread is about OOP ;-))
> > Plus I wanted to say that <G>

> And that's why you used a Set type? <g>

hmm?

Re:OOP isn't so hard


Quote
>     if FJobList.Count>0 then Result := TJob(FJobList[0]).GetJobName()
> else Result='';
>     for i := 1 to FJobList.Count-1 do
>          Result := Result + ',' + FJobList[i].GetJobName;

Actually, this results in one extra if condition with two statements... I
think:

for i:= 0 to FJobLIst.Count-1 do
   Result := Result + FJobList[i].GetJobName;
Delete(Result, Length(Result,1);

would probably work the same or better (wouldn't it?)

--
Deepak Shenoy (TeamB)
Agni Software
http://www.agnisoft.com

Re:OOP isn't so hard, Maybe it is


Quote
> > procedure Swap (var a, b : integer);
> > begin
> >    a := a xor b;
> >    b := a xor b;
> >    a := a xor b;
> > end;

> I profiled it using Zprof and found it, on the average, twice as slow

How about

a := a+b;
b := a-b;
a := a-b;

Probably is slower, just thinking how much though...

--
Deepak Shenoy (TeamB)
Agni Software
http://www.agnisoft.com

Re:OOP isn't so hard, Maybe it is


In article <3E709370.9000...@nospam.codeline.dot.net>, Erwien Saputra
wrote:

Quote
> The problem with the first statement, you need to think whether the
> FileExists returns true or false, then perfrom the 'not' operation, then
> you can decide whether the if statements will be executed or not.

Really? Reads like standard English to me.

Mike Orriss (TeamB and DevExpress)

Re:OOP isn't so hard, Maybe it is


Quote
Deepak Shenoy (TeamB) wrote:

  Actually, this results in one extra if condition with two statements... I

Quote
> think:

> for i:= 0 to FJobLIst.Count-1 do
>    Result := Result + FJobList[i].GetJobName;
> Delete(Result, Length(Result,1);

Deepak,

 > would probably work the same or better (wouldn't it?)
In practice it would work the same. If we get to nanoseconds it will
really work a little worse, but never better.

   There are lots of "hidden ifs" on the delete also, because it checks
for position beeing>0, position<=length, count+position<=length, etc. If
it didn't, your code would crash also on Count=0. (would try to delete
char 1 from a 0 bytes string)

But anyway it doesn't matter at all, because the "if" overhead will
never make a difference, if you consider that each string concatenation
  could mean a memory relocation. And I am not sure about the delete,
but it might end up using some more extra bytes.

I don't know about the numbers, but let's imagine the memory manager
allocates 4 bytes each time you expand the string.
if you have a 16 byte string, you have to allocate 20 bytes for the
string and the ','. When you delete the ',' you leave a hole of 4 bytes.

But anyway, as I said, this doesn't mean anything if we are not using
hugue lists, and in that case no one of the methods exposed here would
be good.

That's why I didn't care to put the "begin" "end" that was suggested by
Alessandro and Johannes, because there are more words to write and no
real performance gain.

Regards

Re:OOP isn't so hard, Maybe it is


"Deepak Shenoy (TeamB)" <shenoy.donotspam@agnisoftdotcom> wrote in message
news:3e70aa9e@newsgroups.borland.com...

Quote
> Actually, this results in one extra if condition with two statements... I
> think:

> for i:= 0 to FJobLIst.Count-1 do
>    Result := Result + FJobList[i].GetJobName;
> Delete(Result, Length(Result,1);

> would probably work the same or better (wouldn't it?)

That would result in "TrollProgramme" insetad of "Troll,Programmer" (notice
the "r" at the end missing with your alghoritm).

Re:OOP isn't so hard, Maybe it is


Quote
> > > > Why would I want my Delphi code to be language nuetral?

> > > Because the thread is about OOP ;-))
> > > Plus I wanted to say that <G>

> > And that's why you used a Set type? <g>

> hmm?

TJob = (jTroll, jProgrammer, jBurgerFlipper);
TJobs = set of TJob;

What other OO language supports this?

--
Brian Moelk
bmoel...@SPAMbrainendeavorFOR.MEcom
http://www.brainendeavor.com

Re:OOP isn't so hard, Maybe it is


Quote
"Brian Moelk" <bmo...@NObrainSPAMendeavorFOR.MEcom> wrote in message

news:3e70bf43@newsgroups.borland.com...

Quote
> What other OO language supports this?

C# has enumerateds so it sort of works there too (differently but the
concept is the same).
Anyways, I get your point now. Many other OO languages are poorer and don't
have enums <G>

Re:OOP isn't so hard, Maybe it is


Quote
> Anyways, I get your point now. Many other OO languages are poorer and
don't
> have enums <G>

Indeed.  The-Unamed-Language-In-Reference is very silly about enums and many
other things....but I'm moving off topic and onto my SoapBox.

--
Brian Moelk
bmoel...@SPAMbrainendeavorFOR.MEcom
http://www.brainendeavor.com

Re:OOP isn't so hard, Maybe it is


Quote
> Deepak,

>  > would probably work the same or better (wouldn't it?)
> In practice it would work the same. If we get to nanoseconds it will
> really work a little worse, but never better.

>    There are lots of "hidden ifs" on the delete also, because it checks
> for position beeing>0, position<=length, count+position<=length, etc. If
> it didn't, your code would crash also on Count=0. (would try to delete
> char 1 from a 0 bytes string)

That's true...but since System.Delete() was in assembly I thought it might
have been more optimized than a regular IF.

Quote
> But anyway it doesn't matter at all, because the "if" overhead will
> never make a difference, if you consider that each string concatenation
>   could mean a memory relocation.

That overhead exists anyways in both cases...a ',' + Result and a Result +
',' both have the concat problem.

Quote
>  I don't know about the numbers, but let's imagine the memory manager
> allocates 4 bytes each time you expand the string.
> if you have a 16 byte string, you have to allocate 20 bytes for the
> string and the ','. When you delete the ',' you leave a hole of 4 bytes.

True - but I wasn't thinking of optimizing memory at all - more on the lines
of optimizing speed.

--
Deepak Shenoy (TeamB)
Agni Software
http://www.agnisoft.com

Go to page: [1] [2] [3] [4] [5] [6] [7] [8]

Other Threads