Re: [GD-General] Eiffel

[Thatcher U. <tu...@tu...>]

On Sat, 22 Dec 2001, Jesse Jones wrote:

> At 10:08 AM -0500 12/21/01, Thatcher Ulrich wrote:
> >On Dec 21, 2001 at 01:56 -0500, Kent Quirk wrote:
> >>
> >>  fact, one of the things that I love about Java and wish that C++
> >>  had was anonymous classes. They provide the only way to deal
> >>  with the concept of functors in generic algorithms where the
> >>  functor is defined at the same point as the algorithm is
> >>  used. In C++ you can put it nearby. In Java you can stick an
> >>  anonymous class right inline. It's a powerful, useful, and very
> >>  general mechanism, similar to a lambda notation.
> >
> >Someone showed me this trick recently:
> >
> >	...
> >	struct Function {
> >		static void Call(int arg) {
> >			// some code.
> >		}
> >	} Instance;
> >	SomeFunctionTakingAFunctionPointer(Function::Call);
> >	...
>
> People have been writing templatized callback classes in C++ for
> years. Boost has recently adopted one that is pretty darn cool (see
> the function and bind links at
> <http://www.boost.org/libs/libraries.htm#Function-objects>).
>
> It allows you to write code like this:
>
> Editor* editor = ...;
> boldButton->SetCallback(boost::bind(&Editor::SetStyle, editor,
> kBold));
>
> italicButton->SetCallback(boost::bind(&Editor::SetStyle,
> editor, kItalic));

That's nice, but I don't think that addresses Kent's complaint.  Let's
say you wanted to toggle the bold mode on boldButton.callback; how
would you write:

	struct anon {
		static Editor* editor;
		anon(Editor* e) : editor(e) {}
		static void callback() {
			int	s = editor->GetStyle();
			s ^= kBold;
			editor->SetStyle(s);
		}
	} instance(editor);
	boldButton->SetCallback(instance::callback);

I'm not claiming that's great (in fact it stinks :).

> >and pardon me,
> >but IMHO the STL stinks as far as usability goes.
>
> I don't think STL stinks at all from a usability standpoint. Once
> you wrap your head around the concept of containers, iterators, and
> algorithms it's really easy to use and very powerful.

An example of how the STL is not "really easy to use":

	std::hash_map<string, int> my_hash;

	...
	string	my_key = something...;
	int	my_value = something...;

	// I want to see if my_key is in my_hash, and if so, whether
	// its value matches my_value.
	std::hash_map<string, int>::iterator it = my_hash.find(my_key);
	if (it != my_hash.end() && (*it).second == my_value)
	{
		// Match.
	} else {
		// Mismatch.
	}

I think I got that right.  The iterator is just obfuscation.  Whereas
the way you'd do it in Perl or Lua, the seemingly obvious:

	if (my_hash[my_key] == my_value) {
		// Match.
	} else {
		// Mismatch.
	}

compiles, and leaks memory!  I've seen code like the above, written by
professional C++ coders.  I probably wrote code like that myself the
first half-dozen times I used map or hash_map.  A hash container
should not define operator[] the way std::hash_map does; it's just
programmer abuse.

I find that kind of thing is endemic to the STL.  The STL was designed
(cleverly) as a demonstration of generic programming, rather than as a
nice container library.  Unfortunately, people use it as a container
library, and IMO it stinks for that.

-Thatcher