[програмирование][учить]C++ + Qt.

> «ленивость» - это необходимо, но не достаточно и «ленивость» «ленивости» - рознь, это тоже важно помнить,да %)

не спорю

Вы прям идеалов каких то рисуете, я таких не видел :)

но кто-то ж пишет качественный код и библиотеки :)

> Для большинства софта обычно подходит С. С++

я тоже так думаю, но для их грамотного использования нужен чуть более высокий уровень - чем «выучить Qt», и это тоже критерий для выбора языка

> Я имел в виду, что если он хочет учить ООП, пусть не учит процедурный подход. Наоборот сложнее

нужно учить от простого к сложному, а не наоборот, за видимой простой ООП скрываются многие грабли и ньюансы

>в чем тут усложнение? прочитать короткий список «несовместимостей» при переходе к С++?

Усложнение в том, что для нормального программирования на сях надо приучиться ко многим правилам. Возвращаемые значения проверять, ресурсы освобождать и т.д. А при переходе к плюсам это всё можно выкинуть.

> Возвращаемые значения проверять, ресурсы освобождать и т.д. А при переходе к плюсам это всё можно выкинуть.

вы так говорите, будто ни разу не пользовались библиотеками на С

>ресурсы освобождать

С каких пор в плюсах появился сборщик мусора?

> С каких пор в плюсах появился сборщик мусора?

в VC есть как расширение к С++, но конечно в самом С++ нет

Не ухватил поинт.

RAII/деструкторы же.

> за видимой простой ООП скрываются многие грабли и ньюансы

что собственно и есть мышление и видение задачи в объектно-ориентированном подходе.

не забываем, что есть Си с классами (что не есть С++ на самом деле).

и против начала с Си, чтобы потом перейти на С++ лично я по собственному опыты: до сих пор printf пишу быстрее, чем cout<<

> Не ухватил поинт

если вы используете библиотеку на С - то должны «возвращаемые значения проверять, ресурсы освобождать и т.д.»

Такая возня с необёрнутыми сишными либами в любом языке. И на плюсах си обёртывать безболезненнее и проще всего.

> и против начала с Си, чтобы потом перейти на С++ лично я по собственному опыты: до сих пор printf пишу быстрее, чем cout<<

iostream вообще неудобен и сделан судя по всему просто, чтоб было

> Такая возня с необёрнутыми сишными либами в любом языке

и в чем тогда проблема научится этой «возне», если она все-равно надо?

Один раз обернул и пользуйся не напрягаясь.

> Один раз обернул и пользуйся не напрягаясь.

вы так говорите, будто обертки к большим библиотекам пишутся за 5 минут

> нужно учить от простого к сложному, а не наоборот

Вот именно. ООп проще процедруного

> Вот именно. ООп проще процедруного

а чего тогда не процитировал полностью и не сказал, что это неправда - ООП на самом деле очень простое, без подводных камней и проектировать не надо уметь совсем? ;)

> Вы прям идеалов каких то рисуете, я таких не видел :)

но кто-то ж пишет качественный код и библиотеки :)

пишет кто-то, да, но напомню суть

а хороший программист - это [..] программист, который сразу пишет так, чтоб было просто, быстро, расширяемо и удобно

пишет то пишет, да только не *СРАЗУ*

как правило это уже версия N, а по Вашим словам и альфы хватает :)

>вы так говорите, будто обертки к большим библиотекам пишутся за 5 минут

К большим они часто уже написаны. И если библиотека спроектирована, а не выросла, то да, быстро пишутся.

> как правило это уже версия N, а по Вашим словам и альфы хватает :)

грамотное проектирование - половина дела, да, но вторую половину никто не отменял

> К большим они часто уже написаны

к freetype, например, уже есть?

Развеж это большая? :)

> И если библиотека спроектирована, а не выросла, то да, быстро пишутся.

к cairo, например, обертка совсем немаленькая - сомневаюсь, что вы ее быстро бы написали, и да - почему для вас написание обертки не требует понимания, как в С обычно работают с ресурсами?

> Развеж это большая? :)

для вас 4.5Мб только исходных файлов( .h/.c ) это мало? да вы гигант - наверное пишете 100Мб-е библиотеки?

>да - почему для вас написание обертки не требует понимания, как в С обычно работают с ресурсами?

Разумеется требует. Просто когда пишешь обёртку к либе X - и думаешь о заморочках либы X. А когда пишешь программу Y - о заморочках X думать не хочется.

для вас 4.5Мб только исходных файлов( .h/.c ) это мало?

Какая разница, сколько исходных файлов? Важен лишь размер заголовков в -devel-пакете. И с фритайпом я не работал, чтоб не было недоразумений.

Вот именно. ООп проще процедруного

http://www.linux.org.ru/forum/talks/4903731

ну объясни же нам, что в этом простом случае происходит, и почему оно происходит именно так?

>любая валидная программа на C является валидной программой на C++

так не любая же

>угу - вот только С++, как я уже писал, по сути ассемблер

слишком толсто

про мануал я конечно выдумал)

> Важен лишь размер заголовков в -devel-пакете.

2.25Мб - мало?

И с фритайпом я не работал, чтоб не было недоразумений.

с этого надо было начинать, точнее вообще не надо было начинать

> слишком толсто

да ладно

>вы так говорите, будто обертки к большим библиотекам пишутся за 5 минут

конечно не за 5, но если API стабилен (для серьезной бибилотеки это обязательное условие, +ABI в придачу), то в обертке менять ничего не надо

> 2.25Мб - мало?

ошибся - их «всего» 1.4Мб, посчитал и .h в ./src

C - да, С с крестами - нет :)

> но если API стабилен (для серьезной бибилотеки это обязательное условие, +ABI в придачу), то в обертке менять ничего не надо

почему глупые тролли, которые пишут Qt, так не делают?

разве в ассемблере есть какой-то намек на классы, полиморфизм, шаблоны, готовые к употреблению связанные списки и прочий STL, ...

>почему глупые тролли, которые пишут Qt, так не делают?

потому, что они писали не обертку для STL, а альтернативную реализацию с б. и ш.

> C - да, С с крестами - нет :)

распространенное заблуждение, что С++ это совсем не С, почитайте Страуструпа - он явно говорит, что С++ призван быть расширением к С и быть с ним максимально совместимым( в том числе за счет изменений в С )

конечно, сейчас в свете с++0х и прочих бустов многие вещи кажутся костылями, но корни этого сидят в середине 90-х, когда даже не все компиляторы поддерживали RTTI...

> разве в ассемблере есть какой-то намек на классы, полиморфизм, шаблоны, готовые к употреблению связанные списки и прочий STL, ...

C99 тоже не представляет из себя набор команд в стиле «классического» ассемблера

совместимым, но не ограниченным возможностями С

а в С++ тоже можно асм втыкать, как и в С, низкоуровневая работа не возбраняется

> потому, что они писали не обертку для STL, а альтернативную реализацию с б. и ш.

я про png, zlib, freetype и т.п.

тогда зачем их сравнивать? у асма свой уровень,у си - свой, у крестов - свой

я не изучал этот код, поэтому не могу ничего сказать

>что С++ призван быть расширением к С и быть с ним максимально совместимым( в том числе за счет изменений в С )

Совместимым чтобы работали старые программы, а не писать новые.

> Совместимым чтобы работали старые программы, а не писать новые.

нет - для возможности написания эффективного и гибкого кода

> тогда зачем их сравнивать? у асма свой уровень,у си - свой, у крестов - свой

я их не сравниваю - я указываю, что эти языки так или иначе привязаны к «железу» сами по себе, в отличие от других

>эти языки так или иначе привязаны к «железу»

и чем же С++ (без ассемблерных вставок) привязан к железу? перекомпиль и радуйся

распространенное заблуждение, что С++ это совсем не С,

я так не считаю

он явно говорит, что С++ призван быть расширением к С и быть с ним максимально совместимым

я хотел сказать, что не видел чтобы в сис. программирование использовали С++