On Wednesday, 16 May 2012 at 02:55:41 UTC, H. S. Teoh wrote:
On Wed, May 16, 2012 at 04:01:23AM +0200, Stephen Jones wrote:
[...]
Using Object gives exactly the same problem as the Object super
class does not have vcount variable. Casting is not a solution
because the reason for throwing different sorts of widgets
into a
single array was so I did not have to track what each type of
object
was; not tracking what each object in the array is I have no
means
of knowing what to cast each Widget in the array to.
If you did not know what type each object was, how do you know
they have
a vcount variable?
If you _do_ know that they have a vcount variable, that means
you know
what type to downcast to. If there is more than one subclass
with a
vcount variable, that's an indication that you want to factor
it into a
common base class that gives a unified access to it, in which
case you'd
downcast to the common base class.
If some one knows void pointer syntax that would be helpful.
As I
understand it there is a type called size_t that takes the
address
of as a a value. Can I make an array of these and simply
initialize
each with &button1, &cursor, etc? Also, how is size_t freed?
Void pointer does not help you at all. You can't access the
vcount
variable through a void pointer unless you know it's a
particular type
that has such a variable -- you'd have to cast the void pointer
to that
type first. And in that case, you might as well be downcasting
instead
because it's type-safe. Blindly casting a void pointer into a
particular
type because you _think_ that's what it is, is a recipe for
disaster
when later on your list changes and the void pointer no longer
points to
what you think it points to.
T
Ali you are right about the void pointer requiring a cast as I
figured out. It does seem kind of odd that you cannot keep an
array of integers that hold the start address of blocks of memory
which blocks of memory contain objects such as Buttons etc. For I
would have thought that the start address would hold something
akin to a header telling whoever pointed at it that it was of a
type, whichever type it was. And that if somebody asked for a
piece of data that was in that block of memory the header would
provide the index to it. But then I have to speculate about how
it is things work because compiler design is not a field I am
familiar with.
Ali your post above, and T your post in the other forum (Simpsons
bit) is sort of what I was after. I tried both interface and
abstract class but not outright super class. The problem I have
with the solution is the same problem I have with header files
and cpp files; in both instances you need to hunt in other files
for the variable's definition. If name is a field that will
contain Bart's name then it should be in the Bart class,
otherwise I end up wasting time confused about some variable that
has been initialized or used to initialize some other variable
and not finding it in the relevant module.
Cain: My understanding is that D is based on "no proper ways of
doing things" just get the job done. The use of properties when
you can use public access baffles me. So long as you are careful
with the namespaces why would you want to incur function
overheads that could only possibly "save" the situation if you
were not careful with namespaces? Another anomaly I have never
understood is why would you use multiple property calls when you
could use a single function to set or get multiple items of data
for the cost of a single function? It is either fashion,
politics, or I am missing some piece of the puzzle.
