generics and arrays and multi-class collections

X

xen

Yo peoples of the earth,

What is the proper use of generics when you want to use arrays as
well?
Is there anybody out there that writes code that does NOT generate
unchecked warnings?

For example, java.util.ArrayList uses an array of Object to store its
elements, and uses a cast (E)elements to retrieve them, which
generates an unchecked warning. I myself have wanted to use an array
of generified sets, so I just create a Set[] and assign it to a
Set<E>[], which generates a warning. I can trim down on the warnings
so that I only get "unchecked conversion" and "unchecked cast"
warnings, but it seems I'll have to live with those.

My last addition was a Map that can store Lists that store different
classes that are all decendants of a superclass:

Map<Class<? extends Feature>, List<? extends Feature>> stores;
stores = new HashMap<Class<? extends Feature>, List<? extends
Feature>>();

I want a method that retrieves each store, and creates one if not
present.

public <F extends Feature> List<F> getStore(Class<F> c) {
List<F> L = (List<F>)stores.get(c); // unchecked cast
if (L == null) {
L = new ArrayList<F>();
stores.put(c, L);
}
return L;
}

The cast generates an unchecked warning.

Now given
class Block extends Feature {}
I can do
List<Block> = getStore(Block.class);
which is what I wanted.

What are your experiences, any advice?

greetings, xen.
 
D

Daniel Pitts

Yo peoples of the earth,

What is the proper use of generics when you want to use arrays as
well?
Is there anybody out there that writes code that does NOT generate
unchecked warnings?

For example, java.util.ArrayList uses an array of Object to store its
elements, and uses a cast (E)elements to retrieve them, which
generates an unchecked warning. I myself have wanted to use an array
of generified sets, so I just create a Set[] and assign it to a
Set<E>[], which generates a warning. I can trim down on the warnings
so that I only get "unchecked conversion" and "unchecked cast"
warnings, but it seems I'll have to live with those.

My last addition was a Map that can store Lists that store different
classes that are all decendants of a superclass:

Map<Class<? extends Feature>, List<? extends Feature>> stores;
stores = new HashMap<Class<? extends Feature>, List<? extends
Feature>>();

I want a method that retrieves each store, and creates one if not
present.

public <F extends Feature> List<F> getStore(Class<F> c) {
List<F> L = (List<F>)stores.get(c); // unchecked cast
if (L == null) {
L = new ArrayList<F>();
stores.put(c, L);
}
return L;
}

The cast generates an unchecked warning.

Now given
class Block extends Feature {}
I can do
List<Block> = getStore(Block.class);
which is what I wanted.

What are your experiences, any advice?

greetings, xen.


In my opinion, using Arrays is akin to the "primative obsession" anti-
pattern. You'd probably be better off using a List<Set<T>> or simply
List<T>, depending on your needs.

The little bit of overhead you incur is *far* outweighed by the
functionality gained.
 
S

SadRed

Yo peoples of the earth,

What is the proper use of generics when you want to use arrays as
well?
Is there anybody out there that writes code that does NOT generate
unchecked warnings?

For example, java.util.ArrayList uses an array of Object to store its
elements, and uses a cast (E)elements to retrieve them, which
generates an unchecked warning. I myself have wanted to use an array
of generified sets, so I just create a Set[] and assign it to a
Set<E>[], which generates a warning. I can trim down on the warnings
so that I only get "unchecked conversion" and "unchecked cast"
warnings, but it seems I'll have to live with those.

My last addition was a Map that can store Lists that store different
classes that are all decendants of a superclass:

Map<Class<? extends Feature>, List<? extends Feature>> stores;
stores = new HashMap<Class<? extends Feature>, List<? extends
Feature>>();

I want a method that retrieves each store, and creates one if not
present.

public <F extends Feature> List<F> getStore(Class<F> c) {
List<F> L = (List<F>)stores.get(c); // unchecked cast
if (L == null) {
L = new ArrayList<F>();
stores.put(c, L);
}
return L;
}

The cast generates an unchecked warning.

Now given
class Block extends Feature {}
I can do
List<Block> = getStore(Block.class);
which is what I wanted.

What are your experiences, any advice?

greetings, xen.

I'll have to live with those.
Yes. And the SuppressWarnings annotation may be our only feeble
solace. Wisdome is "use Java generics only at its shallowest".
Anything deeper can become confusing and unworkable.
 
R

Roedy Green

Is there anybody out there that writes code that does NOT generate
unchecked warnings?

Have a peek inside the source for ArrayList. You will see Sun could
not do it without suppressing warnings. I get the idea Sun is going
to redo generics, perhaps throwing out type erasure and dealing with
embarrassments like this.
 
R

Roedy Green

In my opinion, using Arrays is akin to the "primative obsession" anti-
pattern. You'd probably be better off using a List<Set<T>> or simply
List<T>, depending on your needs.

To me the mess is generics. It is overly complicated, does not work
with sterilisation. It OOKS ugly and tacked on as an after thought.

For more details see http://mindprod.com/jgloss/serialization.html
 
S

SadRed

Have a peek inside the source for ArrayList. You will see Sun could
not do it without suppressing warnings. I get the idea Sun is going
to redo generics, perhaps throwing out type erasure and dealing with
embarrassments like this.
Have a peek inside the source for
ArrayList. You will see Sun could
not do it without suppressing warnings.
What part of the source do you refer?
 
R

Roedy Green

What part of the source do you refer?

code like this:

public <T> T[] toArray(T[] a) {
if (a.length < size)
// Make a new array of a's runtime type, but my contents:
return (T[]) Arrays.copyOf(elementData, size,
a.getClass());
System.arraycopy(elementData, 0, a, 0, size);
if (a.length > size)
a[size] = null;
return a;
}

If you write code like that I think you will get warnings.

It has been a while. I was trying to allocate arrays of the given
generic type, and was baffled. I used code similar to what I found in
Sun's collections and to my surprise discovered it generated warning
messages. I asked about it on the newsgroups and the wise ones
assured me this was indeed a limitation of Java's genericity design.
 
S

SadRed

What part of the source do you refer?

code like this:

public <T> T[] toArray(T[] a) {
if (a.length < size)
// Make a new array of a's runtime type, but my contents:
return (T[]) Arrays.copyOf(elementData, size,
a.getClass());
System.arraycopy(elementData, 0, a, 0, size);
if (a.length > size)
a[size] = null;
return a;
}

If you write code like that I think you will get warnings.

It has been a while. I was trying to allocate arrays of the given
generic type, and was baffled. I used code similar to what I found in
Sun's collections and to my surprise discovered it generated warning
messages. I asked about it on the newsgroups and the wise ones
assured me this was indeed a limitation of Java's genericity design.

Yes. The code you've mentioned does generate an *unchecked* warning.
Sun has just ignored it just like us. :):)
 
X

xen

In my opinion, using Arrays is akin to the "primative obsession" anti-
pattern. You'd probably be better off using a List<Set<T>> or simply
List<T>, depending on your needs.

The little bit of overhead you incur is *far* outweighed by the
functionality gained.

The point is that these arrays are static 2-size arrays that I can
initialize really quick with a

Set<Move>[] tempCaptures = new HashSet[] {
new HashSet<Move>(), new HashSet<Move>()
};

There's just no point in using a List. I don't need dynamic expansion.
I don't need to treat it as a Collection, or get default toString()
functionality, or use any of those nifty java.util.Collections
operations.

And sometimes the overhead is huge. For example, I'm using bitsets to
represent the occupation of a game board. If I use java.util.BitSet, I
get lots of built-in functionality. But using somebitset.or(someother)
takes 10(!) times as much time as using primitive bit operations on a
long, because it has support for bitsets that span more than one long,
whereas I need only one, and it does some checks to make sure its own
operations don't corrupt it. Although I could have created my own
class specially tailored to my needs, even that I haven't done. It
would have saved me some debugging time, but I just happen to like
"long neighbours = (occupation[0] | occupation[1]) & f.neighbourSet()"
and "long available = emptyFields & ~territory[0] & ~territory[1]" and
"inters[player] |= 1L << i" --- instead of using more elaborate method
calls, using (BitSet)bs.clone() everytime I need a copy, etc. I find
my code to be a lot cleaner.

Btw, I find that also to be a major drawback of java enumerations. In
my current project I have a couple of enumerations that I need to
iterate on, but often not on all of the values. So I started using
"for (int i = Player.WHITE.ordinal(); i <= Player.BLACK.ordinal(); i+
+) {}" which caused significant overhead compared to "for (int i =
WHITE; i <= BLACK; i++)"

I also needed to convert one enum constant into another. I couldn't
make them refer to each other at creation time, because when
Direction.N is created, Direction.S does not exist yet. If I create a
method opposite() I get
Direction opposite() {
return values()[ordinal() ^ 4];
}
which is two extra method calls and an array access for a method that
is called zillions of times (well this one isn't, but another one is).
And then you have the fact that you can't have the enum constants be
part of the namespace of the class that declared the enum, so you end
up using Move.Type.NORMAL instead of Move.NORMAL every freakin time. I
also found that when you do a switch on an enum variable, the compiler
creates a static inner class with an array indexed by Enum.ordinal()
and filled with 1,2,3,... and then uses these values as labels for the
cases, because a switch can only use literal case values and an enum
is composed of objects...

Anyway, I don't like them too much. Enums in pascal were much nicer.
The only advantage is that you can call methods on them, and there is
the type safety, but you only need that if you have complex methods
that take different kinds of options in seemingly random order. Now I
have to call Player.opponent(player) each time instead of
player.opponent(), although player ^ 1 would also work ;). Yeah I
could use static imports but I can't use that.

greets, xen
 
X

xen

Yes. And the SuppressWarnings annotation may be our only feeble
solace. Wisdome is "use Java generics only at its shallowest".
Anything deeper can become confusing and unworkable.

Aight, I find it to be the most complex part of the Java language,
well, the only complex part. I have been trying endlessly to fix some
generics code that wouldn't compile, until I read a tutorial and
discovered that what I wanted couldn't be done. I now understand most
of it, but I wouldn't be surprised if I get bitten by something unseen
again.

For example, what exactly are the properties of

HashMap<Class<? extends Number>, List<? extends Number>>

This was the only way to get different kinds of (Lists of) Numbers
into the Map, but when I get() a List, I can't add anything into it,
unless I cast it, which generates a warning. Well, now I have *some*
type safety.
 
D

Daniel Pitts

In my opinion, using Arrays is akin to the "primative obsession" anti-
pattern. You'd probably be better off using a List<Set<T>> or simply
List<T>, depending on your needs.
The little bit of overhead you incur is *far* outweighed by the
functionality gained.

The point is that these arrays are static 2-size arrays that I can
initialize really quick with a

Set<Move>[] tempCaptures = new HashSet[] {
new HashSet<Move>(), new HashSet<Move>()
};
Let me guess, you use something like "tempCaptures[playerNumber]"
You could always "wrap" your sets with a more meaningful and specific
class:
class PlayerData {
private Collection<Move> tempCaptures = new HashSet<Move>();
// other player specific data and methods
}
There's just no point in using a List. I don't need dynamic expansion.
I don't need to treat it as a Collection, or get default toString()
functionality, or use any of those nifty java.util.Collections
operations.
For an array that is ALWAYS two sized, I agree, you probably don't
need a Collection of any sort (unless the Java API finally adds a Pair
type Collection).
And sometimes the overhead is huge. For example, I'm using bitsets to
represent the occupation of a game board.
Why? Did you run out of memory when you did it the other way? Was it
too slow? Sometimes programmers (including me) optimize WAY too
soon. Most experienced OO programmers will start with using objects
and classes for everything, and then optimize -- with the help of
profiler -- down to using primitives and other hacks.
If I use java.util.BitSet, I
get lots of built-in functionality. But using somebitset.or(someother)
takes 10(!) times as much time as using primitive bit operations on a
long, because it has support for bitsets that span more than one long,
whereas I need only one, and it does some checks to make sure its own
operations don't corrupt it. Although I could have created my own
class specially tailored to my needs, even that I haven't done. It
would have saved me some debugging time, but I just happen to like
"long neighbours = (occupation[0] | occupation[1]) & f.neighbourSet()"
and "long available = emptyFields & ~territory[0] & ~territory[1]" and
"inters[player] |= 1L << i" --- instead of using more elaborate method
calls, using (BitSet)bs.clone() everytime I need a copy, etc. I find
my code to be a lot cleaner.

Btw, I find that also to be a major drawback of java enumerations. In
my current project I have a couple of enumerations that I need to
iterate on, but often not on all of the values. So I started using
"for (int i = Player.WHITE.ordinal(); i <= Player.BLACK.ordinal(); i+
+) {}" which caused significant overhead compared to "for (int i =
WHITE; i <= BLACK; i++)"

Why are you dealing with the ordinals at all? That will break things
if you change the order, or add new players. (Also, it sounds more
like an PlayerColor enum, rather than a Player enum)
enum PlayerColor {
White,
Black;
}

for (PlayerColor playerColor: PlayerColor.values()) {
System.out.println(playerColor);
}
I also needed to convert one enum constant into another. I couldn't
make them refer to each other at creation time, because when
Direction.N is created, Direction.S does not exist yet. If I create a
method opposite() I get
Direction opposite() {
return values()[ordinal() ^ 4];
}
How about:
enum Direction {
NORTH {
public Direction opposite() {
return SOUTH;
}
},
SOUTH, {
public Direction opposite() {
return NORTH;
}
},
EAST, {
public Direction opposite() {
return WEST;
}
},
WEST, {
public Direction opposite() {
return EAST;
}
},

public abstract Direction opposite();
}
which is two extra method calls and an array access for a method that
is called zillions of times (well this one isn't, but another one is).
Don't be so obsessed with the underlying mechanics UNTIL it becomes a
problem.
And then you have the fact that you can't have the enum constants be
part of the namespace of the class that declared the enum, so you end
up using Move.Type.NORMAL instead of Move.NORMAL every freakin time.
Java attempted to do that, how would this work:
class MyClass {
enum Foo { JOE, BOB, CHARLES }
enum Bar { JOSEPH, ROBERT, CHARLES }

public static void handle(Foo foo) {}
public static void handle(Bar bar) {}
}

MyClass.handle(MyClass.CHARLES); // Whoops, ambiguity!

Why would it be the namespace of the owning class anyway, since enums
actually can live on their own:
-- MyEnum.java --
public enum MyEnum {
A, B, C
}
-- OtherClass.java --
public class OtherClass {
public MyEnum value = MyEnum.A;
}



I
also found that when you do a switch on an enum variable, the compiler
creates a static inner class with an array indexed by Enum.ordinal()
and filled with 1,2,3,... and then uses these values as labels for the
cases, because a switch can only use literal case values and an enum
is composed of objects...
You usually shouldn't switch on enums, you should use polymorphism
instead. Again, Don't worry so much about under the hood. This level
of obsession with minutia tends to create terrible design.
Anyway, I don't like them too much. Enums in pascal were much nicer.
No they weren't. They were much less OO (which is what you seem to
have a hard time with)
The only advantage is that you can call methods on them, and there is
the type safety, but you only need that if you have complex methods
that take different kinds of options in seemingly random order. Now I
have to call Player.opponent(player) each time instead of
player.opponent(), although player ^ 1 would also work ;). Yeah I
could use static imports but I can't use that.
You could use static imports, but you can't use that? That doesn't
make sense...
Why can't you have player.oppenent()?

enum PlayerColor {
White {
public PlayerColor opponent() {
return Black;
}
},
Black {
public PlayerColor opponent() {
return White;
}
};
public abstract PlayerColor opponent();
}

PlayerColor player = PlayerColor.Black;

System.out.println(player.opponent());
greets, xen

I hope this makes sense to you, and that you find it helpful. I was
once like you, trying to make sure that my code was as optimized as
possible all the way through. I spent more time creating the
program, and the program usually ended up SLOWER and BUGGIER than when
I followed good OO design principals.
 
X

xen

Hey Daniel, thanks for the elaborate reply.

Let me guess, you use something like "tempCaptures[playerNumber]"
You could always "wrap" your sets with a more meaningful and specific
class:
class PlayerData {
   private Collection<Move> tempCaptures = new HashSet<Move>();
   // other player specific data and methods}

Yes I could do that but these two objects exists only during the
execution of some set of methods that use it to communicate results,
it would make no sense to make anything persistent out of it.
You are right that I use playerNumber to index the arrays. Most of
these arrays exist only during the duration of a method call or even a
code block.

Why? Did you run out of memory when you did it the other way? Was it
too slow?  Sometimes programmers (including me) optimize WAY too
soon.  Most experienced OO programmers will start with using objects
and classes for everything, and then optimize -- with the help of
profiler -- down to using primitives and other hacks.

I'm not using the bitsets as the main representation. I'm using a
Board composed of Fields that probably should contain Stones (now an
int attribute). I'm using the bitsets only as a computational tool,
because creating Sets of Fields would be many many MANY times slower.
I update the bitsets on each move perform and undo, and use them for
territory analysis and such, and to select between different
variations of algorithms that tend to perform better in some
situations and worse in others.
Why are you dealing with the ordinals at all? That will break things
if you change the order, or add new players. (Also, it sounds more
like an PlayerColor enum, rather than a Player enum)
enum PlayerColor {
   White,
   Black;

}

for (PlayerColor playerColor: PlayerColor.values()) {
   System.out.println(playerColor);

}

I'll never have to change the colors, or the order. Actually its not
Player but Stone, and Stone has WHITE, BLACK, NONE due to the fact
that I don't use Stone objects (may start using them though, but I'd
get field.stone().color instead of field.stone() - there is no other
use for the existance of a Stone object than to hold a color so it
only makes conceptual sense).
An Enum with only two values would indeed allow me to do a foreach on
them, which I need to do a lot.
I also needed to convert one enum constant into another. I couldn't
make them refer to each other at creation time, because when
Direction.N is created, Direction.S does not exist yet. If I create a
method opposite() I get
        Direction opposite() {
                return values()[ordinal() ^ 4];
        }

How about:
enum Direction {
    NORTH {
        public Direction opposite() {
           return SOUTH;
        }
    },
    SOUTH, {
        public Direction opposite() {
           return NORTH;
        }
    },
    EAST, {
        public Direction opposite() {
           return WEST;
        }
    },
    WEST, {
        public Direction opposite() {
           return EAST;
        }
    },

    public abstract Direction opposite();}

Ah! I hadn't thought of that. I had tried to use constructors with
paramters like

NORTH(SOUTH), SOUTH(NORTH), ...

Direction(Direction op) {
this.opposite = op
}

which didn't work.
Don't be so obsessed with the underlying mechanics UNTIL it becomes a
problem.

Well, you see, at first I did use Enumerations. For example, the
Direction Enum was used in two methods that in current implementation
take up about 37% of processing time. Then I wanted to know what the
incurred overhead was. I changed the lines
for (Direction d: Direction.values())
into
for (int d = 0; d < 8; d++)
and made sure that the methods called on d also accepted ints.
Then I measured execution times. I found that the performance gain was
significant.
Changing these lines back again just now causes a 15% increase in
execution time. That means that for those methods it meant an increase
of 41% in execution time. 41%!!! (This also entails a call to
ordinal() in getAdjacent()). Granted, the inner loop only contains 13
lines of code, but this is massive overhead. Right now, these methods
comprise a larger part of execution time than they probably will in
the future, but they will only be surpasses by methods that also make
extensive use of these kind of loops. 15% is unacceptable.

Btw, the generated code is this:

Direction arr$[] = Direction.values();
int len$ = arr$.length;
for(int i$ = 0; i$ < len$; i$++)
{
Direction d = arr$[i$];

So the overhead is basically a method call, an array indexing, and two
more method calls in the body of the loop. That's why I don't want
"just a couple of calls" inside any inner loop in this program.

I'm also using the Direction constants to index an adjacency table, to
quickly get the neighbouring fields of a field. Using a table is twice
as fast as calculating the indeces each time. (And Field.getAdjacent()
makes up 17% of processing time). What would you suggest I do? Create
a HashMap that retrieves neighbours based on Directions for each
field? I would expect access times at least to quadruple. So I need
these ordinal values. The order isn't going to change anyway. And I
need the ordinal values of the player colors because I'm not about to
create a Map each time I need an array of 2. (Although the most
efficient special purpose Map might have some advantage because it can
just do
V get(K k) { return k == Color.WHITE ? value1 : value2; }

Java attempted to do that, how would this work:
class MyClass {
   enum Foo { JOE, BOB, CHARLES }
   enum Bar { JOSEPH, ROBERT, CHARLES }

   public static void handle(Foo foo) {}
   public static void handle(Bar bar) {}

}

MyClass.handle(MyClass.CHARLES); // Whoops, ambiguity!

Why would it be the namespace of the owning class anyway, since enums
actually can live on their own:
-- MyEnum.java --
public enum MyEnum {
   A, B, C}

-- OtherClass.java --
public class OtherClass {
   public MyEnum value = MyEnum.A;

It doesn't have to be default. Just some kind of within-class import
static feature. The reason I can't use static imports is because I
need to distribute the complete source of the program in one file
(it's a bot programming competition). Right now I all have different
files, but to submit I have to junk everything in one file with one
public class. Static imports would only make things worse, because I'd
have to refit every occurence with the class name. (But I could be
wrong. Is there a way to use static imports in one and the same file?)
You usually shouldn't switch on enums, you should use polymorphism
instead.  

What do you mean?
No they weren't. They were much less OO (which is what you seem to
have a hard time with)

OO isn't the magical solution for every possible situation. At least
with pascal or C enums you could create high performance code.
You could use static imports, but you can't use that? That doesn't
make sense...
Why can't you have player.oppenent()?

enum PlayerColor {
   White {
     public PlayerColor opponent() {
       return Black;
     }
   },
   Black {
     public PlayerColor opponent() {
       return White;
     }
   };
   public abstract PlayerColor opponent();

}

PlayerColor player = PlayerColor.Black;

System.out.println(player.opponent());

Yes, now I see that I could. Probably not gonna do it though. I'd win
some nice syntax but lose some performance (albeit small) and I'd have
to write Color.Black.ordinal() all over the place. After tens of

array[Color.Black.ordinal()] = object.get(Color.Black.ordinal()) *
value
array[Color.White.ordinal()] = object.get(Color.White.ordinal()) *
value

I tend to get a bit tired of this syntax.

array[BLACK] = object.get(BLACK) * value
array[WHITE] = object.get(WHITE) * value

Aaah! Don't you just love concise syntax? I do! :) :) :). Uppercase
words within square brackets are just beautiful ;).
I hope this makes sense to you, and that you find it helpful.  I was
once like you, trying to make sure that my code was as optimized as
possible all the way through.   I spent more time creating the
program, and the program usually ended up SLOWER and BUGGIER than when
I followed good OO design principals.

Yes it was helpful. It's not like I'm this performance oriented in
every application I write. It's just that this particular program is
very performance sensitive. I think I'm at an disadvantage already
because I use Java, although I tend to profit from the knowhow
embedded in methods such as BitMap.nextSetBit() and Long.bitCount()
and the clear data model. Other than that, I'm simply not familiar
with the FreePascal environment and there's no way I'm gonna use C. I
don't like C ;). And Java is quite nice to program in.

grtz, xen.
 
D

Daniel Pitts

xen said:
Hey Daniel, thanks for the elaborate reply.



Yes it was helpful. It's not like I'm this performance oriented in
every application I write. It's just that this particular program is
very performance sensitive. I think I'm at an disadvantage already
because I use Java, although I tend to profit from the knowhow
embedded in methods such as BitMap.nextSetBit() and Long.bitCount()
and the clear data model.

I'm not against performance optimizations at all, I'm just saying you
should do it as a last step after you've created the "perfect" design
(perfect being relative). And you should only do it with the help of
profiling tools. In any case, it sounds like you're particular problem
needs optimization. Is there some form of time-limit?
Other than that, I'm simply not familiar
with the FreePascal environment and there's no way I'm gonna use C. I
don't like C ;). And Java is quite nice to program in.

grtz, xen.


Java is a lot of fun to program in :). But whats wrong with C? You can
write really elegant programs in C if you know what you're doing. Gotta
love function pointers! :)

Well, good luck on your bot competition.

Cheers,
Daniel.

P.S. Ever heard of AT-Robots? Its a robot simulation game where you pit
your robot against other programmers' robots.
 
R

Roedy Green

The rule of thumb is, "Generics and arrays don't mix."

Except that every Collection inside usually has some sort of array.
They might not mix, but you have to use them both anyway.
 
X

xen

I'm not against performance optimizations at all, I'm just saying you
should do it as a last step after you've created the "perfect" design
(perfect being relative). And you should only do it with the help of
profiling tools. In any case, it sounds like you're particular problem
needs optimization. Is there some form of time-limit?

Yeah, the program has 30 seconds for the entire game, which can last
for 200 moves, so I have to fit 100 moves in 30 seconds.
Java is a lot of fun to program in :). But whats wrong with C? You can
write really elegant programs in C if you know what you're doing. Gotta
love function pointers! :)

Well, I haven't finished the book I was reading on C so my opinion
might not be final, but....

I don't like the way the variable declarations have their type mixed
with the variable name, that is, a pointer is not char* p, but char
*p, and an array of char ptrs is char *p[], and a ptr to an array is
char (*p)[], but it kinda makes sense because that's also the way
you're going to use the variable.

Also, it's stupid that you dereference by *p instead of p* or p^. I
think that's the main reason they needed to introduce p->field because
you get pretty tired of writing (*p).field.

And then there's the lack of nice basic string manipulation.
Everything is so bloody low-level. It's like you have to make fire
with firestones when you're used to using matches. String ought to be
a type, not a bloody pointer to a piece of memory that may or may not
have a zero somewhere to terminate it.

It's quite cool that you can set up dynamic 3-dimensional arrays but
writing the code is a major headache. I've coded in basic, in pascal,
in assembler and in java, but i'll never code for fun in C, or even
C++.

Well, good luck on your bot competition.

Thanks.
 
X

xen

Btw,

If I hadn't been so busy with optimizing my search algorithm, I
wouldn't have discovered that there was a huge optimization for it
which was actually quite well known (90% faster), so that now I can
search at least 5 ply instead of 4 ply, which is still not very much,
but anyway, it means that I will have less need for feature extraction
(previously I couldn't even detect some basic 5-move combo's), so my
design is actually dependant on my search capabilities.

Now that I can see no further improvements I can start to focus on my
heuristics.
 
P

Patricia Shanahan

xen said:
On Mon, 01 Oct 2007 20:21:17 -0700, Daniel Pitts
Java is a lot of fun to program in :). But whats wrong with C? You can
write really elegant programs in C if you know what you're doing. Gotta
love function pointers! :)

Well, I haven't finished the book I was reading on C so my opinion
might not be final, but....

I don't like the way the variable declarations have their type mixed
with the variable name, that is, a pointer is not char* p, but char
*p, and an array of char ptrs is char *p[], and a ptr to an array is
char (*p)[], but it kinda makes sense because that's also the way
you're going to use the variable.

Also, it's stupid that you dereference by *p instead of p* or p^. I
think that's the main reason they needed to introduce p->field because
you get pretty tired of writing (*p).field.

Take a look at cdecl, e.g. http://www.linuxcommand.org/man_pages/cdecl1.html

On the one hand, it makes writing C declarations relatively easy. On the
other hand, the fact that such a program exists implies that C
declaration syntax is confusing.

Patricia
 
X

xen

xen said:
I don't like the way the variable declarations have their type mixed
with the variable name, that is, a pointer is not char* p, but char
*p, and an array of char ptrs is char *p[], and a ptr to an array is
char (*p)[], but it kinda makes sense because that's also the way
you're going to use the variable.
Take a look at cdecl, e.g. http://www.linuxcommand.org/man_pages/cdecl1.html

On the one hand, it makes writing C declarations relatively easy. On the
other hand, the fact that such a program exists implies that C
declaration syntax is confusing.

Patricia

My god, I hadn't even imagined that declarations could be so complex.

void (*signal(int x, void (*y)(int )))(int ) { }

But I'm sure they can be much, much complexer.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top