Рассмотрите возможность установки точки останова в следующей строке и перехода к ней с помощью отладчика Visual Studio (в полностью очищенной и перестроенной отладочной сборке):
Poco::URI testUri( "http://somewhere.com/test/path" );
Оказывается, этот шаг приведет вас к этой функции:
URI::URI(const char* uri):
_port(0)
{
parse(std::string(uri));
}
И оказывается, что когда вы сделаете еще несколько шагов и сделаете паузу на последней строке после вызова parse(), все будет хорошо во вновь созданном объекте URI, а именно:
- он был проанализирован правильно;
- можно развернуть указатель
this, чтобы увидеть правильно назначенные переменные-члены (например, для членов its_host, _path и _scheme установлены значения «somewhere.com», «/test/path» и «http» соответственно); - указатель
thisна этом этапе указывает на законное место в памяти (например, 0x002AEE20), и в этом месте можно увидеть то, что, как я уверен, является объектом URI (наборstd::stringпеременных и однаint, как это происходит).
Однако, сделав еще один шаг, вы вернетесь к исходной строке кода, и вдруг:
- расширение объекта
testUriв окнах отладчика "Autos" или "Watch" приводит кstd::stringчленам, которые не могут быть прочитаны (имеются "ошибки чтения символов строки"), и все же... - память, в которой находится сконструированный объект, остается неизменной, и...
- подтверждается, что адрес
testUriуказывает на неизмененную память
Как это может быть? Отладчик VS не работает? Что сломало его?
Это последняя из серии странных проблем, связанных с попыткой запустить библиотеки POCO в многопоточном проекте MFC. Я понятия не имею, должны ли MFC или многопоточность оказывать какое-либо влияние на Poco, но я пережил неделю странностей - часто с задействованными std::string объектами - и я хотел бы добраться до сути. Все предложения по отслеживанию происходящего приветствуются. Я запускаю сообщество VS2015, если это имеет значение.
