This can be simplified further -- there should be one print method for
every class/struct entity as a member method

enum print_flags
{
   print_pretty = 0x1,
   print_decl_only = 0x2,
   print_raw  = 0x4,
   ..
};

class bitmap {
   public:
      void print_me (print_flags flags = print_pretty, FILE *stream = stderr);
     ...
};

class vector {
public:
      void print_me (print_flags flags = print_pretty, FILE *stream = stderr);
...
};

class cgraph_node {
   public:
    void print_me (...);
}..


Example:

decl->print_me (); // dump pretty form of the decl to stderr

decl->print_me (print_pretty | print_decl_only); ...


David

On Wed, Nov 14, 2012 at 5:12 PM, Lawrence Crowl <cr...@googlers.com> wrote:
> Diego and I seek your comments on the following (loose) proposal.
>
>
> It is sometimes hard to remember which printing function is used
> for debugging a type, or even which type you have.
>
> We propose to rely on overloading to unify the interface to a small
> set of function names.  Every major data type should have associated
> debug/dump functionality.  We will unify the current *_dump/*_debug
> functions under the same common overloaded name.
>
> We intend to only apply this approach to functions that take the
> type to display as an argument, and that are routinely used in
> debugging.
>
> We propose to provide several function overload sets, as below.
>
>
> dump_pretty
>
>     This function overload set provides the bulk of the printing.
>     They will use the existing pretty-printer functions in their
>     implementation.
>
> dump_raw
>
>     This function overload set provides the raw oriented dump,
>     e.g. a tuple.
>
> dump_verbose
>
>     This function overload set provides the extra details dump.
>
>
> All of these functions come in two forms.
>
>     function (FILE *, item_to_dump, formatting)
>     function (item_to_dump, formatting)
>
> If the FILE* is not specified, the output is to stderr.  The
> formatting argument is optional, with a default suitable to the kind
> of item to dump.
>
>
> We should remove tree-browser.c.  It is not used at all and it is
> likely broken.
>
> --
> Lawrence Crowl

Reply via email to