I tried an enum. It was slower than both the class and int approaches. Basically changing a color wasn''t fast enough. It either required a conditional or a table lookup, and neither of those were as fast as a single xor. I thought some compiler would be able to optimize a statement like color = (color == white) ? black : white; into an xor, but I haven''t seen it. None of these are that much slower. I''m just wondering what the reason is for any slowdown, because as far as I can tell, it should run at exactly the same speed as the int version. Everyone I''ve asked about this class says it should be just as fast as the int, but it''s not, which makes me think I''m doing something wrong.

quote:Original post by dmikesell
What? Color is a class, which has a copy constructor. If you pass a Color object by value, the copy constructor gets called. If you pass by const reference, it does not.

It''s a class which is a POD-type (plain old data). Copying such a class that contains a 4-byte member through a trivial copy constructor is as fast as copying a pointer. So the passing process is as fast for both. But using a const reference has the problem of slower access times.

quote:Original post by dmikesell
No, I really mean you should avoid returning handles to member data, because evil (or perhaps inexperienced) programmers might find a way to get around the constness, breaking your encapsulation.

If an inexperienced programmer does a const_cast, he''s very strangely inexperienced to know of const_cast but not know that it''s dangerous.. It''s silly to design a system for the dumbest people to use, and waste time for that. And an "evil" programmer can whenever he wishes, take the pointer of any object and change all it''s contents to arbitrary numbers! Aargh, encapsulation is broken in every object you''ve ever designed, what to do what to do. (sorry if I made you have nightmares now! but reality is painful it seems)

You should honestly try a language like Lisp or Python, where there aren''t even private members or constness, yet large systems with the typical level of encapsulation are constantly being done in those languages. The language isn''t exactly enforcing it, but the language relies on programmers having at least the slightest amount of common sense to NOT access an object''s privates. Just like C++ programmers don''t generally directly access the memory given by an object''s pointer.

quote:Original post by dmikesell

quote:All this worry about return const & of internal members is mute.
Since as a programmer you are god and can chose to change anything you want. What stops you from change private to public in the header file, nothing we are gods remember.

What if you don''t have access to the header file? Could be owned by another department, but you *really* want write access to that member variable. That''s not "being evil" or "playing god". You really think that you have a good reason to change the value, and the class designer thinks he has an encapsulated class.

--
Dave Mikesell Software & Consulting

[edited by - dmikesell on October 24, 2003 9:59:51 AM]

You can break ANYTHING if you really want to, so encapsulation is never guaranteed. For example, even without the header file I could, with minimal effort, directly modify a private member inside of a class. Just cast the class pointer and shoot in the dark until you find the 4 bytes where the member is stored at. Boom, no more encapsulation.

quote:Copying such a class that contains a 4-byte member through a trivial copy constructor is as fast as copying a pointer.

The amount of data copied is the same, but you're not calling an extra function (copy ctor) every time you pass a Color around with the const reference. When you pass by value you are calling an extra function. That's the difference.

--
Dave Mikesell Software & Consulting

[edited by - dmikesell on October 25, 2003 8:58:28 AM]

quote:You can break ANYTHING if you really want to, so encapsulation is never guaranteed. For example, even without the header file I could, with minimal effort, directly modify a private member inside of a class. Just cast the class pointer and shoot in the dark until you find the 4 bytes where the member is stored at. Boom, no more encapsulation.

Yeah, but I''m talking about degree of difficulty here. The question is whether or not to return a handle to internal class data in a public member function. Most of the time you''ll probably be OK if you protect it with const, but not necessarily. That''s all.

--
Dave Mikesell Software & Consulting

quote:Original post by antareus
I call BS.

You call BS on what?