gamedevlists-general — List for discussing general game development issues

Re: [GD-General] Eiffel

[Thatcher U. <tu...@tu...>]

On Dec 22, 2001 at 04:30 -0800, Jesse Jones wrote:
> 
> Unfortunately MI has a bad reputation in C++. Even people who should 
> know better like Scot Myers rag on it. But essentially all of the 
> problems with MI in C++ are because of virtual base classes. So how 
> do you avoid virtual base classes? By avoiding diamond shaped 
> inheritance hierarchies.
> 
> One way to do this is by using mixin classes. You have your main-line 
> classes like Widget or Monster or whatever and then you have mixin 
> classes like ReferenceCountedMixin or ObserverMixin or whatever. 
> Mixins only descend from other mixins so you never wind up with the 
> diamond of death.

I've been pondering this.  I've always depended on virtual inheritance
for effective mixins.  For example, how do you implement smart
pointers to mixins of ref-counted classes, without virtual
inheritance?  It would be great if I'm wrong, since virtual
inheritance is a PITA in some ways (in other ways, I think it's the
only usable form of C++ MI, but lets leave that aside for now).

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

RE: [GD-General] Objective Caml (was Ruby opinions)

[Brian H. <bri...@py...>]

> This is a big practical problem with everything other than 
> C/C++.

And Obj-C =)  And Java's JNI interface, while not perfect, at least
works.  I know Eiffel has some mechanism, but I'm not sure how good it
is.  I've never liked Lua's interface.  That you need to use an external
tool like tolua indicates to me that it's just not doing things the
right way.

> Actually, one thing that bothers me is lack of a native 
> 32-bit float type.  floats in OCaml are 64-bit.  I think that 
> will need to get fixed at some point.

I think new languages (and their designers) strive real hard for
orthogonality and minimizing confusing types, and inevitably practical
considerations rear their heads.  The original DEC Alpha didn't support
byte operations, which made a lot of things REAL slow -- their attitude
was that the future is 64-bit, and dropping back to
conversion/pack/unpack for byte support was just going to be a temporary
thing =)

Not to go off on a tangent, I think Java ditching "unsigned" as a type
was probably a good idea.  IIRC Lua is missing integer support?  That's
a bit of an issue as well.  Or the belief that languages shouldn't have
preprocessors because the C preprocessor was so gross; inevitably you
lose major functionality like "#ifdef 0/#endif" and the language
designers defend it to the end.

Brian

Ref-counting vs. GC was RE: [GD-General] The D Programming Language

[Brian H. <bri...@py...>]

Yes, I'm the king of renaming subject lines.

> IMO the time for real GC in game engines is just about ripe. 

I concur.

> Reference counting via smart pointers is not unheard of in 
> C++ game engines, and and OCaml-like GC should be a big 
> improvement over ref counting.

The problem is that systems with arbitrary pointers a ref-count system
can lead to really sloppy allocation and deletion patterns.  This can
cause harsh memory fragmentation, which in turns leads to serious
problems for games that need very long up times (e.g. servers).

With a real GC system and opaque references then it should be able to
compact behind the scenes, alleviating this problem.  With a ref-count
system, you'll have to overload new, delete, etc. to make sure that
everything is done through the appropriate managed heaps, which adds yet
more complexity for the programmer to deal with.

Brian

Re: [GD-General] Re: Simulating constrained genericity in C++

[Patrick M D. <pa...@wa...>]

On Thu, 27 Dec 2001, Joe wrote:

> So assuming point2d was an interface too, wouldn't you
> just do
> interface point3d extends point2d{
> public float z();
> }
> and then your old implimentation should work
>

Here is a more compelling example directly from the JDK.

The interface AbstractCollection contains a number of methods that require
more functionality than is actually required:


    public boolean containsAll(Collection c)
    public boolean addAll(Collection c)
    public boolean removeAll(Collection c)
    public boolean retainAll(Collection c)

Each of these could be implemented on a class that implemented a single
method (e.g. 'contains' or 'iterator').  There was a proposal to
introduce additional interfaces like so:

    public boolean containsAll(Container c)
    public boolean addAll(Iterable c)
    public boolean removeAll(Container c)
    public boolean retainAll(Container c)

But this was rejected because it increased the number of interfaces that
were required.

There's nothing the end-programmer can really do about this without
breaking compatibility with the standard libraries.  This kind of problem
is pervasive throughout languages like Java and C++ that do not
separate the notions of inheritance and subtyping.  I suspect that you
could find similar problems in Eiffel libraries as well.

Patrick

Re: [GD-General] Objective Caml (was Ruby opinions)

[Thatcher U. <tu...@tu...>]

On Dec 24, 2001 at 01:58 -0500, Patrick M Doane wrote:
> To provide a more objective viewpoint on OCaml, here are some thoughts I
> have on how I think it can be improved:
> 
>   - more bindings to native os libraries

This is a big practical problem with everything other than C/C++.
I've done some messing around with binding Lua to C-based APIs, and
found SWIG to be pretty good, but it's still not as easy as "#include
<libraryheader.h>".

I'm also trying to learn OCaml.  It's tough going so far -- almost
nothing about it is intuitive to me.  But it has all the right
marketing bullet-points, so I'm plugging away.

Actually, one thing that bothers me is lack of a native 32-bit float
type.  floats in OCaml are 64-bit.  I think that will need to get
fixed at some point.

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

Re: [GD-General] The D Programming Language

[Thatcher U. <tu...@tu...>]

On Dec 27, 2001 at 01:26 -0500, Patrick M Doane wrote:
> 
>   - While modern garbage collectors can be very efficient, I still worry
> that they may not be appropriate for gaming.  I will be interested to see
> the results of Chris Hecker's work with OCaml, which has an excellent GC
> implementation.  The D programming language might want to consider memory
> management via regions.  This can be a good compromise for realtime
> applications.

IMO the time for real GC in game engines is just about ripe.
Reference counting via smart pointers is not unheard of in C++ game
engines, and and OCaml-like GC should be a big improvement over ref
counting.

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

Re: [GD-General] Re: Simulating constrained genericity in C++

[Patrick M D. <pa...@wa...>]

On Thu, 27 Dec 2001, Joe wrote:

> So assuming point2d was an interface too, wouldn't you
> just do
> interface point3d extends point2d{
> public float z();
> }
> and then your old implimentation should work

Of course, but you may not always be able to make such modifications in
practice.

Patrick

Re: [GD-General] Re: Simulating constrained genericity in C++

[Joe <dar...@ya...>]

So assuming point2d was an interface too, wouldn't you
just do
interface point3d extends point2d{
public float z();
}
and then your old implimentation should work

>
>Sure, here is the initiale code in Java (or something fairly close, I'll
>probably get the syntax wrong):
>
>interface point3d {
>  public float x();
>  public float y();
>  public float z();
>}
>
>class point3d_impl implements point3d { ... }
>
>Now somebody has written some code that only works on 2d points, like so:
>
>  public int dist(point2d p1, point2d p2)
>
>where point2d has the expected interface definition.  Can we pass objects
>of type point3_impl to this method?  If inheritence defines subtyping
>(with the implements keyword being a form of inheritence)  then one
>cannot.  If names and their types define the subtyping relationship then
>this is perfectly legal.
>
>This isn't the best motivating example, but it should be easy enough to
>understand the principle.
>
>Patrick
>
>
>_______________________________________________
>Gamedevlists-general mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>

RE: [GD-General] Re: Simulating constrained genericity in C++

[Patrick M D. <pa...@wa...>]

On Wed, 26 Dec 2001, Brian Hook wrote:

> >When a language relies on inheritence for subtyping relationsips, then
> >additional effort is required when an interface is created after a
> >particular implementation is coded.
>
> Can you give an example of this?

Sure, here is the initiale code in Java (or something fairly close, I'll
probably get the syntax wrong):

interface point3d {
  public float x();
  public float y();
  public float z();
}

class point3d_impl implements point3d { ... }

Now somebody has written some code that only works on 2d points, like so:

  public int dist(point2d p1, point2d p2)

where point2d has the expected interface definition.  Can we pass objects
of type point3_impl to this method?  If inheritence defines subtyping
(with the implements keyword being a form of inheritence)  then one
cannot.  If names and their types define the subtyping relationship then
this is perfectly legal.

This isn't the best motivating example, but it should be easy enough to
understand the principle.

Patrick

RE: [GD-General] Re: Simulating constrained genericity in C++

[Brian H. <bri...@py...>]

I realize I may have inadvertently given the idea that Obj-C doesn't
support static type checking very well (given my examples were that a
client could query if an object supported a message and also what to do
when a message wasn't understood).

Just to be clear, Obj-C also has static type checking just like C++ if
you statically type something.  In addition, Obj-C has the notion of
formal protocols which seem to be pretty much identical to Java
interfaces.  A class can conform to a formal protocol, and if it does
conform than a client knows that all the protocol messages can be
accepted.

Brian

RE: [GD-General] Re: Simulating constrained genericity in C++

[Brian H. <bri...@py...>]

At 02:24 AM 12/27/2001 -0500, Patrick M Doane wrote:
>What happens to these messages that are not understood?

Run-time error.

>Are these messages simply ignored?  Does the recipient simply pass them on 
>to another more
>knowledgeable target? Or can the recipient decode the types and content of
>the message?

First off, the caller can verify that the message receiver understands the 
message:

if ( [obj respondsToSelector:@selector(someMessage)] )
    [obj someMessage];

Second, the recipient can optionally forward stuff.  Before the run-time 
system pukes because a message isn't understood, it will actually send 
another message, forwardInvocation:, to the message's target with an 
NSInvocation object, at which point you can try to recover or do something 
else appropriate.  In fact, the way the system pukes is it actually calls 
up to the default NSObject -forwardInvocation message which executes 
-doesNotRecognizeSelector.  So you can override this message and do the 
appropriate thing (like multiplex unknown messages to delegates).  That, to 
me, is very cool.

http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/5RunTime/Forwarding.html

>BTW, I'm curious to see something unbelievably powerful! :)

FWIW, I don't know Obj-C very well, at all.  The docs do a much better job 
at describing this.  I'm not a language lawyer by any means, I just happen 
to "click" with Obj-C much more than I do with other languages in terms of 
what feels intuitively right.

>When a language relies on inheritence for subtyping relationsips, then
>additional effort is required when an interface is created after a
>particular implementation is coded.

Can you give an example of this?

> > For example, some STL classes require operator < to be overloaded,
> > which goes back to a thread on another mailing list where I said that
> > function name overloading is a Bad Idea so long as you're using text
> > as your representation because you can't find, for example, every
> > place you're doing a comparison between two specific types.
>
>Don't virtual methods suffer from the same problem. or do you consider
>that another form of function name overloading?

Yes, virtual functions definitely suffer from the same problem, but in my 
experience the frequency of name collisions is much lower through 
inheritance than through function name overloading (either "real" 
overloading or just using the same names).

Brian

Re: [GD-General] The D Programming Language

[Brian H. <bri...@py...>]

At 01:32 AM 12/27/2001 -0500, Patrick M Doane wrote:
>On Mon, 24 Dec 2001, Brian Hook wrote:
> > At 10:44 PM 12/24/2001 -0800, Grills, Jeff wrote:
> > >It seems to retain the things I use most in C++, strips away a lot of
> > >cruft I don't care for, and adds a lot of things I really wish C++ had.
> >
> > This actually describes Java (for me).  I'm still torn between Java and
> > Obj-C.  The sheer power from a dynamically typed system is something I'd
> > hate to eschew, which is why Obj-C keeps lingering in the background.
>
>Are you claiming that Jeff's description of why he likes D is why you like
>Java or that the D language looks a lot like Java to you?

The former (i.e. what he likes about D is what I like about Java).

>I'm particularly interested in the struggle between static / dynamic type
>systems.  Why do you feel that dynamic typing is so much more powerful?
>Could you provide some concrete examples?

Maybe "powerful" is the wrong term, but "convenient" trivializes it too 
much, so somewhere in between.

Case in point: Obj-C has the notion of an "informal protocol".  All that 
means is that you can ask that some object responds to some message.

id foo = [[Foo alloc] init ];

[foo ThisIsSomeRandomMessage]; //This will ALWAYS compile

When the above is run, if the class "Foo" doesn't understand that message, 
it will generate a run-time exception.

Small aside -- if you had put "Foo *foo" instead of "id foo", it would have 
generated a warning that "Foo does not understand ThisIsSomeRandomMessage", 
so you get the benefits of both static type checking and dynamic typing 
depending on your mood.  The rule is to "specify type when you know it".

A more concrete example is delegation.  You can assign a delegate to an 
object, and the delegate is responsible for handling some random task.  In 
C you would do this with a callback and some parameters:

void (*delegatefunc)(void*parms);

p->registerDelegateFunc( delegatefunc );

You'd then do a bunch of casting and what not in your delegatefunc to get 
it to work.  In C++, you'd also have to make sure it was friends or had 
appropriate permissions, etc.

In C++, you would probably use MI, which is overkill IMO:

class Foo : public SomeDelegateClass. DelegateClass2, yadda yadda
...

Foo *f = new Foo;
p->registerDelegate( f );

This gets real cumbersome when you have a centralized object, like your 
application, as a delegate for a dozen other objects.

In Obj-C, common places for delegates include "shouldWindowClose" and 
things like that.  Before closing, the window will ask its delegate if it's 
okay to close, etc.  Cocoa, in fact, deprecates inheritance in favor of 
delegation.  Read the Cocoa docs when you get a chance (there are some 
basic introduction to Cocoa and Obj-C docs at the Apple site).

Another place this is nice is that you can get handy container classes that 
can be of any type without forcing gargantuan recompiles and difficult to 
read warnings/error messages.  Aside from technical issues, I think 
templates are difficult to decipher, debug and just plain use in common day 
to day practices.

Dynamically typed container classes are more convenient for me because 
you're not recompiling EVERYTHING just because you've changed how a 
container class works (or how you've instantiated one).  Since classes are 
first class objects (no pun intended), you can pass the class of an 
incoming object as a parameter to make a container of "things like that 
object".

These are pretty trite but common examples.  Post to comp.lang.objective-c 
for some better ones =)

> > But Java's GC and "portability" are also very tempting.
>
>I've heard a colleague describe Java as "write once, debug everywhere".

Early incarnations of Java definitely suffered from this, and I'm sure they 
still do.  Java is evolving rapidly, and while the JREs seem to be 
relatively stable, the libraries are constantly being upgraded, improved, 
fixed, etc.  The AWT->Swing transition and the original container classes 
-> Java collections were pretty major shifts.

So yeah, it's not perfect, which is why I put "portability" in quotes, 
however it's definitely better than trying to find a compiler and 
associated libs for each platform (such as with Eiffel).

>improvements in this area?  Is it a feasible language for developing
>serious games or is it better suited to in-house tools?

Well, there are "not serious" games written in Java (and Flash/Shockwave) 
all over the Web (www.popcap.com or www.gamehouse.com for examples), so it 
can definitely be done.  There are MUD servers written in Java also, and 
there was that Java version of Quake or Doom (JDoom?) that came out a while 
ago.  I plan on using Java for my own server technology, at least enough 
such that I can figure out if it's appropriate or not.

At a high level, I think Java should work fine for games of almost any 
type.  The few places that need to be optimized or that need to get to low 
level system resources (e.g. AGP allocated memory) can be handled through 
JNI, but in the end for a hardcore technology oriented game, the Java 
component would actually turn out to be very small.  For a game where the 
design took precedence over the technology (i.e. the technology was more of 
an implementation detail instead of a selling point) then I think Java 
should work fine.

Brian

RE: [GD-General] Re: Simulating constrained genericity in C++

[Patrick M D. <pa...@wa...>]

On Wed, 26 Dec 2001, Brian Hook wrote:

> So what does C++ use?  Anything at all?  Near as I can tell, from my
> ages old usage of templates, C++ is like a static version of Obj-C -- if
> the function call/operator overload doesn't exist that you need, you get
> a compile time warning (in Obj-C you can still send a message that isn't
> understood, which is unbelievably powerful).

What happens to these messages that are not understood? Are these messages
simply ignored?  Does the recipient simply pass them on to another more
knowledgeable target? Or can the recipient decode the types and content of
the message?

BTW, I'm curious to see something unbelievably powerful! :)

> >of this templates work more like objects in a dynamic language and
> >rely on name commonality.
>
> Right.  And I'm not sure if relying on name commonality is really a good
> design decision.

When a language relies on inheritence for subtyping relationsips, then
additional effort is required when an interface is created after a
particular implementation is coded.

One possible solution to this problem is to make a subclass of the
implementation and specify the new interface that it satisfies.
Unfortunately, this technique may not work when the object is created by a
factory.

So, using names (and their associated types) as a criteria for subtyping
can be a more flexible approach that enables more code reuse.

> For example, some STL classes require operator < to be overloaded,
> which goes back to a thread on another mailing list where I said that
> function name overloading is a Bad Idea so long as you're using text
> as your representation because you can't find, for example, every
> place you're doing a comparison between two specific types.

Don't virtual methods suffer from the same problem. or do you consider
that another form of function name overloading?

Patrick

Re: [GD-General] The D Programming Language

[Patrick M D. <pa...@wa...>]

On Mon, 24 Dec 2001, Brian Hook wrote:

> At 10:44 PM 12/24/2001 -0800, Grills, Jeff wrote:
> >It seems to retain the things I use most in C++, strips away a lot of
> >cruft I don't care for, and adds a lot of things I really wish C++ had.
>
> This actually describes Java (for me).  I'm still torn between Java and
> Obj-C.  The sheer power from a dynamically typed system is something I'd
> hate to eschew, which is why Obj-C keeps lingering in the background.

Are you claiming that Jeff's description of why he likes D is why you like
Java or that the D language looks a lot like Java to you?

I'm particularly interested in the struggle between static / dynamic type
systems.  Why do you feel that dynamic typing is so much more powerful?
Could you provide some concrete examples?

> But Java's GC and "portability" are also very tempting.

I've heard a colleague describe Java as "write once, debug everywhere".
Especially when used outside of a command-line / server environment, this
seemed to be very descriptive a few years ago.  Has Java made significant
improvements in this area?  Is it a feasible language for developing
serious games or is it better suited to in-house tools?

Patrick

Re: [GD-General] The D Programming Language

[Patrick M D. <pa...@wa...>]

Jeff,

Thanks for the pointer to the language.  This is one I hadn't heard of
before and it's always useful to check out new developments.

I feel that D has a lot to offer the game programming world.  Too bad
there is not an implementation to start playing with but there are some
really compelling features:

  - Upgrade path from C/C++ is easy and straightforward.  Integration
with other calling conventions are builtin to the language.

  - Excellent support in basic data types -- floating point is a major
focus of the language design.

  - Builtin support to facilitate good programming practices (e.g unit
tests, pre/post conditions, invariants)

  - Modules, which correspond to files, facilitate namespace management
rather than overloading classes with this responsibility.

  - Good array support - including dynamically resizing arrays,
multi-dimesional arrays (both jagged and rectangular), and associative
arrays.

The language still appears to be in the design phase, so this could be
a useful time to be in touch with the author and help shape its future.

Here are some initial thoughts on ways the language might be improved:

  - While modern garbage collectors can be very efficient, I still worry
that they may not be appropriate for gaming.  I will be interested to see
the results of Chris Hecker's work with OCaml, which has an excellent GC
implementation.  The D programming language might want to consider memory
management via regions.  This can be a good compromise for realtime
applications.

  - There are a number of unsafe features for which some kind of pedantic
option to the compiler will be useful (e.g. pointers in unions could
confuse the garbage collector).

  - No syntactic support for inner classes / function closures.  These are
extremely useful features to have although they introduce significant
complexity in the compiler.

  - It would be useful to allow for functions to exist outside of classes.

Any other opinions?

Patrick

On Mon, 24 Dec 2001, Grills, Jeff wrote:

>
> To throw another language into the mix:
>
> http://www.digitalmars.com/d/
>
> This language looks really promising to me.  It seems to retain the things I
> use most in C++, strips away a lot of cruft I don't care for, and adds a lot
> of things I really wish C++ had.  Since there isn't a compiler available for
> it yet, I'm sure that no one has extensive experience in it to understand
> the ugly spots.  Hopefully that will come soon enough to allow the designers
> the opportunity to fix the language before they end up with too much
> production code they don't dare to break (as certainly is the case in C++).
>
> j
> Jeff Grills
> Star Wars Galaxies
> Technology Director, Austin Studios
> Sony Online Entertainment Inc.
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>

RE: [GD-General] Re: Simulating constrained genericity in C++

[Brian H. <bri...@py...>]

> Sure, but most people don't overload that many methods. Just stuff 
> like the operators and an occasional named method now and then.

I wouldn't quite say that.  The problem with C++ is that there's a
temptation to use everything, and unfortunately a lot of people do.
Real, true expert C++ practitioners that A.) understand the language;
B.) understand how to build frameworks; and C.) know what esoteric
features should NOT be used so as not to alienate their users are few
and far between.

> Yup. It's kind of funny. What has it been? 50 years that people have 
> been designing general purpose programming languages? And what have 
> language designers come to agreement on? Goto's are bad? Even garbage 
> collection still has a bad reputation in many places...

Well, high level languages also had a bad reputation for a long time.
Crap, in my lifetime there were arguments over function pointers vs.
direct calls and how this would slow things down intolerably.

> Yeah, I really need to look into Cocoa. I'm a bit put off though 
> because it seems to be much more C-like than C++ if that makes any 
> sense. :-)

Obj-C, to me, is far more object oriented than C++.  Well, that's not
necessarily true, since that's open to interpretation.  I WILL say it's
a lot cleaner and more expressive for the stuff that I want to do.  You
can learn Obj-C in a day.  It's that simple.  And yet it still feels
more powerful than C++ because it just ditches the dogma of "static type
checking rules all" and says "screw it, we're doing this dynamically,
deal".  Lack of GC is my number one complaint, followed by its lack of
popularity.  Support by GCC is a pretty big benefit however, and it can
seamlessly work with C and C++ code these days, which is HUGE when
compared to other language's interface to C (Java is probably the most
pleasant, but even then, it's a mess).

There's a free PDF on Obj-C at Apple's Web site (developer.apple.com).
I really can't recommend it highly enough.  Add in Cocoa, which are a
gloriously beautiful set of frameworks (GUI and otherwise), and it's a
slam dunk.

Too bad about that whole PowerMac thing though. *sigh*

Brian

RE: [GD-General] Re: Simulating constrained genericity in C++

[Jesse J. <jes...@mi...>]

At 4:47 PM -0800 12/26/01, Brian Hook wrote:
>  > Maybe, but think about how you'd write generic code in a language
>>  like Smalltalk or Ruby. You'd use untyped objects and rely on the
>>  methods being present, just like you would with templates.
>
>Well, it's not quite THAT anarchistic.  In Java you could require that
>the objects conform to a specific interface; in Obj-C the objects would
>have to conform to a formal protocol; and in Eiffel they would have to
>be derived from the appropriate type

Which is why I was careful to say Smalltalk and Ruby. :-)

>(same goes for C++ -- my complaint
>here is that in C++ you're reinventing things like an ultimate "Object"
>class whereas this basic functionality is provided by other languages
>'natively').

Fundamentally C++ is just one great big hack. It's a pretty good 
hack, but when it comes to things like elegance it just can't compete 
with languages that were designed with less historical baggage.

>  > You're in good company with that argument. :-) I don't quite buy it
>>  myself. It's awfully nice to be able to create new types and have
>>  them behave like the primitive types (think point, vector, complex
>>  classes). It's even nicer if you can do this without incurring a big
>>  performance hit.
>
>Well, this is one of those few areas where I'm willing to agree to
>disagree =) I know some people, for example, hate having to remember
>separate "setFloatValue()" vs. "setIntValue()" vs. "setCharValue()"
>methods.  I'm one of those people that happens to hate having the wrong
>damn function called because of some implicit cast.  And, not to beat a
>dead horse, as long as I'm stuck fundamentally editing text, I'd like to
>be able to grep my source in a meaningful way.

Sure, but most people don't overload that many methods. Just stuff 
like the operators and an occasional named method now and then.

>Even my own frameworks still have lots of inadvertent name overloading.
>For example, I have HFile::create() which is completely and utterly
>unrelated to HAudioDevice::create(), but when I want to find every place
>I'm creating a file, I have to grep for "create(", which of course will
>give me "_create(" or "recreate(".  If I look for ".create(" I'll miss
>">create(".  And, of course, I'm going to find my "device->create("
>calls when I want my "file.create(" calls.
>
>Blech.
>
>This is where better tools would just really help a lot when trying to
>refactor source code.

Yeah, tools are just pitiful. It doesn't help matters that C++ is so 
damned hard to parse...

>  > might be right now, but I suspect it would include support for
>>  dynamic types and reflection.
>
>Well, that's the rather big bitch now.  The people designing languages
>often have these really focused philosophies:
>
>"You don't pay for what you don't use"
>"Everything is an object"
>"Static typing and design-by-contract reduce programmer error"
>"Dynamic typing and reflection are powerful"
>"Separate interface from implementation"
>
>Often they're incompatible philosophically, so the notion of adding
>reflection and dynamic typing to, say, C++ or Eiffel would cause those
>advocates to freak out that you're asking for "the wrong thing".  Sort
>of like asking Java people for pointer math.

Yup. It's kind of funny. What has it been? 50 years that people have 
been designing general purpose programming languages? And what have 
language designers come to agreement on? Goto's are bad? Even garbage 
collection still has a bad reputation in many places...

>Obj-C is probably the closest I've seen to a good compromise.  If you
>statically type something, the compiler will warn when you're pitching a
>message that the receiver won't understand.  But if you don't statically
>type it, you can use it however you want, and if ask the object what its
>class is and/or whether it recognizes a particular message.
>
>Damn brilliant language.

Yeah, I really need to look into Cocoa. I'm a bit put off though 
because it seems to be much more C-like than C++ if that makes any 
sense. :-)

   -- Jesse

RE: [GD-General] Re: Simulating constrained genericity in C++

[Brian H. <bri...@py...>]

> Maybe, but think about how you'd write generic code in a language 
> like Smalltalk or Ruby. You'd use untyped objects and rely on the 
> methods being present, just like you would with templates.

Well, it's not quite THAT anarchistic.  In Java you could require that
the objects conform to a specific interface; in Obj-C the objects would
have to conform to a formal protocol; and in Eiffel they would have to
be derived from the appropriate type (same goes for C++ -- my complaint
here is that in C++ you're reinventing things like an ultimate "Object"
class whereas this basic functionality is provided by other languages
'natively').

> You're in good company with that argument. :-) I don't quite buy it 
> myself. It's awfully nice to be able to create new types and have 
> them behave like the primitive types (think point, vector, complex 
> classes). It's even nicer if you can do this without incurring a big 
> performance hit.

Well, this is one of those few areas where I'm willing to agree to
disagree =) I know some people, for example, hate having to remember
separate "setFloatValue()" vs. "setIntValue()" vs. "setCharValue()"
methods.  I'm one of those people that happens to hate having the wrong
damn function called because of some implicit cast.  And, not to beat a
dead horse, as long as I'm stuck fundamentally editing text, I'd like to
be able to grep my source in a meaningful way.

Even my own frameworks still have lots of inadvertent name overloading.
For example, I have HFile::create() which is completely and utterly
unrelated to HAudioDevice::create(), but when I want to find every place
I'm creating a file, I have to grep for "create(", which of course will
give me "_create(" or "recreate(".  If I look for ".create(" I'll miss
">create(".  And, of course, I'm going to find my "device->create("
calls when I want my "file.create(" calls.

Blech.

This is where better tools would just really help a lot when trying to
refactor source code.

> might be right now, but I suspect it would include support for 
> dynamic types and reflection.

Well, that's the rather big bitch now.  The people designing languages
often have these really focused philosophies:

"You don't pay for what you don't use"
"Everything is an object"
"Static typing and design-by-contract reduce programmer error"
"Dynamic typing and reflection are powerful"
"Separate interface from implementation"

Often they're incompatible philosophically, so the notion of adding
reflection and dynamic typing to, say, C++ or Eiffel would cause those
advocates to freak out that you're asking for "the wrong thing".  Sort
of like asking Java people for pointer math.

Obj-C is probably the closest I've seen to a good compromise.  If you
statically type something, the compiler will warn when you're pitching a
message that the receiver won't understand.  But if you don't statically
type it, you can use it however you want, and if ask the object what its
class is and/or whether it recognizes a particular message.

Damn brilliant language.

Brian

RE: [GD-General] Re: Simulating constrained genericity in C++

[Jesse J. <jes...@mi...>]

At 3:19 PM -0800 12/26/01, Brian Hook wrote:
>  >This approach is fundamentally wrong: unlike Eiffel C++ doesn't use
>>classes to model attributes like being assignable or addable.
>
>So what does C++ use?  Anything at all?  Near as I can tell, from my
>ages old usage of templates, C++ is like a static version of Obj-C -- if
>the function call/operator overload doesn't exist that you need, you get
>a compile time warning (in Obj-C you can still send a message that isn't
>understood, which is unbelievably powerful).

Exactly.

>  >of this templates work more like objects in a dynamic language and
>>rely on name commonality.
>
>Right.  And I'm not sure if relying on name commonality is really a good
>design decision.

Maybe, but think about how you'd write generic code in a language 
like Smalltalk or Ruby. You'd use untyped objects and rely on the 
methods being present, just like you would with templates. If this is 
OK for those languages why is it a problem for templates?

Of course you could say that one of the advantages of C++ is that you 
can use the type system to catch errors and templates don't follow 
this model. But I don't see this as a problem, especially given that 
not everything in C++ is an object.

>For example, some STL classes require operator < to be
>overloaded, which goes back to a thread on another mailing list where I
>said that function name overloading is a Bad Idea so long as you're
>using text as your representation because you can't find, for example,
>every place you're doing a comparison between two specific types.

You're in good company with that argument. :-) I don't quite buy it 
myself. It's awfully nice to be able to create new types and have 
them behave like the primitive types (think point, vector, complex 
classes). It's even nicer if you can do this without incurring a big 
performance hit.

>  >Eiffel reminds me of Modula-2: a really nice implementation of
>>yesterdays paradigm. But it just doesn't offer enough over C++ to be
>>compelling (for me at least).
>
>I don't know if Eiffel's implementation of constrained genericity is
>yesterday's paradigm; it's just a different way of doing things.  Eiffel
>still has significant other problems, but I think its support of
>constrained genericity looks pretty elegant (at least, on paper).

In a language that is statically typed and OO from the ground up 
constrained genericity *is* good. But that's not what I was getting 
at. Eiffel is a very nice statically typed OO language. But I want 
something more than C++ in a nicer package. I don't know what that 
might be right now, but I suspect it would include support for 
dynamic types and reflection.

   -- Jesse

RE: [GD-General] Re: Simulating constrained genericity in C++

[Brian H. <bri...@py...>]

>This approach is fundamentally wrong: unlike Eiffel C++ doesn't use 
>classes to model attributes like being assignable or addable.

So what does C++ use?  Anything at all?  Near as I can tell, from my
ages old usage of templates, C++ is like a static version of Obj-C -- if
the function call/operator overload doesn't exist that you need, you get
a compile time warning (in Obj-C you can still send a message that isn't
understood, which is unbelievably powerful).

>of this templates work more like objects in a dynamic language and 
>rely on name commonality.

Right.  And I'm not sure if relying on name commonality is really a good
design decision.  For example, some STL classes require operator < to be
overloaded, which goes back to a thread on another mailing list where I
said that function name overloading is a Bad Idea so long as you're
using text as your representation because you can't find, for example,
every place you're doing a comparison between two specific types.

There are reasonable reasons for saying:

Foo a, b;

if ( a < b )
   return true;

is prettier than:

Foo a, b;

if ( a.compareToFoo( b ) < 0 )
   return true;

But at least when I need to know where I'm comparing Foos I can find it
immediately with grep.

But that's neither here nor there =)

>Eiffel reminds me of Modula-2: a really nice implementation of 
>yesterdays paradigm. But it just doesn't offer enough over C++ to be 
>compelling (for me at least).

I don't know if Eiffel's implementation of constrained genericity is
yesterday's paradigm; it's just a different way of doing things.  Eiffel
still has significant other problems, but I think its support of
constrained genericity looks pretty elegant (at least, on paper).

For me, the incremental advantages over C/C++ are probably to be found
in Obj-C and Java.  The former provides fully dynamic typing/message
passing; the latter provides garbage collection and a shit load of stock
libraries and cross-platform compatibility.

Brian

[GD-General] tools language/framework [was: Eiffel and whatnot]

[Ivan-Assen I. <as...@ha...>]

Just to throw a couple of drops of gasoline in the fire:

I've been looking quite a bit lately in the .NET/C# stuff and it seems a very nice environment
for quick tools development. You can whip up a GUI for a tool with it in minutes, not hours,
it has extensive support for XML and a perl-compatible regexp library for those text files you haven't
yet moved to XML. Executables run fairly fast, and launch instantly (e.g. unlike Java class files).
It has all kinds of nice toys in the library - both low-level (think sockets) and high-level (think
FetchWhateverIsAtThisURLIntoThisString()) network functions, runtime code generation & compilation,
a much cleaned-up GDI (GDI+), threading stuff etc.

And it's less drastic a change than moving your tools to OS X and installing Macs everywhere :-)

[GD-General] Re: Simulating constrained genericity in C++

[Jesse J. <jes...@mi...>]

At 11:17 AM -0800 12/26/01, Brian Hook wrote:
>http://sivut.koti.soon.fi/epulkkin/instructive/simulating-constrained-ge
>nericity.html
>
>I had no idea there was so much crap involved with generic programming.

This approach is fundamentally wrong: unlike Eiffel C++ doesn't use 
classes to model attributes like being assignable or addable. Because 
of this templates work more like objects in a dynamic language and 
rely on name commonality. Of course, in practice there are some 
problems with doing this (like bizarre error messages). Check out 
<http://www.boost.org/libs/concept_check/concept_check.htm> for a 
solution that fits in better with C++.

>Eiffel so far seems like the best implementation I've seen, but the
>language (and implementations) has so many other issues that it doesn't
>look feasible for tool development.

Eiffel reminds me of Modula-2: a really nice implementation of 
yesterdays paradigm. But it just doesn't offer enough over C++ to be 
compelling (for me at least).

   -- Jesse

[GD-General] Simulating constrained genericity in C++

[Brian H. <bri...@py...>]

http://sivut.koti.soon.fi/epulkkin/instructive/simulating-constrained-ge
nericity.html

I had no idea there was so much crap involved with generic programming.
Eiffel so far seems like the best implementation I've seen, but the
language (and implementations) has so many other issues that it doesn't
look feasible for tool development.

So back to Java and Obj-C I go =)

Brian

P.S. After looking at the collection classes in STL, Java, Eiffel and
Obj-C, I'm surprised there hasn't been some reasonable paper written
that describes the architectural decisions each made, and what language
specific features enabled/denied certain aspects.  Lack of constrained
genericity seems like a royal bitch in C++; same with a lack of
introspection, reflection and single reliable hierarchies (e.g. in Java
and Obj-C you can query an object for its class; in Java all object's
have a "toString" method; etc.).

Re: [GD-General] Eiffel

[Jesse J. <jes...@mi...>]

At 10:34 PM -0500 12/25/01, Thatcher Ulrich wrote:
>On Sun, 23 Dec 2001, Jesse Jones wrote:
>
>>  At 11:47 PM -0500 12/22/01, Thatcher Ulrich wrote:
>>
>>  >An example of how the STL is not "really easy to use":
>>  >
>>  >	std::hash_map<string, int> my_hash;
>>  >
>>  >	...
>>  >	string	my_key = something...;
>>  >	int	my_value = something...;
>>  >
>>  >	// I want to see if my_key is in my_hash, and if so, whether
>>  >	// its value matches my_value.
>>  >	std::hash_map<string, int>::iterator it = my_hash.find(my_key);
>>  >	if (it != my_hash.end() && (*it).second == my_value)
>>  >	{
>>  >		// Match.
>>  >	} else {
>>  >		// Mismatch.
>>  >	}
>>
>>  Try:
>>      if (my_hash.count(my_key) > 0)
>>         // match
>>      else
>>         // mismatch
>
>No, that's not the same test --  I want to check the value as well.  I
>don't think it's possible to  do w/ STL without either explicity using
>an iterator, or doing two lookups.

Whoops, you're right of course. I wouldn't consider this a very good 
example of how STL is hard to use though. It's just different 
behavior than what you're used to. Sometimes it makes the code 
slightly more difficult to write, sometimes it makes it easier to 
write.

However I do think this is one of the few places in STL that could 
have been designed better. As was mentioned earlier good 
implementations and good designs will try to catch user errors. 
Having operator[] add a new entry if one isn't already present might 
sometimes be handy, but if users make a mistake they won't know until 
sometime later. OTOH if operator[]'s precondition was that the key be 
present they'll find out right away that there's a problem.

>  > >I think I got that right.  The iterator is just obfuscation.  Whereas
>>  >the way you'd do it in Perl or Lua, the seemingly obvious:
>>  >
>>  >	if (my_hash[my_key] == my_value) {
>>  >		// Match.
>>  >	} else {
>>  >		// Mismatch.
>>  >	}
>>  >
>>  >compiles, and leaks memory!
>>
>>  Compiles, but shouldn't leak memory.
>
>It's a leak -- if my_hash[my_key] is not defined, then it allocates
>memory and there's no way to safely clean it up.  The above code is
>bugged, end of story.

It's not an STL bug though, it's a client bug. And when the hash map 
is destroyed the memory will be released.

   -- Jesse

Re: [GD-General] Eiffel

[Thatcher U. <tu...@tu...>]

On Sun, 23 Dec 2001, Jesse Jones wrote:

> At 11:47 PM -0500 12/22/01, Thatcher Ulrich wrote:
>
> >An example of how the STL is not "really easy to use":
> >
> >	std::hash_map<string, int> my_hash;
> >
> >	...
> >	string	my_key = something...;
> >	int	my_value = something...;
> >
> >	// I want to see if my_key is in my_hash, and if so, whether
> >	// its value matches my_value.
> >	std::hash_map<string, int>::iterator it = my_hash.find(my_key);
> >	if (it != my_hash.end() && (*it).second == my_value)
> >	{
> >		// Match.
> >	} else {
> >		// Mismatch.
> >	}
>
> Try:
>     if (my_hash.count(my_key) > 0)
>        // match
>     else
>        // mismatch

No, that's not the same test --  I want to check the value as well.  I
don't think it's possible to  do w/ STL without either explicity using
an iterator, or doing two lookups.

> >I think I got that right.  The iterator is just obfuscation.  Whereas
> >the way you'd do it in Perl or Lua, the seemingly obvious:
> >
> >	if (my_hash[my_key] == my_value) {
> >		// Match.
> >	} else {
> >		// Mismatch.
> >	}
> >
> >compiles, and leaks memory!
>
> Compiles, but shouldn't leak memory.

It's a leak -- if my_hash[my_key] is not defined, then it allocates
memory and there's no way to safely clean it up.  The above code is
bugged, end of story.

-Thatcher