Nicolás Brailovsky


A modern blog

Archive for August, 2009

“Good Linux users don’t talk about Microsoft”

author Posted by: nico on date Aug 27th, 2009 | filed Filed under: Uncategorized

I don’t usually post links, I’d rather write something myself, but check out this quote:

You don’t see me calling Linux users tux turds, penguin poopers or GUI-challenged, do you?

http://www.pcmech.com/article/good-linux-users-dont-talk-about-microsoft/

Enjoy

commentBe the first!
tags

More preprocessor wizardy: strings

author Posted by: nico on date Aug 25th, 2009 | filed Filed under: C++, Programming
No preprocesor wizard should go out of his house without the always useful string maker. Let’s say you’re trying to create a class with some sort of pseudo type-system (*):

  1. class FooBar {
  2.    public:
  3.    const char* get_name(){ return "FooBar"; }
  4. };

Why would you type ALL that when you can make a simple macro, MK_CLASS, like this:

  1. MK_CLASS( FooBar )
  2.    /* Other methods */
  3. };

Problem is, this will only print “Name”:

  1. #define MK_CLASS( Name ) \
  2.       class Name { public: \
  3.             const char *get_name(){ return "Name"; }

Well, it’s an easy fix, just prepend # to your string, like this:

  1. #define MK_CLASS( Name ) \
  2.       class Name { public: \
  3.             const char *get_name(){ return #Name; }

Or use this nice string maker:

  1. #define MK_STR(str) #str

As usual, use the preprocesor at your own risk.

(*) Yeah, I know, OO purists will try to beat me to death for this, but it actually has some uses. I’ve found it to be a specially good solution when working with low level protocols.

commentBe the first!
tags

Tech Support

author Posted by: nico on date Aug 24th, 2009 | filed Filed under: Uncategorized

Two comics this month, but I’m sure it’s worth it:

This advice would have saved me a couple years of life. Normal post tomorrow.

commentBe the first!
tags

Something to add to your news reader

author Posted by: nico on date Aug 20th, 2009 | filed Filed under: Uncategorized



commentBe the first!
tags

C++ oddities: Self initialization

author Posted by: nico on date Aug 18th, 2009 | filed Filed under: C++, Programming
I get it, C++ is a complex language, but man, I’d like a little warning (lol) when this happens:

  1. class Foo {
  2.   int bar;
  3.   Foo() : bar(bar) {}
  4. };
 cpp

Yeah, it bit me in the ass the other day. Why? A method’s signature was awfully long, I wanted to delete a parameter and ended up deleting two. Luckly my unit tests where there to save the day, but regardless, WTF?

commentBe the first!
tags

Vim: A little color (syntax highlighting)

author Posted by: nico on date Aug 13th, 2009 | filed Filed under: Vim Tips
vim_editor Short tip this time: how do you set Vim to show pretty colors for your source code? Easy enough, :syntax on is all you need!
commentBe the first!
tags

Ubuntu: Dual monitors

author Posted by: nico on date Aug 11th, 2009 | filed Filed under: Gnome, Linux

There’s nothing better than feeling like a super villain by having a dual monitor setup. OK, three may be better, you probably couldn’t hold back the evil laughter, but my laptop won’t support three screens.

dilbert

Fortunately, in Ubuntu JJ having a dual screen setup is a breeze. Just plug the two monitors and hope it works. Of course, it may not. If that’s the case you can go to System > Preferences > Screen for a nice GUI, which will let you select each screen’s resolution and position. Nothing better for productivity than having your monitors swapped, or even better, flipped upside down.

Well, sometimes “Screen Preferences” won’t work either, too bad. In that’ case you’ll have to get dirty with xrandr. It’s not too difficult but it’s console based (you’re not scared of the console, are you?).

Though the man page for xrandr is a little bit intimidating at first you’ll just have to do it once, so I won’t write about using it, I will just copy & paste a script I keep in my desktop to fix the screen whenever it brakes (my lapop tends to foobar my screen when being docked or undocked, not sure why)

  1. xrandr –output HDMI-2 –right-of HDMI-1 –mode 1680×1050 –rotate normal

I am sure you can figure out the rest on your own – enjoy the dual screen setup!

commentBe the first!
tags

Ubuntu: Annoying terminal warning

author Posted by: nico on date Aug 6th, 2009 | filed Filed under: Linux
annoying Although I’m quite happy with Ubuntu 9.04, I find a couple of new features quite annoying. The warning message it pops up whenever you try to close a console with a running program in it falls in this category. Fortunately it’s not difficult to disable:

1. Open up gconf-editor
2. goto /apps/gnome-terminal/global/
3. Untick confirm_window_close

All set. As a bonus side effect now closing a terminal with multiple tabs won’t pop up a message either.
commentBe the first!
tags

C++: Magic callbacks solved

author Posted by: nico on date Aug 3rd, 2009 | filed Filed under: C++

Long post this time – and lots of code too. How fun iz that?
Anyway, remember where we left last time? We’re supposed to make this work:

  1. class Callee {
  2.         Callback notify;
  3.         public:
  4.         Callee(Callback notify) : notify(notify) {}
  5.         void finish(){ notify(this); }
  6. };
  7.  
  8. class Caller {
  9.         Callee c;
  10.         public:
  11.         Caller() : c(Callback(this, &Caller::im_done)) {}
  12.         void im_done(Callee*) { }
  13. };

I’ll write about the different solutions I’ve tried and the problem each of these solutions had:

Experiment 1: Templates

We could to this the easy way, with a template:

  1. template <class Callback>
  2. class Callee {
  3.         …
  4. };
  5.  
  6. class Caller {
  7.         template <class T>
  8.         void operator() (T p){ this->im_done(p); }
  9.         …
  10. };

This has some drawbacks:

  1. We need to change the definition of the Callee
  2. The Caller can only have one callback (or overloaded one callback)
  3. It’s boring

Experiment 2: Template virtual method

So, lets try another approach: the naive one is an interface:

  1. class iCallback {
  2.         public:
  3.         template <class T> void operator () (T o) = 0;
  4. };

Looks great, doesn’t it? Too bad it’s not valid C++, you can’t have a virtual template method (what would the vtable size be?).
If we can’t have a template method let’s make a template class:

  1. template <class T>
  2. class iCallback {
  3.         public:
  4.         virtual void operator () (T o) = 0;
  5. };
  6.  
  7. class Callee {
  8.         iCallback<Callee*> *notify;
  9.         public:
  10.         Callee(iCallback<Callee*> *notify) : notify(notify) {}
  11.         void finish(){ (*notify)(this); }
  12. };
  13.  
  14. class Caller : public iCallback<Callee*> {
  15.         Callee c;
  16.         public:
  17.         Caller() : c(this) {}
  18.         void im_done(Callee*) {}
  19.         void operator ()(Callee *o){ im_done(o); }
  20. };

It may not be pretty but it works. Also, adding a callback means adding a new operator (). Lets try to improve it a little by removing the nasty inheritance (remember, always prefer composition over inheritance):

Experiment 3: Callback Object

  1. template <class P>
  2. class iCallback {
  3.         public:
  4.         void operator () (P o) = 0;
  5. };
  6.  
  7. template <class T, class P>
  8. class Callback : public iCallback<P> {
  9.         // Notice this typedef: we have an object of type T and a
  10.         // function accepting a parameter P
  11.         typedef void (T::*member_func) (P);
  12.         T *cb_obj; member_func f;
  13.  
  14.         public:
  15.         Callback(T* cb_obj, member_func f)
  16.                         : cb_obj(cb_obj), f(f) {}
  17.  
  18.         inline void operator() (P o){
  19.                 (cb_obj->*f)(o); // ->* is the best voodoo operator
  20.         }
  21. };

This new object should help us to:

  1. Implement different callback functions (not tied to an operator() nor a type overload) while staying type-safe
  2. Delete the inheritance
  3. Use the arrow-asterisk operator (!) which is way cool

How would this change leave our code?

  1. class Caller;
  2. class Callee {
  3.         Callback<Caller, Callee*> *notify;
  4.         public:
  5.         Callee(Callback<Caller, Callee*> *notify) : notify(notify) {}
  6.         void finish(){ (*notify)(this); }
  7. };
  8.  
  9. class Caller {
  10.         Callback<Caller, Callee*> cb;
  11.         Callee c;
  12.         public:
  13.         Caller() : cb(this, &Caller::im_done), c(&cb){}
  14.         void im_done(Callee*) {}
  15. };

Oops, looks like we took one step back: now Callee MUST know the type of Caller. Not nice. Luckily it is an easy fix:

Experiment 4: Callback interface

  1. class Callee {
  2.         iCallback<Callee*> *notify;
  3.         public:
  4.         Callee(iCallback<Callee*> *notify) : notify(notify) {}
  5.         void finish(){ (*notify)(this); }
  6. };

OK, we’re back on track. We will solve that weird looking (*notify)(this) later, don’t worry.
We’re almost there, but specifying the callback as <Caller, Callee*> is ugly, Caller should be automagically inferred from the context by some template voodoo. Let’s do it by implementing a wrapper:

  1. template <class R>
  2. class WraperCallback {
  3.         iCallback<R> *cb;
  4.         public:
  5.                 template <class T, class F>
  6.                 WraperCallback(T* cb_obj, F f)
  7.                                 : cb( new Callback<T, R>(cb_obj, f) ) {}
  8.  
  9.                 ~WraperCallback() {
  10.                         delete cb;
  11.                 }
  12.  
  13.                 inline void operator()(R o){
  14.                         (*cb)(o);
  15.                 }
  16. };

Now we no longer need to specify the Caller type. There’s still a nasty issue about pointer-vs-object passing. Using (*notify)(this) is very ugly so let’s do it like this:

Experiment 5: Callback object bis

  1. class Callee {
  2.         WraperCallback<Callee*> notify;
  3.         public:
  4.         Callee(WraperCallback<Callee*> notify) : notify(notify) {}
  5.         void finish(){ notify(this); }
  6. };
  7.  
  8. class Caller {
  9.         Callee c;
  10.         public:
  11.         Caller() : c(WraperCallback<Callee*>(this, &Caller::im_done)) {}
  12.         void do_it(){ c.finish(); }
  13.         void im_done(Callee*) { }
  14. };

Nice, this time it should work as expected. Only it does not, there is something horribly wrong about it. Can you see what it is? Take a second, I’ll wait… OK, back? Right, it segfaults! Why? Easy, take a look at this:

  1.         Callee(Callback<Callee*> notify) : notify(notify) {}

We are using a copy constructor here, and what does our wrapper store?

  1.                 WraperCallback(T* cb_obj, F f)
  2.                                 : cb( new Callback<T, R>(cb_obj, f) ) {}

Indeed, the copied WrapperCallback ends up pointing to a deleted Callback when the cb field of the original object gets copied and then destructed. We should have all the pieces to fix it now: we just need to implement the copy operator to make it work. How does the final version looks like?

Solution

  1. template <class P> class iCallback {
  2.         public:
  3.                 virtual void operator()(P) = 0;
  4.                 virtual iCallback<P>* clone() const = 0;
  5. };
  6.  
  7. template <class T, class P>
  8. class RealCallback : public iCallback<P> {
  9.         typedef void (T::*member_func) (P);
  10.         T *cb_obj; member_func f;
  11.  
  12.         public:
  13.         RealCallback(T* cb_obj, member_func f)
  14.                         : cb_obj(cb_obj), f(f) {}
  15.  
  16.         /**
  17.          * The clone operator is needed for the copy ctr of
  18.          * the Callback object
  19.          */
  20.         inline iCallback<P>* clone() const {
  21.                 return new RealCallback<T, P>(cb_obj, f);
  22.         }
  23.  
  24.         inline void operator() (P o){
  25.                 (cb_obj->*f)(o); // ->* is the best vodoo operator
  26.         }
  27. };
  28.  
  29. template <class R>
  30. class Callback {
  31.         iCallback<R> *cb;
  32.         public:
  33.                 template <class T, class F>
  34.                 Callback(T* cb_obj, F f)
  35.                                 : cb( new RealCallback<T, R>(cb_obj, f) ) {}
  36.  
  37.                 Callback(const Callback& cpy)
  38.                                 : cb( cpy.cb->clone()) {}
  39.  
  40.                 ~Callback() {
  41.                         delete cb;
  42.                 }
  43.  
  44.                 inline void operator()(R o){
  45.                         (*cb)(o);
  46.                 }
  47. };

Conclusion

Now we have a nice callback object which can link two objects without them knowing each other. There is room for future improvement, of course:

  1. Got any ideas to implement a generic callback to a function with an unknown number of params? I don’t (variadic templates == cheating!)
  2. I’m quite sure the param type for the callback could be inferred in some magical template way, but I don’t know how.
  3. Think of anything else to add? Let me know in the comments!
commentComments (1)
tags