0xd34df00d
15.02.2013 13:42 Azoth_primary
Только начал дергать сишный код, а уже хочется блевать:
/home/d34df00d/Programming/leechcraft/src/plugins/azoth/plugins/velvetbird/proto manager.cpp:42:36: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
Recommended by:
@lHooFool: ШОК! Velvet-Bird РАЗРАБАТЫВАЕТ LEECHCRAFT!
69 comments
recommend
bookmark
subscribe
Ты тупой чтоле?
Что?
Кто же так делает?
Как?
>velvetbird
НАССАЛ В РОТЕШНИК ЭТОМУ ПЛАГИНУ!!!!
Нян :3
Так, что конпелятор ворнингами блюет.
Научи делать не так.
криворукий мудак
Расскажи, как надо.
а в жс таких ошибок нету
Ну, показывай свой говнокот
чо за плагин
нет, мой код под ндс!
все как ты, только наооборот, тогда все будет ок.
кстати, твоя анальная банилка меня забанит?
меня банит
Скопипизжено из финча.
g_hash_table_insert (uiInfo, "name", "LeechCraft Azoth");
Вельветберд.
чо делает
Ок.
Ссыт тебе в ротешник.
Че.
норм плагин
Нассал на тебя, извини, я не хотел.
Ну, блять, загони в буфер-то, мудило!
недоязыкопроблемы
А что с ним потом делать?
говна въеби
Потом передавай куда хочешь
А удалить как и когда?
Зачем удалять? Если у тебя там вызовов таких много, то пусть остается как временное вместилище для такой еботы
Какое временное, блядь, вместилище? Под каждую новую строку нужен новый буфер.
dive into python
^^^ палю, там таких проблем нет
Добра поешь, няша.
Блять, ну сделай char** что ты как ребенок
Блядь што. Подумай уже, наконец.
По-моему это тебе пора. Вместо того, чтобы взять и сделать как надо тратишь время на пстачик
Подумай о том, как и что и где хранится, и кто это будет удалять.
Зачем ты собрался что-то удалять? Мне это не понятно. Однажды выделил память под буффер и используй повторно если потребуется снова вызов делать.
Ничего, что хэшмапа опирается на то, что содержимое по переданному ей указателю будет доступно всегда?
Я не в курсе специфики. Учти её и сделай как надо.
Вот это я понимаю, костыли. Спасибо.
Есть еще способ, но он страшнее:)
Лучше все-таки передавать ownership чему нужно.
http://en.cppreference.com/w/cpp/string/... А так пробовал?
И накапливать везде строки.
Зато не костыли же
Эм, зачем? strdup возвращает строку, которую free вполне себе сожрет.
А почему, кстати, накапливаться станут? Temporary bound же
Блеа, ну ты хуйню уже несешь совсем.
Если в вызове создать std::string и взять от него data () разве оно не схлопнется потом?
http://liveworkspace.org/code/4maXlj$1
Оно счастливо деаллоцируется в деструкторе стрингов.
Вопрос на засыпку: когда вызовется деструктор этой строки?
Само собой. Вынеси конструирование в удобное место, тогда все будет хорошо
Стандарт говорит, что lifetime такого объекта простирается до конца инструкции
Ну, конструирование можно делать где угодно, но придется следить, да. Тут согласен
Может API сишное шатает?
Умничка.
Да.
Либпурпле такое сишное.
Пока нет. А тамошние врапперы могут мне посоздавать все что нужно, а потом вернуть сишный объект, который я уже скормплю перплу?
Ну и ладно. Опыт показывает, что все эти g-плюсовые обертки — днище. Я уже qt-gstreamer как-то дергал — ппц оно днище.
какой нахуй буфер, тупица
там const в сишном прототипе не хватает
ох ебать
libgobject полущ
не я // не представляю