0

Is there any way to 'display' the values we get in a For loop into a console continuously to monitor the value changes? There are some examples about this but most likely are not related with loops.

For example, I can use the console to monitor the value changes of the fromPos and toPos which get from the other functions.

void Position()
 for (int iPos=0; iPos<100; iPos++)
 {
   double fromPos = PositionLoop.GetPosition1(iPos);
   double toPos = PositionLoop.GetPosition2(iPos);

   if (fromPos == toPos)
   {
     //do stuff
   }
}
Joshua_0101
  • 57
  • 5
  • 1
    Just as you would output at any other location, e.g. `std::cout << fromPos << ' ' << toPos << '\n';` – it does not matter *where* you print output, inside or outside of a loop. When the code comes across your statement, it executes it – multiple times in a loop... – Aconcagua Oct 25 '21 at 11:45
  • Is it a console program or a program with a GUI (graphical user interface) ? – Jabberwocky Oct 25 '21 at 12:18
  • 1
    The loop is not a problem with output. With that said, do you get output at all if you cout outside a loop? If not perhaps you don't have a console because you have a GUI application and you did not create one? – drescherjm Oct 25 '21 at 12:19
  • Please tell us more about your problem (reading this may help: [ask]). Maybe you are looking for this: https://learn.microsoft.com/en-us/visualstudio/debugger/mfc-debugging-techniques?view=vs-2019#BKMK_The_TRACE_macro ? – Jabberwocky Oct 25 '21 at 12:21
  • 1
    I wrote this answer about options for enabling console output in a windows GUI application long ago: [https://stackoverflow.com/questions/13840942/visual-studio-2012-c-standard-output/13841522#13841522](https://stackoverflow.com/questions/13840942/visual-studio-2012-c-standard-output/13841522#13841522) – drescherjm Oct 25 '21 at 12:21
  • 1
    Since you're developing MFC it is likely you are using developer studio. In that case you could also use OutputDebugString, https://learn.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-outputdebugstringa. This will show you the output in visual studio's output window while you're debugging the program. – Pepijn Kramer Oct 25 '21 at 12:47
  • 2
    @PepijnKramer the [`TRACE`](https://learn.microsoft.com/en-us/visualstudio/debugger/mfc-debugging-techniques?view=vs-2019#BKMK_The_TRACE_macro) macro is probably easier to use then `OutputDebugString`. OTOH latter can be used with release builds. – Jabberwocky Oct 25 '21 at 12:52
  • @Jabberwocky Indeed, depends on what is needed. But you're right TRACE would be a better choice in this case. – Pepijn Kramer Oct 25 '21 at 13:09
  • @Jabberwocky It's an .exe program with GUI. Is it better to create a dialog/window to show the values instead of using console? – Joshua_0101 Oct 25 '21 at 13:16
  • @drescherjm Yes, I can't get the output if cout outside the loop. – Joshua_0101 Oct 25 '21 at 13:21
  • If it works outside the loop. It should work inside. Maybe the loop is never executed. Set a breakpoint using the F9 key to see what is happening. – drescherjm Oct 25 '21 at 13:22
  • @Joshua_0101 it depends on your use case. You need to give us more context information. – Jabberwocky Oct 25 '21 at 13:28
  • This function is called by a running thread and the loop will always been executed. The purpose is to monitor the values of _fromPos_ and _toPos_ from time to time at the particular timing inside the loop (this is due to the _GetPosition1_ and _GetPosition2_ will passed in different value at different timing). For example, we can monitor the _fromPos_ and _toPos_ values of the specific _iPos_ iterator. – Joshua_0101 Oct 25 '21 at 13:42
  • You could probably get that to print in console window, but it's easier to use `TRACE` in MFC GUI. You can also use a custom `OutputDebugString` because `TRACE` gives way too much information, it fills up the screen. – Barmak Shemirani Oct 25 '21 at 14:03
  • 2
    This reads like it's trying to use what's frequently called *"printf-style debugging"*. If that is the case, then don't. Just don't. You're not on Linux, where there simply isn't anything that remotely resembles a useful debugger, and this is what needs to be done. You're on Windows, using Visual Studio. See [Log info to the Output window using tracepoints in Visual Studio](https://learn.microsoft.com/en-us/visualstudio/debugger/using-tracepoints) to learn how to use your debugger effectively. All the printf-style debugging you want without ever changing a single line of code. – IInspectable Oct 25 '21 at 14:17
  • 1
    No debugger on linux??? At very least there's GDB and there are GUI frontends for as well, every IDE should provide a suitable one. – Aconcagua Oct 26 '21 at 10:57
  • @aco Yes, there's GDB. I was specifically talking about *"useful debuggers"*. GDB doesn't fall into that category, and no matter what frontend you throw at it, it won't make it into that category either. If you want to argue for GDB, please explain how to get the equivalent of tracepoints with GDB (local debugging target, immediate feedback, all that useful stuff). – IInspectable Oct 26 '21 at 14:02
  • @IInspectable You mean something like [this one](https://www.sourceware.org/gdb/onlinedocs/gdb/Dynamic-Printf.html)? – Aconcagua Oct 26 '21 at 14:24
  • @aco That's my point, exactly. It's just useless. A heavy-handed approach to get something akin to what **any** Windows debugger has, but then being confined by what GDB *can* do (not a whole lot). So, say, now you want to output the caller of your function. What are you going to do? Anything as simple as just using the symbol `$CALLER`? – IInspectable Oct 26 '21 at 16:12
  • @IInspectable Well, I've seen people working with GDB in console mode as safely as sleepwalking – but that's none of mine either, I've always been appreciating those GUI frontends. For me it's mainly *their* quality that mostly influences how useful GDB really is (how well they hide GDB's complicated interface away...). For getting the caller inspecting the stacktrace (clearly presented in GUI) has always been fine when in breakpoint. `$CALLER` might be fine for live-printing, though. – Aconcagua Oct 26 '21 at 16:58
  • Not sure what GDB's equivalent for is (if there is at all), step by step debugging has been of greater importance for me so far (and memory breakpoints!)... So far I could live with GDB + GUI pretty well, even though maybe inferior to your windows debuggers (hopefully you didn't speak of Visual Studio, though, which appeared to me the worst IDE I've met so far...). – Aconcagua Oct 26 '21 at 16:59
  • @Jabberwocky Yes, I agreed with you, by using the `TRACE` macro is much straight forward. Thanks for the info! – Joshua_0101 Oct 28 '21 at 16:13
  • 1
    Also, `::OutputDebugString`. – Andrew Truckle Oct 28 '21 at 21:05

0 Answers0