Здравствуйте, jazzer, Вы писали:
S>>Дело в том, что ц++ переживет и земноводных и немерле с хаскелями, как уже пережил вижуалбэйсик например. J>Ну так и лисп с фортраном успешно всех переживают, и даже кобол, прости господи
Возможно. Только ц++ всетаки популярнее...
Здравствуйте, okman, Вы писали:
S>>>Да ладно? У строки есть метод sendtoserver? Пример крайне неудачен. C>>Нет, есть extension-метод SendToServer. O>Ну вот если вдуматься, такой метод у строки (пусть и extension) — это нормально ?
Для строки — слишком, но в целом полезно.
O>А если SendToServer занимает продолжительное время и ее надо будет использовать асинхронно ? O>Что дальше — лепим туда еще и мьютекс, рабочий поток, нотификаторы и механизм отмены ?
А какая разница? То же самое будет, если используется helper-метод SendToServer.
Здравствуйте, Young, Вы писали:
Y>А какие возможности вам нужны — из тех которые наиболее часто вызывают сайд эффекты?
Y>Возможность записать за пределы массива?
Нет. Но отключить проверку выхода за пределы массива — да.
Y>Возможность попортить стек?
Нет. Но отключить проверку порчи стека — да.
Y>Или вообще возможность писать в произвольное место памяти?
Нет. Но сделать так, чтобы доступ к памяти не вызывал многочисленных проверок — да.
Y>А зачем нам получать противоречивое состояние объекта? Нет нельзя. Более того — даже изменить состояние переменной нельзя — она переменная в математическом смысле.
Я, вообще-то, писал о том, что на любом языке можно написать код, провоцирующий
возникновение указанных Вами проблем. Можно на C# накатать глобальных переменных и построить
вокруг их использования всю логику программы, да еще открыть доступ к ним из внешних сборок,
приглашая всех желающих злоупотребить этой возможностью. При этом получится в точности по
Вашему сценарию — малейшее изменение в одной части программы вдруг начнет сказываться в
совершенно другом месте. И что, виноваты возможности Шарпа ? Или давайте запрещать
глобальные переменные ?
Y>Все верно — у языка есть ряд вещей от которых избавляютя искуственным путем. Y>Самый древний пример пожалуй с goto будет.
Да, goto. А еще break, continue, вложенные на много уровней if-else, невнятное
именование, злоупотребление наследованием, отсутствие инкапсуляции, дублирование и
многое другое — все это есть во многих языках, не только в C++.
Y>Во первых находим слово потенциально в моем утверждении.
Ок, погорячился.
Y>А во вторых — а как можно утверждать что у функции нету сайд эффекта — ничего не зная например о том как у IP_ADDRESS определен оператор сравнения?
Каким боком тут C++ ? Этот код мог быть на любом языке. И тоже бы имел
обозначенные Вами "сайд-эффекты".
Здравствуйте, Cyberax, Вы писали:
O>>А если SendToServer занимает продолжительное время и ее надо будет использовать асинхронно ? O>>Что дальше — лепим туда еще и мьютекс, рабочий поток, нотификаторы и механизм отмены ? C>А какая разница? То же самое будет, если используется helper-метод SendToServer.
Да не, я о том, что данный функционал логичнее вынести в отдельную сущность, — какой-нибудь
Sender, — а не связывать его с классом строки.
Здравствуйте, Young, Вы писали:
Y>Собственно речь как раз и идет о том, что язык должен обеспечивать невозможность сайд-эффектов.
Вот давайте порассуждаем над этим тезисом.
Итак, есть массив. Все согласны, что выход за границы массива — зло ? Ок.
Теперь предположим, что мы пишем некий алгоритм и точно знаем, что выход за границы
массива невозможен. Например, в этот массив попадают только символы английского алфавита.
Их 26. Вопрос — зачем нам лишние проверки на предмет выхода за его границы, если у нас
это условие обеспечивается корректностью самого алгоритма (да еще набором юнит-тестов в
придачу) ? В C++ такие проверки обычно не мешают, но в ряде случаев они становятся причиной
ухудшения производительности. И именно по этой причине массивы в C и C++ реализованы
наиболее близким и естественным для платформы способом — как последовательность ячеек памяти,
и никаких size(), capacity() и проверок индекса при попытке чтения-записи.
Кому надо — берет std::vector. Короче, в описанном примере сайд-эффектом как раз
является не выход за пределы массива, а лишние проверки, плохо влияющие на перфоманс.
Здравствуйте, Философ, Вы писали:
Ф>Фантастический оверхэд у вас! Ф>целых 24 байта против самых минимальных 16
У нас разные есть строки. Есть быстрые, есть маленькие, есть те, которые
можно передавать COM-объектам и прочие. Можно написать класс строки, объекты
которого будут занимать места не больше, чем указатель. Но тогда, к примеру,
придется каждый раз проходить по строке при вызове метода get_length.
Короче, оверхед — он разный бывает, где-то по производительности, где-то по памяти.
Здравствуйте, Artifact, Вы писали:
A> Иненно об этом и речь, что не станет. Задумывались почему?
Тут не о чем задумываться, в дельфийском варианте запись будет выглядеть крайне нелепо: Console Shl 'Hello, world!';
A> Почему в других языках люди не стараются "удивить мир", а делают так, чтобы библиотека, которою они написали, максимально вписывалась в общую среду, выглядела как что-то привычное?
Да нигде мир удивить не пытаются. Если пишется библиотека, всегда стараются придерживаться единого стиля хотя бы в рамках этой библиотеки. Ну а когда код пишется "для себя", тут уже все возможно.
A> Вы правы, конечно. Просто С++, в отличии от других, с этого начал. Это было в нём с самого начала.
В дельфях, чтоль, по другому? Вообще, в любом языке допускающем смешивание стилей и парадигм они будут смешаны.
A> О внешнем единстве. Разного рода WTF??? — у меня проскакивает, только когда я читаю С++ -ный код. Типа какого чёрта везде были классы и вдруг передача через указатель на void.
Мне кажется, ты излишне демонизируешь плюсы Качество кода зависит в первую очередь от программиста, а не от языка.
A> Пишу о том, что вижу. Я не говорю о том, чтом в том же Дельфи нельзя тип полностью написать в верхнем регистре, я утверждаю, что так никто не делает.
Делают еще и не так Имена типов в верхнем регистре? Да сколько угодно. Вообще все зарезервированные слова, бывает, пишут капсом. Некоторые, например, обрамляют одиночную строку составным оператором, а некоторые нет. Некоторые всегда начинают составной оператор с новой строки, а некоторые нет. Некоторые для освобождения объекта используют FreeAndNil, а некоторые просто Free. Некоторые используют групповое декларирование типа переменных, а некоторые нет. А уж про размер отступа я вообще молчу. Посмотрим на жабу. Сейчас заглянул в два разных жабьих исходника: в одном скобки отделяются пробелами — в другом нет, в одном фигурная скобка всегда на новой строке, в другом наоборот.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, Young, Вы писали:
Y>>Собственно речь как раз и идет о том, что язык должен обеспечивать невозможность сайд-эффектов.
O>Вот давайте порассуждаем над этим тезисом. O>Итак, есть массив. Все согласны, что выход за границы массива — зло ? Ок.
А давайте допустим у нас нету массива — есть списки, кортежи и т.п. А массива нет.
Сильно хуже будет?
O>Теперь предположим, что мы пишем некий алгоритм и точно знаем, что выход за границы O>массива невозможен. Например, в этот массив попадают только символы английского алфавита. O>Их 26. Вопрос — зачем нам лишние проверки на предмет выхода за его границы, если у нас O>это условие обеспечивается корректностью самого алгоритма (да еще набором юнит-тестов в O>придачу) ? В C++ такие проверки обычно не мешают, но в ряде случаев они становятся причиной O>ухудшения производительности. И именно по этой причине массивы в C и C++ реализованы O>наиболее близким и естественным для платформы способом — как последовательность ячеек памяти, O>и никаких size(), capacity() и проверок индекса при попытке чтения-записи. O>Кому надо — берет std::vector. Короче, в описанном примере сайд-эффектом как раз O>является не выход за пределы массива, а лишние проверки, плохо влияющие на перфоманс.
Знаете, лет 15 назад я бы разделил вашу печаль..
Но в текущий момент я (занимаясь разработкой игр под мобильные платформы замечу) — не могу представить себе реальной ситуации, в которой при размере массива в 26 ячеек мне было бы дело до того — есть там проверки или нету там проверок.
Более, того — я предпочту чтобы проверки были — ибо все мы знаем насколько меняются требования — и вполне возможно, что там будут не только символы английского английского алфавита по каким либо внешним причинам (опять же сайд эффекты — изменения в другой части программы могут привести к тому, что на вход нам подадут не символы английского алфавита).
Так что лучше с проверками, а лучше вообще без массивов.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, Young, Вы писали:
Y>>А какие возможности вам нужны — из тех которые наиболее часто вызывают сайд эффекты?
Y>>Возможность записать за пределы массива?
O>Нет. Но отключить проверку выхода за пределы массива — да.
Y>>Возможность попортить стек?
O>Нет. Но отключить проверку порчи стека — да.
Y>>Или вообще возможность писать в произвольное место памяти?
O>Нет. Но сделать так, чтобы доступ к памяти не вызывал многочисленных проверок — да.
Y>>А зачем нам получать противоречивое состояние объекта? Нет нельзя. Более того — даже изменить состояние переменной нельзя — она переменная в математическом смысле.
O>Я, вообще-то, писал о том, что на любом языке можно написать код, провоцирующий
Не на любом.
O>возникновение указанных Вами проблем. Можно на C# накатать глобальных переменных и построить O>вокруг их использования всю логику программы, да еще открыть доступ к ним из внешних сборок, O>приглашая всех желающих злоупотребить этой возможностью. При этом получится в точности по O>Вашему сценарию — малейшее изменение в одной части программы вдруг начнет сказываться в O>совершенно другом месте. И что, виноваты возможности Шарпа ? Или давайте запрещать O>глобальные переменные ?
Да, именно давайте запрещать глобальные переменные.
Y>>Все верно — у языка есть ряд вещей от которых избавляютя искуственным путем. Y>>Самый древний пример пожалуй с goto будет.
O>Да, goto. А еще break, continue, вложенные на много уровней if-else, невнятное O>именование, злоупотребление наследованием, отсутствие инкапсуляции, дублирование и O>многое другое — все это есть во многих языках, не только в C++.
Да, есть еще много столь же плохих как ц++ языков — и что?
Но есть языки в которых от этого пытаются избавится.
И достаточно успешно.
Y>>Во первых находим слово потенциально в моем утверждении.
O>Ок, погорячился.
Y>>А во вторых — а как можно утверждать что у функции нету сайд эффекта — ничего не зная например о том как у IP_ADDRESS определен оператор сравнения?
O>Каким боком тут C++ ? Этот код мог быть на любом языке. И тоже бы имел O>обозначенные Вами "сайд-эффекты".
Нет, в том то и дело. Более того — насколько я знаю, в ряде языков, есть возможность чисто математически это доказать — т.е. что код делает именно это и только это.
Но не суть. Когда я в erlang-е вижу такое — мне как-то спокойнее насчет сайд эффектов
is_local_address(IP_Adress) ->
case IP_Adress of
"localhost" -> true;
"127.0.0.1" -> true;
_ -> false
end.
M>>Когда ты прекратишь слушать голоса в своей голове? То, что ты «нарисовал» — это страшный страх и ужасный ужас со всех сторон — от читаемости до поддержки в будущем
S>Я в тебе не сомневался, ты просто обязан был первым ответить на такое, особенно моё S>Ничего тут страшного нет ни в читаемости, ни в поддержке, ибо кода в реализации кот наплакал
Ты хоть раз участвовал в проектах, в которых был больше, чем один программист, и как долго?
M>>Ну и да, количество реализаций строк для С++ намекает на то, что в консерватории что-то не так.
O>Эдак можно прийти к выводу, что linux тоже в глубоком ауте из-за разнообразия версий. O>А на самом деле обилие реализаций всего лишь отражает широту круга задач, которые ими решаются.
Нет, не отражают. Отражает только ровно один факт: в С++ нет нормального способа работать со строками. Все эти QString/CString/*string'и процентов на 80-90 ублируют функцинальность друг друга.
Здравствуйте, hattab, Вы писали:
H>Да нигде мир удивить не пытаются. Если пишется библиотека, всегда стараются придерживаться единого стиля хотя бы в рамках этой библиотеки. Ну а когда код пишется "для себя", тут уже все возможно.
Я не имею ввиду стиль библиотеки. Я имею ввиду определённый общий стиль, благодоря которому все библиотеки выглядят похожими. Прослеживается некая общсность. В плюсах же я чаще вижу какой-то зоопарк.
H>В дельфях, чтоль, по другому? Вообще, в любом языке допускающем смешивание стилей и парадигм они будут смешаны.
У Дельфи, образно говоря, география сужена до одной конторы. У плюсов различия начинаются уже с лёгкой руки разработчиков компиляторов. Правда это впоследствии привело к появлению стандарта, что исправило положение, но всё же ещё продолжает иметь место быть.
H>Мне кажется, ты излишне демонизируешь плюсы Качество кода зависит в первую очередь от программиста, а не от языка.
Во многих других языках компилятор вам просто не даст вам "выстрелить себе в ногу". В плюсах, как нигде, можно послать компилятор нафиг.
H>Делают еще и не так Имена типов в верхнем регистре? Да сколько угодно. Вообще все зарезервированные слова, бывает, пишут капсом. Некоторые, например, обрамляют одиночную строку составным оператором, а некоторые нет. Некоторые всегда начинают составной оператор с новой строки, а некоторые нет. Некоторые для освобождения объекта используют FreeAndNil, а некоторые просто Free. Некоторые используют групповое декларирование типа переменных, а некоторые нет.
ОК, верю. Я с Дельфи сталкивался только в одной фирме, там было три проекта на Дельфи, начатые в разное время, да ещё и в разных странах, но выглядели они на удивление одинаково. Никакого единого стиля никто придерживаться не заставлял, но похоже все о нём знали.
H>А уж про размер отступа я вообще молчу. Посмотрим на жабу. Сейчас заглянул в два разных жабьих исходника: в одном скобки отделяются пробелами — в другом нет, в одном фигурная скобка всегда на новой строке, в другом наоборот.
Странно. Такое я видел, только когда проект на Джаве писали бывшие С++ программисты (кроме шуток).
Здравствуйте, netch80, Вы писали:
N>Если речь про схему в стиле Вирта
Думаю, речь про модульность, а не про "схему в стиле Вирта". Которая присутствует и в джаве и в дотнете.
N>Зато подход с заголовочными описаниями распространяется практически на все языки.
"Все языки" это С++ что ли?
XC>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this
N>Что такое методы-расширения я не понял.
Это синтаксический сахар для вызова статических методов (и, видимо, свободных функций в случае С++)
N>Вызов метода как статического — а зачем?
Нет — вызов статического метода. Автоматическая замена такого выражения:
X.A(Y.B(Z.C()))
На такое:
X.A().B().C();
Весьма помогает в ряде сценариев, например при использовании всяких монадных штук.
XC>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT
N>Не вижу, почему это недостаток. Такие системы сообщений весьма специфичны для задачи и общая реализация на все случаи не имеет смысла, а для конкретной — есть библиотеки.
Но единый и расширяемый синтаксис для сигналов был бы весьма полезен.
XC>>Отсутсвие вложенных функций (даже в турбо паскале вроде были),
N>Суровой необходимости не вижу, если не считать те же замыкания.
Но очень удобно.
XC>> а лямбды в C++11 на редкость кривые XC>>Отсутствие замыканий, N>Вот для замыканий неплохо бы было увидеть библиотеку в стиле boost, но для C. N>Чтобы умела хотя бы для основных платформ генерировать замыкания.
Без поддержки со стороны языка это будет очередной уродец.
XC>>Отсутствие опциональной возможности структуной типизации N>?
Это, видимо, утиная типизация имеется в виду.
XC>>Отсутствие полноценной рефлексии и атрибутов (как в C#)
N>Это очень дорого
С чего ты взял?
N> и смысл сомнителен.
Смысл в возможности аннотировать метаданные программы? Ну, кому как. Хотя без модульности, конечно, толку мало.
XC>>Отсутствие встроенной параллельности и каналов (как в Go) N>Это возлагается на библиотеки.
Но поддержка со стороны языка была бы весьма пользительна. Хотя бы в виде шарповских async/await.
Здравствуйте, okman, Вы писали:
O>Ну вот если вдуматься, такой метод у строки (пусть и extension) — это нормально ? O>По-моему, это пример плохо продуманного дизайна. O>А если SendToServer занимает продолжительное время и ее надо будет использовать асинхронно ? O>Что дальше — лепим туда еще и мьютекс, рабочий поток, нотификаторы и механизм отмены ?
Тебе по сути экстеншн методов есть что сказать, или будем придираться к примеру?
Здравствуйте, jazzer, Вы писали:
XC>>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые J>в чем кривость лямбд по сравнению с локальными функциями?
во-первых я не писал что он там есть
, если вам так не нравится vtable, можете его убрать class __declspec(novtable)...
