4 ms·

Yeah this is clearly a problem with gdb, not std::vector. Really gdb is pretty rubbish and hasn't been improved for many years. LLDB should be much better.

marcosdumay 13y ago
That's a "problem" with the compiler, not gdb. Also, the "problem" is that the compiler actually optimized the code, when ordered to do so, instead of just pretending it did (like MS tools do when debuging). It's also a very usefull "problem" to have around. I really doubt LLDB can discover what code operators execute if the compiler does not include it at the binary.
- comex 13y ago
  Probably the compiler should both inline it and include a standalone version when debugging is enabled.
  - hdevalence 13y ago
    No, because you need to debug the code you're actually running, not some other code that's easier to debug.
    - comex 13y ago
      I believe we're talking about a function such as std::vector::operator[]. You wouldn't usually be debugging a particular attempt to access an element of a vector, you'd have a vector and want to easily see what's in it, using a debugger-constructed call to the function.
- krakensden 13y ago
  When debugging optimized C++ in Visual Studio you'll run into the same problem. The 'see ASM' feature is easy enough to use that it helps, but, there's no free lunch.
fafner 13y ago
Bullshit. GDB is improving constantly. Last time I checked LLDB was inferior. So stop spreading lies!
- comex 13y ago
  I downvoted you because of the tone of your post, but I do tend to agree with you - almost everything about LLDB strikes me as pretty crappy, although unfortunately the same applies to GDB. In this case, LLDB is no better: (lldb) print v[0] error: call to a function 'std::__1::vector<int, std::__1::allocator<int> >::operator[](unsigned long)' ('_ZNSt3__16vectorIiNS_9allocatorIiEEEixEm') that is not present in the target error: The expression could not be prepared to run in the target (lldb) version lldb-300.2.53
alextingle 13y ago
> gdb is pretty rubbish and hasn't been improved for many years That's such a dirty lie. Example: GDB has reverse step. That's such a amazing debugging feature that VisualStudio users often refuse to believe that it's real, when you try to describe it to them.

marcosdumay 13y ago

That's a "problem" with the compiler, not gdb. Also, the "problem" is that the compiler actually optimized the code, when ordered to do so, instead of just pretending it did (like MS tools do when debuging). It's also a very usefull "problem" to have around. I really doubt LLDB can discover what code operators execute if the compiler does not include it at the binary.

comex 13y ago
Probably the compiler should both inline it and include a standalone version when debugging is enabled.
- hdevalence 13y ago
  No, because you need to debug the code you're actually running, not some other code that's easier to debug.
  - comex 13y ago
    I believe we're talking about a function such as std::vector::operator[]. You wouldn't usually be debugging a particular attempt to access an element of a vector, you'd have a vector and want to easily see what's in it, using a debugger-constructed call to the function.
krakensden 13y ago
When debugging optimized C++ in Visual Studio you'll run into the same problem. The 'see ASM' feature is easy enough to use that it helps, but, there's no free lunch.

fafner 13y ago

Bullshit. GDB is improving constantly. Last time I checked LLDB was inferior. So stop spreading lies!

comex 13y ago
I downvoted you because of the tone of your post, but I do tend to agree with you - almost everything about LLDB strikes me as pretty crappy, although unfortunately the same applies to GDB. In this case, LLDB is no better: (lldb) print v[0] error: call to a function 'std::__1::vector<int, std::__1::allocator<int> >::operator[](unsigned long)' ('_ZNSt3__16vectorIiNS_9allocatorIiEEEixEm') that is not present in the target error: The expression could not be prepared to run in the target (lldb) version lldb-300.2.53

alextingle 13y ago

> gdb is pretty rubbish and hasn't been improved for many years That's such a dirty lie. Example: GDB has reverse step. That's such a amazing debugging feature that VisualStudio users often refuse to believe that it's real, when you try to describe it to them.