[computer-go] C++: copying arrays

[Chrilly]

I've got a class HashTable which contains one field: 


uint64_t data[CAPACITY];


If I have declared two such tables a and b, does


a = b;


copy the array, or do I have to overload the assignment operator =?

I know that I am a programming fosile, but I consider overloading of operators a horror for debugging and maintance. When skipping over code one should see what the operation does. Without having all the classes and definitions in ones head. Overloading destroys this visual information. One never knows what the operator really does. 

Array-names are pointers. Intuitevly I would say, that Pointers are assigned and not the memory is copied. a becomes an alias of b. If one writes it in the good old way

memcpy(a,b,sizeof(a)); 

its clear at the first glance whats going on. The "=" is in this case extremly ambigious and I accept every bet, that one will use the "=" in one place or other in the wrong way.

There are also examples were operator overloading makes sense. E.g. for a liberary of complex-numbers overloading the arithmetic operator is reasonable. In this case the meaning is clear and one can not confuse "+" with something else.

For a similar reason I am very skeptical to class hierarchies, overloaded functions. One never knows which function is really called. This is the purpose of class-hierarchies. One creates black-boxes. Actually like the Russian Babuschka puppets Black-Boxes containing Black-Boxes containig Black-Boxes...
This is fine as long as one can consider the black-box as a black-box. But sometimes one has to find out whats going on, because there is a bug. And then it becomes a nightmare. Visual inspection does not help, because the methods are determined dynamically. One can find it out with a debugger or by inserting "printf". But the really nasty bugs change/disappear if one inserts additional code or compiles in Debug-Mode.

I have not followed the Software-Engineering discussion/publications in the last time (because I am living now on the remote countryside and I can not visit the libaryr of the Univ. of Vieenna reguarly anymore).
I do not know if there are systematic studies about the development of bug statistics.I made for my own code and for code where I was engaged as programmming-consultant bug statistics. The bugs are practically not related to the programing language or methodolgy. The main reasons for errors are:
a) Exceptional cases/conditions. E.g. in chess the enpassant or castling rules. 
b) Poor understanding of the field. 
c) Change of specifications in the last moment or "simple improvements"  of an existing stable programm. There is no innocent change in a programm.
d) Porting a programm from one environment (OS or processor) to another. Every programm contains assumptions about the environment. E.g. on Intel-Processors memory transfers must not be aligned. One has just a time penality. On RISC-processors an unaligned memory transfer creates a processor exception. (In the new Pentium-SSE instructions there are now also aligned memory operations which crash in case of a non-aligned access).

Case b) is related to c). If the field is not really understood, a lot of changes/fixes are made during development and also afterwards in the operation phase. e.g. datastructures are changed many times.

Chrilly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://computer-go.org/pipermail/computer-go/attachments/20060810/ceb5138d/attachment.htm