Почему LLDB в C++ может распечатать всю мою структуру данных, но не может распечатать подкомпоненты? ⇐ C++

[Anonymous]

Я использую Mac OS Sonoma 14.5 с LLDB 1500.0.404.7, установленной с помощью инструментов x-code. Я заметил, что моя LLDB ведет себя довольно запутанно. Он может распечатать некоторые std:containers целиком, но не может распечатать подкомпоненты тех же самых контейнеров. В частности, я могу выполнить следующую команду p Primary_map

Код: Выделить всё

(lldb) p primary_map
(std::unordered_map) size=2 {
[0] = {
first = 1
second = size=2 {
[0] = 5
[1] = 4
}
}
[1] = {
first = 0
second = size=2 {
[0] = 2
[1] = 1
}
}
}

И очевидно, что LLDB может показать мне всю карту. Однако по какой-то причине, если я выполню p Primary_map[0]

Код: Выделить всё

(lldb) p primary_map[0]
error: Couldn't lookup symbols:
__ZNSt3__113unordered_mapIiNS_13unordered_setIiNS_4hashIiEENS_8equal_toIiEENS_9allocatorIiEEEES3_S5_NS6_INS_4pairIKiS8_EEEEEixEOi

LLDB не может визуализировать подкомпонент структуры данных.
Вопрос:
Я хочу знать, почему это происходит, как предотвратить это в будущем, и если это невозможно предотвратить, какой лучший обходной путь.
Контекст:< /h2>
У меня есть образец кода. По сути, он создает карту целых чисел в наборы целых чисел путем чтения содержимого файла. В частности, количество строк в файле и количество целых чисел в строке НЕ известны во время компиляции и обнаруживаются только во время выполнения при чтении самого файла (почему-то я думаю, что это важно).
working_driver.cpp

Код: Выделить всё

#include 
#include 
#include 
#include 
#include 

using namespace std;

unordered_map primary_map;

int main() {
ifstream input("sample_data_working.txt");
int row_count; int col_count; int holder;
input >> row_count; input >> col_count;

for (int i =0; i < row_count; i++) {
primary_map[i] = unordered_set{};
for (int j = 0; j < col_count; j++) {
input >> holder;
primary_map[i].insert(holder);
}
}
return 0;
}

Файл приведен ниже, его заголовок представляет собой пару чисел (количество строк, количество столбцов), а затем строки, содержащие числа.
< strong>sample_data_working.txt

Код: Выделить всё

2 2
1 2
4 5

Воспроизведение проблемы:
Я компилирую свой код с помощью следующей команды: g++ -std=c++14 -g -O0 -fstandalone- debugwork_driver.cpp -owork_driver, который фактически вызывает clang (потому что Mac OS), версия указывается как: Apple clang version 15.0.0 (clang-1500.3.9.4).
Затем я запускаю lldbworking_driver, чтобы запустить экземпляр LLDB. Отсюда я устанавливаю точку останова в своем операторе возврата через b 23, а затем выполняю команду r, которая переходит вперед и приводит меня к моей точке останова. В терминале это должно выглядеть примерно так:

Код: Выделить всё

➜  differentiation git:(main) ✗ lldb working_driver
(lldb) target create "working_driver"
Current executable set to '/Users/sidharthghoshal/cp_training/USACO/python3/chapter4/2/stall4/differentiation/working_driver' (x86_64).
(lldb) b 23
Breakpoint 1: where = working_driver`main + 465 at working_driver.cpp:23:5, address = 0x0000000100000b91
(lldb) r
Process 3140 launched: '/Users/sidharthghoshal/cp_training/USACO/python3/chapter4/2/stall4/differentiation/working_driver' (x86_64)
Process 3140 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000100000b91 working_driver`main at working_driver.cpp:23:5
20               primary_map[i].insert(holder);
21           }
22       }
-> 23       return 0;
24   }
Target 0: (working_driver) stopped.

Именно в этот момент наступает хаос. p Primary_map работает точно так, как ожидалось в начале этого вопроса, а p Primary_map[0] — нет.
Мои идеи о природе проблемы:< /h2>

• Я видел, как команда p Primary_map[0] работала с одной и той же структурой unordered_map/ code> в прошлом, но формировался немного иначе (а именно, жестко закодированные верхние границы row_count, col_count в цикле). Таким образом, сообщения stackoverflow, в которых говорится, что Primary_map[0] не совсем определен, не совсем удовлетворительны, потому что эта команда ДЕЙСТВИТЕЛЬНО иногда работает, но не в этом экземпляре. Каким-то образом «границы цикла, обнаруженные во время выполнения», кажутся здесь сбивающей с толку проблемой.
• Обычно обсуждаемым решением является написание либо собственного распределителя или собственный парсер, я не понимаю, зачем мне это делать? Очевидно, что в некоторых случаях достаточно встроенного анализатора unordered_map, который имеется в LLDB. Только не в этом случае. Я хотел бы знать почему. Тогда я был бы глубоко признателен за как.

Некоторые дальнейшие исследования:
Ответ с самым высоким рейтингом многое проясняет. В частности, фрейм var Primary_map[0] ведет себя так, как ожидалось. Кажется, что LLDB каким-то образом умна, чтобы знать, как печатать фрейм var для некоторых моих кодов, но в других случаях она недостаточно умна, чтобы фрейм var и затем просто выдает ошибка нечетного символа. Мне неясно, какое отношение границы цикла, определенные во время выполнения, имеют к переключению с фрейма var на expr, но теперь связь становится немного яснее.

Подробнее здесь: https://stackoverflow.com/questions/791 ... e-to-print