Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>>И не надо, так как пример ваш — дрянь. Ладно бы человек нахреначил чего-то там с памятью или указателями, а тут он тупо операторы путает. Этак он и плюс с минусом или -= с =- попутает а вы будете орать, какое С — лютое зло.
Pzz>Это могла быть просто описка. И ее, между прочим, не видно. Я долго пялился в тот фрагмент кода, прежде чем понял, в чем проблема. А я на Си пишу давно и помногу.
Pzz>В Си много таких подводных камней. Например, можно написать:
Pzz>
Здравствуйте, LaptevVV, Вы писали:
LVV>Он не путает. Это — простая описка. Бывает, что при наборе слова буквы наоборот напечатаешь. Здесь именно тот случай...
Не, ну а если он 91 вместо 19 напишет, компилятор тоже должен выдать ошибку? Требовать от языка, чтобы он был устойчивым к перестановке букв при наборе слова, это уже чересчур, может он еще и самокорректирующимся должен быть?
Здравствуйте, LaptevVV, Вы писали:
LVV>Я писал пару-тройку полезных программ еще в то время, когда вас даже в проекте не было. Яйца курицу — не учат.
Нус, уважаемый, тут есть только его слово против твоего. Поэтому не надо давить возрастом, это несерьезно выглядит. Возраст, так же как и количество "опыта" ничего не значат вот по какой причине: есть очень много людей, у которых не опыт 20 лет, а 1 год опыта помноженный на 20. Я не говорю, что ты как раз этот случай, но данный факт, дискредитирует подобные аргументы полностью.
Из рассказа «Письмо к ученому соседу» Антона Павловича Чехова (1860—1904). Автор этого письма — «Войска Донского отставной урядник из дворян» Василий Семи-Булатов — пишет своему соседу:
«Вы сочинили и напечатали в своем умном соченении, как сказал мне о. Герасим, что будто бы на самом величайшем светиле, на солнце, есть черные пятнушки. Этого не может быть, потому что этого не может быть никогда. Как Вы могли видеть на солнце пятны, если на солнце нельзя глядеть простыми человеческими глазами, и для чего на нем пятны, если и без них можно обойтиться? Из какого мокрого тела сделаны эти самые пятны, если они не сгорают? Может быть по-вашему и рыбы живут на солнце? Извините меня дурмана ядовитого, что так глупо сострил! Ужасно я предан науке!»
Здравствуйте, rising_edge, Вы писали:
_>Когда я вижу if (c), я не знаю ничего о типе. Глядя на такую запись, я предполагаю, что это булевская переменная. Когда я вижу _>if(c != 0) то, это, очевидно, c — целая; _>if(c != NULL) то, это, очевидно, c — указатель; _>if(c != '\0') то, это, очевидно, c — символ.
Посмотреть тип переменной вполне можно и не полениться. Даже если его не видно из имени. А его должно.
if (n) — очевидно, n — целое;
if (size) — очевидно, size — количество байт или элементов;
if (p) — очевидно, p — указатель;
if (c) — очевидно, c — символ.
Здравствуйте, LaptevVV, Вы писали:
LVV>1. Я имею большИй опыт программирования, чем поучающие меня программисты. Не писал больших программ на С/С++, на остальном — писал. Операционная система — большая программа? И имею 18-тилетний опыт преподавания программирования. Чего поучающий меня программист явно не имеет вообще.
Операционная система — это хорошо, это уважамс.
А вот что может дать 18-летний опыт преподавания — я очень смутно понимаю. Я в университете видел людей, преподававших свой предмет лет по 10 и ничего в нём не понимающих. Видел преподавателей, которые принимая программы на ассемблере или паскале ограничивались проверкой синтаксиса.
Охотно верю, что вы не такой. Но тем не менее, практический опыт применения языка на реальных проектах я ценю больше, чем опыт преподавания полугодового/годового курса ООП студентам.
LVV>Вот именно! А то вы невнимательно читаете. Начинающий — РЕШАЛ ЗАДАЧУ! И все с логикой и алгоритмизацией у него было в порядке. А язык подложил ему БОЛЬШУЮ СВИНЬЮ! И это — ЗЛО!
Ну тут уже несколько раз повторяли, что нужно было читать предупреждения компилятора.
В C++ есть и гораздо более изощрённые способы выстрелить себе в ногу. Никто не спорит с тем, что есть неудобные и чреватые ошибками моменты. Проблема в том, что хороших альтернатив нет (учитываем распространённость языков, доступность библиотек, литературы, средств разработки, API к различным сервисам и т.д.). Может быть тот же Oberon в этом плане лучше, я не знаю. Но я не буду писать на нём продакшн-сервисы сейчас, потому как после меня это некому будет поддерживать. Всё-таки Java/C/C++/C# — это, де-факто, мэйнстрим.
Сам я сначала учил бэйсик (который на спектрумах был), потом паскаль, потом С. Но, честно говоря, я сейчас что-то сомневаюсь в том что изучение бэйсика и паскаля было для меня полезным. Я изучил два языка, которые сложно применить в работе, а потом тратил время на изучение синтаксиса и библиотек С. Уж наверное лучше бы сразу С учил.
А сейчас можно начинать изучение с питона — его знание не будет бесполезным, это вполне себе распространённый язык.
Здравствуйте, LaptevVV, Вы писали:
LVV>На винграде обнаружил замечательный образчик кода на С, который замечательно демонстрирует, что начинать учиться программировать на С, не имея за плечами пару-тройку более простых языков, — сильно не рекомендуется.
А в чем вообще цель обучения? Если написать курсовую из 300 строк и забыть об этом программировании, как о страшном сне, то лучше может и вовсе ему (программированию) так не учиться? Если же стать программистом, все промышленные языки довольно плохие, а было бы неплохо, чтобы ученик рос не в совсем уж стерильных условиях. Иначе как он научится такие проблемы в реальной жизни решать?
И да, изучать алгоритмы лучше на каком-то совсем уж упрощенном языке, типа того, который Дейкстра использует. Потому что прибамбасы современных языков для изучения алгоритмов совершенно не нужны и только мешают.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, LaptevVV, Вы писали:
LVV>>На винграде обнаружил замечательный образчик кода на С, который замечательно демонстрирует, что начинать учиться программировать на С, не имея за плечами пару-тройку более простых языков, — сильно не рекомендуется.
Pzz>А в чем вообще цель обучения? Если написать курсовую из 300 строк и забыть об этом программировании, как о страшном сне, то лучше может и вовсе ему (программированию) так не учиться? Если же стать программистом, все промышленные языки довольно плохие, а было бы неплохо, чтобы ученик рос не в совсем уж стерильных условиях. Иначе как он научится такие проблемы в реальной жизни решать?
Цель — понравиться преподу, и, даже, если заказчики жмут хвост, с проектом который ты пишешь, выдать ему кусок из него, переделанный за хз сколько времени на оберон.
Pzz>И да, изучать алгоритмы лучше на каком-то совсем уж упрощенном языке, типа того, который Дейкстра использует. Потому что прибамбасы современных языков для изучения алгоритмов совершенно не нужны и только мешают.
И да и нет. Я бы под это вообще среду отдельную сделал, с интерпретатором, генератороми всяких данных, и сандбокс к ней.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, rising_edge, Вы писали:
_>Когда я вижу if (c), я не знаю ничего о типе. Глядя на такую запись, я предполагаю, что это булевская переменная. Когда я вижу
Когда я вижу if (c) я точно знаю что это проверка на неравенство нулю.
И мне совершенно плевать какой тип у данной переменной. bool, числовой или указатель. Один фиг.
_>Код делается более читабельным. Строгая типизация рулит. Он и так совершенно читабелен.
Здравствуйте, igna, Вы писали:
I>Не, ну а если он 91 вместо 19 напишет, компилятор тоже должен выдать ошибку?
Некорректное сравнение. Во-первых 19 и 91 — это совершенно определенно какие-то константы, хардкодить которые непосредственно внутрь алгоритма — зло. Вероятность же ошибки в хедере меньше во столько же раз, во сколько количество объявлений констант меньше количества мест, где они используются. Во-вторых 19 и 91, как ни крути, отличаются лишь семантикой — с точки зрения синтаксиса они совершенно похожи и отличить, когда в коде нельзя использовать одно, а когда другое — компилятор в принципе не способен. В случае же смешения "!=" и "=!" мы имеем не просто разные по смыслу действия, мы имеем синтаксически различные конструкции — у них даже количество операций и то не совпадает. Причем насколько я помню C++ (давно его не трогал уже, так что может и вру), нормальные компиляторы в курсе этой проблемы и, в отличие от "19 vs 91", честно выдают на подобном коде warning. Вопрос лишь в том, почему именно warning, почему не error.
I>Требовать от языка, чтобы он был устойчивым к перестановке букв при наборе слова, это уже чересчур
Дык как раз с перестановками букв в слове проблем, как правило, не бывает — в большинстве случаев, написав скажем dobule вместо double или PACKET_SZIE вместо PACKET_SIZE, мы честно получим некомпилирующуюся программу. Проблемы возникают, когда мы начинаем переставлять слова в предложениях.
П>> if b = not True: pass
П>> ^
П>>SyntaxError: invalid syntax
П>>
Ops>Диагностика — супер, понравилась. Лучше просто:"Error"
Ну в сочетании со стрелкой-указателем это фактически означает "line XXX: Unexpected token '=' at position 10". Вполне так информативно имхо. Т.е. могло бы быть и получше, конечно, не спорю, но при минимальном знании питоновского синтаксиса и такое сообщение тоже напрягов не вызывает.
Здравствуйте, LaptevVV, Вы писали:
LVV>На винграде обнаружил замечательный образчик кода на С, который замечательно демонстрирует, что начинать учиться программировать на С, не имея за плечами пару-тройку более простых языков, — сильно не рекомендуется.
Правильно. Учится нужно на КулХацкеле.
А true недостаков С и (С++) вы, профессор, еще не заметили.
Вот то с чем осознанно или неосознанно мучается почти любой Ц/ЦПП программист:
1. препроцессор вместо раздельной компиляции
2. сишные строки
K>Вот то с чем осознанно или неосознанно мучается почти любой Ц/ЦПП программист: K>1. препроцессор вместо раздельной компиляции
/me поперхнулся
причем тут препроцессор и чем плоха та раздельная компиляция что есть в любой мало мальски стоящей среде — разбиеие на проекты, модули etc..
K>2. сишные строки
а че мучительного в std::string/std::wstring?
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
K>>Вот то с чем осознанно или неосознанно мучается почти любой Ц/ЦПП программист: K>>1. препроцессор вместо раздельной компиляции O>/me поперхнулся O>причем тут препроцессор и чем плоха та раздельная компиляция что есть в любой мало мальски стоящей среде — разбиеие на проекты, модули etc..
1) Отладка сколь-нибудь нетривиальных макросов — ещё то веселье.
2) Заголовки вместо нормальных модулей особо доставляют при поиске зависимостей, а в сочетании с препроцессором иногда очень трудно сказать, что же ты конкретно навключал. А раздельная компиляция — изменение одного хедера может привести к пересборке всего солюшена, запросто.
K>>2. сишные строки O>а че мучительного в std::string/std::wstring?
Хотя бы то, что при неосторожном обращении получаем полное копирование на каждый чих. А проблема стандартных сишных строк относится скорее к проблеме сишных массивов как таковых, а это потеря размерности при передаче в другую функцию вследствие приведения к указателю.
O>>/me поперхнулся O>>причем тут препроцессор и чем плоха та раздельная компиляция что есть в любой мало мальски стоящей среде — разбиеие на проекты, модули etc.. МС>1) Отладка сколь-нибудь нетривиальных макросов — ещё то веселье.
макросы зло (c)
МС>2) Заголовки вместо нормальных модулей особо доставляют при поиске зависимостей, а в сочетании с препроцессором иногда очень трудно сказать, что же ты конкретно навключал. А раздельная компиляция — изменение одного хедера может привести к пересборке всего солюшена, запросто.
Ну это да.. Но все в ваших руках — не надо делать настолько глобальные хедеры и не надо их часто менять если уж сделали Впрочем проблема конечно имеется, но она не так уж страшна
K>>>2. сишные строки O>>а че мучительного в std::string/std::wstring? МС>Хотя бы то, что при неосторожном обращении получаем полное копирование на каждый чих.
Дык.. это зависит от реализации стринга. Вот тут например строки reference-counted: http://stdcxx.apache.org/
МС>А проблема стандартных сишных строк относится скорее к проблеме сишных массивов как таковых, а это потеря размерности при передаче в другую функцию вследствие приведения к указателю.
Ну так не пользуйтесь в С++ "сишными" строками. Пользуйтесь string'ом, он хранит длину (или может быстро ее посчитать)
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Kluev, Вы писали:
K>Вот то с чем осознанно или неосознанно мучается почти любой Ц/ЦПП программист:
K>1. препроцессор вместо раздельной компиляции K>2. сишные строки
Нельзя ли развить мысль?
Бо единственное что на самом деле меня в околоС++шной области напрягает — криво написанные библиотеки.
В частности на 80% бесполезная и в целом малофункциональная библиотека под названием CRT.
Но это ни разу не проблема именно языка. Это извечная проблема обратной совместимости и поддержки legacy.
Здравствуйте, ononim, Вы писали:
O>>>/me поперхнулся O>>>причем тут препроцессор и чем плоха та раздельная компиляция что есть в любой мало мальски стоящей среде — разбиеие на проекты, модули etc.. МС>>1) Отладка сколь-нибудь нетривиальных макросов — ещё то веселье. O>макросы зло (c)
МС>>2) Заголовки вместо нормальных модулей особо доставляют при поиске зависимостей, а в сочетании с препроцессором иногда очень трудно сказать, что же ты конкретно навключал. А раздельная компиляция — изменение одного хедера может привести к пересборке всего солюшена, запросто. O>Ну это да.. Но все в ваших руках — не надо делать настолько глобальные хедеры и не надо их часто менять если уж сделали Впрочем проблема конечно имеется, но она не так уж страшна
K>>>>2. сишные строки O>>>а че мучительного в std::string/std::wstring? МС>>Хотя бы то, что при неосторожном обращении получаем полное копирование на каждый чих. O>Дык.. это зависит от реализации стринга. Вот тут например строки reference-counted: http://stdcxx.apache.org/
МС>>А проблема стандартных сишных строк относится скорее к проблеме сишных массивов как таковых, а это потеря размерности при передаче в другую функцию вследствие приведения к указателю. O>Ну так не пользуйтесь в С++ "сишными" строками. Пользуйтесь string'ом, он хранит длину (или может быстро ее посчитать)
Вы правильно описали ситуацию. Ничего смертельного и неисправимого нет, но эти мелочи в целом могут организовать недетский баттхёрт. А по поводу string в частности и всех шаблонов в общем, могу сказать, что меня как программиста под Windows крайне печалит основная их проблема — передача владения через границу DLL. Мне известно только то, что это вызвано особенностями работы с памятью в VS реализации CRT и соотв-но не лечится.
А за stdcxx спасибо, посмотрю на досуге.
Здравствуйте, Мишень-сан, Вы писали:
K>>>Вот то с чем осознанно или неосознанно мучается почти любой Ц/ЦПП программист:
Кстати по проблемам С и С++ довольно таки отличаются друг от друга. Так что С и С++ программисты как правило "мучаются" с довольно таки разными проблемами.
O>>причем тут препроцессор и чем плоха та раздельная компиляция что есть в любой мало мальски стоящей среде — разбиеие на проекты, модули etc.. МС>1) Отладка сколь-нибудь нетривиальных макросов — ещё то веселье.
С макросами в основном Сшники сношаются.
В С++ эквилибристика на макросах используется крайне редко, бо есть более удобные средства генерации кода.
МС>2) Заголовки вместо нормальных модулей особо доставляют при поиске зависимостей
Покуда особых проблем не имел.
Разве что при разгребании говнокода.
Говнокод на C# разгребать было не проще.
МС> а в сочетании с препроцессором иногда очень трудно сказать, что же ты конкретно навключал.
Для особо тяжких случаев есть /showIncludes
МС>А раздельная компиляция — изменение одного хедера может привести к пересборке всего солюшена, запросто.
Если он воткнут везде — да. И что?
Предложи вариант как от этого избавиться но сохранить все плюшки типа инлайнинга.
В любом случае все зависимости придётся обработать. А зависимости ты указал включением хидера. Не включай его там где он не нужен и будет тебе щасте.
K>>>2. сишные строки O>>а че мучительного в std::string/std::wstring? МС>Хотя бы то, что при неосторожном обращении получаем полное копирование на каждый чих.
А можно пример? А то что то у меня не придумывается что надо с ними делать чтоб на каждый чих копировалось. В C# стиле писать что ли.
МС> А проблема стандартных сишных строк относится скорее к проблеме сишных массивов как таковых, а это потеря размерности при передаче в другую функцию вследствие приведения к указателю.
Честно говоря не сильно помню когда мне приходилось использовать массивы кроме как временного буфера для вызова Сшных функций, который за пределы небольшого scope никуда не выходил.
Всё больше контейнеры и обёртки.
Он и так совершенно читабелен.
