 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> __normal_iterator& operator++() { ++_M_current; return *this; }
>
> That's the ++ operator for one of the STL iterators. And it does make
> sense to do it this way...other operators have to do more complex
> things, but it still makes sense to have a ++ operator.
Damn, I'll grant you that's a good example :)
> > prevents people writing lines like a = b + 3*(c-d), which looks
> > perfectly innocent, but could be a major bottleneck.
>
> All the coder has to do is look at the types being worked on.
Which is not as easy as just looking at the name of the function being called. I
realise this sounds messy and cumbersome to you, but this "mess" is actually
information that we find useful for our application.
> And this
> still isn't an argument against the existance of operator overoading.
I never said it was!!!
I like operator overloading, I'm just explaining why we don't use it where I
work (or indeed at the last place I worked either).
> > We like the clunkier syntax *because* it is harder to use and requires more
> > thought from the programmer. In our situation this is a good thing.
>
> But it requires more thought about the wrong things...I don't see how it
> can help.
For us, these are not the wrong things, these are the things we want people to
think about. In most OO programming applications you want to free people to
think at a higher level, we do not. In fact we seldom even use objects and
inheritance, because we prefer to keep things at a lower level than that.
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Game coding and movie special-effects both have the advantage that once
> released, you're likely to never look at the code again. (Well, at least
> until they started doing MMORPGs and such.)
Not true, we do sequels. Every game I've worked on has used elements of an
engine from an earlier game, so we try to write code that helps us do that. For
our applications it is more useful to see which function is being called than to
see a simpler looking piece of code that has a complex back end.
I guess what I'm saying is normal people look at a piece of code to work out
what it does, games programmers look at it to see how it does it.
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40391f1d$1@news.povray.org>, "Tek" <tek### [at] evilsuperbrain com>
wrote:
> > All the coder has to do is look at the types being worked on.
>
> Which is not as easy as just looking at the name of the function
> being called. I realise this sounds messy and cumbersome to you, but
> this "mess" is actually information that we find useful for our
> application.
I've written a raytracer using vectors that use operator overloading. It
was much easier to see what the code did than it is in POV, which uses
macros for the vector operations.
> > And this
> > still isn't an argument against the existance of operator overoading.
>
> I never said it was!!!
Yes you did...in a reply to one of my earlier messages:
> > I am. I definitely would want operator overloading. I've never seen a
> > good argument against it..."you can make the plus operator multiply" is
> > not a good argument. I can make a "plus()" method that multiplies as
> > well...I can also do a lot of useful things with the ability to use
> > operators with my own types.
>
> Well, I know a good argument against it. So good in fact that it's the reason
> why every games programmer I know doesn't use operator overloading: It hides
> processing.
> > But it requires more thought about the wrong things...I don't see how it
> > can help.
>
> For us, these are not the wrong things, these are the things we want people
> to think about.
If you don't know anything about optimization. You optimize the big
things first, algorithms and specific bottlenecks. You do the smaller,
more work for the return items later, if necessary. By forcing more
focus on every little operation done, you make it more likely that some
larger problem will go unnoticed, and you make the programmer waste time
they could be spending doing actually useful optimizations.
> In most OO programming applications you want to free people to
> think at a higher level, we do not. In fact we seldom even use objects and
> inheritance, because we prefer to keep things at a lower level than that.
Frankly, I don't think you understand OO programming. Unless you use
virtual functions, inheritance has zero overhead. If you have virtual
functions, overhead is still miniscule. And abstracting things can be of
great help in creating a tight, efficient module that is still both easy
to use and understand. And I don't buy your argument about vector-matrix
multiplication...if you're doing high-performance code, you should
always be aware of the types you're working with.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4038f726@news.povray.org>, Darren New <dne### [at] sanrrcom>
wrote:
> Warp wrote:
> > Int foo = container.size(); // <- gets a *reference*
> > foo -= 100; // Ooops! The container breaks badly!
>
> In this case, you'd make the -= operator return a new reference to be
> assigned to foo.
You make the initial = create a copy. The actual copy operation may be
done later, in the -= (copy on write), but from the point of view of the
user of the code, the -= operator should modify the value of the object
on the left hand side, not create a new one.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4038f64d$1@news.povray.org>, Darren New <dne### [at] sanrrcom>
wrote:
> > wouldn't you (unless you want to make the language so that it does
> > not support virtual functions, which would limit its OO capabilities
> > by a whole lot).
>
> Well, then it wouldn't be OO at all, as you wouldn't have any dynamic
> dispatch.
Oh? Objective C doesn't have anything called virtual functions. It has
methods and messages instead. And they're not the same thing...the
messaging model is a bit more flexible than the member function call
model.
> > Someone will inevitably use it in the wrong way and his code can then
> > break with an updated version of the library.
>
> Interestingly enough, C# actually addresses this problem. Nice language,
> that.
Could you clarify this?
C# does sound like a good language from what I've heard, too bad it's
MS-only.
(Don't say Mono...it's incomplete, and will always be so...its existance
only gives people something to point at when claiming C# isn't MS-only.)
> That's actually what Eiffel does. You might want to look into it. It
> even goes a step farther, in that it allows you to restrict (for
> example) what values a child object is allowed to return from a member
> function it overrides.
So the superclass can define that a method returns a real value between
0 and 1, and subclass overrides must remain in that range? This is one
of Eiffel's design-by-contract features, right?
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I've written a raytracer using vectors that use operator overloading. It
> was much easier to see what the code did than it is in POV, which uses
> macros for the vector operations.
Well yes, I'm not debating that. I'm saying for what you're doing it's better to
deal with things on a cleaner more mathematical basis, but for what I do at work
it's better to deal with things on a more technical implementation-based level.
> > > And this
> > > still isn't an argument against the existance of operator overoading.
> >
> > I never said it was!!!
>
> Yes you did...in a reply to one of my earlier messages:
No, I said it was an argument against the *use* of operator overloading, not
it's existence. I'm not saying it should never be used, I'm just explaining why
we don't use it.
> If you don't know anything about optimization. You optimize the big
> things first, algorithms and specific bottlenecks. You do the smaller,
> more work for the return items later, if necessary.
Which still is not a reason to hide what the code is actually doing.
Besides, a good optimiser does neither of those, you begin by profiling the
system extensively to ascertain what is slow. It doesn't matter how cumbersome
the big concepts are, or how badly implemented the low level things are, all
that matters is how long things take.
> By forcing more
> focus on every little operation done, you make it more likely that some
> larger problem will go unnoticed,
This is a valid point, but you must see that this is a balance. Depending on
your needs you choose how high/low level you want to be. If you only care about
the simplest processes you work in assembler, if you care most about the overall
structure you code in OO. We have gravitated to a point a little above the
functionality supported by C, and a little below true OO C++. This is the
balance that works for us, but I do not suggest it is applicable to all
situations.
> And abstracting things can be of
> great help in creating a tight, efficient module that is still both easy
> to use and understand.
High level code can be very good for dealing with high-level concepts. And
certainly as the games become more sophisticated people move naturally to higher
level concepts. But at this point in time the people I have worked with feel
that we're still dealing with concepts best expressed by C-style code with just
a few C++ features.
> And I don't buy your argument about vector-matrix
> multiplication...if you're doing high-performance code, you should
> always be aware of the types you're working with.
But how do I gain this awareness if it's not my code? Last project I was on had
20 programmers, and I was one of the main people assigned to optimise things. It
was more important to me to see how the code worked at a lower level than to see
nice clean algorithms.
However I know there are other games companies that go all out for OO code,
because they wish to code at a higher level. They do not produce such efficient
code as we do :)
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4037f302@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sha### [at] hotmailcom> wrote:
> > But it can happen.
>
> Of course it can happen. And it can also happen that a function
> named "multiply" calculates the square root. But that doesn't mean
> it's not avoidable. It just means the design of the program/library
> has a flaw.
>
But is it always a flaw?
For example, say you want to manipulate an image:
Fade(Object.DC)
function Fade(myDC AS DC ByRef)
Do you want Fade to have *only* the contents of the DC, which could be
40x40 or 80x20 or even 1600x1? No, you pass it a reference to the DC, so
you can manipulate the original contents.
You could also pass the DC to the function with it automatically making a
copy by using it like:
Object.Image = Fade(Object.DC)
function Fade(myDC AS DC ByVal)
But you are performing two copies here, instead of just manipulating the
actual data. This will take more time and added memory to accomplish. Why
exactly do you think the first version is bad design? It makes a whole
heck of a lot more sense that wasting extra processor cycles making
copies, instead of performing the effect on the original image. Yes, this
may not be the 'best' way in some case, but what if you do this:
set a = GetCompatibleDC(Object.DC)
Grayscale(a)
Fade(a)
FindEdges(a)
Object.DC = a
That eliminates 6 extra copy processes you have to make by passing the
contents of the DC, instead of a reference to the one copy your actually
needed. This is not *bad* library design.
--
void main () {
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tek" <tek### [at] evilsuperbraincom> wrote in message
news:40391d91$1@news.povray.org...
> "Warp" <war### [at] tagpovrayorg> wrote in message
news:4038bb04@news.povray.org...
> > Tek <tek### [at] evilsuperbraincom> wrote:
> > > We like the clunkier syntax *because* it is harder to use and requires
more
> > > thought from the programmer. In our situation this is a good thing.
Thank you, Warp. This has been a puzzle for me for some time now: why do so
many programmers write such awful code? At first, I thought it was because
they didn't want other programmers to understand it because they could be
replaced. Then, I figured it was just because they were engineers with no
sense of cognitive psychology. Finally, I read your message, and now I
understand it: these engineers are doing the world a /favor/ by making code
hard to read because it makes other programmers think more. I get it now!
It's alturism.
Don't send me a resume.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40392ffb@news.povray.org>, Darren New <dne### [at] sanrrcom>
wrote:
> Christopher James Huff wrote:
> > Oh? Objective C doesn't have anything called virtual functions.
>
> They're not called that, but that's the effect. Messages are dynamically
> dispatched to the appropriate method.
It's more than a different name for the same thing. Virtual functions
are just function calls that are looked up at run-time through a virtual
function table. Message lookup is based on a message selector that is
itself a piece of data the program can manipulate. You can forward
messages that you can't handle, for instance. You can even send them to
objects on other machines. The overhead is higher, but surprisingly low.
Virtual functions are just a specific implementation detail, not a core
requirement for object oriented languages.
> I've found it useful to learn a bunch of different languages, if only to
> understand useful paradigms, even if I never obtain a compiler for them.
I agree. If you don't keep learning new things, you'll end up being
unable to.
BTW, have you ever looked at Dylan?
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4039335d$1@news.povray.org>,
"Dan P" <dan### [at] yahoocom> wrote:
> > > > We like the clunkier syntax *because* it is harder to use and requires
> more
> > > > thought from the programmer. In our situation this is a good thing.
>
> Thank you, Warp. This has been a puzzle for me for some time now: why do so
> many programmers write such awful code? At first, I thought it was because
> they didn't want other programmers to understand it because they could be
> replaced. Then, I figured it was just because they were engineers with no
> sense of cognitive psychology. Finally, I read your message, and now I
> understand it: these engineers are doing the world a /favor/ by making code
> hard to read because it makes other programmers think more. I get it now!
> It's alturism.
>
> Don't send me a resume.
Warp didn't write that. And even if he had, your attack would have been
completely unwarranted. Speaking as a member of the TAG, please stop
these personal attacks, insults, and other anti-social behavior. Now.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
