А текущем проекте возникла необходимость работать с MySQL базой данных из C++. Кроме базового API на «чистом»  C, разработчики MySQL (кому она там сейчас принадлежит?) предоставляют надстройки для различных языков программирования, называя их connector'ами. В их числе имеется и красивая высокоуровневая обвязка для C++. Хорошая альтернатива слабо предназначенному для непосредственного использования libmysqlclient, казалось бы.

Вскоре начались проблемы. Случайные вылеты, причинами которых были баги самого мерзкого характера: какая-то дрянь портила чужие области памяти. Потратив предварительно несколько часов, я так и не сумел сходу решить проблему. Уже тогда я подошёл вплотную к MySQL коннектору, но решил что столь явной проблемы (на максимально простом тест-кейсе) в официальной библиотеке быть просто не может, а значит проблема где-то раньше в моём коде. Потому решено было временно отложить решение (вылеты были регулярными, но не столь частыми) и сначала дописать функционал до определённого уровня, что и было проделано.

Пришло время второго захода. В ход пошли хитроизощрённые отладочные техники с hardware watchpoint'ами и утилитами для отслеживания выделения памяти. Снова несколько часов и снова вижу проблему в connector'е. Тут-то я наконец сосредоточенно погуглил и нагуглил письмо в mailing list MySQL, где описывалась похожая проблема. Автор письма потрудился залезть в исходники коннектора (что я уже было собирался делать) и обнаружил там серьёзные проблемы. Кому интересно, подробно могут почитать по ссылке, но суть в том, что там просто элементарная ошибка (и не одна) с освобождением памяти, которая приводит к самым неприятным последствиям.

В итоге, код работы с базой (благо, ещё не разросшийся) был переориентирован на использование сишной libmysqlclient и счастье наступило.

Мораль:

1. Не используйте MySQL C++ Connector. Это какой-то вообще слабо поддерживаемый проект. Мало ли что там ещё за проблемы найдутся.
2. Нельзя доверять третьесторонним библиотекам даже если они часть хорошо зарекомендовавших себя продуктов. Если бы не моё слепое доверие, времени на починку было бы потрачено в разы меньше.

Microsoft Visual Studio я считаю лучшей из доступных IDE для разработки C++, которой в основном и занимаюсь. И это при том, что я являюсь идеологическим противником корпорации из Редмонда. Просто IDE для Линукса слабы. Вообще все решения в этой области, основанные на GCC провальны из-за дебаггера. Не знаю, то ли GDB настолько плох, то ли никто не в состоянии нормально встроить его в IDE, то ли он просто идеологически для этого не предназначен. Eclipse c CDT монструозен и тормознут. Vi или emacs с командной строкой и make, которое сразу же посоветует какой-нибудь Линукс-джедай, я лично осилить до того уровня производительности, что имею в MSVS, не в состоянии (а в состоянии ли вообще кто-то?). Впрочем, справедливости ради отмечу, что не сильно-то я и старался.

Альтернативные среды вроде Code::Blocks и Dev-Cpp, когда я последний раз смотрел, были в очень зачаточном состоянии. Вот сегодня скачал первую, собираюсь пересмотреть ещё раз — вдруг что-то изменилось. Но всё это тема для отдельного долгого разговора, перерастающего в холивар. А этот пост именно о Visual C++ и одной её полезной и практически не документированной фиче, на которую я недавно набрёл. Это — кастом визуализаторы (custom visualizers) для переменных — то, что разработчик видит в панельке Watch во время отладки программы. Вещь очень удобная и сильно облегчающая жизнь, если вы, например, как и я, любите писать «велосипеды» в виде собственных библиотек, или вообще часто используете какую-нибудь стабильную библиотеку/фреймворк/движок со своими, сложными для быстрого понимания as is в отладчике, типами данных.

дальше