с или с++ ваше мнение, какой лучше?

[NickLion]

то есть мне например не ясно, в чистом си если подключить библиотеку пинговалки, то что именно это будет за библиотека и будут ли у нее забавные баги. В делфи, после ошибочного пинга надо ждать 3 секунды перед следующим ошибочным пингом (три секуды!!! - бесят такие тормоза), иначе вылетает ошибка.

Зависит от библиотеки. Я сказал о Qt, там уровень кода достаточно высок и проблем не будет.

yoshakar - то есть сейчас qt creator для с++ наилучший, равных ему нет?

Есть и другие, которые в других задачах моугт быть лучше, но Qt Creator прост, понятен и не требует очень много ресурсов. Плюс нативная поддержка Qt.

мне вот в силу моей некомпетености не совсем понятен такой вопрос. qt-5 ведь компилирует не совсем чистый с++, а с++ + свою библиотеку, верно?

Библиотека никак не влияет на чистоту языка. Просто в Qt используется сигнал-слотовая схема, которая в коде записывается упрощенно, а потом разворачивается в необходимую конструкцию.

Благодаря этому он более кроссплатформенен, но зато благодаря этому он не такой уж и быстрый код дает, файл ресурсов имеет большой и прочее, прочее.

Кросплатформенность, размер — это да. А скорость никаким боком не страдает.

Главное, что на нем ваще бесполезно писать именно на с, в том виде как я его понимаю (минимальный, максимально оптимизированный код, который можно вставить в любое место программы написанной на более высоком уровне в виде библиотеки, к примеру).

Спокойно можно, но зачем нужен будет Qt в изначально маленькой задаче, о которой Вы говорите?

Мало того, программирование на с++ в qt (я встречал такие мнения) - это мол почти делфи, только язык другой.

Не совсем, но GUI делать легко и можно мышкой сделать очень много без написания кода.

У C++, вестимо. Это вообще самый граблястый из известных мне языков. Настолько граблястый, что грабли в нём стреляют, и отстреливают ноги, причём сильно чаще, чем раз в год.

Некторые любят использовать на нём грабли, но сам язык вполне нормален. Особенно граблистость возникает, когда программисты гонятся за несуществующим выигрышем и начинают писать на C++ как на Си, при этом не зная нормально Си.

[Bizdelnick]

Qt, там уровень кода достаточно высок и проблем не будет.

Ой да ладно, хватает в нём багов. Не больше, чем в большинстве проектов такого размера, но и не меньше.

[NickLion]

Слова про несовместимость C++ и C — это, по большей части, просто слова. Формально, эта несовместимость есть (если почитать стандарты), но идейно C присутствует в C++ как подмножество.

Не совсем так, различий достаточно много, начиная от func(), sizeof('x'), имён структур и т.д. и заканчивая "новыми" вещами, вроде restrict. И далее, о писать в С++ как в Си, да, формально в С++ есть приведение типов (type), но лучше использовать *_cast<>(), а не Си стиль. Иногда такие несовместимости портят жизнь.

Ой да ладно, хватает в нём багов. Не больше, чем в большинстве проектов такого размера, но и не меньше.

Баги есть, конечно. Но:
1. Открытость и активность разработчиков приводит к тому, что найденные баги фиксятся достаточно быстро.
2. Качество кода Qt отмечают и разработчики статических анализаторов для C++.

[azsx]

NickLion вы за с++, верно?
зы

Кросплатформенность, размер — это да. А скорость никаким боком не страдает.

я встречал мнения, что страдает.

[NickLion]

azsx
Да, я за C++. (Но я не против Си).

Насчёт скорости. Один и тот же код C++, будет выполняться с одинаковой скоростью, не важно, будете Вы линковаться с Qt или нет. Наличие Qt не повлияет. Вон OpenCV содержит библиотеку для GUI, которая использует Qt, скорость их кода от этого не падает.

Те отзывы или были неправильно поняты, либо неправильно сформулированы. Механизм сигнал-слотов, конечно, будет медленнее непосредственного вызова функции (хотя использование C++11 и нового стиля связывания ускорит вызов), но он и не предполагается как замена всем вызовам. Плюс сигнал-слотовая схема позволяет вызывать функции в других потоках, что не получится в случае обычного вызова.

[watashiwa_daredeska]

Не совсем так, различий достаточно много, начиная от func(), sizeof('x'), имён структур и т.д.

Реально, это мелочи. На практике я никогда не встречал с этим проблем (ну вот кому, нафиг, нужен sizeof('x')? :) ). Если они и есть, то их количество исчезающе мало по сравнению с прочими граблями. Ну, разве что некоторое спотыкание об имена структур, но к этой штуке быстро привыкаешь.

и заканчивая "новыми" вещами, вроде restrict.

Эти штуки прошли уже мимо меня, сейчас я на C не пишу. Однако, я что-то не видел никаких «новых штук», которые бы существенно меняли идею — так, косметические правки языка. Ловится же большинство таких несовместимостей легко. restrict — просто не скомпилируется в C++, инициализация структур с именами полей тоже просто получит отлуп от компилятора. В отличие от sizeof('x'), которого можно долго ловить в отладке, большинство несовместимостей ловится на этапе компиляции и не вызывает вообще никаких проблем: через пару недель привыкнешь и перестанешь в C++ пользоваться чисто C'шными плюшками.

И далее, о писать в С++ как в Си, да, формально в С++ есть приведение типов (type), но лучше использовать *_cast<>(), а не Си стиль. Иногда такие несовместимости портят жизнь.

Ну, C-стиль в C++ это в основном не о приведении типов, а например, об использовании C-string вместо std::string где не надо.

[watashiwa_daredeska]

Особенно граблистость возникает, когда программисты гонятся за несуществующим выигрышем и начинают писать на C++ как на Си, при этом не зная нормально Си.

Да нет, в этом случае получаются простые и привычные, всем знакомые C'шные грабли. В C++ хватает своих новеньких сверкающих, начиная от виртуальных деструкторов с exception'ами и множественным наследованием и до overloading помноженного на template со специализацией. Я уж молчу про стандартную библиотеку с её vector<bool>, который не совсем vector :)

[Hephaestus]

Издеваетесь? C — очень простой язык. На него хватит пары недель. Месяц, если вместе со стандартной библиотекой.

Другое дело, что зная C, даже со стандартной библиотекой, почти ничего написать нельзя.

Эти две цитаты вступают в противоречие.
Язык простой, на освоение надо максимум месяц, но спустя этот месяц мы ничего сложнее HelloWorld не напишем.
Это называется простой?
Пары недель не хватит даже на то, чтобы вдумчиво прочитать K&R. А читать их нужно больше одного раза.
А если ещё разбирать задачи/упражнения, которые там есть, то нужно ещё больше времени. И это книга объемом порядка 200 страниц. Конечно, это можно пробежать галопом, не то, что за пару недель, а за пару дней. Но это не тот уровень усвоения, о котором я говорю.

А книга Праты имеет объем 900 страниц. Как это осилить за пару недель? Никак.
Много ли воды в этой книге? Сейчас вот читаю, воды практически нет, всё вроде по делу.

Когда я говорил про полгода-год, это значит, что спустя год мы можем спокойно решать поставленную задачу и кодить решение на Си. Спустя две недели-месяц мы этого явно не сможем, по Вашим же словам.

А теперь интересный вопрос: Человек потратил пару недель и освоил Си. Но кодить пока не может. Можно ли сказать, что он знает язык Си? Сказать-то можно, но что толку от этих знаний? Какого работодателя устроит такой уровень знаний?

Так там в списке имеющихся у читателя знаний присутствует Delphi. В Delphi есть указатели

Покажите мне живого дельфера, который всерьёз использует указатели. Я хочу на него посмотреть.
Указатели там есть, но для определенных задач (далеко не для всех) для работы со сплайнами, например.
Вот в литературе по Дельфи мне нигде не попадалось использование указателей, кроме как со сплайнами или чем-то подобным. И много ли народу среди дельферов вообще знает про эти указатели, и как их правильно использовать?

А вот в системном программировании без указателей никак. Что ни системная функция - то указатель в параметрах. Но вот незадача - Дельфи (ну или Object Pascal) в системном программировании не используется вообще совсем никак.

[NickLion]

Особенно граблистость возникает, когда программисты гонятся за несуществующим выигрышем и начинают писать на C++ как на Си, при этом не зная нормально Си.

Да нет, в этом случае получаются простые и привычные, всем знакомые C'шные грабли. В C++ хватает своих новеньких сверкающих, начиная от виртуальных деструкторов с exception'ами и множественным наследованием и до overloading помноженного на template со специализацией. Я уж молчу про стандартную библиотеку с её vector<bool>, который не совсем vector

Если писать исключительно в стиле Си, то да, но когда смешивается Си и C++, то возникают грабли.
Исключения в деструкторе — это зло, какого не должно быть и в C++11 по-умолчанию исключение в деструкторе приводит к std::terminate.

А чем множественное наследование не угодило не понимаю. Тем более overloading. В чём грабли-то? Специализация шаблонов тоже бывает необходима. Да, std::vector<bool> — это неудачный пример специализации шаблона, но оставили до сих пор. Печалька, да.

Но всё это не грабли, а скорее опасная бритва. Можно эффективно использовать, можно пораниться. Иначе вообще UB и sequenced можно отнести к граблям.

Язык простой, на освоение надо максимум месяц, но спустя этот месяц мы ничего сложнее HelloWorld не напишем.
Это называется простой?
… skipped …
А теперь интересный вопрос: Человек потратил пару недель и освоил Си. Но кодить пока не может. Можно ли сказать, что он знает язык Си? Сказать-то можно, но что толку от этих знаний? Какого работодателя устроит такой уровень знаний?

КМК имелось в виду, что язык человек может знать, но для практической работы, кроме знания языка и успешной реализации алгоритмов надо знать функции вроде тех же сокетов, которые непосредственно к Си не имеют отношения, но без их понимания работать с сетью не получится.

[azsx]

только тема совсем не о lazarus, который вам не понравился в универе. Я просто упомянул, что в активе я умею и пишу простые программы в делфи иногда. Вот давно не писал (так как предыдущими прогами сжег 2 винчестера), сейчас всё вспоминаю, понадобилось 2 проги написать.
зы
Очень верное высказывание встречал в познавательной статье. В нашей стране более половины специалистов получающих высокое образование проходят курс хотя бы одного ЯП. Это делфи, джава, с#, чистый с в особо упоротых случаях (в школах кумир, тот же делфи). По разным причинам (достаточно необычным в моей интерпретации) из тех, кто программировать не умел до универа, в универе также программистами не становятся. Иногда устраиваются после высокого образования на профильную специальность и получив опыт - бывает уходят в плюс. Иначе, всё впустую. Сходите в рф устройтесь реально программистом с нормальной оплатой...
оффтопик

Покажите мне живого дельфера, который всерьёз использует указатели. Я хочу на него посмотреть.

где то рядом, в этом топике... Проблема только в моем уме (он у меня есть и хороший, но мало). Например, так на память я могу только pchar вспомнить как я использовал. Но, обратите внимание, я очень часто (то есть много в штуках) пишу мелкие программы на пару запусков.

Указатели там есть, но для определенных задач (далеко не для всех) для работы со сплайнами, например.
Вот в литературе по Дельфи мне нигде не попадалось использование указателей, кроме как со сплайнами или чем-то подобным.

Бакнелл.Фундаментальные алгоритмы на Delphi, как пример.
ваще то используют для постоянных сортировок данных (массивов, списков) от 1 гб в оперативке, особенно динамически меняющихся в значениях. Очень хорошо юзают их в деревьях (получается и вбит дереве, когда в программе из массива делаете БД с няшкой индексации), но я не осилил, хотя надо. api с указателями.

[Bizdelnick]

прогами сжег 2 винчестера

Интересно. Расскажите, как можно программно спалить винчестер?

[Hephaestus]

КМК имелось в виду, что язык человек может знать, но для практической работы, кроме знания языка и успешной реализации алгоритмов надо знать функции вроде тех же сокетов, которые непосредственно к Си не имеют отношения, но без их понимания работать с сетью не получится.

Обратите внимание, изучение языка программирования сродни изучению естественного языка. С поправкой на объём и отсутствие слуховой/разговорной составляющей.
А в основе то же самое: алфавит, лексемы (словарный запас), языковые конструкции (грамматика).

Если я знаю язык до такой степени, что не могу на нём ни писать, ни читать, ни говорить, то правильнее будет сказать, что я язык не знаю.
Я использовал книгу Герберта Шилдта для ознакомления с недокументированными возможностями Windows.
Стало быть, разбирался в примерах (которые там сплошь на Си), анализировал код, проще говоря. И даже использовал эти функции в своей курсовой по системному программированию. Правда писал уже на другом языке. То есть мне приходилось читать, переводить и писать. Не совсем тривиальная задача, доложу я Вам.
Но означает ли это, что я знаю язык Си? Да вот ни разу не означает.
В противном случае я смогу сказать, что знаю Си/С++, perl, ruby, phyton, а заодно немецкий и латынь.
И пофиг, что я не могу ничего написать на этих языках. Так выходит? Не, не пойдёт.

Вот давно не писал (так как предыдущими прогами сжег 2 винчестера)

Ну, силён!

По разным причинам (достаточно необычным в моей интерпретации) из тех, кто программировать не умел до универа, в универе также программистами не становятся.

Не знаю, откуда Вы это взяли, но я - живой пример, опровергающий данный тезис.

Сходите в рф устройтесь реально программистом с нормальной оплатой...

Я сходил и устроился. И даже оказался конкурентоспособным на рынке труда (сам не ожидал).
Что касается зарплаты, она, конечно, небольшая, но в нашей местности других нету.
И дело здесь не в том, что студент в универе не стал программистом, а в том, что работодатели жадные, а бюджеты сокращаются.

[azsx]

Не знаю, откуда Вы это взяли, но я - живой пример, опровергающий данный тезис.

привет нео, ты избранный

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

в вашей местности кто нибудь ездит на дорогих иномарках, покупает дома и квартиры, ради баловства забегает в бутик за сапожками и аппле часами?

Расскажите, как можно программно спалить винчестер?

для этого надо 2 вещи: 1. писать файлы в среднем по 25 кб и обрабатывать их. До полумиллиона штук ежедневно; 2. Делать это в несколько потоков; 3. Делать это на старых ide винчестерах зы всё это на винхр.
Сперва я забодал 80 гб старый винт, затем я нашел в коробке 20 гб винт. Оба умерли, внутри чо то стучит при включении.
Теперь у меня физически нет ide винтов на семпрон. А какой комп был, сам крепление для процессорного куллера из жестянки ему сколачивал, вентиялтор на мосте. ээх...
зы
но ваще странно, что вас удивляет винты сата у меня также ломаются время от времени. Конечно срок службы меряется годами, но ведь винчестеров далеко не один (далеко не в одном компе по городу).

[Bizdelnick]

Сходите в рф устройтесь реально программистом с нормальной оплатой...

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

странно, что вас удивляет

Удивляет, что Вы связываете смерть винтов со своей программой. Скорее всего они просто ресурс выработали. Вы разве что немного приблизили этот момент.

[Hephaestus]

в вашей местности кто нибудь ездит на дорогих иномарках, покупает дома и квартиры, ради баловства забегает в бутик за сапожками и аппле часами?

Про бутики и часы не знаю, а на иномарках ездят, конечно.
Только не все владельцы иномарок - программисты.

Зарплата программиста в нашем регионе от 6000 до 40000 руб.
Нижняя планка - это бюджеты, где программистами называют всех, кто может поставить винду и настроить сеть.
Верхняя планка - это 1С. Там требуется знание бухучёта, сертификаты и пр.
Большинство вакансий (средняя прослойка) - на 10000-12000-15000 руб.
Вот моя зарплата как раз в этих пределах. И конкретно для нашего города это практически без вариантов.
В более крупных городах нашего региона средняя прослойка чуть выше - 20000-25000 против наших 15000 руб.

[azsx]

Пообщался с программистом на С. Возобновил с ним разговор. Его слова:
1. бывает, что он ходит работу 2 недели и ему не дают ваще никаких заданий. Все хабры уже перечитал.
2. его осовные работы две. 1. программисты на php бьются и воюют но никак не могут заставить работать какой либо программный блок без багов. Тогда зовут его и он переписывает их блок скрипта на с. 2. Крайне редко бывает, что скорости php не хватает. Он переписывает на с. По его слова скорости не хватает из-за неверных алгоритмов, а вот баги на пустом месте из-за языка php.
3. сам лично он программ не пишет уже давно. По его словам нет нужды.
4. Он за чистый с.
Верно ли его мнение?
оффтопик

Нижняя планка - это бюджеты, где программистами называют всех, кто может поставить винду и настроить сеть.
Верхняя планка - это 1С. Там требуется знание бухучёта, сертификаты и пр.

с очень большой натяжкой из выше приведенных вами специальностей только 1Сников можно называть программистами (если 1С := программисты, то тогда написание bat файлов это реальное программирование, а bash или vbs - это ваще крутое программирование). Всё таки я под словом программист понимаю написание готовых программных решений на ЯП высокого и среднего уровня под требования конкретных задач. А вовсе не написание скриптов в 1С. Таким образом зп обсуждать также бесмысленно, хотя косвенно вы подверждаете, специалисты в рф сейчас не нужны. Программисты тем более.

[eddy]

А "освоить язык"... десять лет - это как-то многовато.

Я на сях уже лет 12 пописываю. И что? Не сказал бы, что я освоил язык!
Это еще от рукожопия зависит. Скажем, пхытон я вообще никогда не освою (больно иррациональный ЯП), С++ могу и освоить, но мне эта дрянь не нужна.

P.S. Насчет зарплат. Понятно, что в нашем регионе такой профессии как "программист" не существует. Я даже не знаю, сколько эникейщики в банках получают — как-то не интересно. У меня зарплата около 18т.р. в месяц + разные шабашки и экскурсии (если бы не они, то мы с женой и дочкой питались бы только хлебом и водой, а на машине ездили лишь по экстренным случаям). Однако, программистом бы я пошел работать лишь за ОЧЕНЬ большую зарплату (скажем, не меньше пары тысяч долларов) и без смены региона проживания — уж больно похабная это работа: однообразная и унылая.

OpenCV содержит библиотеку для GUI, которая использует Qt, скорость их кода от этого не падает.

Я не уверен в этом. Кстати, навелосипедил уже уйму всяких вещей для работы с изображениями, но все так и не пришел к выводу о том, что опенЦВ проще. А то, как с каждым годом эта библиотека все жирней и жирней становится, говорит о ненужности опенЦВ. И да, культи и Ц++ — это априори тормоза и баги!

[NickLion]

Обратите внимание, изучение языка программирования сродни изучению естественного языка. С поправкой на объём и отсутствие слуховой/разговорной составляющей.
А в основе то же самое: алфавит, лексемы (словарный запас), языковые конструкции (грамматика).

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

Так вот именно, можно изучить язык — алфавит, лексемы и грамматику — и уметь реализовать любой алгоритм и читать спокойно любой написанный код. Но не знать сокетов. Такое знание скорее как знание специальной терминологии — просто не разбираетесь в определённой области. Например, не зная терминологии, к примеру, астрономии, вы всё равно будете знать язык, но текст по астрономии понять не сможете.

Я не уверен в этом. Кстати, навелосипедил уже уйму всяких вещей для работы с изображениями, но все так и не пришел к выводу о том, что опенЦВ проще. А то, как с каждым годом эта библиотека все жирней и жирней становится, говорит о ненужности опенЦВ. И да, культи и Ц++ — это априори тормоза и баги!

1. OpenCV без использования Qt и с его использованием работает одинаково. Потому что работает один и тот же алгоритм, написанный на одном и том же языке.
2. OpenCV удобен для того, чтобы как раз не писать и дебажить стопицотые велосипеды, а сконцентрироваться на непосредственно задаче. Хотя я сам тоже чаще велосипедил, но тем не менее инструмент полезен.
3. Отзывы отормознутоси C++ обычно связано с людьми, которые эти самые плюсы не особо понимают, а просто что-то написали, думая, что это просто Си с классами. Также можно написать и на Си, не понимая, что происходит и думать, что Си тормознее C++, например, что-то такое:
C

Код: Выделить всё

#include <stdio.h>
#include <string.h>
#include <memory.h>
#include <stdlib.h>

int main(int argc, const char *argv[])
{
    const int n = 1024 * 256;
    char* text = (char*) malloc(n);
    int i, j;
    for (i = 0; i < n - 1; i++) {
        text[i] = 'a' + rand() % ('z' - 'a' + 1);
    }
    text[n - 1] = 0;
    for (i = 0; i < strlen(text); i++) {
        if (text[i] == '0')
            printf("0 found at %d\n", i);
    }
    free(text);
    return 0;
}

C++

Код: Выделить всё

#include <iostream>
#include <string>
#include <cstdlib>

int main(int argc, const char *argv[])
{
    const int n = 1024 * 256;
    std::string text(n, 'x');
    int i, j;
    for (i = 0; i < n - 1; i++) {
        text[i] = 'a' + std::rand() % ('z' - 'a' + 1);
    }
    text[n - 1] = 0;
    for (i = 0; i < text.size(); i++) {
        if (text[i] == '0')
            std::cout << "0 found at " << i << std::endl;
    }
    return 0;
}

Но если знать, то просто выходит, что в случае Си просто получается ещё один вложенный цикл в strlen, который всё и портит, и задача ускоряется в разы. А в C++ начинают бездумно пихать неправильную работу с std::vector, хотя там и этого не нужно.

[eddy]

NickLion, у меня за больше чем 10 лет только один раз понадобилось написать что-то на С++ — у библиотеки для работы с ПЗС матрицей не было сишного варианта, пришлось обертку писать. Во всех остальных случаях (в т.ч. числодробилках и даже CUDA) мне эти плюсы и задаром не нужны!

[Hephaestus]

с очень большой натяжкой из выше приведенных вами специальностей

Где в моём посте Вы увидели специальности? Я упомянул 1С, но не назвал ни одной специальности.

если 1С := программисты, то тогда написание bat файлов это реальное программирование, а bash или vbs - это ваще крутое программирование

А что такое? Да, 1С-ники - это программисты. И написание bat-файлов и прочих скриптов - это программирование.
На всякий случай, 1С - это платформа для разработки информационных систем, с собственной СУБД.
У них даже есть поставки, позволяющие создавать собственные продукты.
Но даже типовые конфигурации таковы, что под нужды конкретной конторы, их порой нужно переписывать практически полностью. Кто это может сделать, кроме программиста? Это во-первых.
Во-вторых, встроенный язык программирования в 1С есть не что иное как Visual Basic. И написание модулей на этом языке - вполне себе программирование. Если же Вам представляется, что это язык чересчур легкий и любая мартышка способна написать модуль или конфигурацию, уверяю Вас, это не так. Программировние для 1С требует квалификации, даром, что язык высокоуровневый и в этом смысле ничем не хуже FoxPro, к примеру.

Что касается bat-файлов - да, это тоже программирование.
В bat-файлах допустимы переменные, циклы, условия, есть свой набор операторов. То есть это вполне себе язык программирования. Более того, с некоторыми кроссплатформенными программами поставляется shell-скрипт для unix-систем и bat-файл для windows-систем. Эти скрипты выполняют одни и те же действия. То есть возможности bat-файлов сопоставимы с возможностями shell-скриптов.
Другое дело, что в языке bat-файлов многое реализовано неудобно, и сама среда будто нарочно выворачивает пользователю руки, всё это не способствует активному использованию bat-файлов, но тем не менее, язык bat-файлов достаточно функционален.

Я на сях уже лет 12 пописываю. И что? Не сказал бы, что я освоил язык!

Если Вы припомните себя самого 12 лет назад, то поймёте, что Вы всё-таки освоили язык.
В противном случае придётся признать, что 12 лет прошли впустую. Я не думаю, что это так.

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

И это достижимо за две недели или за месяц? Напоминаю, что выше речь шла именно о таких сроках. И именно это я оспариваю.
Я-то говорил о сроке в полгода-год, мне возразили, дескать, язык простой, хватит и двух недель, месяц - максимум.

[azsx]

А что такое? Да, 1С-ники - это программисты. И написание bat-файлов и прочих скриптов - это программирование.

в контексте данной темы более интересно ваше мнение о с и с++, а не обсуждение кто круче shell, powershell или vds по винду или bash под линукс.
Я понял, что вы также начали читать о с языке, верно? Вы стали учить чистый с?
зы
как вот по моему мнению - изучать новый язык под новую задачу - это дурь от безделья. И проблема не в том, что ЯП учатся годами, команды реально за пару недель наизусть выучите, если со структурой написания прог особых проблем не возникнет, то вот вы уже прогер на ЯП вновь изученным. Проблема в том, что под каждый язык есть библиотеки, исходные коды, специфические проблемы компиляторов и так далее. Вот это всё фиг и за год выучите. Правда опыта у меня... basic, delphi, foxpro, php, java. Зато за время существования этой темы я сегодня начну писать 3 прогу на делфи. На чистом с такой номер у меня бы не прошел, как я понимаю.
оффтопик

Где в моём посте Вы увидели специальности? Я упомянул 1С, но не назвал ни одной специальности.

в том то и дело, что на мое высказывание, что программисту сложно найти работу в рф вы написали кучу работ из которых программистами можно назвать только 1Сников. Вы даже не упоминаете программисткие специальности.
----------
Останавливается ферари на парковке, из него выходит пузатенький мужичок, жеманно так одним мизинцем толкает и захлопывает дверь и внезапно, возле него на парковку протискивается жигуль, с него выходит мужик, одновременно через руль тащит какой то мешок с пассажирского сиденья. Водила ферари, так презрительно "ездят тут всякие". Водила жигуля "и не говори братан, вчера по дворам еду, мне в бочину на лесапеде какой то урод въехал, я ему когда в морду бил также говорю, мол ездят тут всякие".

[watashiwa_daredeska]

Пары недель не хватит даже на то, чтобы вдумчиво прочитать K&R. А читать их нужно больше одного раза.
А если ещё разбирать задачи/упражнения, которые там есть, то нужно ещё больше времени. И это книга объемом порядка 200 страниц.

А книга Праты имеет объем 900 страниц. Как это осилить за пару недель? Никак.
Много ли воды в этой книге? Сейчас вот читаю, воды практически нет, всё вроде по делу.

Я не читал K&R, не знаю, сколько на него времени надо. И Прату не читал, но уверен, что 900 страниц — это просто немеряно. Как я говорил, я учил C по книге Бочкова, Субботина, там ~350 страниц карманного формата, из них половина — краткое описание функций стандартной библиотеки. Правда, без примеров и упражнений. Мне хватило.

Когда я говорил про полгода-год, это значит, что спустя год мы можем спокойно решать поставленную задачу и кодить решение на Си. Спустя две недели-месяц мы этого явно не сможем, по Вашим же словам.

Я смог. Конечно, пришлось подглядывать в справку, но это нельзя считать незнанием языка, просто потому, что некоторые вещи совершенно не нужно запоминать.

Во времена, когда я изучал C, я даже не знаю, какая библиотека была для создания полнотекстовых интерфейсов в DOS (был Turbo Vision для Turbo C++ и Turbo Pascal), под *nix/Linux для полнотекстовых интерфейсов была и остаётся [n]curses, для развлечься с графикой в Turbo * была BGI. Потом была Windows и какие-то модификации того же Turbo Vision (но для C++), голый WinAPI для C, для C++ был MFC, под X Window System были всякие Xaw, Motif и уже сильно потом появился Gtk. Кроме того, под Windows нужно было ещё писать всякие манифесты, и это входило в перечень необходимых знаний и умений для написания GUI-программ на C для Windows.

Итого, чтобы банально сделать программу с полнотекстовым/графическим интерфейсом нужно знать хренову тонну библиотек. Можно ли сказать, что зная эти библиотеки, знаешь C?

Кроме окошек есть ещё много всего — та же сеть, например. В DOS я сетью не занимался, тогда это была экзотика похлеще манипулятора «мышь» и звуковой карты, но в Windows уже появилась библиотека winsockets, которая криво реализовывала BSD sockets, и чтобы писать переносимые программы, нужно было отдельно знать winsockets, как отдельную библиотеку, а не только BSD sockets. А ещё были потоки (threads), которые были по разному реализованы в Win, Lin и прочих других *nix, и их реализация в Lin на моей памяти уже несколько раз менялась. Ещё возьмём IPC, которое тоже совсем не одинаковое. А если ко всему этому ещё заглянуть в man, то там почти по каждой функции есть внушительный раздел BUGS, в котором расписано, какими граблями и по какому месту можно получить в разных вариациях *nix.

А когда приходишь в какую-нибудь компанию с историей, то оказывается, что там есть coding standards и просто исторически сложившиеся практики, и прдётся использовать какой-нибудь GLib, потому что тут так принято.

Так сколько библиотек нужно знать, чтобы соответствовать Вашему требованию "знаю C"? А формат видеопамяти текстового режима VGA знать надо? А то ведь в DOS приходилось с ним работать напрямую, и вызывать и перехватывать int 10h и int 21h и ещё какое-то, которое дёргала мышь.

Но это не тот уровень усвоения, о котором я говорю.

Подозреваю, что на том уровне освоения, о котором Вы говорите, тот же C++ знают ~10 человек в мире :) Для 99.9% этот уровень совершенно невостребован.

И даже использовал эти функции в своей курсовой по системному программированию. Правда писал уже на другом языке. То есть мне приходилось читать, переводить и писать. Не совсем тривиальная задача, доложу я Вам.
Но означает ли это, что я знаю язык Си? Да вот ни разу не означает.

Я что-то не понял: писали-то на C или на «другом языке»? Если второе, то да, не означает.

[bormant]

Сейчас крамольную вещь скажу.
Язык Си -- это собственно язык (и его стандартная библиотека, если смотреть на вещи широко).
Язык Си плюс плюс -- это собственно язык (и его стандартная библиотека, если смотреть на вещи широко).
Да, чтобы воспользоваться знанием языков C и C++ для получения полезного на практике результата нужно как правило знать намного больше. Но эти знания, будем объективны, не надо называть знанием языков С или C++. Наличие у библиотек интерфейса для языка или реализация библиотеки на этом языке не делает библиотеку саму по себе частью языка.
Мухи отдельно, котлеты отдельно.

C11, черновик: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
C99, черновик: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
C++ 2014, черновик: https://github.com/cplusplus/draft/blob/mas...apers/n4140.pdf
C++ 2011, черновик: http://www.open-std.org/jtc1/sc22/wg21/doc.../2012/n3337.pdf

[watashiwa_daredeska]

Исключения в деструкторе — это зло, какого не должно быть и в C++11 по-умолчанию исключение в деструкторе приводит к std::terminate.

Вот-вот, именно.

А чем множественное наследование не угодило не понимаю.

Тем, что грабли. Именно поэтому множественное наследование в C++ на практике выродилось практически до Java-style: множественные интерфейсы и одиночный implementation. Другое встречается довольно редко.

Тем более overloading. В чём грабли-то?
Специализация шаблонов тоже бывает необходима.

Бывает, но грабли. Очень мутные правила. Пример:

Код: Выделить всё

#include <iostream>
#include <string>

using namespace std;

void f(int i) {
    cout << "f(int): " << i << endl;
}

void f(char const* s) {
    cout << "f(char const*): " << s << endl;
}

void f(string const& s) {
    cout << "f(string): " << s << endl;
}

template <typename T>
void f(T v) {
    cout << "f(T): " << v << endl;
}

template <typename T>
void f(T const& v) {
    cout << "f(T const&): " << v << endl;
}

void g(string const& s) {
    cout << "g(string const&): " << s << endl;
}

int main() {
    f(5);
    f("test 1");
    f(string("test 2"));
    g("test 1");
    return 0;
}

Вывод программы:

Код: Выделить всё

f(int): 5
f(char const*): test 1
f(string): test 2
g(string const&): test 1

Т.е. шаблонные варианты f не используются. Если в main добавить f(5.5), то получим ошибку компиляции.

Если убрать определение f(char const*), то получим ошибку компиляции, но если дополнительно ещё убрать все шаблонные определения f, то нормально будет вызвана f(string const&).

Но если убрать f(char const*) и добавить шаблонное определение f:

Код: Выделить всё

template <typename T>
void f(T const* v) {
    cout << "f(T const*): " << v << endl;
}

, то будет собираться, при этом для f(5.5) мы получаем ошибку компиляции :)

А если пойти дальше по программированию на шаблонах, то там вообще трэш и угар.

[NickLion]

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

И это достижимо за две недели или за месяц? Напоминаю, что выше речь шла именно о таких сроках. И именно это я оспариваю.
Я-то говорил о сроке в полгода-год, мне возразили, дескать, язык простой, хватит и двух недель, месяц - максимум.

Если есть хорошие знания других языков, например, того же Pascal, а лучше пары языков, то реально. Во всяком случае основа будет, а специфические детали по ходу практики выучатся. Если же учить как язык, так и программирование, алгоритмизацию, то конечно, недостаточно.

Исключения в деструкторе — это зло, какого не должно быть и в C++11 по-умолчанию исключение в деструкторе приводит к std::terminate.

Вот-вот, именно.

Не понял к чему вот именно. Отслеживание наличия исключений вещь достаточно сложная, которая только ещё больше увеличит время компиляции, которое и так не относятся к позитивным характеристикам C++. Поэтому вместо просто UB ранее, ввели определённое поведение в виде завершения. Не вижу проблем. Я вообще на стороне Qt и Google в вопросе исключений, а именно — их не использовать.

А чем множественное наследование не угодило не понимаю.

Тем, что грабли. Именно поэтому множественное наследование в C++ на практике выродилось практически до Java-style: множественные интерфейсы и одиночный implementation. Другое встречается довольно редко.

И тем не менее даже в Java ввели интерфейсы с реализацией, читай то же множественное наследование, но сбоку.
Множественное наследование даёт возможность использовать его и в стиле 1 * implementation + n * interface (c++ == abstract class), но и в прямом смысле как множественное наследование. Это не грабли, а опасный мультиинструмент. Да, таких опасных мультиинструментов в C++ много, но всё равно не согласен называть это граблями.

Тем более overloading. В чём грабли-то?
Специализация шаблонов тоже бывает необходима.

Бывает, но грабли. Очень мутные правила. Пример:
…
Вывод программы:

Код: Выделить всё

f(int): 5
f(char const*): test 1
f(string): test 2
g(string const&): test 1

Т.е. шаблонные варианты f не используются. Если в main добавить f(5.5), то получим ошибку компиляции.

Если убрать определение f(char const*), то получим ошибку компиляции, но если дополнительно ещё убрать все шаблонные определения f, то нормально будет вызвана f(string const&).

Но если убрать f(char const*) и добавить шаблонное определение f:

Код: Выделить всё

template <typename T>
void f(T const* v) {
    cout << "f(T const*): " << v << endl;
}

, то будет собираться, при этом для f(5.5) мы получаем ошибку компиляции

А если пойти дальше по программированию на шаблонах, то там вообще трэш и угар.

1. Специализация имеет преимущество над общим. Если надо явно вызвать шаблон можно написать f<type>(x);
2. Ну, всё правильно, компилятор не может понять что именно ему выбрать, тут Вы такое нагородили, что разобраться трудно. Вот если бы C++ выбирал что-то одно, а повлиять на это было нельзя — это были бы грабли. Вы для l-value объявили и T, и const T&, конечно, компилятор в полном шоке. Какое решение предложили бы Вы? Единственное, что можно было бы объявить ошибку на этапе объявления и T, и const T&, да, пожалуй, немного прошляпили.

[watashiwa_daredeska]

Не понял к чему вот именно.

К тому, что «быть не должно», но язык это позволяет → грабли.

Я вообще на стороне Qt и Google в вопросе исключений, а именно — их не использовать.

Ага, я тоже. Потому что грабли :)

читай то же множественное наследование, но сбоку.

Не то же. «Наследование ромбиком» долго было вопросом на собеседованиях, и недостижимо средствами наследования в Java, только явной композицией.

опасный мультиинструмент.

Это и есть грабли. Или грабли недостаточно опасны? Бензопила «Дружба»? :)

1. Специализация имеет преимущество над общим.
2. …

Я знаю, что и почему тут происходит, да и компилятор в этом простом случае даёт вполне вменяемое сообщение об ошибке. Но это не отменяет факта, что вся эта хренота взаимодействует не совсем очевидным образом, особенно в более реальном коде, где не всегда можно легко отследить, где и кто там чего на overload'ил, особенно если оно компиляется, но не вызывает того, что нужно, потому что где-то в другом неизвестном месте кто-то чего-то лишнего переопределил/специализировал.

не согласен называть это граблями.

Вот тут наши мнения расходятся :) Грабли — это инструмент, придуманный для одного, но имеющий множество побочных явлений, как правило нежелательных. Если использовать правильно — штука хорошая, но… в большой команде кто-нибудь может случайно отстрелить ногу не только себе, но и сотне своих коллег сразу.

[Hephaestus]

как вот по моему мнению - изучать новый язык под новую задачу - это дурь от безделья.

Это Вы работодателю будете рассказывать.
Жил-был программер, кодил на FoxPro. Прошли годы. В какой-то момент работодатель сказал: Выкидываем это старьё, закупаем новый продукт, переходим на него.
А новый продукт на платформе 1С или что-то в этом роде.
Наш программер об 1С ни сном, ни духом. Будет изучать? Будет, как миленький. Куда он денется?

На чистом с такой номер у меня бы не прошел, как я понимаю.

Правильно понимаете. Порог вхождения повыше будет.

в том то и дело, что на мое высказывание, что программисту сложно найти работу в рф вы написали кучу работ из которых программистами можно назвать только 1Сников. Вы даже не упоминаете программисткие специальности.

Я написал не кучу работ, а вилки зарплат.
Открываем список вакансий, находим несколько строк с надписью "программист" или "инженер-программист" (более грамотная формулировка) и видим те зарплаты, которые я привёл выше. Если посмотреть детали вакансии, то окажется, что за 40000 руб. хотят видеть 1С-ника.
А ~6000 руб. предлагает какая-нибудь городская больница или детский садик, понятно, что в таких конторах программировать особо нечего, нужен админ-эникейщик, но конторы эти в силу своей неграмотности "программистами" называют любого мало-мальски сведущего человека.

Так сколько библиотек нужно знать, чтобы соответствовать Вашему требованию "знаю C"?

Я не знаю, сколько требуется библиотек. Я скажу по-другому.
Я могу открыть свой любимый текстовый редактор и с "чистого листа" написать модуль для FoxPro.
Если что-то не работает, я могу понять, почему не работает.
Я могу прогнать отладку/трассировку и найти ошибку. То же самое я могу сделать с чужим модулем.
Аналогично обстоит дело с Pascal/Object Pascal.

Вот когда я смогу делать то же самое с модулями на C/C++, я буду считать, что знаю язык.
На данный момент я этого не могу. У меня не собирается линуксовая прога, компилятор выдаёт ошибку. И я лезу в интернет, чтобы скормить гуглу текст этой ошибки. Ошибки FoxPro или компилятора Pascal не вызывают у меня потребности гуглить.
И мне ясно, что для достижения такого уровня двух недель недостаточно. Нужно несколько месяцев, может быть, год, имея в виду, что в течение этого года будет много-много-много практики.

Я что-то не понял: писали-то на C или на «другом языке»? Если второе, то да, не означает.

Да, на "другом". Прога создавалась в среде Delphi, соответственно, на ObjectPascsl, но в ней вызывались недокументированные функции win из системных библиотек. Ознакомление с этими функциями происходило посредством книги Шилдта и анализа приведенных там примеров сишного кода.

Если есть хорошие знания других языков, например, того же Pascal, а лучше пары языков, то реально.

Ну, я пару абзацев выше написал, что я понимаю под знанием языка. Согласитесь, за пару недель или месяц этого не достичь. Кроме того, посудите сами: потратил человек месяц, освоил K&R. Ни одной программы пока не написал.
Может ли он в своём резюме указать язык Си? Или на собеседовании с работодателем утвердительно ответить на такой вопрос?
Я бы не рискнул. Потому что с языком знаком буквально пару недель.
А вот спустя полгода-год практики, решения задач (пусть даже учебных) будет совсем другой разговор.

[NickLion]

К тому, что «быть не должно», но язык это позволяет → грабли.

Это действительно трудно выявить.

читай то же множественное наследование, но сбоку.

Не то же. «Наследование ромбиком» долго было вопросом на собеседованиях, и недостижимо средствами наследования в Java, только явной композицией.

Потому что C++ позволяет делать как обычное наследование, так и виртуальное. В Java используются только виртуальные методы и виртуальное наследование (ну, не совсем, но ближе к виртуальному наследованию в C++). И наследование "ромбиком" теперь, фактически, тоже возможно:

Код: Выделить всё

class aa
{
    public static void main (String [] args)
    {
        new o().f();
    }

    static interface a
    {
        default void f() {
            System.out.println("a");
        }
    }

    static interface a1 extends a
    {
        default void f1() {
            System.out.println("a1");
        }
    }

    static interface a2 extends a
    {
        default void f2() {
            System.out.println("a2");
        }
    }

    static class o implements a1, a2
    {
    }
}

Оставить только виртуальное наследование и функции в C++ нельзя, упадёт скорость. С Вашей точки зрения невиртуальные функции тоже грабли, потому, что по указателю на родительский элемент будет вызван родительский метод, а не метод переопределённый в данном классе?

Это и есть грабли. Или грабли недостаточно опасны? Бензопила «Дружба»?
…
Вот тут наши мнения расходятся Грабли — это инструмент, придуманный для одного, но имеющий множество побочных явлений, как правило нежелательных. Если использовать правильно — штука хорошая, но… в большой команде кто-нибудь может случайно отстрелить ногу не только себе, но и сотне своих коллег сразу.

Да, тут не согласны. Грабли (те, которые наступать на грабли) — это инструмент с неочевидниым правильным использованием, а не просто те, которые опасны при неправильном использовании.

Я знаю, что и почему тут происходит, да и компилятор в этом простом случае даёт вполне вменяемое сообщение об ошибке. Но это не отменяет факта, что вся эта хренота взаимодействует не совсем очевидным образом, особенно в более реальном коде, где не всегда можно легко отследить, где и кто там чего на overload'ил, особенно если оно компиляется, но не вызывает того, что нужно, потому что где-то в другом неизвестном месте кто-то чего-то лишнего переопределил/специализировал.

Неочевидность со стороны программиста, а не языка — грабли конкретной программы/либы, а не языка. Да, C++ не запрещает в написании грабель.

Ну, я пару абзацев выше написал, что я понимаю под знанием языка. Согласитесь, за пару недель или месяц этого не достичь. Кроме того, посудите сами: потратил человек месяц, освоил K&R. Ни одной программы пока не написал.
Может ли он в своём резюме указать язык Си? Или на собеседовании с работодателем утвердительно ответить на такой вопрос?
Я бы не рискнул. Потому что с языком знаком буквально пару недель.
А вот спустя полгода-год практики, решения задач (пусть даже учебных) будет совсем другой разговор.

Нет, но если человек знает программирование, работает и вдруг надо использовать Си, то через 2 недели чтения о языке его можно сажать за работу с Си. С C++ я бы вряд ли доверил серьёзный код. С новым работником основная проблема, что не знают надёжно как он вообще знает программирование.

[azsx]

Прошли годы. В какой-то момент работодатель сказал: Выкидываем это старьё, закупаем новый продукт, переходим на него.

это и есть дурь от безделья, только у работодателя. Хотя под своей фразой я конечно подразумеваю современный тренд, мол язык выбирается под задачу. Для меня это также логично, как художественные произведения я буду писать на русском, публицистику на английском, а природу описывать на каком нибудь африканском языке.

Порог вхождения повыше будет.

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

[yoshakar]

художественные произведения я буду писать на русском, публицистику на английском, а природу описывать на каком нибудь африканском языке

Звучит разумно.