Databases
StackOverflow2013
Postsdbo
POLogging code execution in C++
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POLogging code execution in C++
    primarykey
    data
    text
    <p>Having used <strong>gprof</strong> and <strong>callgrind</strong> many times, I have reached the (obvious) conclusion that I cannot use them efficiently when dealing with large (as in a CAD program that loads a whole car) programs. I was thinking that maybe, I could use some C/C++ <strong>MACRO</strong> magic and somehow build a simple (but nice) logging mechanism. For example, one can call a function using the following macro:</p> <pre><code>#define CALL_FUN(fun_name, ...) \ fun_name (__VA_ARGS__); </code></pre> <p>We could add some clocking/timing stuff before and after the function call, so that every function called with CALL_FUN gets timed, e.g</p> <pre><code>#define CALL_FUN(fun_name, ...) \ time_t(&amp;t0); \ fun_name (__VA_ARGS__); \ time_t(&amp;t1); </code></pre> <p>The variables t0, t1 could be found in a global logging object. That logging object can also hold the calling graph for each function called through <strong>CALL_FUN</strong>. Afterwards, that object can be written in a (specifically formatted) file, and be parsed from some other program. </p> <p>So here comes my (first) question: <em>Do you find this approach tractable ? If yes, how can it be enhanced, and if not, can you propose a better way to measure time and log callgraphs ?</em></p> <p>A collegue proposed another approach to deal with this problem, which is annotating with a specific comment each function (that we care to log). Then, during the make process, a special preprocessor must be run, parse each source file, add logging logic for each function we care to log, create a new source file with the newly added (parsing) code, and build that code instead. I guess that reading CALL_FUN... macros (my proposal) all over the place is not the best approach, and his approach would solve this problem. So what is your opinion about this approach? </p> <p>PS: I am not well versed in the pitfalls of C/C++ MACROs, so if this can be developed using another approach, please say it so. </p> <p>Thank you. </p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USJohn
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. COIn another words : you are reinventing the wheel. Your collected data will contain not more information then from callgrind (if not less)
      singulars
      1. POLogging code execution in C++
      1. USBЈовић
    2. COYes his problem is not amount of information, but overhead.
      singulars
      1. POLogging code execution in C++
      1. USGiovanni Funchal
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload