class Particle
{
public:
Particle( double x, double xVelocity = 0 )
{
this->x = x;
this->xVelocity = xVelocity;
}
void Update( double deltaTime )
{
x += deltaTime * xVelocity;
}
readonly double x;
private:
double xVelocity;
}
void main()
{
Particle p( 10.0, 1.0 );
cout << "The particle is currently at x = " << p.x << endl;
p.x = 12.0; // Compile Error, writing to a readonly variable
cout << "The particle is now at x = " << p.x << endl;
p.Update( 10.0 );
cout << "The particle is now at x = " << p.x << endl;
}
This style would allow for easy and efficient C style data access since there is no function call overhead using C++ style data accessor functions. But at the same time you would maintain the safety and encapsulation C++ offers. Its win win.
Writeonly variables would be similiar, only they would not be able to be read from. While likely not as useful as readonly, writeonly would definitely still have use. Namely in setting state variables of an object before updating that object and insuring proper adherence to the interface. There would be no reason to read variables which should be obsolete before updating the object, and with writeonly variables the object could insure this is an effective fashion without having to rely on potentially costly function overhead if the only ways to modify its state data was with tiny manipulator functions.
This seems much more elegant and in the C++ spirit, rather than writing the 1-3 line functions and relying on the virtually undefined implementation of inline and the obfuscation its obscurities bring your code.
Why aren't readonly and writeonly C++ Keywords?
Why was the concept of readonly/writeonly variables not included in C++? The idea is simple and useful. A readonly variable can only be written to by the class it is created within. A writeonly variable can only be read from the class it is created within.
For example:
Well, the function call overhead isn't really a problem because you can inline functions. Plus, for read-only variables you could use the const keyword so you wouldn't need accessor functions. Write only variables might be convenient sometimes, but since the functionality is so easy to get with accessor functions (inlined if necessary), there's not really any need for it. Also, a reason you give for needing write-only variables is for communicating across an interface but write-only variables expose implementation details of the interface b/c names and data types of all write-only variables would have to be the same across all implementations of the interface. So their utility would be very marginal.
[edited by - gurgi on July 8, 2003 1:03:50 AM]
[edited by - gurgi on July 8, 2003 1:03:50 AM]
The idea of a read only variable is a variable that can be modified from within the context of the class that creates the variable. As the example program shows, if the readonly variable was changed to a const then the program would not compile since the update function CHANGES THE VALUE OF THE READONLY VARIABLE SINCE IT IS WITHIN THE SAME CLASS AS THE VARIABLE WAS DECLARED WITHIN.
Also, as mentioned. The idea was to get rid of pointless 1-3 line inline declarations scattered throughout your .h files. It looks silly. Ideally, I would like to have a header as a pure header. No implementations, just headers. This makes for easier reading, updating and maintenance of code. Not to mention that, also as mentioned, the implementation of inline is not truly defined. A compiler can do pretty much of anything it likes when it sees an inline in code, so you're not even sure if your 50 little functions are actually being inlined ( though admittedly, they presumably are.. and should be even if you did not manually specify inline ).
It would be very nice if compilers, and the language, could evolve to point to where the inline keyword is as relevant as the register keyword is today.
[edited by - haro on July 8, 2003 1:26:10 AM]
Also, as mentioned. The idea was to get rid of pointless 1-3 line inline declarations scattered throughout your .h files. It looks silly. Ideally, I would like to have a header as a pure header. No implementations, just headers. This makes for easier reading, updating and maintenance of code. Not to mention that, also as mentioned, the implementation of inline is not truly defined. A compiler can do pretty much of anything it likes when it sees an inline in code, so you're not even sure if your 50 little functions are actually being inlined ( though admittedly, they presumably are.. and should be even if you did not manually specify inline ).
It would be very nice if compilers, and the language, could evolve to point to where the inline keyword is as relevant as the register keyword is today.
[edited by - haro on July 8, 2003 1:26:10 AM]
As another thought, readonly variables would almost definitely have to be restricted to primitives for the sake of efficiency, since accessing a readonly object would mean preventing access to the address of that object which would mean returning a copy of the entire object any time it was requested.
On the other hand, this is what I intend with readonly variables. They would be commonly used non-complex types, such as coordinate positions which will likely be represented as simple sets of real numbers long into the future.
[edited by - haro on July 8, 2003 1:20:00 AM]
On the other hand, this is what I intend with readonly variables. They would be commonly used non-complex types, such as coordinate positions which will likely be represented as simple sets of real numbers long into the future.
[edited by - haro on July 8, 2003 1:20:00 AM]
C++ isn''t about reading and writing, it''s about showing and hiding. Providing interfaces. That''s exactly what encapsulation is. I''m sorry that you don''t like the way things are done now, but that''s the paradigm.
quote:Original post by Zipster
C++ isn't about reading and writing, it's about showing and hiding. Providing interfaces. That's exactly what encapsulation is. I'm sorry that you don't like the way things are done now, but that's the paradigm.
Actually, C++ is a language. OO is the paradigm. Paradigms are things of whim and OO could be obsolete next year, though highly unlikely.. but who would have thought purely C style procedural code would become veritably obsolete a few decades after it was accepted as the method for code development.
If you have anything negative to argue with the concept of readonly/writeonly themselves I'd love to hear, but comments such as: "Well, OO doesn't do it that way.. so its dumb." are pointless, ignorant and lead to a lack of creative thought, so shouldn't have been stated in the first place. Remember, paradigms aren't there for you to memorize and accept as "The one and only holy path of good coders." , but rather as guides and tools for development. If something goes completely against your paradigm(s) of choice but helps you complete your task in a more timely or efficient manner without consequence, then by all means follow through with it.
[edited by - haro on July 8, 2003 1:40:03 AM]
readonly once existed. It was what const was originally called
But yes, readonly would be a neat feature. I''ve always hated using interfaces for the same purposes. It would be good if there was some distinction between accessing a variable to read it or to write to it.
But yes, readonly would be a neat feature. I''ve always hated using interfaces for the same purposes. It would be good if there was some distinction between accessing a variable to read it or to write to it.
Fine then. I don''t have time to argue with you about languages and paradigms.
How do your new keywords eliminate the usage of those "pointless" 1-3 accessor functions? If a variable is readonly, then what happens when it needs to be written to? If a variable is writeonly, then what happens when it needs to be read? And if a variable is then both readonly and writeonly, then why isn''t it just private? Have you really thought out the usage of these keywords, or was it simply out of frustrating at all the accessor functions you had to write?
quote:If you have anything negative to argue with the concept of readonly/writeonly themselves I''d love to hear
How do your new keywords eliminate the usage of those "pointless" 1-3 accessor functions? If a variable is readonly, then what happens when it needs to be written to? If a variable is writeonly, then what happens when it needs to be read? And if a variable is then both readonly and writeonly, then why isn''t it just private? Have you really thought out the usage of these keywords, or was it simply out of frustrating at all the accessor functions you had to write?
quote:Original post by Zipster
How do your new keywords eliminate the usage of those "pointless" 1-3 accessor functions? If a variable is readonly, then what happens when it needs to be written to? If a variable is writeonly, then what happens when it needs to be read? And if a variable is then both readonly and writeonly, then why isn't it just private? Have you really thought out the usage of these keywords, or was it simply out of frustrating at all the accessor functions you had to write?
I'm sorry, I hadn't realized you don't understand the basic concepts. Okay, let's say you create a new class, a particle class. And that particle class has a series of 3 variables representing the location of the individual particle (x,y,z). Now let's assume you want to access the x location of that particle for some function.
There are two ways to do that. Create an inlined function and make a call along the lines of:
someFunction( particle.GetXValue() );
Or as suggested, you could simply do:
someFunction( particle.x );
The latter method is cleaner and does not require dirty looking inlining to prevent having an extra 6 cycles added to a likely 2 cycle function. Now, the point of readOnly is that you are allowing classes outside of the particle class to read the data, but not to modify it. Do you understand at all?
particle.x = 13 would create a compile time error.
Let me know if you're still confused. writeonly is very similiar, only outside classes can only 'write' to the respective variables.. hence the name 'writeonly'.
EDIT: As far as a writeonly and readonly primitive, that would be illogical. That would be along the same lines as trying to declare an unsigned signed integer. And again, I would ask you to lay off the childish flames -- I'm not sure if you're truly as confused as you sound or if you're just trying to hijack the thread, either way I will not respond to further 'taunts' which these clearly are considering you wrote this message and then deleted it earlier for whatever reason.
[edited by - haro on July 8, 2003 2:31:36 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement