RFC: Better C++ support

["Eray Ozkural (exa)" <erayo at cs dot bilkent dot edu dot tr>]

Hi there,

I'd like to make some suggestions for C++ support which I think would
make insight a really distinguished product. One that you could write
in an advertisement oriented feature list :)

What I wish is probably very difficult to implement, not doable and
prone to errors, so please no flames ;) Also excuse my ignorance if
these have been implemented elsewhere. If you think these can be done
relatively easily on insight I'll be willing to help coding. I once
wanted to do it on DDD but it required too much work for me, and I didn't
do it yet, still on my todo list.

Here is the wish list:

  1) C++ Standard Library support:
  --------------------------------

    * Since C++ library is standard, a debugger can parse type information
and display data in a more suited way. This should probably be an
optional feature that can be turened on/off.

    * For instance, in a watch window if there is a string instance, it
would be visualized as "....". If a variable is a vector<T,A> instance
it would be displayed like <1,2,3,4,...>

    * For collection objects we would also need a way to navigate into
elements of the list and accessing elements individually. Then again C++
syntax can be used. Suppose the program has these lines:

   vector<int> vec;
   for (vector<int>::iterator i=vec.begin(); i!=vec.end(); i++) {
     whatever(vec);
   }
  
Now after the constructor, we might want to have a look at 3rd element of
vec. This would be accomplished by requesting "vec[3]" from variable
display or watch component. Last time I checked this didn't work on DDD.
I suppose it can be done without mocking with low-level gdb?

The vector<int> instance <1,2,3,4> could be graphically represented as
a collection of thin boxes. Something similar to what DDD does for data
display but it can be done in a more conservative way. In particular, I'm
not talking about visualizing pointers. It's a hard topic. This is easier
and yields more benefits for less work I guess. Ideally, I would like the
widget to be space conservative at least :) It would be very neat if you
could choose whether to display addresses, element indices or contents of
a vector. The third is the most essential and the two would be easy to
add once you get third done so I think both three can be done. :)

    * A map<string,int> could be displayed like <("a", 1), ("b", 2), ("c",3)>
Also a way to view all keys and navigate through keys would be useful.

    * This idea can be nicely extended to parse other classes in the
standard library. An idea that occured to me while I began writing is
recognizing exceptions, and reporting them in a separate exception window
perhaps. Anyway, all container classes can be visualized better this
way or other.


  2) Extensible visualization support
  ----------------------------------

     * These would be useful, but wouldn't work if the programmer used
  things other than the standard library. For that we need a way for the
  programmer to write visualization plug ins.

     * The handling level of the plug in would matter. I can think of a
  few alternatives

       * A plugin spec at the level of display system : like netscape plugins
  perhaps. This might be clumsy because it requires a lot of new code I
  guess. Basically embedding a small X app in a tk window would do this. But
  I have never written such a plugin framework and I don't know if it could
  be done since plugins have to be portable (or would better be) and thus
  we would need yet-another-display-abstraction which isn't a good idea.
  Though, perhaps we could use some existing architecture, perhaps from
  mozilla. Anyway, perhaps this is the way to go but I don't know if it's
  good enough.

       * A plugin directly at language binding. The programmer writes the
  plugin by writing his code in a parse-able way. Basically some magic
  functions that the debugger knows, and would call them to visualize a
  class.

  #include <insight_visualization>
 
  class My_Array {
  public:
     // wonderful array class that never works fast enough :)
     ...
     ...

     insight_visualize() {
       init_visualizer(num_elements*100, ....);
       for (....) {
         add_box( &(*i), to_string(*i) );
       }
       // something that makes it tick :)
        ...
     }
     insight_visualize(int index) {
        ...
     }
  private:
     // who knows what
     ...
  }
  
   Anyway, you get the idea. I know it sounds a bit weird but I like it
   because it is consistent with the standard lib support I described
   earlier.

   This could also be done in C++ by specifying an abstract class with
   pure virtual functions, but it wouldn't be desirable in all cases.

           * Extensions as tcl/tk code. This might be good, but I could
   describe it if I knew tcl/tk good enough. I don't. I just read that
   "practical programming with tcl/tk", skimming it a bit to fix the
   errors in my insight build. Then I guess, one could write a library
   that specifies how to write these visualizations. Then, it would be
   quite easy to do the plugging in because everything would be tcl/tk.
   But I honestly don't know how this is done in tcl/tk.

  3) Example for extensible visualization:
  ---------------------------------------
    Assume a class for holding image data. Say in JPEG format. When you
  display that variable, the actual image, perhaps thumbnailed, would be
  displayed in a separate window.


I'm hoping that one day I'll be using a debugger with these features, but
as I said these are just ideas :) Perhaps I flew too high, but at any
rate I await your comments.

Regards,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo