Здравствуйте, Sheridan, Вы писали:
P>>А прикинь, как математики измельчали. Не хотят почему-то использовать римские цифры при записи чисел. Перешли на позиционные системы счисления. И теперь любой школьник выполняет арифметические действия без особых проблем. Не хотят разбираться в римских цифрах, считают их источником ошибок и тратой времени. S>Ой передергиваешь. Римские цифры от арабских отличаются только при письме. Считать надо ровно также уметь. И если математика попросить римскими цифрами писать — он недельку привыкать будет, а потом обратно в колею войдет. S>А вот ежели шарпея например или там заводчиков земноводных вдруг за ц++ посадить — ВНЕЗАПНО окажется что ой. Не хватает в головах и надо доучиваться.
Когда шарпей садится за с++ все что нужно это вспомнить указатели и забыть про вкусные фичи. А вот когда ц++ садится за чтото посильнее, начинается ОЙ — не хватает знаний по ООП, Дизайну.
ц++ путают ссылки с указателями, кричат на каждом углу "александреску не нужен" и продолжают рожать монстров еще страшнее тех что у александреску. Твои макросы именно такие
Здравствуйте, Tanker, Вы писали:
S>>Ой передергиваешь. Римские цифры от арабских отличаются только при письме. Считать надо ровно также уметь. И если математика попросить римскими цифрами писать — он недельку привыкать будет, а потом обратно в колею войдет. S>>А вот ежели шарпея например или там заводчиков земноводных вдруг за ц++ посадить — ВНЕЗАПНО окажется что ой. Не хватает в головах и надо доучиваться. T>Когда шарпей садится за с++ все что нужно это вспомнить указатели и забыть про вкусные фичи.
Интересно, как можно "вспомнить" то, что никогда не знал? Значительная часть "шарпеев", явистов и т.д. уже никогда не писала под языки, где указатели, ручное распределение памяти и явный вызов free().
T> А вот когда ц++ садится за чтото посильнее, начинается ОЙ — не хватает знаний по ООП, Дизайну.
В чём-то, наверно, не хватает. Только не в ООП или дизайне, а в специфике реализации. Я тут в соседней дискуссии упорно называл интерфейсы классами, потому что для меня это специальные варианты класса, а собеседники не понимали — у них это уже несочетаемые понятия. Вот на таком — да, можно нарваться. Или в специфических шарповских фичах вроде делегатов или Linq. А при чём тут дизайн или ООП в общем?
T>ц++ путают ссылки с указателями,
Вот как раз выходцы с C++ их никогда не путают, потому что в C++ есть оба понятия и они заметно разнятся.
Ещё примеров? А то твой текущий набор как-то неубедителен.
T> кричат на каждом углу "александреску не нужен" и продолжают рожать монстров еще страшнее тех что у александреску. Твои макросы именно такие
Нормальные макросы. Я бы в таком виде, наверно, не делал, но мне и задача такая пока не приходила.
Здравствуйте, Sheridan, Вы писали:
P>>А прикинь, как математики измельчали. Не хотят почему-то использовать римские цифры при записи чисел. Перешли на позиционные системы счисления. И теперь любой школьник выполняет арифметические действия без особых проблем. Не хотят разбираться в римских цифрах, считают их источником ошибок и тратой времени. S>Ой передергиваешь. Римские цифры от арабских отличаются только при письме. Считать надо ровно также уметь.
Даже если считаешь в уме в десятичных, но пишешь и читаешь в римских — будет масса тривиальных ошибок из-за конверсии. А теперь расскажи, как ты будешь умножение или деление столбиком делать в римских цифрах? Каким образом из логики следует, что CCXXII * II == CDXLIV?
Признайся, что ты это написал не подумав более трёх секунд.
S> И если математика попросить римскими цифрами писать — он недельку привыкать будет, а потом обратно в колею войдет.
Не войдёт. Ибо зверски неудобно. Количество очевидных ошибок в древних расчётах, дошедших до нас, безумно именно из-за такой специфики старых систем, и не важно, это римская, греческая или шумерская.
S>А вот ежели шарпея например или там заводчиков земноводных вдруг за ц++ посадить — ВНЕЗАПНО окажется что ой. Не хватает в головах и надо доучиваться.
Тут в целом согласен, что переход сложен. Но твои акценты сомнительны. В случае C++ сложность заметно другая. Если сейчас "шарпей" пересядет на C++, из того, что он потеряет и заметит это, будет в первую очередь Linq, во вторую делегаты и замыкания — эти фичи отсутствуют совсем на C++ или очень тяжело эмулируются. А ведь это средства уровнем выше, чем любые штатные средства C++. Да, он получит весь арсенал C вплоть до прямого ассемблера, но нужно ли это было ему для прежних задач?
Здравствуйте, netch80, Вы писали:
S>>>А вот ежели шарпея например или там заводчиков земноводных вдруг за ц++ посадить — ВНЕЗАПНО окажется что ой. Не хватает в головах и надо доучиваться. T>>Когда шарпей садится за с++ все что нужно это вспомнить указатели и забыть про вкусные фичи.
N>Интересно, как можно "вспомнить" то, что никогда не знал? Значительная часть "шарпеев", явистов и т.д. уже никогда не писала под языки, где указатели, ручное распределение памяти и явный вызов free().
Значительная часть шарпеев это бывшие ц++. Вдобавок, указатели в шарпе имеются, сюрприз ! Явное управление ресурсами это the must — IDisposable. Вот с конструкторами-десктрукторами и исключениями могут быть проблемы. Шарпею и в голову может не прийти, что исключения могут работать наполовину
N>В чём-то, наверно, не хватает. Только не в ООП или дизайне, а в специфике реализации. Я тут в соседней дискуссии упорно называл интерфейсы классами, потому что для меня это специальные варианты класса, а собеседники не понимали — у них это уже несочетаемые понятия. Вот на таком — да, можно нарваться. Или в специфических шарповских фичах вроде делегатов или Linq. А при чём тут дизайн или ООП в общем?
при том, что ц++ обычно работают на низком уровне. ха-ха.
T>>ц++ путают ссылки с указателями,
N>Вот как раз выходцы с C++ их никогда не путают, потому что в C++ есть оба понятия и они заметно разнятся.
Высказывания "Banned by IT" хороший пример ?
* и & это фигня. Сама идея получать указатель по ссылке однозначно демонстрирует ущербность реализации. Ссылка это всегда идентити, а в с++ ссылка неразрывно связана с указателями, а потому чуть более чем все ц++ яростно доказывают что это вообще одно и то же
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Mamut, Вы писали:
N>>>>>Такого рода отношение к проекту, в котором участвуешь, неприемлемо как для меня, независимо от того, он платный, бесплатный, открытый, или какой-то ещё. P>>>>Целая толпа народу пытается объяснить это мсье д'Артаньяну черт знает сколько времени. S>>>А Дарт Аньян все никак не может донести толпе, что работать в сторону интереса намного продуктивнее, нежели работать в сторону необходимости. Например, сравни сколько жил авалон в мусорке и за сколько я его привел в порядок и добавил в туда несколько вкусных возможностей
M>>Например, напрочь поломав кодировку старых сообщений и сам процесс сборки S>Например процесс сборки я перевел в cmake и даже скрипт нарисовал. S>Также например кодировку я починил, но то что успело засинхронизироваться — уже было невозможно исправить.
Тесты тебя не учили писать?
Или "ну их нахрен"?
Здравствуйте, blackhearted, Вы писали:
B>Тесты тебя не учили писать? B>Или "ну их нахрен"?
А как ты думаешь я выяснил что не смогу поправить "??? ????? ?????" в уже полученных сообщениях?
Здравствуйте, Sheridan, Вы писали:
S>Ой передергиваешь. Римские цифры от арабских отличаются только при письме. Считать надо ровно также уметь. И если математика попросить римскими цифрами писать — он недельку привыкать будет, а потом обратно в колею войдет.
Когда ты выучишь матчасть и узнаешь, в чем различие между непозиционными и позиционными системами счисления, тогда, возможно, тебе станет ясно, что ни фига я не передергиваю. А в качестве упражнения попробуй ответить на вопрос, который тебе по этому поводу задал netch80. Я и сам бы его задал, да был в отъезде пару дней, без всяких компьютеров, Интернета и прочей технологической ерунды.
S>А вот ежели шарпея например или там заводчиков земноводных вдруг за ц++ посадить — ВНЕЗАПНО окажется что ой. Не хватает в головах и надо доучиваться.
На это тебе тоже ответили, не буду повторяться.
P>>Следует ли это понимать так, что ты хочешь ввести для разработчиков условия, о которых как-то писал Pavel Dvorkin: Вот если бы было введено ограничение по количеству переменных в программе (вот тебе 100 на программу и крутись как хочешь
S>Я честно попытался представить себе ход твоих мыслей, которые привели тебя к этому умозаключению, но тщетно. Поведаешь как ты додумался до такого что я буду подобный бред разделять?
Потому что это сейчас кажется бредом, а в начале компьютеризации это была суровая реальность. Представь: машина с 64К памяти, 512 байт стека. Ее Basic поддерживал не 100, а, ЕМНИП, 206 переменных. В таких условиях люди писали весьма качественный софт. Проблема в том, что человек в этом случае должен был помнить целую кучу деталей, которые в условиях, например, PC, можно поручить машине.
И это ни фига не рассуждения теоретика. Мне довелось участвовать по крайней мере в одном промышленном проекте, который разрабатывался в таких условиях, был успешно выполнен, не содержал ни одной строки спагетти-кода. Я о нем несколько раз писал здесь, в КСВ.
S>Так ограничивать программиста не просто глупо, а граничит с шизофренией.
XC>Ужасная система #include и препроцессора, отсутствие нормальной модульной системы
А чем ужасна система #include?
Что такое "модульная система"? Я компоную исходники по модулям так, как мне захочется. Компилирую их отдельно в библиотеки. Также делают и поставщики библиотек. Это не модульность?
XC>Отсутствие вложенных блочных комментариев
Их наличие уже лишь warning. Но, anyway, зачем они?
XC>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)
Собака виляет хвостом, когда радуется. Нелогично! У кошек же не так!
Иными словами — а почему должно быть так и в структурах?
XC>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода
ЗАЧЕМ???
XC>goto на переменные метки (в gcc есть, но это нестандартно)
Goto, надеюсь, когда-нибудь вообще отменят.
XC>Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3});
Вот с этим соглашусь.
XC>Отсутствие именованных блоков кода,
Это "функция" называется, не?
XC>соответственно невозможность сделать break и continue на именованный блок/из блока
Нипонел. break/continue делается на текущий цикл. Вы хотите чтобы break/continue выходил сразу из более чем одного цикла?
XC>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this
"Методы-расширения" — это что?
Зачем надо обращаться к не-статическому?
XC>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT
То, что вы называете системой сообщений в ObjC — это про
[obj performSelector:@selector(mySelector)]
?
XC>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)
Примите за правило не делать более N методов в классе. Получается больше — рефакторинг.
XC>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые
С лямбдами не знаком вообще, а отсутствие вложенных функций — сомнительное неудобство. Какая разница? Объявил статической и ладно.
XC>Отсутствие замыканий, простого объявления функциональных типов (int=>int)
Что это и зачем это надо?
XC>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую
Что это и зачем это надо?
XC>Отсутствие опциональной возможности структуной типизации
Что это и зачем это надо?
XC>Оператор :: вместо точки (некрасиво)
Точка тоже есть. И ->
XC>Ужасно громоздкая система шаблонов (каждый раз писать template), и тенденция использования шаблонов не по назначению (метапрограммирование на них)
Да забудьте вы про Александреску, он ненормальный
XC>При этом отсутствие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше) XC>Отсутствие полноценной рефлексии и атрибутов (как в C#) XC>Отсутствие встроенной параллельности и каналов (как в Go) XC>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)
Про это я вообще не в курсе, так что вообще ничего не скажу.
Здравствуйте, Dair, Вы писали:
XC>>Ужасная система #include и препроцессора, отсутствие нормальной модульной системы D>А чем ужасна система #include?
Тормозами и отсутствие контроля соответствия хидера бинарнику.
D>Что такое "модульная система"? Я компоную исходники по модулям так, как мне захочется. Компилирую их отдельно в библиотеки. Также делают и поставщики библиотек. Это не модульность?
http://en.wikipedia.org/wiki/Modular_programming
XC>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this D>"Методы-расширения" — это что?
Я на этот вопрос в топике уже отвечал.
D>Зачем надо обращаться к не-статическому?
Чтобы получить более читаемый код.
XC>>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые D>С лямбдами не знаком вообще
В чистоте синтаксиса разница. Ряд задач вложенные функции позволяют описывать чище и красивее.
XC>>Отсутствие замыканий, простого объявления функциональных типов (int=>int) D>Что это и зачем это надо?
Долго объяснять. Начни с лямбд.
XC>>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую D>Что это и зачем это надо?
Для алгоритмов, которые оперируют большим количеством кортежей разных типов, чтобы не описывать каждый такой тип отдельной структурой.
XC>>При этом отсутствие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше) XC>>Отсутствие полноценной рефлексии и атрибутов (как в C#) XC>>Отсутствие встроенной параллельности и каналов (как в Go) XC>>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)
D>Про это я вообще не в курсе
XC>>>Ужасная система #include и препроцессора, отсутствие нормальной модульной системы D>>А чем ужасна система #include? НС>Тормозами и отсутствие контроля соответствия хидера бинарнику.
На это есть линковка, не?
D>>Что такое "модульная система"? Я компоную исходники по модулям так, как мне захочется. Компилирую их отдельно в библиотеки. Также делают и поставщики библиотек. Это не модульность? НС>http://en.wikipedia.org/wiki/Modular_programming
Удобно. А .so (dll в win, dylib в OSX) и заголовочные файлы не то же самое?
XC>>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this D>>"Методы-расширения" — это что?
НС>Я на этот вопрос в топике уже отвечал.
D>>Зачем надо обращаться к не-статическому? НС>Чтобы получить более читаемый код.
А можно пример?
Поясню недоумение: метод класса — он и есть метод класса, т.е., некая операция, которую осуществляет этот класс.
Статические методы — это, кмк, такой костыль, которым иногда можно пользоваться для группировки методов по классам.
XC>>>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые D>>С лямбдами не знаком вообще НС>Так познакомься, тем паче что в свеженьком С++ они есть — http://en.wikipedia.org/wiki/C%2B%2B11#Lambda_functions_and_expressions .
Это я читал, спасибо.
Практического применения не вижу ни одного пока что.
D>>, а отсутствие вложенных функций — сомнительное неудобство. Какая разница? НС>В чистоте синтаксиса разница. Ряд задач вложенные функции позволяют описывать чище и красивее.
Beauty is in the eye of the beholder. Но — соглашусь, иногда может быть удобнее. Я не встречал.
XC>>>Отсутствие замыканий, простого объявления функциональных типов (int=>int) D>>Что это и зачем это надо? НС>Долго объяснять. Начни с лямбд.
XC>>>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую D>>Что это и зачем это надо? НС>Для алгоритмов, которые оперируют большим количеством кортежей разных типов, чтобы не описывать каждый такой тип отдельной структурой.
Меня смутило незнакомое мне слово "кортеж". Да, проблема есть, согласен.
XC>>>При этом отсутствие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше) XC>>>Отсутствие полноценной рефлексии и атрибутов (как в C#) XC>>>Отсутствие встроенной параллельности и каналов (как в Go) XC>>>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)
D>>Про это я вообще не в курсе
НС>Суров.
Увы, за свою скромную карьеру я познакомился не со всеми языками. На C# написал пару простейших вещей, Nemerle и go не видел вообще. Основным языком уже много лет остается C++. И ещё ObjectiveC. И немного perl/python/bash/Java.
Здравствуйте, Dair, Вы писали:
НС>>Тормозами и отсутствие контроля соответствия хидера бинарнику. D>На это есть линковка, не?
Линковка тоже явно версии не отслеживает, просто пишет что функция не найдена.
НС>>http://en.wikipedia.org/wiki/Modular_programming D>Удобно. А .so (dll в win, dylib в OSX) и заголовочные файлы не то же самое?
Если это обернуть нормальными метаданными и получить что то вроде СОМ или CORBA, то это оно. Но какой ценой ...
НС>>Чтобы получить более читаемый код. D>А можно пример?
Пример я тоже уже приводил.
D>Практического применения не вижу ни одного пока что.
Тут я вряд ли чем смогу помочь. ФП — тема объемная, не для форума.
Здравствуйте, Sheridan, Вы писали:
S>А вот ежели шарпея например или там заводчиков земноводных вдруг за ц++ посадить — ВНЕЗАПНО окажется что ой. Не хватает в головах и надо доучиваться.
Май йанг френд...
Я после це-пэ-пэ стал уже шарпеем. И обратно не хочу очень сильно.
Здравствуйте, Dair, Вы писали:
XC>>Ужасная система #include и препроцессора, отсутствие нормальной модульной системы D>А чем ужасна система #include? D>Что такое "модульная система"? Я компоную исходники по модулям так, как мне захочется. Компилирую их отдельно в библиотеки. Также делают и поставщики библиотек. Это не модульность?
... XC>>соответственно невозможность сделать break и continue на именованный блок/из блока D>Нипонел. break/continue делается на текущий цикл. Вы хотите чтобы break/continue выходил сразу из более чем одного цикла?
... XC>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this D>"Методы-расширения" — это что? D>Зачем надо обращаться к не-статическому?
... XC>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT D>То, что вы называете системой сообщений в ObjC — это про
[obj performSelector:@selector(mySelector)]
?
... XC>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы) D>Примите за правило не делать более N методов в классе. Получается больше — рефакторинг.
... XC>>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые D>С лямбдами не знаком вообще, а отсутствие вложенных функций — сомнительное неудобство. Какая разница? Объявил статической и ладно.
... XC>>Отсутствие замыканий, простого объявления функциональных типов (int=>int) D>Что это и зачем это надо?
... XC>>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую D>Что это и зачем это надо?
... XC>>Отсутствие опциональной возможности структуной типизации D>Что это и зачем это надо?
... XC>>При этом отсутствие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше) XC>>Отсутствие полноценной рефлексии и атрибутов (как в C#) XC>>Отсутствие встроенной параллельности и каналов (как в Go) XC>>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)
D>Про это я вообще не в курсе, так что вообще ничего не скажу.
...
Мда... Ппц, нет слов. А зачем это сообщение вообще? Ты словно из лесу вышел и был там лет 20.
Ф>>строки должны быть единственными Ф>>а тут только в std уже 2 варианта
O>Спорно. O>Допустим, для какой-то задачи мне нужны очень компактные, пусть и не быстрые, строки. O>Стандартная std::string не подходит, так как на 32-битных системах весит "аж" 24 байта. O>Зато есть CString (MFC), QString (Qt) и всякие велосипеды, при желании можно найти или O>собрать реализацию с объектами размером в указатель. O>Прелесть в том, что C++ позволяет выбирать.
ф>>Ничего он не позволяет. Все вышеописанное — это не прелесть, а костыли для обхода того факта, что нормальных строк в С++ нет. Поэтому каждый пишет собственные велосипеды, которые еще и между собой несовместимы.
да что тут спорить это как в спорте и в жизни есть пилоты
и есть любители у пилота в каре движок наполовину в машине
и ему в кайф управлять каждым винтиком в этой машине за
каждое движение например не вовремя отжатое сцепление он
отвечает головой он чувствует машину сердце стучит в такт
с мотором рука сростается с рычагом переключения скоростей
пилот и машина становится единым целым
а есть просто любители которым надо
доехать на машине до работы одни других никогда
не поймут
отсюда и не любовь к си и си++ (только непоятно
зачем тогда вообще программировать если это не в кайф?)
Здравствуйте, netch80, Вы писали:
N>Интересно, как можно "вспомнить" то, что никогда не знал? Значительная часть "шарпеев", явистов и т.д. уже никогда не писала под языки, где указатели, ручное распределение памяти и явный вызов free().
Тут вроде речь про С++, а не ущербный С.
T>> А вот когда ц++ садится за чтото посильнее, начинается ОЙ — не хватает знаний по ООП, Дизайну.
N>Или в специфических шарповских фичах вроде делегатов или Linq.
Я в С++ активно использую делегаты.
>А при чём тут дизайн или ООП в общем?
Он думает, что это шарпоспецифичная вещь.
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>да что тут спорить это как в спорте и в жизни есть пилоты
Только пилотов единицы, зато много малолетних задротов мнящих себя пилотами и "стритрэйсерами". И в жизни, к сожалению, из-за этих пи...обля..ков страдают другие люди когда случаются ДТП по вине "пилотов".
Да и реальные пилоты порой влетают так, что по кускам их собирают.
