You should see me break inheritance. I'm master at that. I need a less thick skull
EDIT: I mean polymorphism... I do need that skull
You should see me break inheritance. I'm master at that. I need a less thick skull
EDIT: I mean polymorphism... I do need that skull
Last edited by Mario F.; 08-04-2006 at 07:39 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
It is actually possible to emulate properties using proxy objects, but it's not particularly useful, and they don't behave exactly like public member variables.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
A tendency towards monolithic classes is not a direct result of refraining from exposing internals.Originally Posted by Prelude
>Whatever fucntion is needing those values should probably be a member of the class where the variables live.
This is another symptom of bad design that promotes monolithic classes.Naturally, any good programmer will refrain from abusing features. Judicious use of getters and setters is just fine, ne?
More accurately it comes from making classes that are not mono-semantic.
If the programmer wishes to expose all or most member variables, then the class should possibly be a POD type.
there are obvious limitations with language, but with a little work it is possible.
Code:#include <iostream> template <class Type, class Get, class Set> class property { public: property(Type init = Type()) : get(Get()), set(Set()), data(init) { } property(Get lhs, Set rhs, Type init = Type()) : get(lhs), set(rhs), data(init) { } property(const property & rhs) : get(rhs.get), set(rhs.set), data(rhs.data) { } Type operator = (Type value) { set(value); return data = value; } operator Type (void) { get(data); return data; } /* accessing the value_type in a friend function isn't practicle (yet), so a temporary property is used. */ template <class Stream> friend Stream & operator >> (Stream & lhs, property & rhs) { property temp(rhs); lhs >> temp.data; if(lhs.good()) { rhs = temp.data; } return lhs; } template <class Stream> friend Stream & operator << (Stream & lhs, const property & rhs) { property temp(rhs); temp.data = rhs; return lhs << temp.data; } protected: Type data; Get get; Set set; }; /// struct Get { void operator () (double d) { std::cout << d << " = get()" << std::endl; } }; struct Set { void operator () (double & d) { if(d < 0) d = -d; else if(d == 0) d = 1; if(d < 1) d = 1/d; std::cout << "set(" << d <<")" << std::endl; } }; int main(void) { double z; property<double&, Get, Set> a(z); std::cin >> a; a = a * a; std::cout << z << std::endl; return 0; }
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
>A tendency towards monolithic classes is not a direct result of refraining from exposing internals.
No, it's the direct result of the tendency to make everything a member, which is precisely what I was referring to and what you seemed to be suggesting.
My best code is written with the delete key.
