Окно просмотра Visual Studio 2013 C ++: массивы некорректно копируются в буфер обмена
Я сейчас поднял этот вопрос непосредственно с Microsoft Вот, Вот а также Вот. Очевидно, проблема все еще возникает в текущем RC для VS2015 (см. Вторую ссылку выше).
В Visual Studio 2013 можно просматривать несколько элементов массива C с помощью таких часов, как p, 10000 (где p, например, double *).
В приведенном ниже примере я показываю скриншот части такого массива, который виден в окне просмотра, и ту же часть массива, что и CTRL-C, скопированные и CTRL-V, вставленные в текстовый редактор. Обратите внимание, что начиная с элемента 25 значения копирования / вставки не соответствуют значениям в окне просмотра (которые являются правильными).
[20] 1.0945579725021715 double
[21] 0.99979213435791758 double
[22] 1.0971002689671798 double
[23] 0.99977802981060826 double
[24] 1.1002739126009620 double
[25] 0.99964664435140704 double
[26] 1.1054689877466559 double
[27] 0.99963245464284955 double
[28] 1.1002149405804762 double
[29] 0.99961125488418856 double
[30] 1.0956742333763470 double
До сих пор в моих экспериментах я склонен видеть первые несколько значений, а последние несколько значений копируются правильно, оставляя средний раздел массива, что неверно. Это не всегда идет не так, как надо. Часто это работает для первого проверенного массива, но не работает для последующих. Также, когда это идет не так, кажется, что копирование / вставка значений во второй раз иногда приводит к правильному результату. Похоже, что неправильные числа, как правило, являются предыдущими значениями некоторых элементов массива — то, что копируется в буфер обмена, представляет собой смесь текущего и предыдущего содержимого массива. Массивы, с которыми я вижу это, имеют длину более 2000 элементов.
Это наводит на мысль о неверно недействительной (то есть иногда только частично обновленной) копии данных, используемой в реализации копирования в буфер обмена в Visual Studio. Мои эксперименты убедительно показывают, что элементы в копии данных, представленных в буфер обмена, обновляются тогда и только тогда, когда эти элементы (или достаточно «соседние» элементы — кажется, может быть задействован «размер блока подкачки»), были показаны на экране. , В частности, прокрутка массива страница за раз, кажется, заставляет копирование работать правильно, в то время как пролистывание от вершины массива до его основания, используя клавиши HOME и END, не приводит к обновлению средней части массива в копия, которая затем отображается в буфере обмена.
Действительно, если установить несколько часов в одном массиве, можно получить несколько ответов, например, это данные, скопированные в буфер обмена после трехкратного попадания в одну и ту же точку останова. При первом достижении точки останова я копирую все данные, и все они правильно копируются в буфер обмена. Второй раз пятнистый. Важно отметить, что затем я прокрутил окно просмотра примерно на 25%, и этого было достаточно, чтобы вставить желтые данные в то, что попадает в буфер обмена. Затем я вернулся к началу окна наблюдения и продолжал выполнение, пока в третий раз не будет достигнута точка останова. Затем я выбрал все данные в окне просмотра и скопировал их, используя CTRL-A CTRL-C. В результате данные в розовом цвете получены с первого раза, когда была достигнута точка останова. Данные желтого цвета взяты со второго раза, и невыделенные данные на самом деле верны. Обратите внимание, что элементы 0 и 1 розовых данных даже не совпадают со сводкой массива чуть выше них! Для краткости я опустил элементы 2-497 и 503-997.
Используя различные версии VC ++ начиная с 6 лет, я ранее не видел такого поведения и не сразу смог найти ссылку на него в Интернете.
Если кто-то полагается на эту функциональность при отладке чего-то сложного, можно почесать голову, размышляя о странных числах целую вечность, прежде чем понять, что его вводят в заблуждение.
Я использую Microsoft Visual Studio Professional 2013, версия 12.0.31101.00, обновление 4.
Кто-нибудь еще видел это, и кто-нибудь знает больше об этом или знает, как исправить или обойти это?
Решение
Различные коллеги также видят это. По-видимому, это влияет и на выпуски Visual Studio 2015.
На момент написания статьи Microsoft, очевидно, приняла отчет об ошибке и повторила проблему, но еще не указала расписание или план исправления.
Обходной путь — прокрутить все данные в окне просмотра, которые вы хотите скопировать, прежде чем копировать их. По-видимому, то, что показано, обновляется, но то, что не было показано, не обязательно является актуальным в момент, когда копируются данные.
Обновление (февраль 2018 г.)
Простое повторение, приведенное ниже, теперь корректно работает в Visual Studio 2017. Таким образом, похоже, что ошибка исправлена, хотя этап копирования занимает годы и появляется всплывающее окно, в то время как в буфере обмена создается 10000 строк текста. это было много быстрее (и работал правильно) до и после Visual Studio 2010.
Смотреть на a и расширить его. Ctrl-A, Ctrl-C означает выделять и копировать все в окне просмотра.
int a[10000];
for (int i=0; i<10000; ++i)
a[i] = i;
(void)a[0]; // breakpoint here, Ctrl-A, Ctrl-C, paste somewhere
for (int i=0; i<10000; ++i)
a[i] += 100;
(void)a[0]; // breakpoint here, Ctrl-A, Ctrl-C, paste somewhere
Visual Studio 2013 и 2015 даст вам что-то вроде этого
- a 0x00ef5af4 {100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, ...} int[10000]
[0] 100 int
[1] 101 int
[2] 102 int
[3] 103 int
[4] 104 int
[5] 105 int
[6] 106 int
[7] 107 int
[8] 108 int
[9] 109 int
[10] 110 int
[11] 11 int // Oops. The line it goes wrong on depends
[12] 12 int // on the number of visible lines in the
[13] 13 int // watch window.
...
Другие решения