Подножка для AI в виде UTF-8

[@goldexer]

...показываешь ему проблемное место со своими объяснениями. Да, говорит, ты прав, «вот исправленный код», а там пошли костыли вокруг этого места, с дополнительным выделением памяти, копированиями, подсчётом адресов и пр.

Но когда он в VB.NET пытается сишные указатели объявить и разыменовать, я понимаю, что пока ещё рано...

[@SeyKo4]

Народ (приятель) пришёл к выводу, что Claude лучше GigaChat, DeepSeek и ChatGPT (уж не знаю какой). Типа не врёт напропалую как ChatGpt

[@aamonster]

Я пока сравнивал только Copilot с DeepSeek, разница кардинальная в пользу Copilot (меньше галлюцинаций, DeepSeek любит использовать выдуманные API). Хотя доверять нельзя никому.

Но результат таких сравнений может внезапно устаревать – все вендоры периодически меняют модели.

[@xtraroman]

У нас в проекте есть проверка кодировки исходников. Она написала в виде analyzer'a . Если у исходного файла кодировка не utf8 bom, генертся ошибка. Сделали это потому что народ любит писать комментарии в коде на русском, а дефолтная кодировка нас не устраивала.

Так вот, когда мы пробовали вайбкрдинг, почти всегда ИИ ломал кодировку наших исходных файлов. Так что там много всяких подножек )

[@ALexKud]

Deеpseek. Дал ему неработающий код запроса sqlite с оператором on conflict. Спрашиваю почему не работает запрос. Выдает стандартный ответ, где указывает наличие уникального индекса и с ним запрос должен работать. Пишу что индекс есть, но запрос не работает. ИИ зацикливается, повторяя одно и тоже, что запрос должен работать. Иду на stackoverflow и быстро нахожу ответ, должна быть обязательно в запросе секция where в связи с тем что парсинг запроса с on conflict в sqlite содержит ошибку при отсутствии where. Но у меня нет where секции, oна не нужна. Добавляю в запрос where true и наконец все заработало. Другие ИИ не проверял, но зацикливание Deepseek на таком простом случае показательно. Всё-таки Stackoverflow eще нужен.

[@domix32]

За способости GigaChat не скажу, но мне DeepSeek больше всего ломал малину, когда использовал API из разных стандартов, несмотря на ограничения. Да ещё и давал доп.примеры формата "а вот если бы был стандарт поновеее, то". Либо вообще выдумал то-чего-на-свете-нету. Особенно с std::range проблемы. Иногда велосипедил какие-нибудь встроенные функции. Но так чтобы висячих указателей наоставлять пока не сталкивался.

[@Jijiki]

а почему std::vector<char> или std::string, проще есть std::u32string(платим памятью зато не надо постоянно перегонять биты туда сюда как я понимаю) тут задача сводится к хранению номера глифа и врапается в текстуру, происходит только 1 раз при чтении ttf файла таблицы, тут же можно добавить ttf файлы с нужными поддержками, чтобы совмещать поддержку глифов

[@Andrey2008]

[@sergio_nsk]

Потому что std::u32string до сих пор малополезный тип, как контейнер - ок, для работы со строками - беда. Потому что стандарт требует std::char_traits только для char и wchar_t, и у многих компиляторов нет специализаций для charN_t.