Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 297
Кто первый скажет, что ему заплатила МС? :D
Можно и в английском языке поискать недостатки и заменить его на эсперанто, например
но народ все равно продолжает использовать английский… просто тут так принято.
Это было бы здорово. У английского, всё-таки, довольно много недочётов. С русским, не сравнить, конечно, но всё же.
Для патриотов, которые сейчас кинутся меня минусовать: я очень люблю родной язык, я его даже довольно неплохо знаю. Поэтому я хорошо осознаю его недостатки: он плохо структурирован, в нём масса нелогичных правил, исключений и т.д. Например, с точки зрения логики какое-нибудь «жи/ши» не несёт абсолютно никакой пользы.
Для патриотов, которые сейчас кинутся меня минусовать: я очень люблю родной язык, я его даже довольно неплохо знаю. Поэтому я хорошо осознаю его недостатки: он плохо структурирован, в нём масса нелогичных правил, исключений и т.д. Например, с точки зрения логики какое-нибудь «жи/ши» не несёт абсолютно никакой пользы.
Поэтому как интернациональный язык русский не подходит совершенно. А вот эсперанто — вполне, насколько я знаю.
Не стоит забывать о таких вещах как литература, поэзия. И опять же эсперанто непригоден, например, для медицины или техники — в нём мало терминов.
Термины прекрасно заимствуются из того же английского. А для литературы и поэзии эсперанто использовать я и не призываю. Это именно синтетический язык, задуманный как средство интернационального общения.
Совершенно верно, не стоит забывать о существовании эсперантистской прозы и поэзии.
В русском, кстати, тоже мало терминов. Куда не ткнёшь — заимствование в лучшем случае из латыни и греческого, в худшем — из английского. ;)
В русском, кстати, тоже мало терминов. Куда не ткнёшь — заимствование в лучшем случае из латыни и греческого, в худшем — из английского. ;)
Да есть в нём много терминов, мощная система словообразования позволит создать новые…
А вы знаете, что в нём ВСЕ существительные оканчиваются на О? И их не очень то просто отличить от прилагательных, оканчивающихся на А?
И вообще, фонетика — это слабое место эсперанто.
Слова вроде altaukvajo и прочее :)
P.S. Вот уж лингвосрача тут не ожидал :)
А вы знаете, что в нём ВСЕ существительные оканчиваются на О? И их не очень то просто отличить от прилагательных, оканчивающихся на А?
И вообще, фонетика — это слабое место эсперанто.
Слова вроде altaukvajo и прочее :)
P.S. Вот уж лингвосрача тут не ожидал :)
Большинство медицинских терминов было заимствовано с латыни. Технические термины можно внедрить. Так что препон никаких нет, кроме как целесообразности…
Если вспомнить про английскую орфографию, то русский по логичности ему фору дать может. Потому что, отдельные правила можно исправить, а орфографию целиком — нет.
Имхо, в естественных языках общения немало должно быть уделено эстетике и чувству прекрасного. Чтобы было приятно общаться.
Насчет «жи/ши»: так как на слух и через «и», и через «ы» всё слышится одинаково, то легче запомнить одно правило написания, чем для каждого слова вспоминать, как оно пишется. По-моему, всё логично.
Насчет «жи/ши»: так как на слух и через «и», и через «ы» всё слышится одинаково, то легче запомнить одно правило написания, чем для каждого слова вспоминать, как оно пишется. По-моему, всё логично.
«Например, с точки зрения логики какое-нибудь «жи/ши» не несёт абсолютно никакой пользы.»
Просто ни один натуральный язык не устроен «с точки зрения логики».
Просто ни один натуральный язык не устроен «с точки зрения логики».
Тогда лучше всего Ithkuil. Хоть это и конлэнг, он совершенно не содержит двумсмысленностей и скорость мышления на нем самая большая. По крайней мере так говорят — нет ни одного человека который его выучил :)
Полностью поддерживаю Роба.
В современном Си++ количество ключевых слов приближается к сотне.
Десятки синонимов не делают язык лучше.
Язык чрезвычайно сложен. Взять хотя бы те-же функторы со списками типов из всем известной книге.
Вы думаете такой код будет легко понять множеству программистов различной квалификации.
Непродуманность многих частей языка ведет к невозможности их комбинации. Это недопустимо для хорошего языка.
В общем в области системного программирования есть Си. Изумительный и чудесный язык. Краткий и емкий.
Человечеству нужен такой-же немногословный высокоуровневый язык. Краткий, продуманный, понятный каждому на 100%.
В современном Си++ количество ключевых слов приближается к сотне.
Десятки синонимов не делают язык лучше.
Язык чрезвычайно сложен. Взять хотя бы те-же функторы со списками типов из всем известной книге.
Вы думаете такой код будет легко понять множеству программистов различной квалификации.
Непродуманность многих частей языка ведет к невозможности их комбинации. Это недопустимо для хорошего языка.
В общем в области системного программирования есть Си. Изумительный и чудесный язык. Краткий и емкий.
Человечеству нужен такой-же немногословный высокоуровневый язык. Краткий, продуманный, понятный каждому на 100%.
C++ сложен совсем не из-за того, что там много ключевых слов.
немногословный, высокоуровневый, универсальный
Выберете два.
Выберете два.
Python?
Вы много написали драйверов на питоне?
Я не писал, но это ещё не значит, что это невозможно. Есть проект, позволяющий транслировать текст Python на C (или C++, не помню), а потом уже компилировать.
а много ли вообще пишут драйверов?
Тогда D, почти без вариантов, насколько я знаю :)
На нем не пишут драйвера, но язык работает с указателями и прочим, поэтому в этой области вполне сгодился бы.
На нем не пишут драйвера, но язык работает с указателями и прочим, поэтому в этой области вполне сгодился бы.
Питон можно не любить уже за отсутствие инкапсуляции:)
Конечно, в «серьёзных» языках для изучения объектов делаются специальные модули, а Python просто использует соглашения. Это недостаток, по-вашем?
Собственно это была одна из причин просить питон у меня.
Ну, если вы легко можете из объекта получить данные, которые вам не следует получать, то… да!
В других языках всего лишь нужно использовать какой-нибудь модуль «Reflection». Так стоит ли вообще заниматься защитой? Python предлагает разумный компромисс.
Я не согласен с вами. Да, я не сторонник скриптовых языков, но все свои слова я могу обосновать.
Например в джаве можно запретить рефлексию просто используя необходимые нстройки секьюрити менеджера. При этом jar-файл можно подписать и это будет гарантировать, что его не изменят… Но это я так, к слову. Были бы средства…
С другой стороны в питоне уровень доступа регулируется лишь соглашением. Окей. Питон с момента появления сменил уже немало версий. Тогда почему до сих пор в нем не ввели инкапсуляцию, если язык претендует на ооп? Это же один из столпов, ничего волшебного. У меня на эту тему лишь одно соображение (да простят меня минусующие питонофилы) — соглашение это не всегда соблюдается и введение инкапсуляции может положить немало кода. Вот такой вот компромисс.
Например в джаве можно запретить рефлексию просто используя необходимые нстройки секьюрити менеджера. При этом jar-файл можно подписать и это будет гарантировать, что его не изменят… Но это я так, к слову. Были бы средства…
С другой стороны в питоне уровень доступа регулируется лишь соглашением. Окей. Питон с момента появления сменил уже немало версий. Тогда почему до сих пор в нем не ввели инкапсуляцию, если язык претендует на ооп? Это же один из столпов, ничего волшебного. У меня на эту тему лишь одно соображение (да простят меня минусующие питонофилы) — соглашение это не всегда соблюдается и введение инкапсуляции может положить немало кода. Вот такой вот компромисс.
Python просто пошёл по другому пути, только и всего. Вам этот путь чужд, только и всего.
А соображение, что инкапсуляцию на уровне языка не ввели потому, что она там не нужна, вам в голову не приходило? Что иметь ее на уровне соглашений — решение более гибкое? Убрать, например, ее всегда можно (think java→groovy), а добавить так легко нельзя, потому что ее отсутствие дает программисту больше возможностей, чем наличие?
По соглашениям вообще много чего положено: форматировать код, давать грамотные имена переменным, разделять M, V и С, ходить в душ хотя бы раз в пару дней, чтобы коллегам было с вами комфортно работать… Не все правда следуют.
Выходит, смерть инкапсуляции — новый виток в эре ООП?
Выходит, смерть инкапсуляции — новый виток в эре ООП?
Так с ней ничего не случилось, есть она, инкапсуляция, просто ее с одного уровня на другой перенесли. Или вы думаете, что вот есть инкапсуляция, и все сразу поумнели и начали ее по делу использовать? О том, какой вред она может наносить в кривых руках, не задумывались?
У меня вот, из наболевшего, Wicket Web Framework — все внутренности закрыты железобетонно, и что, думаете, хорошо это? А я вот постоянно плачу, что-то в принципе не расширяется, у чего-то, чтобы расширить, приходится тупо реализацию из исходников копировать и менять, потому что нихрена в классе поменять не могу — инкапсуляция. Это ваше светлое будущее, за которое стоит бороться?
Все рассуждения про инкапсуляцию хороши, пока дело не доходит до реальных ситуаций. Из двух зол — похакать исходник библиотеки либо вообще не реализовать функциональность вы предлагаете выбрать второе решение как более «правильное»? Не кажется ли вам, что стоит оставить этот выбор все-таки программисту и дать ему решать в каждом конкретном случае?
У меня вот, из наболевшего, Wicket Web Framework — все внутренности закрыты железобетонно, и что, думаете, хорошо это? А я вот постоянно плачу, что-то в принципе не расширяется, у чего-то, чтобы расширить, приходится тупо реализацию из исходников копировать и менять, потому что нихрена в классе поменять не могу — инкапсуляция. Это ваше светлое будущее, за которое стоит бороться?
Все рассуждения про инкапсуляцию хороши, пока дело не доходит до реальных ситуаций. Из двух зол — похакать исходник библиотеки либо вообще не реализовать функциональность вы предлагаете выбрать второе решение как более «правильное»? Не кажется ли вам, что стоит оставить этот выбор все-таки программисту и дать ему решать в каждом конкретном случае?
Простите, но у меня не было ситуаций, когда надо было бы лезть в исходники либ и их править. Расширять можно грамотным использованием наследования и проектирования.
Расширяемость приложения — это прерогатива архитектуры, а не языка.
Расширяемость приложения — это прерогатива архитектуры, а не языка.
Я сам работаю с Wicket и ниразу не хотелось лезть внутрь. Есть высокоуровневые компоненты, типа меню, диалогового окна и пр., которые приходится затачивать под себя, но они не входят в ядро. Хотя может у Вас свои задачи.
Вообще защита внутренностей позволяет разработчикам фреймворка не боятся, что они нарушат совместимость со старыми версиями и если они что-то не сделали частью публичного api, то на то были причины.
Вообще защита внутренностей позволяет разработчикам фреймворка не боятся, что они нарушат совместимость со старыми версиями и если они что-то не сделали частью публичного api, то на то были причины.
Да, они этим оправдываются, но на деле даже внутри багфикс-релизов ее умудряются ломать, я уж не говорю про минор (одно переименование getModel → getDefaultModel чего стоило). Видимо, для них совместимость все-таки несущественна.
если они что-то не сделали частью публичного api, то на то были причины.
Как раз наоборот, им нужны причины, чтобы что-то сделать частью публичного апи. На деле же оказывается, что они совсем не так дальновидны, как им кажется. И вот тут я бы с удовольствием сам решал проблемы с совместимостью (натурально, правил бы свой код, реши мы проапгрейдить версию), чем имел бы возможность безболезненно переходить на новую версию. Как-то новые версии меня не очень греют, а вот задачи, которые я не могу решить сейчас, все-таки напрягают.
если они что-то не сделали частью публичного api, то на то были причины.
Как раз наоборот, им нужны причины, чтобы что-то сделать частью публичного апи. На деле же оказывается, что они совсем не так дальновидны, как им кажется. И вот тут я бы с удовольствием сам решал проблемы с совместимостью (натурально, правил бы свой код, реши мы проапгрейдить версию), чем имел бы возможность безболезненно переходить на новую версию. Как-то новые версии меня не очень греют, а вот задачи, которые я не могу решить сейчас, все-таки напрягают.
Переход с 1.3 на 1.4 трудно назвать минорным. Даже сейчас в вики у них можно нйти упоминание о версии 2.0, которая превратилась в итоге в 1.4 Трудно сказать зачем они так поступили. Наверно, чтобы переманить побольше разработчиков с 1.3 на 1.4 А в версии 1.5 они уже обещают нарушить обратную совместимость. В багфикс-релизах ошибки встречал, но в последующих версиях они как-то сами исчезали. Можно пример поломки? Просто интересно.
Заменой getModel → getDefaultModel они хотели показать, что элементы типа Panel не дожны иметь встроеную модель, т.к. они не знают сколько их вообще нужно: одна, две, три или вообще ни одной. getDefaultModel осталось только для поддержки элементов без явного указания модели, типа new Label(«name»); В рассылке писали, что было очень много споров о том как вводить параметризацию. Остается только верить, что сделали правильно. Если не веришь, то надо менять фреймворк :)
Если бы сам писал библиотеку, то тоже закрыл бы все что мог, кроме специально подготовленных частей. Я не верю в самоорганизующися хаос в разработке.
Заменой getModel → getDefaultModel они хотели показать, что элементы типа Panel не дожны иметь встроеную модель, т.к. они не знают сколько их вообще нужно: одна, две, три или вообще ни одной. getDefaultModel осталось только для поддержки элементов без явного указания модели, типа new Label(«name»); В рассылке писали, что было очень много споров о том как вводить параметризацию. Остается только верить, что сделали правильно. Если не веришь, то надо менять фреймворк :)
Если бы сам писал библиотеку, то тоже закрыл бы все что мог, кроме специально подготовленных частей. Я не верю в самоорганизующися хаос в разработке.
В 1.4.2, что ли, у них тег wicket:enclosure тупо не работал. То есть вообще. Минорный, потому что вторая цифра называется минорным номером версии.
Я о том и говорю, если совместимости все равно нифига нет, ради чего внутренности-то прятать? Получается, только ради того, чтобы жизнь усложнить.
Поймите, библиотека — это инструмент, и нужна она для одной цели — чтобы люди ей пользовались и она приносила им пользу, помогала решать их задачи. Поймите также, что никто никогда не предугадает всех возможных вариантов использования. Лучшее, что может библиотека — помочь тем, чем может, и не мешать в остальном. Если миссия библиотеки — облегчить жизнь создателю/мейнтейнеру, или научить, как жить пользователям, то нафиг такую библиотеку.
В случае с Викетом, например, получается, что их цель — обеспечить пользователям плавный переход между релизами (у них не получается, но в идеале). Но нет такого пользователя, которому был бы интересен плавный переход на новую версию. Есть пользователи, которым интересно, позволяет библиотека сейчас решить их проблему или нет. Если ответ «почти», то лучше пусть они ее доточат, чем выкинут, не?
Я о том и говорю, если совместимости все равно нифига нет, ради чего внутренности-то прятать? Получается, только ради того, чтобы жизнь усложнить.
Поймите, библиотека — это инструмент, и нужна она для одной цели — чтобы люди ей пользовались и она приносила им пользу, помогала решать их задачи. Поймите также, что никто никогда не предугадает всех возможных вариантов использования. Лучшее, что может библиотека — помочь тем, чем может, и не мешать в остальном. Если миссия библиотеки — облегчить жизнь создателю/мейнтейнеру, или научить, как жить пользователям, то нафиг такую библиотеку.
В случае с Викетом, например, получается, что их цель — обеспечить пользователям плавный переход между релизами (у них не получается, но в идеале). Но нет такого пользователя, которому был бы интересен плавный переход на новую версию. Есть пользователи, которым интересно, позволяет библиотека сейчас решить их проблему или нет. Если ответ «почти», то лучше пусть они ее доточат, чем выкинут, не?
Это все-таки баг. Они же не сознательно его убрали. В следующей версии надо полагать исправили, т.к. у меня все работает. ИМХО, их номерация вводит в заблуждения. Я бы сменил с 1.3.х и 1.4.х на 3.х.х и 4.х.х. Тогда все было бы понятней. Внутри версий 1.3 и 1.4 у меня все переносилось отлично. Были ошибки с ajax и формами под оперой и ie, но в следующих версиях они исправлялись. Вот переход с 1.3 на 1.4 был жестоким. Получил 3000 предупреждений, некоторые дожили до сих пор.
Дело в том, что веб-фреймворки это сверх конкурентная сфера. Если просто двигаться вперед, то вскоре обнаружишь, что кроме своих старых пользователей, ты уже никому не нужен. В какой-то другой области можно сделать библиотеку решающую 80% фич, а оставшиеся отдать на откуп программистам. Тут так никогда не получится.
Дело в том, что веб-фреймворки это сверх конкурентная сфера. Если просто двигаться вперед, то вскоре обнаружишь, что кроме своих старых пользователей, ты уже никому не нужен. В какой-то другой области можно сделать библиотеку решающую 80% фич, а оставшиеся отдать на откуп программистам. Тут так никогда не получится.
Описанная проблема проистекает не из инкапсуляции, а из low cohesion. В фреймворке есть что-то, что решает несколько задач сразу и поэтому изменение решения одной задачи тащит за собой другие.
Инкапсуляция — это сокрытие того как объект делает свою работу, а не того что он делает.
По сути вопроса: использование Python в масштабах более нескольких тысяч строк требует высокой дисциплины. Перед началом програмимрования на нём стоит подумать обладаете-ли вы ей, и если нет взять что-нибудь менее опасное в неумелых руках.
Инкапсуляция — это сокрытие того как объект делает свою работу, а не того что он делает.
По сути вопроса: использование Python в масштабах более нескольких тысяч строк требует высокой дисциплины. Перед началом програмимрования на нём стоит подумать обладаете-ли вы ей, и если нет взять что-нибудь менее опасное в неумелых руках.
Он не претендует на ООП, он претендует на то, что в нём можно программировать в оо-стиле. Почувствуйте тонкую разницу.
Умиляют плюсующие под фразой «Так стоит ли вообще заниматься защитой?» :)) Вы что, серьезно так думаете?:)
It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun (Larry Wall).
Шкалы к счастью аналоговые и можно двигать ползунки :)
Ну очень спорное выступление. Пример с foo:: вообще странный. Что мешает предыдущей строчкой написать using namespace foo;? Это с одной стороны.
С другой, я сильно сомневаюсь, что есть хоть что-то что может вытеснить С и С++ из области сис.по, потому что здесь их преимущества (а именно, скорость в сочетании с гибкостью) неоспоримы.
С другой, я сильно сомневаюсь, что есть хоть что-то что может вытеснить С и С++ из области сис.по, потому что здесь их преимущества (а именно, скорость в сочетании с гибкостью) неоспоримы.
Роб Пайк стоял у истоков Unix, Plan 9, Inferno и UTF-8. Сейчас работает в Google.действительно, вам лучше знать :)
А то что он стоял у истоков что-то меняет?
Ага, давайте еще вспомним советских профессоров, стоявших у истоков ламповых компьютеров :) Многие из которых давно уже ничего не учат, а впаривают студентам знания их далеких 70-х, потому что ничего другого не знают. Как раз в данном вопросе, нужен эксперт со свежей головой, а не забитой предвзятостями из предыдущих (и текущих в особенности!) мест работы
Как известно, Аристотель, стоявший у истоков всей современной науки, написал однажды, что у мухи 8 ног. Так все и думали, пока несколько столетий спустя не пересчитали.
Доказательство истинности методом сравнения авторитетности (сейчас это называется «пиписьками меряться») — самый худший способ доказательства.
Доказательство истинности методом сравнения авторитетности (сейчас это называется «пиписьками меряться») — самый худший способ доказательства.
Я системный программист, что вы предлагаете мне вместо С и С++?
Cython допилят и будет няшно :)
Do not use a using-directive.
Google C++ style guide
Что-то мешает, и не ему одному.
Там еще есть
И много других спорных моментов. Не нужно слепо следовать гайдлайнам гугла просто потому, что они Гугл.
We do not use C++ exceptions.
We do not use Run Time Type Information (RTTI).
We do not allow default function parameters, except in a few uncommon situations explained below.
All parameters passed by reference must be labeled const.
И много других спорных моментов. Не нужно слепо следовать гайдлайнам гугла просто потому, что они Гугл.
хм. и что тут спорного?
Абсолютно всё.
а по пунктам?
Для людей, заинтересованных в эффективности своих программ, отключение exceptions/rtti это естественно. За легкость написания хелло-вордов расплачиваются производительностью и обьемом кода/занимаемой памяти в «больших» программах. Обе этих вещи отвечают за те самые легендарные тормоза и bloat C++. И использовать их попросту нельзя если у софтины есть мало-мальские требования по перформансу. Сразу видно — если человек использует эти вещи в C++, значит, либо джавист, либо академик непуганый, который и ассемблера-то ни разу не видывал, что впринципе одно и тоже =)
Если понадобились эти фичи, значит неверно выбран язык программирования для проекта.
Я, например, работаю с фиксированной железкой, где ничего не добавишь, и жесткие требования по перформансу.
Дефолтные параметры затрудняют читабельность кода.
test(foo, bar)
test(foo)
совершенно не ясно, не посмотрев, что там ставится в bar по дефолту
«Референснутые» параметры, которые не изменяются, должны быть обьявлены константными, чтобы помочь оптимизатору. Да и GCC часто ругается в некоторых случаях употребления неконстантных параметров.
const — очень полезная штука, НЕиспользование которой ведёт опять же к тормознутости кода
Для людей, заинтересованных в эффективности своих программ, отключение exceptions/rtti это естественно. За легкость написания хелло-вордов расплачиваются производительностью и обьемом кода/занимаемой памяти в «больших» программах. Обе этих вещи отвечают за те самые легендарные тормоза и bloat C++. И использовать их попросту нельзя если у софтины есть мало-мальские требования по перформансу. Сразу видно — если человек использует эти вещи в C++, значит, либо джавист, либо академик непуганый, который и ассемблера-то ни разу не видывал, что впринципе одно и тоже =)
Если понадобились эти фичи, значит неверно выбран язык программирования для проекта.
Я, например, работаю с фиксированной железкой, где ничего не добавишь, и жесткие требования по перформансу.
Дефолтные параметры затрудняют читабельность кода.
test(foo, bar)
test(foo)
совершенно не ясно, не посмотрев, что там ставится в bar по дефолту
«Референснутые» параметры, которые не изменяются, должны быть обьявлены константными, чтобы помочь оптимизатору. Да и GCC часто ругается в некоторых случаях употребления неконстантных параметров.
const — очень полезная штука, НЕиспользование которой ведёт опять же к тормознутости кода
По пунктам:
RTTI/Exceptions: если вы заинтересованы в эффективности кода, это не значит, что исключения ВЕЗДЕ неприемлемы. Работает старый принцип 80-20: 80% тормозов находится в 20% кода. Соответственно, 80% всего кода, связанного с исключениями, вряд ли тормозит программу. Можно привести кучу примеров отлично работающего кода, в котором исключения без проблем уживаются. Вообще, с чего ВЫ решаете, какие фичи «правильные», а какие нет? В С++ есть механизм RTTI и исключений — и он ничуть не менее «родной» для этого языка, чем битовые поля или арифметика указателей. Нравится ассемблер — да флаг в руки.
Зачем нужны не-const references? 1) а как вы напишете без этого функцию swap()? 2) а как вы опишете operator<< для ostream? (да и любая аналогичная перегруженная операция)?
Дефолтные параметры тоже иногда полезны. Посмотрите примеры из Boost/STL — их просто надо использовать с умом.
Например, есть такая функция boost::to_lower() — приводит строку к нижнему регистру. В 99.9% случаев вы просто приводите. Однако иногда надо указать другую языковую среду (локаль) — для этого предусмотрен дефолтный аргумент, равный текущей локали. Если бы он не был дефолтным, код бы разросся…
RTTI/Exceptions: если вы заинтересованы в эффективности кода, это не значит, что исключения ВЕЗДЕ неприемлемы. Работает старый принцип 80-20: 80% тормозов находится в 20% кода. Соответственно, 80% всего кода, связанного с исключениями, вряд ли тормозит программу. Можно привести кучу примеров отлично работающего кода, в котором исключения без проблем уживаются. Вообще, с чего ВЫ решаете, какие фичи «правильные», а какие нет? В С++ есть механизм RTTI и исключений — и он ничуть не менее «родной» для этого языка, чем битовые поля или арифметика указателей. Нравится ассемблер — да флаг в руки.
Зачем нужны не-const references? 1) а как вы напишете без этого функцию swap()? 2) а как вы опишете operator<< для ostream? (да и любая аналогичная перегруженная операция)?
Дефолтные параметры тоже иногда полезны. Посмотрите примеры из Boost/STL — их просто надо использовать с умом.
Например, есть такая функция boost::to_lower() — приводит строку к нижнему регистру. В 99.9% случаев вы просто приводите. Однако иногда надо указать другую языковую среду (локаль) — для этого предусмотрен дефолтный аргумент, равный текущей локали. Если бы он не был дефолтным, код бы разросся…
RTTI это бинарный свитч. либо будет, увеличивая стоимость обьектов либо нет. Вы не можете выключить его для 20% кода.
Лично меня бесит когда простейшие программы занимает мегабайты. Потому что пишут её такие люди, которым посрать на какие-то там 20%.
Может потому что я привык бороться за миллисекунды и килобайты…
>>Вообще, с чего ВЫ решаете, какие фичи «правильные», а какие нет?
Для своей программы я волен выбирать сам. Разве нет?
Google, как заказчик, тоже вправе выбирать каким образом будет написана та или иная ИХ программа.
Посему сам вопрос обсуждения их конвеншенов является неправомерным.
Лично меня бесит когда простейшие программы занимает мегабайты. Потому что пишут её такие люди, которым посрать на какие-то там 20%.
Может потому что я привык бороться за миллисекунды и килобайты…
>>Вообще, с чего ВЫ решаете, какие фичи «правильные», а какие нет?
Для своей программы я волен выбирать сам. Разве нет?
Google, как заказчик, тоже вправе выбирать каким образом будет написана та или иная ИХ программа.
Посему сам вопрос обсуждения их конвеншенов является неправомерным.
Причём тут бинарный свитч? Если объект не содержит виртуальных функций, для него RTTI в принципе не работает. Если же содержит, вы уже имеете данные накладные расходы.
По поводу — кто решает, тут вы правы, решает заказчик. Мне действительно плевать, занимает программа «Hello, world» пять килобайт или пять мегабайт — это не техническое, а бизнес-решение. Если заказчик хочет пять килобайт и готов потратить на разработку два месяца работы — да не проблема, он за это и платит. Если другой заказчик хочет решение за неделю и готов смириться с раздутой и менее быстрой программой — это тоже его право. Я всего лишь следую его пожеланиям :)
По поводу — кто решает, тут вы правы, решает заказчик. Мне действительно плевать, занимает программа «Hello, world» пять килобайт или пять мегабайт — это не техническое, а бизнес-решение. Если заказчик хочет пять килобайт и готов потратить на разработку два месяца работы — да не проблема, он за это и платит. Если другой заказчик хочет решение за неделю и готов смириться с раздутой и менее быстрой программой — это тоже его право. Я всего лишь следую его пожеланиям :)
Ваши +-20% могут быть важны для «фиксированной железки», но ведь не весь же мир вокруг вашей задачи крутится. Преимущества от RTTI вполне могут перевешивать 20% проседание производительности.
Как вариант, оттуда же — You may use a using-declaration anywhere in a .cc file, and in functions, methods or classes in .h files.
Лучший способ испортить себе репутацию — это написать гайдлайн для С++. Это такой волшебный язык, где любое средство рано или поздно «выстреливает» так, что все гайдлайны надо переписывать.
Пример. По всем учебникам, которые я читал, препроцессор — это рудимент С, ужос-ужос, который надо забыть как страшный сон.
А теперь вышел Boost.Preprocessor, и люди начинают понимать, что использовать его с умом для метапрограммирования очень здорово и замечательно.
Пример. По всем учебникам, которые я читал, препроцессор — это рудимент С, ужос-ужос, который надо забыть как страшный сон.
А теперь вышел Boost.Preprocessor, и люди начинают понимать, что использовать его с умом для метапрограммирования очень здорово и замечательно.
«using namespace» действительно помогает упростить код.
Но есть один минус — эту конструкцию ни в коем случае нельзя использовать в заголовочных файлах! Только в .cpp. Иначе незаметно сложится ситуация, когда порядок включения заголовочных файлов будет влиять на работу программы.
Но есть один минус — эту конструкцию ни в коем случае нельзя использовать в заголовочных файлах! Только в .cpp. Иначе незаметно сложится ситуация, когда порядок включения заголовочных файлов будет влиять на работу программы.
Да, не спорю. Я вообще его стараюсь избегать даже в .cpp в global scope. А вот в block scope эта конструкция весьма к месту, особенно для имплементации шаблонных методов / функций — там без этого (и без typedef) черт ногу сломит.
Именно поэтому в хидерах всегда будет куча гуано, подобного тому, что в примере.
меня смущает другое. При написанни программы длинней сотни строк время потраченное на выписывание foo:: стремится к нулю. Куда больше усилий требуется на создание абстракций, структур классов, на отладку наконец.
Вопрос не в написании, а в чтении.
Все эти «foo» нужны компилятору, а не программисту.
Все эти «foo» нужны компилятору, а не программисту.
Часто «foo::» очень помогает разобраться в чужом коде. А то видишь вызов метода, и хрен поймёшь, из какого он класса. На DE положиться в этом вопросе тоже не всегда получается.
Нет я не о нейспейсах. Для человека
foo::Foo* myFoo = new foo::Foo(bla, bla);
Означает то же что и
myFoo = new foo::Foo(bla, bla);
Тип переменной выводится из конструктора. То же касается указания типа параметров.
Самая жесть — отдельные секции описания и реализации. Это никак не DRY со всеми вытекающими.
Хуже может быть только C++ с венгерской нотацией. Бессмысленно и беспощадно.
HRESULT hResult = someCall();
foo::Foo* myFoo = new foo::Foo(bla, bla);
Означает то же что и
myFoo = new foo::Foo(bla, bla);
Тип переменной выводится из конструктора. То же касается указания типа параметров.
Самая жесть — отдельные секции описания и реализации. Это никак не DRY со всеми вытекающими.
Хуже может быть только C++ с венгерской нотацией. Бессмысленно и беспощадно.
HRESULT hResult = someCall();
вот как Гугл напишет что-нибудь существенное на Go, например кодер/декодер их WebM, тогда и посмотрим. А пока Go – прикольный язык на посмотреть
Я бы предложил дяденьке попробовать автоматизировать производство (в смысле производственное предприятие, где нужно работать с большим кол-вом различных датчиков, приводов и т.д.) на его любимом языке пусть то Javascript, Python, Ruby и т.д., да хоть .NET. Пусть на них попишет для микроконтроллеров, через которые пролетает гигантские потоки данных и им надо успевать обрабатывать и т.д.
Может быть и сложно писать, но сложным это делается в кривых руках, а если язык знаешь, то проблем и не ощущаешь.
Может быть и сложно писать, но сложным это делается в кривых руках, а если язык знаешь, то проблем и не ощущаешь.
Вот статья про завод Foxconn, статья в общем то не в тему, но оттуда цитата:
Не могу не отметить для здешних пуристов и интеллектуалов: софт, который управлял линией стоимостью в 140 миллионов долларов был написан… [барабанная дробь] на С# (ну это так, лирика).Цитата как раз про производство с большим кол-вом различных датчиков, приводов и т.д. Там дальше в комментариях подробнее, если интересно.
«сложным это делается в кривых руках» — так считают те, кто не работал с другими языками. Это по собственному опыту :) Когда я изучал C#, я плевался на него. Когда я изучил его, я стал плеваться на C++. Когда изучил AS3, иногда стал плеваться даже на C# :)
«а если язык знаешь, то проблем и не ощущаешь» — если не пишешь на нем, то да. А когда приходится писать на C++ кучу кода для того, что на других языках гораздо компактнее, когда паришься с системой глобальных инклюдов (все нормальные языки используют только локальные)… Когда нужно в хидер добавлять то, что написал а cpp-шнике… Когда много чего еще… То думаешь, что тратишь силы и жизнь на рутину, которую должен выполнять компьютер, но не человек :)
«а если язык знаешь, то проблем и не ощущаешь» — если не пишешь на нем, то да. А когда приходится писать на C++ кучу кода для того, что на других языках гораздо компактнее, когда паришься с системой глобальных инклюдов (все нормальные языки используют только локальные)… Когда нужно в хидер добавлять то, что написал а cpp-шнике… Когда много чего еще… То думаешь, что тратишь силы и жизнь на рутину, которую должен выполнять компьютер, но не человек :)
Во многом согласен с тем что растёт количество «шума» в коде.
Как бы то ни было, не во всём остальном я согласен…
Как бы то ни было, не во всём остальном я согласен…
Стоит ли в вопросах языков программирования доверять человеку без бороды? ;)
Нужно было добавить во фразу — «Роб Пайк стоял у истоков Unix, Plan 9, Inferno и UTF-8.», что он ещё стоял и у истоков Go. :)
Ждемс ide для go.
интересное название
Go (ogle)?
Go (ogle)?
Интересно как язык C получил свою популярность. Просто взяли и написали Unix и сказали, что если хотите что-то поменять — изучайте сей язык? Интересно что в современном мире можно написать на Go или каком-либо другом языке чтобы он пошел в массы? И что интересно из него выйдет через 20 лет… Язык довольно интересный, я его попробовал использовать, только под мои задачи он не подошел.
А мнее С++ всегда нравился свой так называемой сложностью.
Лучше разгребать переплетения меташаблонов чем косить мобов в подземельях.
Лучше следить за разворачиваниваем циклов и красотой сцепки динамески загружаемых классов.
Лучше биться башкой об эти переменые, которые почему-то не меняют свой тип по моему хотению, и насладаться когда они всетаки начинают это делать магией буста.
Вот такое у меня извращеное чувство прекрастного
Лучше разгребать переплетения меташаблонов чем косить мобов в подземельях.
Лучше следить за разворачиваниваем циклов и красотой сцепки динамески загружаемых классов.
Лучше биться башкой об эти переменые, которые почему-то не меняют свой тип по моему хотению, и насладаться когда они всетаки начинают это делать магией буста.
Вот такое у меня извращеное чувство прекрастного
мсье знает толк в извращениях
Полностью согласен. Плюсы не прощают ошибок в дизайне, поэтому некоторым кажутся сложными.
Плюсы де-факто сложные. А сложные из-за просчетов в дизайне языка.
Сложные? Врядли. Зависит от подмножества, которое вы используете. В системном программировании — используется лишь мелкая часть и тут все просто. Но если же вы хотите джедайствовать в стиле Александреску…
У C++ нет подмножества. Это цельный ЯП. STL является неотъемлемой частью языка, как и шаблоны. Если нет STL или шаблонов, то это уже «недоC++».
В вас заговорил адепт языка. Вы уж извините, но иначе как подмножеством С++ Embedded C++ не называют. Не надо цепляться к словам :)
Мы про C++ или про Embedded C++?
Тема была про C++. НедоС++ не рассматривали. Хотя даже там все очень плохо в плане дизайна языка.
Есть две вещи, которые больше всего не нравятся в плюсах:
1) глобальные инклюды
2) необходимость заголовочных файлов
Если от этих вещей избавиться, то можно было бы более-менее нормально пользоваться языком.
Тема была про C++. НедоС++ не рассматривали. Хотя даже там все очень плохо в плане дизайна языка.
Есть две вещи, которые больше всего не нравятся в плюсах:
1) глобальные инклюды
2) необходимость заголовочных файлов
Если от этих вещей избавиться, то можно было бы более-менее нормально пользоваться языком.
Мы говорим о C++ как о языке, безотносительно стандартов и придирки к словам. Embedded C++ тут как пример.
О чем была мысль: вы можете программировать на С с классами и не знать всех проблем С++, но также вы можете попытаться стать докой проектирования на шаблонах и испытать все проблемы С++.
С++ сложен в общем, но совершенно прост если вы не используете все его возможности.
О чем была мысль: вы можете программировать на С с классами и не знать всех проблем С++, но также вы можете попытаться стать докой проектирования на шаблонах и испытать все проблемы С++.
С++ сложен в общем, но совершенно прост если вы не используете все его возможности.
Я использую его в игрострое, там невозможно не пользоваться шаблонами, по крайней мере по той причине, что замены для STL нет.
А вы пользуетесь именно недоC++, и дело не в придирках. C++ без шаблонов — это уже не C++, это lightC++, notC++ или что-то еще.
Скажем так, несмотря на ужасность шаблонов, без них в текущем виде от С++ вообще нет толку.
А вы пользуетесь именно недоC++, и дело не в придирках. C++ без шаблонов — это уже не C++, это lightC++, notC++ или что-то еще.
Скажем так, несмотря на ужасность шаблонов, без них в текущем виде от С++ вообще нет толку.
Вы преувеличиваете всю глубину проблемы. В подавляющем большинстве проектов шаблоны используются только в рамках STL и сопутствующих библиотек, ни о каком дизайне и речи не идет.
Касательно меня — я использую С в WDK, Embedded C++ в IOKit на OS X и VxWorks, и самый обычный C++ в пользовательских утилитах. И да, мы проектируем приложения по принципу KISS.
Касательно меня — я использую С в WDK, Embedded C++ в IOKit на OS X и VxWorks, и самый обычный C++ в пользовательских утилитах. И да, мы проектируем приложения по принципу KISS.
Я не преувеличиваю. Без шаблонов нет STL, без STL нет даже встроенного строкового типа, не говоря уже о контейнерах.
Вашими утверждениями можно дойти до того, что Java — это тоже C++, только упрощенный/улучшенный.
Вашими утверждениями можно дойти до того, что Java — это тоже C++, только упрощенный/улучшенный.
И когда вы начинаете использовать контейнеры STL, вы автоматически начинаете использовать шаблоны C++.
О, не вы один такой. В это есть какая-то особая прелесть. А уж когда отправляешь вижак в internal compiler error испытываешь ни с чем не сравниемое чувство собственного могущества :)
Расскажите это своему менеджеру, а лучше сразу заказчикам :)
Имхо, как бы не было противно, но часто стоит делать работу и добиваться результата, а не разбираться в красоте (часто, чужого) кода.
Хотя красоту плюсов тоже понимаю.
Хотя красоту плюсов тоже понимаю.
Эритик!
Метапрограммирование тоже разным бывает — взляните на nemerle с его макросами.
Периодически то в C++, то в C#.
Кратко это выглядит так:
C# — если вам нужно сделать действие, то вы его делаете.
C++ — если вам нужно сделать действие, то вы: подготавливаетесь к действию, делаете действие, убираете за собой. Компилите, не компилится. Вспоминаете, что забыли что-то изменить в заголовочном файле, меняете это. После этого изменения время компиляции вырастает в два раза. Вы разбираетесь с этим, выносите некоторые определения в отдельный класс (на который нужно создать файл и поставить его под контроль), после этого время компиляции возвращается к прежнему значению. Теперь вы наслаждаетесь красотой своего кода :)))
Конечно это пример «худшего случая», но на C# такой случай практически невозможен.
Кратко это выглядит так:
C# — если вам нужно сделать действие, то вы его делаете.
C++ — если вам нужно сделать действие, то вы: подготавливаетесь к действию, делаете действие, убираете за собой. Компилите, не компилится. Вспоминаете, что забыли что-то изменить в заголовочном файле, меняете это. После этого изменения время компиляции вырастает в два раза. Вы разбираетесь с этим, выносите некоторые определения в отдельный класс (на который нужно создать файл и поставить его под контроль), после этого время компиляции возвращается к прежнему значению. Теперь вы наслаждаетесь красотой своего кода :)))
Конечно это пример «худшего случая», но на C# такой случай практически невозможен.
Ох… Рендеринг от C++ уже слабо зависит.
Да и скорости не хватает только в определенном типе приложений. Многим приложениям современных скоростей, даже на C#, за глаза хватает.
Да и скорости не хватает только в определенном типе приложений. Многим приложениям современных скоростей, даже на C#, за глаза хватает.
Еще раз напоминаю про «определенный тип приложений»: это игры, сильно завязанные на графику (для них часто и программная часть сложная, приходится выжимать максимум). И казуальные игры. Последние давно бы уже писали на C#, если бы не нужно было тянуть .NET Framework. Но и их уже пишут и на C#, Java, Python.
«И почему же тогда 90% DirectX приложений написаны на С++, ума не приложу»
Статистику в студию пожалуйста.
«И почему же тогда 90% DirectX приложений написаны на С++, ума не приложу»
Статистику в студию пожалуйста.
Из D тоже можно было бы выжать «максимум», будь он популярен.
«Да, статистики я привести не могу. Кроме как взять список популярных 2D и 3D движков (как коммерческих, так и не) и посмотреть, на каких языках они написаны.»
И это ни о чем не скажет. Не всякий движок часто используется, и многие движки имеют «обертки» для Java, Python и C#.
«Да, статистики я привести не могу. Кроме как взять список популярных 2D и 3D движков (как коммерческих, так и не) и посмотреть, на каких языках они написаны.»
И это ни о чем не скажет. Не всякий движок часто используется, и многие движки имеют «обертки» для Java, Python и C#.
Что то вы в первом предложение не то сказали.
Да, Графика делается видеокартой на 99%, от програмиста надо только подготовить сырые данные и скормить ей.
Подготовить и скормить — не сложно.
В отведеное время посчитать физику( ой, забыл она же опять на видео карте), направить толпу монстров в нужную строну…
Ой, я еще забыл уточнить что данные видеокарте надо кормить в «сыром виде» битиков и байтиков с правильным выраниванием
Те в том виде что из java и С# не доступен «просто так»( и именно это убирает весь гемор на задние планы )
Эх, никогда не забуду как одна маленькая конкатенация строя убила FPS на треть…
Да и самое главное не надо забывать — графика это МЕНЬШАЯ часть приложения
Да, Графика делается видеокартой на 99%, от програмиста надо только подготовить сырые данные и скормить ей.
Подготовить и скормить — не сложно.
В отведеное время посчитать физику( ой, забыл она же опять на видео карте), направить толпу монстров в нужную строну…
Ой, я еще забыл уточнить что данные видеокарте надо кормить в «сыром виде» битиков и байтиков с правильным выраниванием
Те в том виде что из java и С# не доступен «просто так»( и именно это убирает весь гемор на задние планы )
Эх, никогда не забуду как одна маленькая конкатенация строя убила FPS на треть…
Да и самое главное не надо забывать — графика это МЕНЬШАЯ часть приложения
99% начинающих геймдевелоперов согласятся с вами.
99% продвинутых геймдевелоперов скажут что они вообще-то делают игры а не демосцены( хотя вот в них програминга больше чем графики, особенно если 64к)
Да почти год делались тени для Дальнобойшиков, хрен знает сколько альбедо для халфы, но ИМХО потому что придумать технологию на было — сейчас все это так… банальность…
А 99% игроков которым хотя бы за 25( те 10-15-20 лет стажа играния) скажут что, вообще-то, не в графике дело.
А в кризисе да — графика конечно самая ресурсоемкая часть, а вот по коду, я так думаю 10-15% от всего.
Расчет скелетов, оклюжена и других интерсекшенов и проверок видимости — не графика.
(пс: я не гейм девелопер, но я наступал на грабли в пункте 1)
99% продвинутых геймдевелоперов скажут что они вообще-то делают игры а не демосцены( хотя вот в них програминга больше чем графики, особенно если 64к)
Да почти год делались тени для Дальнобойшиков, хрен знает сколько альбедо для халфы, но ИМХО потому что придумать технологию на было — сейчас все это так… банальность…
А 99% игроков которым хотя бы за 25( те 10-15-20 лет стажа играния) скажут что, вообще-то, не в графике дело.
А в кризисе да — графика конечно самая ресурсоемкая часть, а вот по коду, я так думаю 10-15% от всего.
Расчет скелетов, оклюжена и других интерсекшенов и проверок видимости — не графика.
(пс: я не гейм девелопер, но я наступал на грабли в пункте 1)
Таких приложений очень много. Приведу пару примеров из моего опыта работы — распознавание образов для промышленных роботов, и энтерпрайз бэкап. Что тут, что там даже выигрыш в некоторых операциях в пару десятков миллисекунд является существенным достижением. При этом изза объемов кода С там использовать уже неуместно.
Также сюда можно отнести субд, серверные приложения рассчитанные на огромное количество транзакций и т.д. и т.п.
Также сюда можно отнести субд, серверные приложения рассчитанные на огромное количество транзакций и т.д. и т.п.
«При этом изза объемов кода С там использовать уже неуместно.» А можно про это по подробнее?
Вот в ядре ликуса кода тоже много, но им уместно использовать чистый Си.
Вот в ядре ликуса кода тоже много, но им уместно использовать чистый Си.
Вот поэтому там сейчас черт ногу сломит. Если бы в то время когда появился юникс существовал С++ думаю на нем бы и писали. А сейчас уже никуда не денешься (ну и не стоит забывать странную неприязнь к нему Торвальдса).
К примеру, в последнем проекте где я работал, над энтерпрайз бэкапом, любой бранч занимал порядка 5 гигабайт, чистых исходников. И это только для одного продукта. Если бы это все было на С… я даже не представляю как можно было бы в этом разобраться, и сколько бы времени занимала разработка. Там же немерено всего — поддержка всех файловых систем, централизованное хранилище, дедупликация, несколько баз данных, десятки потоков, черт знает что еще.
К примеру, в последнем проекте где я работал, над энтерпрайз бэкапом, любой бранч занимал порядка 5 гигабайт, чистых исходников. И это только для одного продукта. Если бы это все было на С… я даже не представляю как можно было бы в этом разобраться, и сколько бы времени занимала разработка. Там же немерено всего — поддержка всех файловых систем, централизованное хранилище, дедупликация, несколько баз данных, десятки потоков, черт знает что еще.
Много, но меньшинтво, улавливаете разницу?
Но как для таких «ресурсоемких» приложений на подходе есть новые языки, которые удобнее С++ и такие же мощные. Это упоминавшийся D (если бы его взял гугл под крыло...), и, возможно в будущем, Go.
Но как для таких «ресурсоемких» приложений на подходе есть новые языки, которые удобнее С++ и такие же мощные. Это упоминавшийся D (если бы его взял гугл под крыло...), и, возможно в будущем, Go.
www.ffconsultancy.com/languages/ray_tracer/comparison.html
не для холивара и подпитки спора, просто дополнение
не для холивара и подпитки спора, просто дополнение
«Я говорю о том, что во многих случаях это плохо».
В большинстве случаев — это ХОРОШО!
Кстати игры на C# пишут, особенно для XBOX360. Если бы не необходимость тащить за собой фреймворк, то игр на C# было бы гораздо больше.
Драйвера не пишут, потому что C# для этого не предназначен (он работает в вирутальной машине и не имеет прямого доступа к железу).
В большинстве случаев — это ХОРОШО!
Кстати игры на C# пишут, особенно для XBOX360. Если бы не необходимость тащить за собой фреймворк, то игр на C# было бы гораздо больше.
Драйвера не пишут, потому что C# для этого не предназначен (он работает в вирутальной машине и не имеет прямого доступа к железу).
На XNA не крупные тайтлы пишут, а инди-игры. Не путайте. На любой приставке топовые тайтлы будут писать на С++, потому что железо у них довольно ограниченное и особенное, приходится часто извращаться (особенно на PS3).
«Уж поверьте, если бы для игры, занимающей DVD-диск, требовался бы .net, то проблемой бы это не стало.»
Есть какие-то игры, которые его с собой так и тащат. Но сколько их — who knows.
«Уж поверьте, если бы для игры, занимающей DVD-диск, требовался бы .net, то проблемой бы это не стало.»
Есть какие-то игры, которые его с собой так и тащат. Но сколько их — who knows.
>> Драйвера не пишут, потому что C# для этого не предназначен (он работает в вирутальной машине и не имеет прямого доступа к железу).
Смотря где. Вот, например, в Singularity, на c# написана практически вся ОС за вычетом кусков на асме. ru.wikipedia.org/wiki/Microsoft_Singularity
Смотря где. Вот, например, в Singularity, на c# написана практически вся ОС за вычетом кусков на асме. ru.wikipedia.org/wiki/Microsoft_Singularity
Пардон, но кесарю — кесарево. Давайте еще обсудим тут, что верстальщики — это не программисты. Программисты же. Я бы посмотрел, как бы работала какая-нибудь сетевая игра на С#, если бы разработчик драйвера сетевой карты не знал бы таких мелочей, как calling convention и т.д.
>> А действительно интересные для программиста задачи
Есть мнение, что ДЕЙСТВИТЕЛЬНО интересные для программиста задачи, это использовать возможности железа на полную катушку.
Есть мнение, что ДЕЙСТВИТЕЛЬНО интересные для программиста задачи, это использовать возможности железа на полную катушку.
Это ваше исключительно частное мнение. Не стоит считать, что хоть немного заметное в общей массе количество программистов его разделяет.
Поэтому то все те программы, подобные тем, что летали 10 лет назад, сейчас умудряются тормозить имея в 100 раз больше ресурсов.
Глупости говорите.
Тормозят програмы вовсе не от того, что программисты не озабочены поголовно выдавливанием всего что можно из железа. Любит народ примитивизировать всё.
Тормозят програмы вовсе не от того, что программисты не озабочены поголовно выдавливанием всего что можно из железа. Любит народ примитивизировать всё.
И, кстати, 10 лет назад озабоченных выжиманием производительности было ничуть не больше чем сейчас. Так что ваши выводы просто смешны.
Нет, не более оптимальный, а тот, который хорошо ложится на железо.
Например какая-нибудь сортировка на GPU будет менее оптимальной с точки зрения затраченных ресурсов, но лучше подходит к архитектуре чипа, достигая большего быстродействия.
Например какая-нибудь сортировка на GPU будет менее оптимальной с точки зрения затраченных ресурсов, но лучше подходит к архитектуре чипа, достигая большего быстродействия.
Да пожалуйста. Если напишете транслятор =)
Просто GPU очень чувствительны к низкоуровневым вещам, таким как распределение данных по банкам памяти. И производительность тут отличается в разы и десятки раз.
А что за более сложные вещи? Любой «сложный» алгоритм состоит из элементарных операций. Если они медленно выполняются, то ваш «оптимальный» алгоритм гроша ломаного не стоит.
Просто GPU очень чувствительны к низкоуровневым вещам, таким как распределение данных по банкам памяти. И производительность тут отличается в разы и десятки раз.
А что за более сложные вещи? Любой «сложный» алгоритм состоит из элементарных операций. Если они медленно выполняются, то ваш «оптимальный» алгоритм гроша ломаного не стоит.
Нет, вы не правы. C++ дает полную свободу действий, C# — предлагает удобные инструменты для реализации данной свободы.
>Но такое очищение убивает замечательные вещи вроде метапрограммирования.
в С++ метапрограммирование настолько через жопу сделано, что аж страшно становится. Посмотрите хотя-бы на Руби.
в С++ метапрограммирование настолько через жопу сделано, что аж страшно становится. Посмотрите хотя-бы на Руби.
«Я скажу всем, до чего довел планету этот фигляр БГ! Сишники паскалистам на голову сели...»
Он прав, если бы не stl (которую многие тоже не жалуют), то с++ был бы очень кривым велосипедом.
Я вообще не хочу использовать stl и с++. К счастью, мне и не надо)
Вы здесь немного пристрастны к STL. Да, надо знать, что vector может скопировать все содержимое при росте размера, а list не будет.
Но это не какие-то детали работы, а особенности, явно прописанные в спецификации.
Точно так же библиотека для работы с БД, хоть и изолирует пользователя от деталей, но не факт, что полностью. Допустим, после нескольких минут бездействия следующее обращение может занимать больше времени за счет того, что придется восстанавливать соединение.
Или взять Dictionary в C# — их работу легко можно замедлить на порядки, если неудачно переопределить получение хэша у ключей. Но для того, чтобы найти эту ошибку, не надо лезть в исходники стандартных библиотек, все описано в документации. Так же и с контейнерами STL.
Но это не какие-то детали работы, а особенности, явно прописанные в спецификации.
Точно так же библиотека для работы с БД, хоть и изолирует пользователя от деталей, но не факт, что полностью. Допустим, после нескольких минут бездействия следующее обращение может занимать больше времени за счет того, что придется восстанавливать соединение.
Или взять Dictionary в C# — их работу легко можно замедлить на порядки, если неудачно переопределить получение хэша у ключей. Но для того, чтобы найти эту ошибку, не надо лезть в исходники стандартных библиотек, все описано в документации. Так же и с контейнерами STL.
>Да, надо знать, что vector может скопировать все содержимое при росте размера, а list не будет.
Но это не какие-то детали работы, а особенности, явно прописанные в спецификации.
Я бы даже сказал, что это особенность не STL, а самих структур данных. И для понимания физики процесса знать STL совершенно необязательно.
Но это не какие-то детали работы, а особенности, явно прописанные в спецификации.
Я бы даже сказал, что это особенность не STL, а самих структур данных. И для понимания физики процесса знать STL совершенно необязательно.
я бы удивился если бы он про ASP так распинался!
эээ,
а кто-нибудь мне может на пальцах объяснить, почему С++ — сложный? Все повторяют эту фразу как мантру, однако никто еще не привел убедительных доказательств…
а кто-нибудь мне может на пальцах объяснить, почему С++ — сложный? Все повторяют эту фразу как мантру, однако никто еще не привел убедительных доказательств…
вы кроме С++ знаете какой-нибудь другой язык?
#include using std::cout;
using std::endl;
struct A {
virtual void f() { cout << "A::f()" << endl;}
};
struct B : virtual A {
virtual void f() { cout << "B::f()" << endl;}
};
struct C : B , virtual A {
using A::f;
};
void foo() {
C c;
c.f(); //calls B::f, the final overrider
c.C::f(); //calls A::f because of the using-declaration
}
Отправилось раньше времени блин.
В общем приведенный пример, как по мне, совершенно нелогичен и неинтуитивен. Я вам даже больше скажу, g++ его неправильно компилит (по версии g++ будет оба раза A::f()). Слава всем, кому только можно, такое в реальной жизни почти никогда не встречается.
А если мы начнем рассматривать правила разрешения перегрузки, когда у нас функции в разных неймспейсах, или порядок инстанциации шаблонов, вам С++ уж точно лёгким не покажется.
В общем приведенный пример, как по мне, совершенно нелогичен и неинтуитивен. Я вам даже больше скажу, g++ его неправильно компилит (по версии g++ будет оба раза A::f()). Слава всем, кому только можно, такое в реальной жизни почти никогда не встречается.
А если мы начнем рассматривать правила разрешения перегрузки, когда у нас функции в разных неймспейсах, или порядок инстанциации шаблонов, вам С++ уж точно лёгким не покажется.
— Доктор, когда я кончиком языка касаюсь комочка фольги, в котором ранее запекали картошку, у меня покалывает за левым ухом. Что это значит?
— Это значит, что у Вас слишком много свободного времени.
Приведённый Вами пример — из той же оперы. Если кто-то напишет что-то подобное в реальном коде, его просто обязаны выгнать нахрен из профессии с волчьим билетом (либо за профнепригодность, либо за саботаж — в зависимости от причин, побудивших его написать такое).
Задачи, где требовался бы подобный код, не существует. А если кто-то думает, что такая задача существует, то он патологически неспособен к дизайну ПО.
P.S.: "требовался" — ключевое слово, и оно не может быть заменено на «допускался» или «мог быть использован» без искажения смысла высказывания.
— Это значит, что у Вас слишком много свободного времени.
Приведённый Вами пример — из той же оперы. Если кто-то напишет что-то подобное в реальном коде, его просто обязаны выгнать нахрен из профессии с волчьим билетом (либо за профнепригодность, либо за саботаж — в зависимости от причин, побудивших его написать такое).
Задачи, где требовался бы подобный код, не существует. А если кто-то думает, что такая задача существует, то он патологически неспособен к дизайну ПО.
P.S.: "требовался" — ключевое слово, и оно не может быть заменено на «допускался» или «мог быть использован» без искажения смысла высказывания.
Если кто-то напишет что-то подобное в реальном коде, его просто обязаны выгнать нахрен из профессии с волчьим билетом (либо за профнепригодность, либо за саботаж — в зависимости от причин, побудивших его написать такое).Ну это всё же не совсем правильно, выгонять из профессии за то, что используешь в коде примеры из стандарта. Вообще, если вашу мысль развить, то надо запретить вообще множественное наследование, а за ним и шаблоны (и может быть исключения). Потом запретить указатели (не все их понимают) и получить Паскаль.
>Ну это всё же не совсем правильно, выгонять из профессии за то, что используешь в коде примеры из стандарта.
Прошу прощения за каламбур, но тот факт, что что-то можно использовать («можно» в смысле «технически возможно»), ещё не говорит о том, что это можно использовать («можно» в смысле «разрешается»).
Блин, по-английски проще: if you can do something it doesn't mean you may do it.
Конструкция кухонного ножа тоже предусматривает много «интересных» ему применений, но это не является достаточным основанием для того, чтобы применять его именно таким образом.
>Вообще, если вашу мысль развить....
Если любую мысль «развить», то можно свести к абсурду всё, что угодно.
А мысль сама по себе проста: промышленный код должен писаться так, чтобы он был в первую очередь читаемым и понятным. Чтобы человек уровня «средний программист в компании», увидевший код первый раз в жизни, через 2 минуты мог догадаться, что и как этот код делает. Компаний, где средний программист сходу правильно ответит, что и [самое главное] как делает приведённый Вами код, далеко не так много, как хотелось бы.
Одно из лучших негласных правил, порождающих хороший код — «пиши код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где ты живешь».
P.S.: ни в коем случае не претендую на «истину в последней инстанции», каждый волен писать так, как считает нужным. Чем больше «фокусников», пишущих такие вот заковыристые конструкции, тем более ценным будут те, кто думает и пишет иначе.
Прошу прощения за каламбур, но тот факт, что что-то можно использовать («можно» в смысле «технически возможно»), ещё не говорит о том, что это можно использовать («можно» в смысле «разрешается»).
Блин, по-английски проще: if you can do something it doesn't mean you may do it.
Конструкция кухонного ножа тоже предусматривает много «интересных» ему применений, но это не является достаточным основанием для того, чтобы применять его именно таким образом.
>Вообще, если вашу мысль развить....
Если любую мысль «развить», то можно свести к абсурду всё, что угодно.
А мысль сама по себе проста: промышленный код должен писаться так, чтобы он был в первую очередь читаемым и понятным. Чтобы человек уровня «средний программист в компании», увидевший код первый раз в жизни, через 2 минуты мог догадаться, что и как этот код делает. Компаний, где средний программист сходу правильно ответит, что и [самое главное] как делает приведённый Вами код, далеко не так много, как хотелось бы.
Одно из лучших негласных правил, порождающих хороший код — «пиши код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где ты живешь».
P.S.: ни в коем случае не претендую на «истину в последней инстанции», каждый волен писать так, как считает нужным. Чем больше «фокусников», пишущих такие вот заковыристые конструкции, тем более ценным будут те, кто думает и пишет иначе.
ну вот я о том же. Если у автора предыдущего ответа с помощью бульдозера плохо получилось сделать скамейку, то разве это как-то оправдывает утверждение «бульдозером сложно пользоваться?».
На мой взгляд, С++ — весьма простой и элегантный язык программирования.
На мой взгляд, С++ — весьма простой и элегантный язык программирования.
Спецификация на более чем тысячу страниц. Не очень простой, увы.
Как по мне, сложность языка определяется по сложности реализации компилятора для него.
Как по мне, сложность языка определяется по сложности реализации компилятора для него.
у многих популярных нынче языков вообще нет спецификации. А совместимые реализации делают методом тыка. Может детальная спецификация всех аспектов языка — признак хорошей проработанности и проверенности временем?
Спецификация Java — намного меньше, хоть и столь же формальна. Спецификация ECMAscript вообще крошечная. R5RS так и вовсе мелкий (только R6RS уже испортился, хоть и все равно намного меньше C++).
Я компилятор С++ писал. И компиляторы других языков писал. C++ самый ужасный по сложности и кривости стандарта. Даже парсер, обычно самая банальная часть любого языка, там неимоверно сложен и неоднозначен.
Я компилятор С++ писал. И компиляторы других языков писал. C++ самый ужасный по сложности и кривости стандарта. Даже парсер, обычно самая банальная часть любого языка, там неимоверно сложен и неоднозначен.
а при чем тут парсер и компилятор? В оригинальном топике я попросил мне на пальцах объяснить, почему С++ считается сложным языком. Вместо этого мне пытаются объяснить, что де сложно сделать компилятор С++. Меня мало волнует и сложность парсера, и ваш опыт в написании компиляторов. мне интересно, почему _язык_ С++ считается сложным. Я считаю, что язык С++ — простой и элегантный. Если я не прав — попробуйте аргументированно опровергнуть.
Да просто:
— написание одного и того же кода на C++ дольше, нежели на любом другом современном языке,
— при этом С++ еще и провоцирует больше ошибок,
— компиляция занимает в РАЗЫ и ДЕСЯТКИ раз больше времени на С++ в сравнении с другими языками
Этого вам недостаточно? Все три условия важны в разработке приложений.
— написание одного и того же кода на C++ дольше, нежели на любом другом современном языке,
— при этом С++ еще и провоцирует больше ошибок,
— компиляция занимает в РАЗЫ и ДЕСЯТКИ раз больше времени на С++ в сравнении с другими языками
Этого вам недостаточно? Все три условия важны в разработке приложений.
пункт 1 и 2 это из разряда холивара, надеюсь вы не будете отрицать, что все от задачи зависит?
пункт 3 — есть такое, но опять же, в отрыве от контекста данное утверждение больше на сферического коня в вакууме похоже.
пункт 3 — есть такое, но опять же, в отрыве от контекста данное утверждение больше на сферического коня в вакууме похоже.
Судя по всему у вас нет опыта профессиональной разработки на других языках. Я не знаю о каком холиваре вы говорите, но я говорю о своем опыте разработки на разных языках. 1 и 2 пункты это самые очевидные (другие языки просто не дают вам выстрелить в ногу случайно, как это делает С++).
Если бы вы занимались реальной разработкой, то знали бы что 3 пункт отнюдь не выдуманный, а вполне реальный, и очень досаждающий.
Если бы вы занимались реальной разработкой, то знали бы что 3 пункт отнюдь не выдуманный, а вполне реальный, и очень досаждающий.
Уж даже не знаю, что на это ответить. У вас, похоже, какое-то своё определение сложности, которое ничего общего не имеет с тем определением, которым оперирует всё остальное человечество.
Язык со сложным синтаксисом не может называться «простым». Язык с перегруженным и неоднозначным синтаксисом не может называться «элегантным». Язык с семантикой, которую надо описывать на 1000 страниц текста, не может быть ни простым ни элегантным.
Скажите — вы видели хотя бы один отличный от C++ язык? Например, Схему в версии R5RS? Вот это — простой и элегантный язык. А C++ — сложный язык. Не на какой-то там абсолютной шкале сложности (сомневаюсь, что такую можно определить), а относительно действительно простых и действительно элегантных языков.
Язык со сложным синтаксисом не может называться «простым». Язык с перегруженным и неоднозначным синтаксисом не может называться «элегантным». Язык с семантикой, которую надо описывать на 1000 страниц текста, не может быть ни простым ни элегантным.
Скажите — вы видели хотя бы один отличный от C++ язык? Например, Схему в версии R5RS? Вот это — простой и элегантный язык. А C++ — сложный язык. Не на какой-то там абсолютной шкале сложности (сомневаюсь, что такую можно определить), а относительно действительно простых и действительно элегантных языков.
а какое у вас определение сложности и почему вы решили, что оно соответствует чему-то, чем оперирует остальное человечество?
Синтаксис С++ ничуть не сложнее и не перегруженнее большинства остальных производных от С языков. Само собой, есть языки с более простым синтаксисом, но это еще не повод называть синтаксис С++ сложным, так ведь? Если вы утверждаете обратное — хотя бы укажите, по каким критериям синтаксис сложен и чем он принципиально от той же джавы по сложности отличается.
Сравнение с «простыми» и «элегантными» языками несколько натянуто. Мне вот лисп не нравится, я его считаю сложным, на таком языке я бы никогда не взялся делать проект.
Мне не нравится синтаксис пролога, но это не повод называть его сложным. Подозреваю, что по вашим общечеловеческим критериям эти языки должны попадать в категорию простых по сравнению С++?
Синтаксис С++ ничуть не сложнее и не перегруженнее большинства остальных производных от С языков. Само собой, есть языки с более простым синтаксисом, но это еще не повод называть синтаксис С++ сложным, так ведь? Если вы утверждаете обратное — хотя бы укажите, по каким критериям синтаксис сложен и чем он принципиально от той же джавы по сложности отличается.
Сравнение с «простыми» и «элегантными» языками несколько натянуто. Мне вот лисп не нравится, я его считаю сложным, на таком языке я бы никогда не взялся делать проект.
Мне не нравится синтаксис пролога, но это не повод называть его сложным. Подозреваю, что по вашим общечеловеческим критериям эти языки должны попадать в категорию простых по сравнению С++?
Понятие о сложности, которым пользуется всё цивилизованное человечество, тесно связано с очень формальным представлением о количестве информации. Вам знакомы такие имена, как Шеннон, Колмогоров, Чейтин?
Язык C++ содержит в себе очень, очень много информации. Работа с этим языком требует от программиста переработки гораздо больших объёмов информации в каждый момент времени, чем практически любой другой язык. Это и называется «сложностью». Ну, знаете, большая буква O, и всё такое.
Синтаксис C++ намного сложнее и перегруженее чем даже синтаксис большинства производных от Си. Например, у Java синтаксис однозначный, разбирается банальным LL-парсером, легко читается с любого места. В результате и программист очень легко читает Java с листа, без перескоков по куче заголовочных файлов с целью узнать, что же такое у нас сегодня, в этом вот месте, оператор "()", и какие там неявные конструкторы копирования вызываются. И IDE получаются очень умными и продвинутыми — легко читая Java-код с любого места, они правильные подсказки программисту дают. Всё это следствие разницы в сложности синтаксиса.
А что вы считаете Лисп сложным — так это ваше субъективное мнение. Мне не интересны субъективные взгляды. Объективно Лисп намного проще чем даже plain C, в нем конструкций меньше, а синтаксиса так мало, что он практически отсутствует. И, да, что Пролог что Лисп — языки намного проще чем C++. Я говорю о некотором собирательном Лиспе, конечно же, а не о толстом монстре Common Lisp, спецификация которого может поспорить по объёму со стандартом C++.
Язык C++ содержит в себе очень, очень много информации. Работа с этим языком требует от программиста переработки гораздо больших объёмов информации в каждый момент времени, чем практически любой другой язык. Это и называется «сложностью». Ну, знаете, большая буква O, и всё такое.
Синтаксис C++ намного сложнее и перегруженее чем даже синтаксис большинства производных от Си. Например, у Java синтаксис однозначный, разбирается банальным LL-парсером, легко читается с любого места. В результате и программист очень легко читает Java с листа, без перескоков по куче заголовочных файлов с целью узнать, что же такое у нас сегодня, в этом вот месте, оператор "()", и какие там неявные конструкторы копирования вызываются. И IDE получаются очень умными и продвинутыми — легко читая Java-код с любого места, они правильные подсказки программисту дают. Всё это следствие разницы в сложности синтаксиса.
А что вы считаете Лисп сложным — так это ваше субъективное мнение. Мне не интересны субъективные взгляды. Объективно Лисп намного проще чем даже plain C, в нем конструкций меньше, а синтаксиса так мало, что он практически отсутствует. И, да, что Пролог что Лисп — языки намного проще чем C++. Я говорю о некотором собирательном Лиспе, конечно же, а не о толстом монстре Common Lisp, спецификация которого может поспорить по объёму со стандартом C++.
И еще — все то, что должен знать о C++ компилятор, должен знать и программист, пишущий на C++. Все эти более тысячи страниц спецификации. То есть, это однозначно сложный язык. Для того, чтобы программировать на простом языке, надо знать и помнить намного меньше. Никаких неявных правил преобразования типов, никаких правил порядка вызова конструкторов, ничего лишнего. Голова у программиста должна быть забита концепциями предметной области, должна прикладные задачи решать, а не помнить многочисленные особенности «простого и элегантного» языка.
Раз так, то напишите для него полноценный парсер и вы поймете что язык очень не простой и совсем не элегантный :)
т.е. вы почему-то считаете, что сложность языка определяется сложностью парсера?
Вы не увиливайте от ответа, сами же сказали, что «С++ — весьма простой и элегантный язык программирования».
Ну раз простой и элегантный, то напишите парсер.
Нет простых языков, со сложными парсерами (обратное возможно).
Ну раз простой и элегантный, то напишите парсер.
Нет простых языков, со сложными парсерами (обратное возможно).
если я считаю автомобиль простым и элегантным способом передвижения, то я обязательно должен сделать его сам, что бы понять, что это сложное и неповоротливое сооружение? Извините, у вас логика хромает.
Повторюсь — я считаю, что язык С++ — простой и элегантный. Проблемы создателей компиляторов меня мало волнуют, как пользователя языка. Точно так же, как простого водителя, меня мало волную проблемы инженеров автоконцернов. Уверен, что с их точки зрения, любой автомобиль — большая и сложная штука. С моей точки зрения это руль, педали, да горловина бензобака.
Улавливаете?
Повторюсь — я считаю, что язык С++ — простой и элегантный. Проблемы создателей компиляторов меня мало волнуют, как пользователя языка. Точно так же, как простого водителя, меня мало волную проблемы инженеров автоконцернов. Уверен, что с их точки зрения, любой автомобиль — большая и сложная штука. С моей точки зрения это руль, педали, да горловина бензобака.
Улавливаете?
Тогда для вас понятнее объясню связь между сложностью парсера и языка.
Парсер — это алгоритм распознавания конструкций языка. Когда вы изучаете язык — у вас в голове формируется алгоритм, который отдаленно напоминает этот самый парсер. Так вот для «элегантных» языков и то и другое происходит просто. Для кривых и монструозных языков алгоритм распознавания будет таким же. Не забывайте — алгоритмы люди придумывают, т.е. это не что-то «только под капотом», это именно в голове.
Но дискутировать на тему удобства языка можно только с человеком, который знает другие языки. Под «знает», как обычно, подразумевается «умеет и использует в рабочих проектах». А не просто «видел».
Парсер — это алгоритм распознавания конструкций языка. Когда вы изучаете язык — у вас в голове формируется алгоритм, который отдаленно напоминает этот самый парсер. Так вот для «элегантных» языков и то и другое происходит просто. Для кривых и монструозных языков алгоритм распознавания будет таким же. Не забывайте — алгоритмы люди придумывают, т.е. это не что-то «только под капотом», это именно в голове.
Но дискутировать на тему удобства языка можно только с человеком, который знает другие языки. Под «знает», как обычно, подразумевается «умеет и использует в рабочих проектах». А не просто «видел».
Конечно, если вы раньше писали на ассемблере, а теперь освоили С++ — он будет вам казаться сказкой.
А если вы после C++ изучили Java, C#, Python, AS3,… То C++ язык не повернется назвать элегантым и уж тем более простым.
А если вы после C++ изучили Java, C#, Python, AS3,… То C++ язык не повернется назвать элегантым и уж тем более простым.
я с вами не соглашусь. Мой опыт говорит об обратном — чем проще программа (не важно какая) для пользователя, тем сложнее она устроена внутри. Поэтому утверждение о том, что сложный парсер автоматически означает сложный язык — на мой взгляд весьма сомнительно, по крайней мере если мы рассматриваем языки примерно одной весовой категории.
И опять же, почему все пытаются объяснить сложность С++ через сложность создания компилятора? Мне, как пользователю, это должно быть фиолетово, мы же язык обсуждаем, а не детали реализации.
Вот как пример (очень упрощенно) — написать ОС с коммандной строкой куда проще, чем ОС с ГУИ, но, надеюсь, вы не будете утверждать, что первый вариант проще для средневзятого пользователя?
И опять же, почему все пытаются объяснить сложность С++ через сложность создания компилятора? Мне, как пользователю, это должно быть фиолетово, мы же язык обсуждаем, а не детали реализации.
Вот как пример (очень упрощенно) — написать ОС с коммандной строкой куда проще, чем ОС с ГУИ, но, надеюсь, вы не будете утверждать, что первый вариант проще для средневзятого пользователя?
Повторю еще раз — пользователь C++ обязан знать все то же самое, что знает компилятор C++.
Вы не очень честно (и, скорее всего, преднамеренно) передергиваете, сопоставляя это с автомобилем или с пользовательским приложением с простым и понятным интерфейсом.
Интерфейс C++ — это весь язык, целиком, со всей его невообразимой сложностью.
Вы не очень честно (и, скорее всего, преднамеренно) передергиваете, сопоставляя это с автомобилем или с пользовательским приложением с простым и понятным интерфейсом.
Интерфейс C++ — это весь язык, целиком, со всей его невообразимой сложностью.
Для водителя автомобиль — это руль, коробка передач и три педали. А язык для программиста — это абсолютно все его конструкции, все особенности его семантики. В языке нет ничего, что можно спрятать под капот, всё торчит наружу. Так что, то, что сложно для компилятора — то сложно и для программиста. Они должны знать про язык одно и то же.
следуя вашей логике, единственные настоящие (разбирающиеся) программисты на С++ (и любом другом языке) — это люди, которые написали компилятор С++ (или любого другого языка)?
Еще раз, повторю — я не спрашиваю про конструкции, нюансы и т.п., я всего лишь прошу объяснить, почему вы считаете С++ сложным языком? Может для начала попробуете хотя бы определиться с самим понятием сложности? Т.е. сложный по отношению к чему например, в каких аспектах и т.п. А то, вот для меня управление танком — сложный процесс, а для механика-водителя прошедшего учебку — простой.
Еще раз, повторю — я не спрашиваю про конструкции, нюансы и т.п., я всего лишь прошу объяснить, почему вы считаете С++ сложным языком? Может для начала попробуете хотя бы определиться с самим понятием сложности? Т.е. сложный по отношению к чему например, в каких аспектах и т.п. А то, вот для меня управление танком — сложный процесс, а для механика-водителя прошедшего учебку — простой.
В том числе и сложностью парсера. Парсер в голове программиста спотыкается на кривых конструкциях еще хуже чем косолапо сделанный захардкоженный парсер в GCC.
И уж тем более нельзя говорить об «элегантности», когда даже синтаксис столь крив.
И уж тем более нельзя говорить об «элегантности», когда даже синтаксис столь крив.
вы бы лучше примеры привели кривого синтаксиса.
Кривость например в том, что даже лексер должен иметь доступ к информации о типах. Синтаксис неоднозначен без семантической информации.
Вот примерчик:
publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=/com.ibm.vacpp7a.doc/language/ref/clrc08cplr403.htm
Вот примерчик:
publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=/com.ibm.vacpp7a.doc/language/ref/clrc08cplr403.htm
это проблемы создателей компиляторов. Я, как опытный программист, приведенные по ссылке примеры читаю («парсю») на ходу «с листа», вы, наверное, тоже. Я не планирую обсуждать с вами проблемы построения компиляторов, мне интересно, почему вы считаете язык С++ сложным?
Вы зачем обманываете? Не парсите вы это с листа, вы не телепат. Это нельзя распарсить, не имея в памяти информации о том, что является типом, а что идентификатором. И чем больше разнообразных определений у вас в контексте, тем сложнее распарсить код на C++, тем больше нерелевантной информации нужно держать в голове только для того, чтобы всего лишь понять, что там написано.
>На мой взгляд, С++ — весьма простой и элегантный язык программирования.
Я тоже так когда-то думал.
Я тоже так когда-то думал.
все программисты на С++ проходят 3 стадии
1) все легко и просто
2) все тяжело и непонятно
3) все легко и просто
вы, видимо, застряли на втором этапе.
1) все легко и просто
2) все тяжело и непонятно
3) все легко и просто
вы, видимо, застряли на втором этапе.
Только 3? Почему не 4 или 8?
Я на C++ пишу где-то так с 1993го. Делал и компилятор С++, и средства для статического анализа кода на C++. Не знаю уж, какая это по счету стадия, но сложно назвать ее иначе как «терпеть не могу этот самый уродливый и криво спроектированный из языков». Статия восторга про «все легко и просто» прошла вообще очень быстро и не возвращалась, потому как параллельно с C++ я писал на Common Lisp.
От того, что я начал понимать сложные конструкции, сам язык проще не становится.
какие вы все серьезные.
Откуда такое странное наследование? Зачем 2 раза от A? Я бы еще понял если бы было struct B: virtual A {};
struct C: virtual A {};
struct D: A, B;
PS Почему в вашем случае должен быть B::f а не A::f, разве они не оба финальные, просто в разных ветвях?
struct C: virtual A {};
struct D: A, B;
PS Почему в вашем случае должен быть B::f а не A::f, разве они не оба финальные, просто в разных ветвях?
Зачем 2 раза от A?Ну хорошо, давайте перепишем код вот так:
struct A {
virtual void f() { cout << "A::f()" << endl;}
};
struct B : virtual A {
virtual void f() { cout << "B::f()" << endl;}
};
struct D : virtual A {
virtual void g() {}
};
struct C : B , virtual D {
using A::f;
};Нам нужно наследовать C и от B и от D. Зачем нужно множественное наследование, я думаю объяснять не нужно.
PS Почему в вашем случае должен быть B::f а не A::f, разве они не оба финальные, просто в разных ветвях?По стандарту (10.3/2, class.virtual/2).
есть такая замечательная книга, Страуструп Б. — Дизайн и эволюция C++, в ней можно найти ответы на все ваши вопросы. Уверяю, для каждого такого, на ваш взгляд «нелогичного» поведения есть вполне простое, разумное и понятное объяснение.
Самое главное, язык С++ не сложный, он просто мульти-парадигменный (это слово надо повторять как мантру :), т.е., говоря русским языком, дизайн языка подразумевает несколько возможных стилей написания программ.
Язык не навязывает программисту какой-либо один стиль, пишите как хотите, используя лишь те конструкции языка, которые вам более всего по душе.
Самое главное, язык С++ не сложный, он просто мульти-парадигменный (это слово надо повторять как мантру :), т.е., говоря русским языком, дизайн языка подразумевает несколько возможных стилей написания программ.
Язык не навязывает программисту какой-либо один стиль, пишите как хотите, используя лишь те конструкции языка, которые вам более всего по душе.
Я полностью согласен со вторым абзацем вашего комментария. Я читал Дизайн и эволюцию. Я неплохо знаю С++. Я программирую на нём 8 лет. Я знаю, что он мульти-парадигменный. Но я всё равно считаю, что язык сложный. У него очень высокий порог вхождения. Для того, чтобы писать без ошибок на С++ нужно знать множество нюансов. На С++ можно писать безопасный код, но на нём очень просто «выстрелить себе в ногу» и для того, чтобы случайно этого не сделать нужно много знать. Для того, чтобы читать шаблонный код на С++ нужно иметь нехилый опыт. Это плата за его гибкость и мощь. Но я всё равно утверждаю, что он сложный.
да просто пишите понятный лично вам код, и не будет никаких проблем. Все почему-то стараются использовать различные фичи и нюансы по-максимуму, забывая о том, что язык — всего лишь инструмент для решения вашей конкретной задачи. Не нравятся шаблоны — да просто не используйте их, на то мультипарадигменность и имеется.
да просто пишите понятный лично вам код, и не будет никаких проблем
Да понимаете, какая ситуация. Мне, например, много чего нравится. Я напишу понятный лично мне код, не с целью происпользовать по максимуму фичи, а потому, что я так вижу. А потом меня по совету Mezomish «выгонят нахрен из профессии с волчьим билетом». Поэтому и получается, что либо писать на С++, но тогда С++ — сложный и понятный только людям с большим опытом, либо писать на C with classes — поймёт кто угодно, даже новичок, но только мы же не про C with classes говорим, а про C++…
Ещё можно почитать «Mein kampf», там тоже объясняется много «нелогичных» эпизодов истории.
" дизайн языка подразумевает несколько возможных стилей написания программ."
Не так. Дизайн языка ничего не подразумевал изначально. Все это в языке появилось в процессе эволюции. А эволюция — штука слепая и беспощадная.
Не так. Дизайн языка ничего не подразумевал изначально. Все это в языке появилось в процессе эволюции. А эволюция — штука слепая и беспощадная.
using System;
using System.Linq;
namespace SampleEvent
{
public delegate void SummResultDelegate(int summ);
class CalculatorCore
{
public event SummResultDelegate SummResultEvent;
public void Summ(params int[] arguments)
{
//Какая нибудь очень долго выполняющаяся функция ...
if (SummResultEvent != null)
{
SummResultEvent(arguments.Sum());
}
}
}
class CalculatorManager
{
public void Run()
{
var calc1 = new CalculatorCore();
calc1.SummResultEvent+=new SummResultDelegate(Calc1SummResultEvent);
calc1.Summ(1,2);
var calc2 = new CalculatorCore();
calc2.SummResultEvent += new SummResultDelegate(Calc2SummResultEvent);
calc2.Summ(5,6,7,8,9,10,12,15,17);
}
void Calc1SummResultEvent(int summ)
{
Console.WriteLine("Обработка результата 1-го калькулятора: {0}", summ);
}
void Calc2SummResultEvent(int summ)
{
Console.WriteLine("Обработка результата 2-го калькулятора: {0}", summ);
}
}
class Program
{
static void Main(string[] args)
{
new CalculatorManager().Run();
Console.ReadKey();
}
}
}
Сильно упрощенный пример, но попробуйте в «несложном С++» написать то же самое не превышая объем хотя бы в 3 раза?
у вас в голове каша, вы путаете язык и его обвес. Я вас могу аналогично попросить, например, сделать быстренько несколько аллокаторов с разными стратегиями. Или, ой, ваш оператор new не позволяет такое делать? Ну извините… :-)
Вряд ли переход на оскорбления делают ваши доводы убедительными. Я всего лишь привел пример из жизни — при чем всего лишь месяц назад — когда мне пришлось портировать приложение с C# на С++ (для новых коммуникаторов Samsung Bada). Задача — перенести приложение — и не важно используете хоть аллокаторы или кашу в Вашей голове. У меня код на С++ получился значительно больше, изначально написание с нуля на C# заняло в 5 раз меньше времени чем последующее портирование, может ваша каша получится меньшего объема? Или, ой, Вы не понимаете что языки используют для решения задач а не для того что бы их использовать ради них самих?
Подойдёт?
PS: Да, я знаю, что std::function не то же самое, что event'ы в шарпе. Но для приведённого примера эти различия не принципиальны.
#include <numeric>
#include <functional>
#include <iostream>
class CalculatorCore
{
public:
std::function<void (int)> SummResultEvent;
void Summ(std::initializer_list<int>&& nums)
{
if (nums.size() != 0)
{
SummResultEvent(std::accumulate(nums.begin(), nums.end(), 0, std::plus<int>()));
}
}
};
class CalculatorManager
{
public:
void Run()
{
CalculatorCore calc1;
calc1.SummResultEvent = std::bind(
&CalculatorManager::Calc1SummResultEvent, this, std::placeholders::_1);
calc1.Summ({1,2});
CalculatorCore calc2;
calc2.SummResultEvent = std::bind(
&CalculatorManager::Calc2SummResultEvent, this, std::placeholders::_1);
calc2.Summ({5,6,7,8,9,10,12,15,17});
}
void Calc1SummResultEvent(int summ)
{
std::cout << "First calculator result: " << summ << std::endl;
}
void Calc2SummResultEvent(int summ)
{
std::cout << "Second calculator result: " << summ << std::endl;
}
};
int main()
{
CalculatorManager().Run();
std::cin.get();
}
PS: Да, я знаю, что std::function не то же самое, что event'ы в шарпе. Но для приведённого примера эти различия не принципиальны.
К сожалению пришлось портировать код на Bada, где единственным языком разработки является С++ и где нет поддержки std::function, да и сами разработчики предоставили в API для работы с асинхронными методами через объекты приемники унаследованные от абстрактных классов (интерфейсов). А так, С++ .NET тоже ничем не уступает C# (если не превосходит), только синтаксис чуть сложнее возможно.
Рискну предположить, что поддержка std::function и многих других вкусных фич включается в Bada SDK с помощью опции компилятора -std=c++0x.
Тем не менее, приведённый мною код не сильно отличается от исходного, предоставленного вами, а реализация функциональности шарповых эвентов (в необходимом для этого примера объёме) увеличит код ещё на десяток строчек.
Тем не менее, приведённый мною код не сильно отличается от исходного, предоставленного вами, а реализация функциональности шарповых эвентов (в необходимом для этого примера объёме) увеличит код ещё на десяток строчек.
К сожалению многие опытные С++ ники (ну или как они сами себя считали) не смогли добиться такого поведения для Bada API. Был бы признателен если бы вы нашли способ сделать это. К тому же к сожалению создатели API не посчитали нужным механизм эвентов и в реализации самого API и для использования API
Ну, я только предположил, что такое может быть возможно. Для точного ответа мне нужен Bada SDK, а это только вечером.
Это лишь говорит об убогости BADA SDK. Юзайте уже блин Qt+gcc, там уж точно std::function есть.
По не совсем понятным для меня причинам сайт самсунга не даёт мне залогиниться. По этому прошивку скачать (пока) не могу, и проверка отменяется…
можно еще вот так
оно должно и на вашей байде завестись
#include <numeric>
#include <functional>
#include <iostream>
template<class CalcMan, void (CalcMan::*ResultEvent)(int)>
class CalculatorCore
{
public:
void Summ(CalcMan* manager, const int* val, int size) const
{
if (size != 0)
{
(manager->*ResultEvent)( std::accumulate(val, val + size, 0, std::plus<int>()) );
}
}
};
class CalculatorManager
{
public:
void Calc1SummResultEvent(int summ)
{
std::cout << "First calculator result: " << summ << std::endl;
}
void Calc2SummResultEvent(int summ)
{
std::cout << "Second calculator result: " << summ << std::endl;
}
void Run()
{
CalculatorCore<CalculatorManager, &CalculatorManager::Calc1SummResultEvent> calc1;
int vals1[] = {1,2};
calc1.Summ(this, vals1, sizeof(vals1)/sizeof(vals1[1]));
CalculatorCore<CalculatorManager, &CalculatorManager::Calc2SummResultEvent> calc2;
int vals2[] = {5,6,7,8,9,10,12,15,17};
calc2.Summ(this, vals2, sizeof(vals2)/sizeof(vals1[2]));
}
};
int main()
{
CalculatorManager().Run();
std::cin.get();
}
оно должно и на вашей байде завестись
Возможно я изначально не так выразился — как я говорил выше — на C++ .NET я бы тоже написал такой же код как и на C# .NET — но очевидно что С++ .NET и С++ «немного» не одно и то же. Я был бы рад увидеть такое поведение как и для С++ бады — в любом случае — сами же разработчики той же Бады не просто так отказались от использования событийных моделей в пользу унаследования от интерфейсов (абстрактных классов) — где для скачивания одной странички в XML недостаточно написать метод который примет результат выполнения — а где надо создавать отдельный объект унаследованный от интерфейса с 8 методами, который и будет принимать результат выполнения операции (скачивания XML) и все остальные события в том же духе
Троллинг становится популярным инструментом самопиара. :)
У меня есть вопрос по Python, который давно меня мучает. У меня есть проект на Python. Возникает необходимость поменять входные параметры некоторой функции. Как определить все места, где она вызывается?
Рекламный звон вокруг инструментов и методов это чума индустрии ПО. Большая часть усовершенствований средств и методов приводит к увеличению производительности и качества примерно на 5–35%. Но многие из этих усовершенствований были заявлены как дающие преимущество
«на порядок».
У нас могут быть и языки четвертого поколения («программирование без программистов»), и средства CASE («автоматизация программирования»), и объектно: ориентированная методология («лучший путь построения ПО»), и экстремальное программирование («будущее отрасли»), и какое угодно другое новомодное достижение. Но все эти подходы, каким бы звоном ни сопровождались их представление и продвижение, не так уж сильно увеличивают наши возможности в разработке ПО. Перефразируя
Брукса, самую разумную точку зрения на технологические прорывы можно было бы сформулировать так: «не сейчас и никогда больше». Или, пожалуй, «маловероятно, что они вообще возможны в будущем».
«Гласс Р. Факты и заблуждения профессионального программирования 2007»
«на порядок».
У нас могут быть и языки четвертого поколения («программирование без программистов»), и средства CASE («автоматизация программирования»), и объектно: ориентированная методология («лучший путь построения ПО»), и экстремальное программирование («будущее отрасли»), и какое угодно другое новомодное достижение. Но все эти подходы, каким бы звоном ни сопровождались их представление и продвижение, не так уж сильно увеличивают наши возможности в разработке ПО. Перефразируя
Брукса, самую разумную точку зрения на технологические прорывы можно было бы сформулировать так: «не сейчас и никогда больше». Или, пожалуй, «маловероятно, что они вообще возможны в будущем».
«Гласс Р. Факты и заблуждения профессионального программирования 2007»
Инструменты не могут радикально увеличить производительность труда. Но зато могут очень, очень радикально ее уменьшить ;)
Как же это не могут, когда вся история человечества показывает, что могут. Комбайны вместо лошадок, интернеты вместо почтовых голубей. Даже вот возьмите молоток, и гвозди забиваются значительно продуктивнее, чем собственным лбом. Только благодаря инструментам производительность труда и увеличиваем.
У программистов полно инструментов, повышающих производительность труда в сравнении с выбиваением ноликов и единичек на перфокарте. Это и высокоуровневые языки, и СУБД, и регулярки, и облачные хранилища данных, и системы контроля версий. Что это, если не инструменты?
У программистов полно инструментов, повышающих производительность труда в сравнении с выбиваением ноликов и единичек на перфокарте. Это и высокоуровневые языки, и СУБД, и регулярки, и облачные хранилища данных, и системы контроля версий. Что это, если не инструменты?
Приведу пример. Компьютер казалось бы служит для упрощения жизни человеку. И есть случаи, когда эффект от внедрения автоматизации прямо противоположный. Прихожу я в Сбербанк оплатить по квитанции, заполняю невероятной длинны БИК, КБК, Р/Счет, и прочеее. Потом кассирша снова вручную с этой бумажки перепечатает реквизиты в компьютер, все эти огромной длинны БИК, КБК, Р/Счет, и прочеее, потом обработает, распечатает. Даёт мне чеки под роспись и просит перепроверить. Пример того, как человек стал работать на компьютер, а не компьютер на человека.
Короче, стремясь к лучшему, необходимо в самом процессе стремления не забыть, ради чего всё затевалось изначально.
Короче, стремясь к лучшему, необходимо в самом процессе стремления не забыть, ради чего всё затевалось изначально.
Автоматизация, по определению, перекладывает работу на механизмы. В Сбербанке никто не будет заниматься автоматизацией, сложно продвигать вещи, нервно, никакой личной выгоды. Как я это вижу: кто-то родил лозунг, кто-то сделал фичу для галочки. С тем же успехом можно было использовать компьютер в качестве поставки для кофе.
Ключевое слово — «радикально»
А то, что я перечислил, разве не радикально повышает производительность?
Ты не с тем человеком споришь. И почитай Брукса, очень рекомендую.
Мы живем в мире, где небоскребы строятся в считанные месяцы исключительно благодаря инструментам. Знать это и говорить, что инструменты не могут радикально увеличить производительность труда — это бред. С бредом я, безусловно, не спорю. Как можно спорить с тем, что не содержит логики.
Брукс писал совершенно о другом. Есть несокращаемые затраты времени — там, где нужен человеческий мозг и координация этих мозгов. Пока нет инструментов, функционально эквивалентных или превосходящих человеческий мозг, все будет упираться в это узкое место.
Брукс писал совершенно о другом. Есть несокращаемые затраты времени — там, где нужен человеческий мозг и координация этих мозгов. Пока нет инструментов, функционально эквивалентных или превосходящих человеческий мозг, все будет упираться в это узкое место.
Для начала — у тебя неверная аналогия. Разработка софта — это не строительство небоскреба по готовому плану, а его проектирование.
Я все это прекрасно понимаю. Моя критика относится к двусмысленной фразе: «Инструменты не могут радикально увеличить производительность труда. Но зато могут очень, очень радикально ее уменьшить ;)».
Сведем ее к менее двусмысленной: «Инструменты разработки ПО не могут радикально увеличить производительность труда». Но тогда вопрос, а компиляторы разве не увеличили? Никто не пишет социальные сети на ассемблере. Чисто технологическое решение, которое дало несказанный выигрыш в производительности труда.
И возможности не исчерпаны. Например, разработка SaaS в массе своей далеко не на том уровне, когда все упирается в мозги. У меня есть опыт работы над большими коммерческими проектами и управления командой. 30-90% времени программисты занимаются чисто механической работой из-за отсуствия хороших инструментов разработки, нормального DSL, низкого качества готовых решений.
Сведем ее к менее двусмысленной: «Инструменты разработки ПО не могут радикально увеличить производительность труда». Но тогда вопрос, а компиляторы разве не увеличили? Никто не пишет социальные сети на ассемблере. Чисто технологическое решение, которое дало несказанный выигрыш в производительности труда.
И возможности не исчерпаны. Например, разработка SaaS в массе своей далеко не на том уровне, когда все упирается в мозги. У меня есть опыт работы над большими коммерческими проектами и управления командой. 30-90% времени программисты занимаются чисто механической работой из-за отсуствия хороших инструментов разработки, нормального DSL, низкого качества готовых решений.
>Сведем ее к менее двусмысленной: «Инструменты разработки ПО не могут радикально увеличить производительность труда»
И это совершенно зря, потому что главное в ней — вторая часть.
И это совершенно зря, потому что главное в ней — вторая часть.
Добавьте вторую часть, что меняется? Идиоты, которые поклоняются культу карго и ведутся на рекламный звон, не переведутся никогда. Только технология тут не при чем. Ну да, если пилой колоть дрова то радикально уменьшишь проивзодительность труда. Пила тут виновата или идиот, который не знает как ей пользоваться?
Пока для Go не появится нормальных IDE он все равно не станет популярным.
IDE, библиотек, большого количества реализованных проектов, опенсоурс проектов и т.д. Пока это академическая игрушка гугля, как его не пиарь. А зная гугль, у меня закрадываются сомнения, что язык будет доведен до конца.
Гугл — это очень большая контора. И доведение-недоведение до конца зависит от конкретных людей. Поэтому в данном случае лучше смотреть не на слово Google, а на слово Роб Пайк. Не все проекты, которые он делал, приобрели широкую популярность, но я что-то не припомню за ним привычки начинать и бросать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Роб Пайк подверг критике C++ и Java