Top Mud Sites Forum - View Single Post

Yui Unifex · 03-31-2003, 07:33 PM

I see you're using multiple inheritence -- I'm sorry, I must have misunderstood your earlier post and thought that it was a single hierarchy.

It is plainly obvious why this is not a bug, however: Class A and class B simply can not share the same memory address. When assigning a pointer to one of the parents here, you have to grab the part of C where B starts. So you should get an address like sizeof(overlapping parent)+sizeof(object overhead)+address. So what exactly is the problem here? The only way to fix this would be to make A and B both share the same address, and that's impossible.

You can return an error code from "in place" operators where the "real" return value is not something essential to the operation. This tends to break other idioms and is certain to confuse readers of your code, but it's definately possible.

Few non-functional, non-dynamic languages have achieved the flexibility and genericity that C++ has. Every one of the features you consider 'bad' has a use that would cause severe detriment were it removed.

That is incorrect. I said that they were not the same as each other. I don't know where you came up with this.
That is also incorrect. Where did this come from?

I don't think you understood me here. Restricting people from working in both ceramics and glass is radically different than allowing people to choose a specialty of their own accord. In one case, people are forced into what they do. In the other, they still have the choice to make some sort of ceramic-glass hybrid (It'll take the world by storm!) if they felt like it. As you can see, they are plainly not the same thing.

Here we move into the realm of principle. More on this in another post.

I'm not Swiss, nor am I a Sociologist, nor am I in a position to understand their situation. But anyone with a little savoir-faire knows that parts of languages tend to seep into others, neh?

Just as all people do not always write for a mass audience, all programmers do not always write for a mass audience.

This is a common tactic amongst logicians, to see how a particular argument stands up to scrutiny. If an argument or position, through extrapolation, condones something that is unacceptable, the argument or position must be revised to correct it. By doing this, I hope that you will either clarify your argument so that the unacceptable situation is avoided, or modify your argument for the same effect. In essence: What makes C and C++ so special that your logic only applies to it and not C and VB? Specifically, the part about certain features being confusing (on average) and thus should be removed from the language.

Even if a language design document states "Private members are never accessible under any circumstances not controlled by the class", these extensions (btw, Obj.magic is part of ocaml's standard library) prove that they were useful enough to include. Even still, one that relies on private members as anything more than a way to keep oneself from making stupid mistakes with regards to encapsulation of data is placing far too much trust in their environment.

Furthermore, unfettered access to a class' memory is very useful for those languages which lack functional properties like closures. It is useful for serialization and optimizations that scrunch classes together to avoid overhead, like a memory pool. There are thousands of C libraries which C++ was designed to interoperate with, that require a void or char pointer and a size, and then provide an operation on that memory. C++ wouldn't be operating as designed if it did not provide this functionality, and provide it easily.

They're pretty obvious: Every time you see the dereference operator (&), look for an address to be used. References and pointers are too different things.

References come with their own problems. They aren't re-assignable, so you are forced to encapsulate changes to them which causes problems with iteration constructs. They're always "valid", so you can't have a find operation return NULL. And for languages that pass them by value (like Java and Ruby), you have to implement silly workarounds (like encapsulating them in another object) to assign to the base value.

03-31-2003, 07:33 PM	#38
Yui Unifex Senior Member Join Date: Apr 2002 Location: Florida Posts: 323	I see you're using multiple inheritence -- I'm sorry, I must have misunderstood your earlier post and thought that it was a single hierarchy. It is plainly obvious why this is not a bug, however: Class A and class B simply can not share the same memory address. When assigning a pointer to one of the parents here, you have to grab the part of C where B starts. So you should get an address like sizeof(overlapping parent)+sizeof(object overhead)+address. So what exactly is the problem here? The only way to fix this would be to make A and B both share the same address, and that's impossible. You can return an error code from "in place" operators where the "real" return value is not something essential to the operation. This tends to break other idioms and is certain to confuse readers of your code, but it's definately possible. Few non-functional, non-dynamic languages have achieved the flexibility and genericity that C++ has. Every one of the features you consider 'bad' has a use that would cause severe detriment were it removed. That is incorrect. I said that they were not the same as each other. I don't know where you came up with this. That is also incorrect. Where did this come from? I don't think you understood me here. Restricting people from working in both ceramics and glass is radically different than allowing people to choose a specialty of their own accord. In one case, people are forced into what they do. In the other, they still have the choice to make some sort of ceramic-glass hybrid (It'll take the world by storm!) if they felt like it. As you can see, they are plainly not the same thing. Here we move into the realm of principle. More on this in another post. I'm not Swiss, nor am I a Sociologist, nor am I in a position to understand their situation. But anyone with a little savoir-faire knows that parts of languages tend to seep into others, neh? Just as all people do not always write for a mass audience, all programmers do not always write for a mass audience. This is a common tactic amongst logicians, to see how a particular argument stands up to scrutiny. If an argument or position, through extrapolation, condones something that is unacceptable, the argument or position must be revised to correct it. By doing this, I hope that you will either clarify your argument so that the unacceptable situation is avoided, or modify your argument for the same effect. In essence: What makes C and C++ so special that your logic only applies to it and not C and VB? Specifically, the part about certain features being confusing (on average) and thus should be removed from the language. Even if a language design document states "Private members are never accessible under any circumstances not controlled by the class", these extensions (btw, Obj.magic is part of ocaml's standard library) prove that they were useful enough to include. Even still, one that relies on private members as anything more than a way to keep oneself from making stupid mistakes with regards to encapsulation of data is placing far too much trust in their environment. Furthermore, unfettered access to a class' memory is very useful for those languages which lack functional properties like closures. It is useful for serialization and optimizations that scrunch classes together to avoid overhead, like a memory pool. There are thousands of C libraries which C++ was designed to interoperate with, that require a void or char pointer and a size, and then provide an operation on that memory. C++ wouldn't be operating as designed if it did not provide this functionality, and provide it easily. They're pretty obvious: Every time you see the dereference operator (&), look for an address to be used. References and pointers are too different things. References come with their own problems. They aren't re-assignable, so you are forced to encapsulate changes to them which causes problems with iteration constructs. They're always "valid", so you can't have a find operation return NULL. And for languages that pass them by value (like Java and Ruby), you have to implement silly workarounds (like encapsulating them in another object) to assign to the base value.