3 ms·

Can Just My Code help if it is precisely my code that I want to skip over? I believe it does not -- IIUC it works based on modules i.e. the DLL that contains th

Can Just My Code help if it is precisely my code that I want to skip over? I believe it does not -- IIUC it works based on modules i.e. the DLL that contains the machine code. IOW it doesn't even help if I move the "zero-cost" stuff to a separate source file -- templates and other stuff that have to be instanciated or inlined won't be separable from the code that I want to debug based on the module they're running in. > Also, there are scenarios where debugging without optimizations isn't an option. There are scenarios where debugging isn't an option in the first place. Doesn't mean that I should have to suffer in the typical case where debugging with no or only light optimizations is perfectly viable. An acceptable solution I guess would be to have a [DebuggerHidden] function attribute as I found for C#. Didn't find one for C++.

pjmlp 3y ago
Well, if we are going down tiny details about what to skip, there are lots of C preprocessor stuff, standard library functions implementated in crazy ways for ISO/POSIX compliance, and own abstractions/functions, that I might also want to skip over.
- jstimpfle 3y ago
  Well, don't go down that path. Stop bringing decreasingly relevant points. You are too argumentative. "standard library functions implemented in crazy ways" is what I though about once in my life, when writing a toy compiler whose output was linked to libc. Such "crazy functions" do exist but but apart from libc having little relevance in this context it's not at all like debugging a line my_arr[i] = make_arr_elem(). That is a reasonably looking line but can easily contain two more function calls than is immediately visible, and it's very very tiring in actual practice to step through such code. The only solution I've found is to be careful to use very little such magic. The general way that C is written in practice is that you don't have 3 function calls per line. So even if you have lots abstractions and macros in place that you would like to ignore (which can happen, but it's more rare than common) you can still skip over them (e.g. F10 in VS).
gpderetta 3y ago
[[gnu:: artificial]]
- jstimpfle 3y ago
  cool!

pjmlp 3y ago

Well, if we are going down tiny details about what to skip, there are lots of C preprocessor stuff, standard library functions implementated in crazy ways for ISO/POSIX compliance, and own abstractions/functions, that I might also want to skip over.

jstimpfle 3y ago
Well, don't go down that path. Stop bringing decreasingly relevant points. You are too argumentative. "standard library functions implemented in crazy ways" is what I though about once in my life, when writing a toy compiler whose output was linked to libc. Such "crazy functions" do exist but but apart from libc having little relevance in this context it's not at all like debugging a line my_arr[i] = make_arr_elem(). That is a reasonably looking line but can easily contain two more function calls than is immediately visible, and it's very very tiring in actual practice to step through such code. The only solution I've found is to be careful to use very little such magic. The general way that C is written in practice is that you don't have 3 function calls per line. So even if you have lots abstractions and macros in place that you would like to ignore (which can happen, but it's more rare than common) you can still skip over them (e.g. F10 in VS).

gpderetta 3y ago

[[gnu:: artificial]]

jstimpfle 3y ago
cool!