Здравствуйте, varenikAA, Вы писали:
AA>А что думаешь ты, russian developer, какой ЯП имеет всё необходимое для написания идеального кода?
C. Простой синтаксис, понятный код, быстро компилируется, быстро работает, нет никакой магии, неявно влияющей на поведение, быстродействие и потребление памяти.
Трудоемкость написания кода и требования к квалификации оставим за скобками.
Здравствуйте, scf, Вы писали: scf>C. Простой синтаксис, понятный код, быстро компилируется, быстро работает, нет никакой магии, неявно влияющей на поведение, быстродействие и потребление памяти.
Справедливости ради замечу, что Линус говорит о работе с железом, вероятно речь не идет о бизнес-приложениях или вэбе.
Здравствуйте, varenikAA, Вы писали:
AA>Справедливости ради замечу, что Линус говорит о работе с железом, вероятно речь не идет о бизнес-приложениях или вэбе.
Не так давно тут высказывались мнения, что веб нужно писать на Ассемблере.
Здравствуйте, varenikAA, Вы писали:
scf>>C. Простой синтаксис, понятный код, быстро компилируется, быстро работает, нет никакой магии, неявно влияющей на поведение, быстродействие и потребление памяти. AA>Справедливости ради замечу, что Линус говорит о работе с железом, вероятно речь не идет о бизнес-приложениях или вэбе.
Я о том же, для бизнес-приложений и веб нужен анти С — магический, тормозной, навороченный, но дуракоустойчивый и с минимальным порогом входа.
Здравствуйте, Privalov, Вы писали:
P>Не так давно тут высказывались мнения, что веб нужно писать на Ассемблере.
Если бы вся страница была представлена байт-кодом. Однако, UI по прежнему представляется собой отдельную сущность,
к которой у вэбасма довольно длинный путь. т.е. для бизнес-приложения которому нужно отображать кучу полей выигрыша нет.
КД>Когда видишь в исходниках винды вещи типа:
И пруф, конечно же будет?
КД>Я недавно с GitHUB заимствовал одну хрень на плюсах, порожденную инженером MS, там было нечто аналогичное.
Анало гично.
КД>Не поленился, написал в трекер. КД>Получил ответ — "да по#ер".
Реально "похер" от МС?
Здравствуйте, Коваленко Дмитрий, Вы писали:
M>>Баян, было уже. Дедуля просто C++ не осилил КД>Когда видишь в исходниках винды вещи типа:
Кажется, что они всё своё плюсовое добро тестируют с помощью Application Verifier, в том числе и на нехватку памяти. Может быть, ты видел не исходники Винды и даже не исходники приложения, которое идёт вместе с ней?
Здравствуйте, Nuzhny, Вы писали:
M>>>Баян, было уже. Дедуля просто C++ не осилил КД>>Когда видишь в исходниках винды вещи типа:
N>Кажется, что они всё своё плюсовое добро тестируют с помощью Application Verifier, в том числе и на нехватку памяти. Может быть, ты видел не исходники Винды и даже не исходники приложения, которое идёт вместе с ней?
Это я копался в nt5src.
Поиск по "delete" ну и потом методом тыка нашел. Возможно, во вспомогательной гуе. Второй раз это место искать бесполезно
Один new был в секции инициализации конструктора (присваивался голому указателю), второй new в теле — тоже голому указателю. Улыбнулся и закрыл.
Я так думаю, они "bad_alloc" (и вообще исключения) не любят кидают, поэтому типа прокатывает.
Вот что зацепило — обнуление указателей после delete. Даже в деструкторах. Но встречаются delete и без обнуления.
---
Application Verifier — он же вроде бинарники тестирует?
Cдается мне, такое надо статическим анализатором искать.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Application Verifier — он же вроде бинарники тестирует?
Да, бинарники. Но оно реально вынуждает всему, что есть кидаться bad_alloc. Если статический что-то и пропустит, то там нет шансов.
КД>Cдается мне, такое надо статическим анализатором искать.
Здравствуйте, scf, Вы писали:
scf>C. Простой синтаксис, понятный код, быстро компилируется, быстро работает, нет никакой магии, неявно влияющей на поведение, быстродействие и потребление памяти.
А ещё склонность к образованию трудновылавливаемых багов, просто потому что всё приходится делать на ручнике.
Здравствуйте, varenikAA, Вы писали:
AA>Справедливости ради замечу, что Линус говорит о работе с железом, вероятно речь не идет о бизнес-приложениях или вэбе.
Да пофигу. С железом тот же С++ работает замечательно.
Здравствуйте, scf, Вы писали:
scf>Линус и С++ это известный мем — http://harmful.cat-v.org/software/c++/linus
Мда. Его гит таки лютое говно — месиво из скриптов и кусочков фруктов Сшной бинарщины.
Он утвеждает, что когда читает код на C, то знает, во что он скомпилируется. Насколько он прав? Мне кажется, современные компиляторы настолько замудрённые, что там уже так просто не поймёшь, что во что скомпилируется. Какой-нибудь цикл развернётся в векторную инструкцию, какой-нибудь по 4 тела развернёт, какой-то не развернёт. Какую-то переменную засунет в регистр, какую-то не засунет. Как такое можно понимать.
Я бы понял, если бы он говорил про какие-то старинные примитивные компиляторы, для которых C был эдаким макро-ассемблером на стероидах. Но это ведь уже давно не так.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>Когда видишь в исходниках винды вещи типа:
Ф>А что там не так. Я плюсы много лет не видел.
Здравствуйте, Свободу rg45!, Вы писали:
СR>Философ:
Ф>>А что там не так. Я плюсы много лет не видел. СR>Небезопастность по исключениям.
Если Вы об генерации исключений в конструкторе (при создании новых объектов), то возможна и небезопасность.
Но ИМХО здесь следует смотреть конкретно — сколько памяти выделяется при их создании?
Если 1 KB — принятое решение вполне прокатит, если же 1 GB — возможен "нежданчик" (в виде исключения).
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здесь же, в целом, проблема в другом — если конструктор кинет исключение, деструктор не вызовется.
Здесь следует подходить дифференцированно.
Так, например, если я запросил (примерно) 1 KB памяти — то здесь никогда исключения не будет. Зачем тогда закладываться на это?
Если же я здесь (при создании нового объекта по new) загружаю большой массив данных (сотни MB или даже 1 GB) —
тогда да — сделать обработку исключения в конструкторе необходимо.
КД>И даже если сейчас у них new исключения не кидает, такой код представляет собой "мину замедленного действия".
Если у объекта 5-ть полей типа int, но завтра — их может стать семь.
Где здесь "мина_замедленного_действия"?
Здравствуйте, AlexGin, Вы писали:
КД>>Здесь же, в целом, проблема в другом — если конструктор кинет исключение, деструктор не вызовется.
AG>Здесь следует подходить дифференцированно.
Меня папа в детстве приучил делать либо хорошо, либо никак.
Поэтому для меня — что 1KB, что 1GB — без разницы.
КД>>И даже если сейчас у них new исключения не кидает, такой код представляет собой "мину замедленного действия".
AG>Где здесь "мина_замедленного_действия"?
В copy&paste этого кода в другой проект с другими правилами.
Или в переходе на new, кидающем исключения.
Я видел и то и другое. В проекте, претендующем на роль элемента инфраструктуры.
---
Понятно, что для кого-то все это высосанные из пальца проблемы.
Но я уже по другому не могу. Да и не хочу
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, AlexGin, Вы писали:
AG>P.S. Отметим, ради справедливости, что несмотря на то, что в приведеннок коде AG>контроль памяти вручную, каких-либо явных ошибок он не содержит.
Он содержит, как минимум:
* утечку памяти, если второй new бросит исключение;
* отсутствие переопределенных операторов/конструкторов копирования (даже не будем сейчас про C++11 с сего move semantic). Из-за чего объекты TObj можно копировать с побитовым копированием значений указателя из одного TObj в другой. Что затем приведет к double free. Оператор/конструктор должен быть для такого объекта либо явно реализован, либо явно запрещен (в C++03 и более древних стандартах для этих целей был специальный трюк с объявлением оператора/конструктора в private секции без реальной реализации).
Здравствуйте, vsb, Вы писали:
vsb>Он утвеждает, что когда читает код на C, то знает, во что он скомпилируется. Насколько он прав? Мне кажется, современные компиляторы настолько замудрённые, что там уже так просто не поймёшь, что во что скомпилируется...
vsb>Я бы понял, если бы он говорил про какие-то старинные примитивные компиляторы, для которых C был эдаким макро-ассемблером на стероидах. Но это ведь уже давно не так.
И лучше не думать о том, как это потом сама железяка переварит
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, so5team, Вы писали:
S>* отсутствие переопределенных операторов/конструкторов копирования (даже не будем сейчас про C++11 с сего move semantic). Из-за чего объекты TObj можно копировать с побитовым копированием значений указателя из одного TObj в другой. Что затем приведет к double free. Оператор/конструктор должен быть для такого объекта либо явно реализован, либо явно запрещен (в C++03 и более древних стандартах для этих целей был специальный трюк с объявлением оператора/конструктора в private секции без реальной реализации).
Бессмысленные названия классов и переменных забыл.
Ты действительно решил что это вот буквально реальный кусок исходников?
Здравствуйте, AlexGin, Вы писали: Ф>>А что там не так. Я плюсы много лет не видел.
AG>Много лет в плюсах есть ...:
А теперь вспомним что топик о превосходстве голых сей. И в качестве примера — типичный сишный говнокод.
Что-то как-то не очень превосходство демонстрируется.
Здравствуйте, Константин Б., Вы писали:
AG>>Много лет в плюсах есть ...: КБ>А теперь вспомним что топик о превосходстве голых сей. И в качестве примера — типичный сишный говнокод. КБ>Что-то как-то не очень превосходство демонстрируется.
Ну дык эта, "настАящЫй прАфИсиАнал на любом языке способен написать программу на фортране" (С)
Если дать С++ в руки пингвину бородатым сишникам они будут на нём писать как привыкли — на С.
Так что тут всё ожидаемо.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Мужик начал свой профессиональный рост в 90-ых?
И?
КД>Какие тогда ... плюсы? Я думаю — реально никакие.
С тогда тоже был тем ещё куском субстанции, но даже он с тех пор развился.
Здравствуйте, vsb, Вы писали:
vsb>Он утвеждает, что когда читает код на C, то знает, во что он скомпилируется. Насколько он прав?
Да в общем то нинасколько, если только не пользоваться одной и той же версией компилера вечно.
Здравствуйте, CreatorCray, Вы писали:
КД>>Мужик начал свой профессиональный рост в 90-ых? CC>И?
КД>>Какие тогда ... плюсы? Я думаю — реально никакие. CC>С тогда тоже был тем ещё куском субстанции, но даже он с тех пор развился.
Вообще я хотел написать не "плюсы", а "компиляторы плюсов", но что-то пошло не так ...
А на чем тогда можно было писать в то время?
Когда у тебя обычная локальная переменная внутри цикла убивает стек, причем ты это увидишь только если после этого цикла выкинут исключение, то невольно подумаешь — ...ный по голове да ну его ... этот C++.
Только на C.
А потом, с куевой хучей сишного кода на руках — дергаться поздно.
---
В общем — когда нормальные компиляторы плюсов появились-то?
Лично я только с VS2005 перестал ....ться с плюсовым кодом и сидеть на измене. А это 2005/2006 год.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Инновации, о которых так много говорят в индустрии — это чушь. Кто угодно может заниматься инновациями. Не так уж это и трудно — думать иначе. Забейте. Это бессмысленно. Реальная работа кроется в деталях. Успешные проекты это 99% пота и 1% инноваций.
Это довольно скучно, насколько хорошо сегодня отлажен у нас процесс, — отметил он. — Раньше вот были неспокойные времена, полные стресса. Вот когда код не работает, тогда идет оживление. Проблемы в процессе — это боль в заду. А проблем никто не хочет, и люди начинают себя агрессивно вести по отношению друг к другу.
А теперь представим, что разработка ядра велась бы на плюсах. Огромное количество незнакомых друг с другом людей из разных организаций без единого начальства. Как организовать процесс, чтобы не прищемить друг друга? Очевидно, что каждому модулёчку для этого просто жизненно необходимо было бы выставлять наружу строго стандартизированные примитивные C-подобные интерфейсы, а не развесистые объектно-ориентированные+обобщённыe. А вся настоящая магия современного C++ поисходила бы камерно, в изоляции, не показываясь наружу. А это такой binary bloating, что мама не горюй.
Так что именнно с этой колокольни (язык, чтобы по-минимуму мешать друг другу в разношёрстном базар-коллективе) — сишечка как раз идеальна.
PS. Про время компиляции гипотетического современного разросшегося Линукса, будь он написан на современных плюсах, а также о требуемом железе для компиляции проектов подобных масштабов на C++ 17/20, я вообще промолчу.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>А на чем тогда можно было писать в то время?
КД>Когда у тебя обычная локальная переменная внутри цикла убивает стек, причем ты это увидишь только если после этого цикла выкинут исключение, то невольно подумаешь — ...ный по голове да ну его ... этот C++.
что-то ты странное говоришь.
был watcom, был gcc, был borland.
не замечал там такого
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Когда у тебя обычная локальная переменная внутри цикла убивает стек, причем ты это увидишь только если после этого цикла выкинут исключение, то невольно подумаешь — ...ный по голове да ну его ... этот C++.
А можно пример кода, в котором "переменная внутри цикла убивает стек"?
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gardener, у Вас внезапно пригорело
если бы Cтрауструп ставил Торвальдсу диагноз то это было бы норм (но как правило образованные люди тактичны и не опускаються до такого)
а когда человек не решавший аналогичного уровня задач, это как бы странно
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>А на чем тогда можно было писать в то время?
КД>>Когда у тебя обычная локальная переменная внутри цикла убивает стек, причем ты это увидишь только если после этого цикла выкинут исключение, то невольно подумаешь — ...ный по голове да ну его ... этот C++.
NB>что-то ты странное говоришь. NB>был watcom, был gcc, был borland. NB>не замечал там такого
Накатал много нехороших букв про BC5, BCB1, BCB3, BCB5, BCB6. Период эксплуатации: 1999-2007.
Перечитал и стер.
Скажем так — жаль, что они так сильно глючили.
---
Я еще VC6 смотрел в то время. Наверное он был надежным, но был реально убогим в плане поддержки плюсов.
С остальными компиляторами дело не имел.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>--- КД>В общем — когда нормальные компиляторы плюсов появились-то?
КД>Лично я только с VS2005 перестал ....ться с плюсовым кодом и сидеть на измене. А это 2005/2006 год.
Borland C++ 3.0/3.1 — 1991/1992. На нём Wolfenstein написан, если что. Линупс как раз примерно в это время только начал. Но Борман — на самом деле отличный C++ был, на то время. Имхо, практически C++98/03, только без STL. TurboVision, OWL, все дела...
Кроме бормана еще куча компилеров была, часто похуже, да, но были
STL — Степанова позвали в Белл лабс писать STL еще в 1987м году, в C++ тогда ещё шаблонов не было, в 88м он перешел в HP, а в 92м начал таки писать STL. Потому что а) до этого занимался другой хренью, б) уже появились годные шаблоны в плюсах.
В 95ом уже куча всего была на плюсах, и были годные среды и компиляторы. В 97ом уже BCB был
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Накатал много нехороших букв про BC5, BCB1, BCB3, BCB5, BCB6. Период эксплуатации: 1999-2007.
КД>Перечитал и стер.
КД>Скажем так — жаль, что они так сильно глючили.
BC3/4/5, BCB — норм, жили. Watcom — норм. VC — норм. Бывало, конечно, что глючили, но не ужас-ужас
Здравствуйте, varenikAA, Вы писали:
AA>Сказад как отрезал. AA>Linus Torvalds "Nothing better than C" AA>А что думаешь ты, russian developer, какой ЯП имеет всё необходимое для написания идеального кода?
Ээ. И?
Там в заголовке видосика написано: "Linus Torvalds. Embedded Software Engineer. Nothing better than C".
Ключевое слово выделил.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
SE>А теперь представим, что разработка ядра велась бы на плюсах. Огромное количество незнакомых друг с другом людей из разных организаций без единого начальства. Как организовать процесс, чтобы не прищемить друг друга? Очевидно, что каждому модулёчку для этого просто жизненно необходимо было бы выставлять наружу строго стандартизированные примитивные C-подобные интерфейсы, а не развесистые объектно-ориентированные+обобщённыe. А вся настоящая магия современного C++ поисходила бы камерно, в изоляции, не показываясь наружу. А это такой binary bloating, что мама не горюй.
SE>Так что именнно с этой колокольни (язык, чтобы по-минимуму мешать друг другу в разношёрстном базар-коллективе) — сишечка как раз идеальна.
C++ уже тогда умел бить по рукам за очень многое. Всевозможные API — элементарно можно выставлять наружу в виде абстрактных классов с виртуальными функциями.
SE>PS. Про время компиляции гипотетического современного разросшегося Линукса, будь он написан на современных плюсах, а также о требуемом железе для компиляции проектов подобных масштабов на C++ 17/20, я вообще промолчу.
Сипипишечка тех времён компилилась тоже мнгновенно, так-то.
Здравствуйте, Коваленко Дмитрий, Вы писали:
NB>>что-то ты странное говоришь. NB>>был watcom, был gcc, был borland. NB>>не замечал там такого
КД>Накатал много нехороших букв про BC5, BCB1, BCB3, BCB5, BCB6. Период эксплуатации: 1999-2007.
В компиляторах Борланд оптимизация иногда криво работала.
Я как то, когда был студентом, писал код на BC++ под DOS
// что то вродеfor (int i = 0; i < n; i++)
{
for (int j = 0; j < m; j++)
{
...
}
...
}
Не работало и я не понимал, почему. В отладчике пошёл по шагам. И при прохождении внутреннего цикла увидел, что на каждом шаге меняется и i и j. Удивился, посмотрел в отладчике адреса переменных — они совпадали! Отключил оптимизацию, пересобрал, заработало.
Здравствуйте, smeeld, Вы писали:
SE>>А теперь представим, что разработка ядра велась бы на плюсах.
S>Ничего бы не получилось. Это только местные C++-ные гуру-осиляторы думают, что такое возможно, так не пишут ничего, кроме простейших хеллоуворлдов.
Сам-то много линупсов на чистой сишечке написал? Ни одного? А что так?
Здравствуйте, AleksandrN, Вы писали:
AN>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>Когда у тебя обычная локальная переменная внутри цикла убивает стек, причем ты это увидишь только если после этого цикла выкинут исключение, то невольно подумаешь — ...ный по голове да ну его ... этот C++.
AN>А можно пример кода, в котором "переменная внутри цикла убивает стек"?
Зачем?
Вы не можете представить себе for(;){int x;}?
Это были глюки BCB3 и это было в 2001 году. Там генерировалась неправильная коррекция стека при завершении работы цикла с локальной переменной. Ошибка втихую исправлялась при выходе из функции. Но если после цикла генерировалось исключение, то программа падала. Можно было открыть в отладчике ассемблерный код, поправить инструкцию коррекции стека и программа не падала.
Я это привел чисто как потенциальную причину отказа от плюсов из-за глючности компиляторов.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, удусекшл, Вы писали:
У>Сам-то много линупсов на чистой сишечке написал? Ни одного? А что так?
С ядром линукса много работал: драйверы железок, драйверы ФС (специализированные), драйверы сетевых протоколов. А ещё раньше с ядром соляриса имел дело.
SE>>PS. Про время компиляции гипотетического современного разросшегося Линукса, будь он написан на современных плюсах, а также о требуемом железе для компиляции проектов подобных масштабов на C++ 17/20, я вообще промолчу.
У>Сипипишечка тех времён компилилась тоже мнгновенно, так-то.
упоминавшися вами BC31 в 93 год на 386 c 8 mb памяти
собира досовский проект доморощеного аналога маткада с TurboVision иминут 15-20
компалиру притенщий нет по тем временнам был хорошим
хотя справделивости ради Turbo C 1.5 на том же компе просто летал
Здравствуйте, smeeld, Вы писали:
У>>Сам-то много линупсов на чистой сишечке написал? Ни одного? А что так?
S>С ядром линукса много работал: драйверы железок, драйверы ФС (специализированные), драйверы сетевых протоколов. А ещё раньше с ядром соляриса имел дело.
Ну и где твой собственный линупс?
А так-то вон Креатор вполне в ядро на плюсах пилит, если не ошибаюсь. Правда, в виндовое вроде, или что-то там для маков
Здравствуйте, sergey2b, Вы писали:
У>>Сипипишечка тех времён компилилась тоже мнгновенно, так-то.
S>упоминавшися вами BC31 в 93 год на 386 c 8 mb памяти S>собира досовский проект доморощеного аналога маткада с TurboVision иминут 15-20
Проект на плюсах был?
Сколько бы он писался бы на чистой сишечке?
Так-то и на тех компах и чистая сишечка небыстрая была
S> компалиру притенщий нет по тем временнам был хорошим S>хотя справделивости ради Turbo C 1.5 на том же компе просто летал
На проектах с аналогичной функциональностью, написанных за разумное время? Не верю
КД>Вы не можете представить себе for(;){int x;}?
КД>Это были глюки BCB3 и это было в 2001 году. Там генерировалась неправильная коррекция стека при завершении работы цикла с локальной переменной. Ошибка втихую исправлялась при выходе из функции. Но если после цикла генерировалось исключение, то программа падала. Можно было открыть в отладчике ассемблерный код, поправить инструкцию коррекции стека и программа не падала.
КД>Я это привел чисто как потенциальную причину отказа от плюсов из-за глючности компиляторов.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Вы не можете представить себе for(;){int x;}?
КД>Это были глюки BCB3 и это было в 2001 году. Там генерировалась неправильная коррекция стека при завершении работы цикла с локальной переменной. Ошибка втихую исправлялась при выходе из функции. Но если после цикла генерировалось исключение, то программа падала. Можно было открыть в отладчике ассемблерный код, поправить инструкцию коррекции стека и программа не падала.
КД>Я это привел чисто как потенциальную причину отказа от плюсов из-за глючности компиляторов.
Не компиляторов, а одного из компиляторов. В компиляторах MS, Intel, Watcom и gcc такого не наблюдалось.
Здравствуйте, ·, Вы писали:
AA>>Сказад как отрезал. AA>>Linus Torvalds "Nothing better than C" AA>>А что думаешь ты, russian developer, какой ЯП имеет всё необходимое для написания идеального кода? ·>Ээ. И? ·>Там в заголовке видосика написано: "Linus Torvalds. Embedded Software Engineer. Nothing better than C". ·>Ключевое слово выделил.
Коллега ходил на собесед в какую-то типа гос контору, на эмбеддера. Сказал, что там жоский C++ 20
Здравствуйте, удусекшл, Вы писали:
У>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>Накатал много нехороших букв про BC5, BCB1, BCB3, BCB5, BCB6. Период эксплуатации: 1999-2007.
КД>>Перечитал и стер.
КД>>Скажем так — жаль, что они так сильно глючили.
У>BC3/4/5, BCB — норм, жили. Watcom — норм. VC — норм. Бывало, конечно, что глючили, но не ужас-ужас
BC4.5 — это я еще был испуганным ребенком, который шарахался от ошибок компилятора
BC5 — у него были серьезные проблемы с генерацией исключений. Я не могу сейчас с уверенностью сказать, но, по-моему, если в одном потоке выкинуть исключение, то второй при выкидывании исключения упадет. Или надо было одновременно их кидать. Не помню. Да и в целом, я только через несколько лет я понял — какая эта была глючная вещь. Просто нереально глючная.
Из BCB1-BCB6, только BCB5 более менее. Но только с линковщиком от BCB6. BCB5, точнее его бесплатный компилятор, я замучил до смерти в апреле 2010. И закопал.
Так что, да. То есть нет — на BC5 и билдере операционку писать точно не получилось бы.
По-моему, свой InterBase своим компилятором они никогда не собирали.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, AleksandrN, Вы писали:
КД>>Я это привел чисто как потенциальную причину отказа от плюсов из-за глючности компиляторов.
AN>Не компиляторов, а одного из компиляторов. В компиляторах MS, Intel, Watcom и gcc такого не наблюдалось.
Вот я про другие и спрашиваю — может про них кто тоже чего "веселого" напишет.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, удусекшл, Вы писали:
У>·>Ээ. И? У>·>Там в заголовке видосика написано: "Linus Torvalds. Embedded Software Engineer. Nothing better than C". У>·>Ключевое слово выделил. У>Коллега ходил на собесед в какую-то типа гос контору, на эмбеддера. Сказал, что там жоский C++ 20
Ну в эмбед сейчас и на питоне пишут, и даже на javascript... И что?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
У>>·>Ээ. И? У>>·>Там в заголовке видосика написано: "Linus Torvalds. Embedded Software Engineer. Nothing better than C". У>>·>Ключевое слово выделил. У>>Коллега ходил на собесед в какую-то типа гос контору, на эмбеддера. Сказал, что там жоский C++ 20 ·>Ну в эмбед сейчас и на питоне пишут, и даже на javascript... И что?
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>>Я это привел чисто как потенциальную причину отказа от плюсов из-за глючности компиляторов.
AN>>Не компиляторов, а одного из компиляторов. В компиляторах MS, Intel, Watcom и gcc такого не наблюдалось.
КД>Вот я про другие и спрашиваю — может про них кто тоже чего "веселого" напишет.
Здравствуйте, удусекшл, Вы писали:
КД>>Вы не можете представить себе for(;){int x;}?
КД>>Я это привел чисто как потенциальную причину отказа от плюсов из-за глючности компиляторов.
У>А если оптимизацию отключить, тоже глючило?
Если мне не изменяет память, я её и не включал
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, удусекшл, Вы писали:
КД>>>Вы не можете представить себе for(;){int x;}?
КД>>>Я это привел чисто как потенциальную причину отказа от плюсов из-за глючности компиляторов.
У>>А если оптимизацию отключить, тоже глючило?
КД>Если мне не изменяет память, я её и не включал
А компилировал из командной строки или из IDE? В IDE часть опций по оптимизации была включена по умолчанию.
Здравствуйте, varenikAA, Вы писали:
AA>А что думаешь ты, russian developer, какой ЯП имеет всё необходимое для написания идеального кода?
В каком смысле идеальный? Идеальный — семантически близкий для решения задачи? Так задачи бывают разные. Идеальный для превращения в код? Так тут участвует и транслятор и архитектура процессора, да и "идеальный" код для разных задач разный. Идеальный для понимания? Так это дело привычки и зависит от опыта работы именно с этим языком. Скорее всего имеется в виду близкий к архитектуре процессора. Т.е. к ассемблеру привычной архитектуры. Никто не гарантирует что эта архитектура идеальна и стало быть вечна. Тем более, у меня есть абсолютно новая. Совсем не похожая на императивную, и последовательное выполнение команд. И даже реализующая недетерминированную машину Тьюринга. Т.е. с параллельной работой и без прерываний.
Здравствуйте, AleksandrN, Вы писали:
AN>В компиляторах Борланд оптимизация иногда криво работала. AN> Удивился, посмотрел в отладчике адреса переменных — они совпадали! Отключил оптимизацию, пересобрал, заработало.
У меня подобное было в 2003 с gcc, причем собирал драйвер для линукса как раз. Правда ошибка возникла на нестабильной версии gcc, которую я за пару месяцев до бага установил и забыл.
Сейчас же на работе часто собираю разные ядра линукса, уже стабильными gcc. И пару раз видел как gcc получает segfault при этом.
Если по теме, то против С++ ничего не имею. Но С++ я называю С++98, а не более новую ахинею.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, AleksandrN, Вы писали:
У>>>А если оптимизацию отключить, тоже глючило?
КД>>Если мне не изменяет память, я её и не включал
AN>А компилировал из командной строки или из IDE?
AN>В IDE часть опций по оптимизации была включена по умолчанию.
Мне таки придется написать большую часть того, что я стер
Здравствуйте, ononim, Вы писали:
O>Си это конечно хорошо. Но вы пробовали секс?
Ради программирования на Си хотя бы не идёшь на безумные поступки, не тратишь кучу денег, написанный код не надо водить в школу, а компилятор ничем не заразит. Си лучше!
S> а компилятор ничем не заразит
Помню для делфи были вирусы которые заражали компилятор, а точнее стандартную либу, с которой линкуются проги, скомпиленные им. И потом он делал заразные проги, которые заражали другие компиляторы.
Как много веселых ребят, и все делают велосипед...
S>>>после хорошей девушки S>>>вштыривает покодить на для души Си O>>а после плохой — на C++17 S>это после общения с начальством
Если начальство — плохая девочка, то вполне, вполне..
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
S>>>>после хорошей девушки S>>>>вштыривает покодить на для души Си O>>>а после плохой — на C++17 S>>это после общения с начальством O>Если начальство — плохая девочка, то вполне, вполне..
Здравствуйте, CreatorCray, Вы писали:
CC>Если дать С++ в руки пингвину бородатым сишникам они будут на нём писать как привыкли — на С.
Не только бородатые сишники, но и просто люди, не являющиеся специалистами в С++. А поскольку специалисты в С++ не нужны (нужны специалисты в какой-то предметной области), то "наибольший общий делитель" в распеределённой команде с большим разбросом по квалификации и компетенциям оказывается весьмя близким к "чистому" С или С с классами. Обратное, кстати, тоже верно: небольшая сплочённая кучка ультра-профессионалов, пилящая что-то очень хардкорное, но ограниченное по объёму и горизонту планирования, с современным С++ выдаст гораздо более простой, читаемый, устойчивый и расширяемый код.
Здравствуйте, scf, Вы писали:
scf>C. Простой синтаксис, понятный код, быстро компилируется, быстро работает, нет никакой магии, неявно влияющей на поведение, быстродействие и потребление памяти.
scf>Трудоемкость написания кода и требования к квалификации оставим за скобками.
А трудоемкость написания коррелирует с понятностью. Когда конструкция на 3 строчки в одном языке и на 3 экрана в другом, то первый понятнее.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Вообще я хотел написать не "плюсы", а "компиляторы плюсов", но что-то пошло не так ...
Компиляторы плюсов под линух были ужасны весьма долгое время, да. Под винду было сильно получше.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Я еще VC6 смотрел в то время. Наверное он был надежным, но был реально убогим в плане поддержки плюсов.
Для целей системного программирования был весьма нормально. Я VC6 геймдевил — работало вполне нормально.
Здравствуйте, sergey2b, Вы писали:
S>если бы Cтрауструп ставил Торвальдсу диагноз то это было бы норм
Мне пофигу на регалии, что вижу так и называю.
S> но как правило образованные люди тактичны и не опускаються до такого
Сам верховный пЫнгвин с его посыланиями нах в публичной переписке и маханиями middlefingerом на конференциях согласно твоей формулировке образованным не является.
S>а когда человек не решавший аналогичного уровня задач, это как бы странно
Yet another linux не писал за ненадобностью, системного же кода в кернел и на си и на плюсах пописал достаточно и продолжаю писать.
Слепого поклонения пингвину не понимаю, более того осуждаю.
Здравствуйте, El Camino Real, Вы писали:
CC>>Если дать С++ в руки пингвину бородатым сишникам они будут на нём писать как привыкли — на С. ECR>Не только бородатые сишники, но и просто люди, не являющиеся специалистами в С++.
Для того, чтоб научиться пользоваться готовыми RAII wrappers особо много мозгов не надо а одно только это в сравнении с рукопашкой на сях и код упрощает и от кучи ошибок избавляет.
ECR>С с классами.
Уже лучше чем просто С.
Здравствуйте, so5team, Вы писали:
S>Он содержит, как минимум:
S>* утечку памяти, если второй new бросит исключение;
Если эти объекты в памяти занимают по 5 байт, то исключений не будет (от слова вообще).
S>* отсутствие переопределенных операторов/конструкторов копирования (даже не будем сейчас про C++11 с его move semantic).
Да, это может быть ошибкой. Но может ошибкой и не быть. Смотря какое назначение объектов данного класса.
Так, например, для головного окна приложения — конструкторы копирования и перемещения не актуальны.
Однократно создаваемый singleton объект (например контроллер протокола обмена) — также из той же оперы.
S>Ваш К.О.
Не живу догмами, и вам не советую
То, что для одного случая однозначно будет ошибкой, для другого — нормой.
Так, например, кто-то будет утверждать, что одна программа (или сервис) — должна выполнять только одну функцию.
Но это также сильно зависит от ситуации (а не от веры в догму UNIX-way).
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Меня папа в детстве приучил делать либо хорошо, либо никак. КД>Поэтому для меня — что 1KB, что 1GB — без разницы.
Но делать хорошо — это не значит переусложнять код, без требуемой надобности.
Или Ваш папа не знает про принцип KISS?
КД>>>И даже если сейчас у них new исключения не кидает, такой код представляет собой "мину замедленного действия".
AG>>Где здесь "мина_замедленного_действия"?
КД>В copy&paste этого кода в другой проект с другими правилами.
Да, именно так — в бездумном copy&paste и есть мина_замедленного_действия
Вне зависимости от того, что копируем и куда это вставляем.
КД>Или в переходе на new, кидающем исключения.
При правильной архитектуре, когда в конструкторе просто создаётся объект, а не происходит активная работа с ним,
данной проблемы не возникнет. Ну разве в случае совсем уж гигантского объекта, на что я и указывал выше.
КД>Я видел и то и другое. В проекте, претендующем на роль элемента инфраструктуры.
КД>--- КД>Понятно, что для кого-то все это высосанные из пальца проблемы. КД>Но я уже по другому не могу. Да и не хочу
Ваш выбор, который я уважаю, но перенимать его в повседневную практику не вижу смысла.
Здравствуйте, AlexGin, Вы писали:
AG>Если эти объекты в памяти занимают по 5 байт, то исключений не будет (от слова вообще). AG>Да, это может быть ошибкой. Но может ошибкой и не быть. Смотря какое назначение объектов данного класса.
Сперва вы не увидели двух простейших ошибок. Затем вы не заметили, как публично обосрались. Поздравляю, верной дорогой идете.
AG> и вам не советую
Да уж, показательный неосилятор в том проекте. А ведь достаточно было засунуть этот m_rgwszArgs в std::unique_ptr. Было бы и безопасно в плане исключений, и некопируемо.
Но видимо проще закрыть глаза с меткой wont fix и типа нет проблем. Zero bug tolerance, судя по другим issue.
Здравствуйте, varenikAA, Вы писали:
scf>>C. Простой синтаксис, понятный код, быстро компилируется, быстро работает, нет никакой магии, неявно влияющей на поведение, быстродействие и потребление памяти. AA>Справедливости ради замечу, что Линус говорит о работе с железом, вероятно речь не идет о бизнес-приложениях или вэбе.
Здравствуйте, vsb, Вы писали:
vsb>Он утвеждает, что когда читает код на C, то знает, во что он скомпилируется. Насколько он прав? Мне кажется, современные компиляторы настолько замудрённые, что там уже так просто не поймёшь, что во что скомпилируется. Какой-нибудь цикл развернётся в векторную инструкцию, какой-нибудь по 4 тела развернёт, какой-то не развернёт. Какую-то переменную засунет в регистр, какую-то не засунет. Как такое можно понимать.
В одной конторке видел такого мужика. Но он писал на TC/BC под шелезяку на i386, наверное и до сих пор пишет
Здравствуйте, Marty, Вы писали:
M>Баян, было уже. Дедуля просто C++ не осилил
современные плюсы это какой-то сюр и треш, от изначального языка только название осталось.
Только Си спасет мир. Правда, последнее время и туда "умники" с комитетом то ООП хотят всунуть, то вот массивы динамические на этапе инициализации. Но все же.
Здравствуйте, AlexGin, Вы писали:
AG>Здесь следует подходить дифференцированно. AG>Так, например, если я запросил (примерно) 1 KB памяти — то здесь никогда исключения не будет. Зачем тогда закладываться на это? AG>Если же я здесь (при создании нового объекта по new) загружаю большой массив данных (сотни MB или даже 1 GB) - AG>тогда да — сделать обработку исключения в конструкторе необходимо.
Размер памяти тут вообще не причем, вы не поняли проблему, которую демонстрирует этот код.
Здравствуйте, morgot, Вы писали:
M>>Баян, было уже. Дедуля просто C++ не осилил
M>современные плюсы это какой-то сюр и треш, от изначального языка только название осталось.
Да всё нормасик с современными C++. Главное, что никто не запрещает писать в любом стиле, от древнего C++98, до последнего 17-20го.
Вся моя котобаза живет местами ещё с прошлого века, и ничего. И ничто, при этом, не мешает мне использовать новые плюшки в новых проектах
CC>Для того, чтоб научиться пользоваться готовыми RAII wrappers особо много мозгов не надо а одно только это в сравнении с рукопашкой на сях и код упрощает и от кучи ошибок избавляет.
Сначала wrappers притянут, потом еще больше магии, потом еще. А потом никто в этом всей красивой сложности перестанет разбираться.
Я с El Camino Real вверху согласен. Где людей-то брать?
vsb>>Он утвеждает, что когда читает код на C, то знает, во что он скомпилируется. Насколько он прав? CC>Да в общем то нинасколько, если только не пользоваться одной и той же версией компилера вечно.
Нет, примерно понятно во что код скомпилится. А точно обычно и не надо.
Здравствуйте, gardener, Вы писали:
CC>>Для того, чтоб научиться пользоваться готовыми RAII wrappers особо много мозгов не надо а одно только это в сравнении с рукопашкой на сях и код упрощает и от кучи ошибок избавляет.
G>Сначала wrappers притянут, потом еще больше магии, потом еще. А потом никто в этом всей красивой сложности перестанет разбираться.
Ещё и ещё — это ты себя сам запугал
G>Я с El Camino Real вверху согласен. Где людей-то брать?
AA>C has everything you need to write absolutely bullet-proof code. If you can't, that's your problem, not Cs.
AA>Сказад как отрезал.
Кстати, внезапно, это подходит для любого языка
C++ has everything you need to write absolutely bullet-proof code. If you can't, that's your problem, not C++s.
Python has everything you need to write absolutely bullet-proof code. If you can't, that's your problem, not Python's.
Go has everything you need to write absolutely bullet-proof code. If you can't, that's your problem, not Go's.
Здравствуйте, gardener, Вы писали:
G>Сначала wrappers притянут, потом еще больше магии, потом еще.
Сначала сову приложат, потом натянут, потом ещё...
G> А потом никто в этом всей красивой сложности перестанет разбираться.
А потом сова лопается и всех забрызгивает
Ты как те мужики, что в лесопилку пихают всё что можно, в итоге ломают её ломом и идут дальше валить лес двуручными пилами.
Здравствуйте, gardener, Вы писали:
G>Естественно. Но других-то нет.
А куда они делись?
Впрочем можешь не отвечать, я примерно представляю куда деваются вменяемые люди из мест, где согласны работать только бородатые сишники.
Здравствуйте, gardener, Вы писали:
G>Нет, примерно понятно во что код скомпилится.
Нынче компилер способен весьма внезапно удивить. Как один из старых примеров когда компилер функцию swap реализовал одной единственной инструкцией ROL
CC>А куда они делись? CC>Впрочем можешь не отвечать, я примерно представляю куда деваются вменяемые люди из мест, где согласны работать только бородатые сишники.
Здравствуйте, Cyberax, Вы писали:
C>Это интервью из 2013-го года, насколько я помню. Тогда ещё не было Rust'а.
Rust слишком длинное название для хорошего ЯП ))))
Тут люди на 2-буквенных спотыкаются (F#, C#)
Вот честно — это типичный кусочек фубли.
Да он работает, да он работает правильно. Нет, типичный сишник тут сделает 3 ошибки.
Код пишется для людей, машине всё равно.
Какой у него на самом деле taste все могут посмотреть на примере сурсов git.
Здравствуйте, gardener, Вы писали:
G>>>Это все, что я хотел сказать о твоих репликах и вообще о качестве разговора CC>>Обожежмой, я же теперь не усну!!! G>Похоже у меня есть на тебя влияние.
Только не говори что у тебя в парсере всё так плохо что надо расставлять везде таблички
G>>>>Это все, что я хотел сказать о твоих репликах и вообще о качестве разговора CC>>>Обожежмой, я же теперь не усну!!! G>>Похоже у меня есть на тебя влияние. CC>
CC>Только не говори что у тебя в парсере всё так плохо что надо расставлять везде таблички
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, AlexGin, Вы писали:
AG>>Если эти объекты в памяти занимают по 5 байт, то исключений не будет (от слова вообще).
M>Почему?
Это из соображений — чтобы в конструкторе просто создать объект (ну и минимально инициализировать его).
А уже все действия с этим объектом — делаем дальше.
Конечно же, апологеты RAII здесь могут раскритиковать такой подход.
Но это не умаляет его удобства.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, AlexGin, Вы писали:
AG>>Если эти объекты в памяти занимают по 5 байт, то исключений не будет (от слова вообще). CC>С какого перепугу?
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, Холодный, Вы писали:
Х>>В каком смысле идеальный?
AA>Смотрел выступление где Линус приводил кусочек идеального кода. AA>Думаю идеальный в абсолютном выражении. Если мы не говорим об ограниченности ресурсов.
Вынужден повториться. Идеальный в смысле императивной парадигмы. Т.е. там где команды выполняются последовательно одна за другой. Само понятие цикла искусственное. Вспомни как ты первый раз столкнулся с сортировкой. В определении упорядоченного множества нет ни слова о циклах. Мы применяем циклы вынужденно в каком-то смысле. И нам даже кажется что это идеальная находка. А ведь это не так. Это просто привычка связанная с определенной архитектурой процессора. Представь архитектуру процессора, где команды выполняются по событиям(просто переходит по адресу указанному в подписке на событие). И как тебе такой код?
‘Создаем массив Integer A
Integer A Change |‘Две подписки на событие Change
‘В первой сравниваем текущий элемент со следующим
{A [Index] ~ A [Index+1]) | > A [Index+1]:=: A [Index] ‘Если событие > то меняем.
‘Во второй подписке сравниваем текущий элемент с предыдущим
A [Index] ~ A [Index-1]) | < A [Index]:=: A [Index -1] ‘Если < то меняем
} [] ‘Определение массива Integer
Из незнакомого здесь только знаки операции сравнения «~» и перестановки «:=:». Выполнение начинается с изменения значения какого-то элемента массива (событие Change). Так как определены подписки на события больше и меньше то, выполняются операция сравнения и реакция на произошедшие события – обмен соседними значениями, что приводит в свою очередь к изменению значения соседнего элемента массива. И так до тех пор, пока элемент не найдет свое место в массиве.
Хочу отметить что определение события может выполняться параллельно. Это тот же конвейерный подход только выполняется не команда сравнения, а полностью выражение.
Но это детали производительность. Главное, здесь нет ничего искусственного. Здесь исключительно определение упорядоченности. Т.е. если условие упорядоченности не выполняется, то обмен элементов. Мне кажется это красивее цикла.
PS. Вертикальная черта это подписка.
Здравствуйте, AlexGin, Вы писали:
AG>>>Если эти объекты в памяти занимают по 5 байт, то исключений не будет (от слова вообще).
M>>Почему?
AG>Это из соображений — чтобы в конструкторе просто создать объект (ну и минимально инициализировать его). AG>А уже все действия с этим объектом — делаем дальше.
Это какие-то левые соображения, никак не относящиеся к вопросу о том, почему new для объекта размером в 5 байт никогда не бросит исключения. Ну, по вашим же утверждениям.
Бросает ли new исключения или нет зависит не столько от размера памяти, сколько от:
* окружения, в котором работает приложения, и текущего рабочего профиля. Грубо говоря, если приложению при самой большой нагрузке нужно всего 200Mb памяти, а работает оно на машине с 65Gb, то это одно дело. Другое, когда те же 200Mb потребуются при общем объеме в 256Mb. Причем в эти 256Mb будет впихнуто все: и ОС, и само приложение, и другие параллельно работающие приложения. И это даже если не брать во внимание такую штуку, как фрагментация хипа;
* типа и принципов работы аллокатора. Если аллокатор при нехватке памяти тупо вызывает abort, а не бросает исключения, тогда об исключениях из new можно не беспокоится. Или если аллокатор просто полагается на поведение нижележащей ОС и вы работаете на Linux-е со включенным overcommit-ом. Тогда new может всегда возвращать какой-то указатель, но ваше приложение будет убито OOM killer-ом при первом обращении по нему. Если же аллокатор раздает память из небольшого фиксированного буфера и бросает исключения при отсутствии свободного места в нем, то запросто может возникнуть исключение даже при попытке выделить память под объект в 1 байт.
Так что бросающий new и использование two phase initialization -- это разные вещи и two phase initialization никак не освобождает от опасности выброса исключения из new. Ваш К.О.
Здравствуйте, AlexGin, Вы писали:
AG>>>Если эти объекты в памяти занимают по 5 байт, то исключений не будет (от слова вообще). M>>Почему?
AG>Это из соображений — чтобы в конструкторе просто создать объект (ну и минимально инициализировать его). AG>А уже все действия с этим объектом — делаем дальше.
Это вообще никак не отвечает на вопрос с какого перепугу new гарантированно не сблеванёт для размера 5 байт.
Здравствуйте, AlexGin, Вы писали:
AG>>>Если эти объекты в памяти занимают по 5 байт, то исключений не будет (от слова вообще).
M>>Почему?
AG>Это из соображений — чтобы в конструкторе просто создать объект (ну и минимально инициализировать его). AG>А уже все действия с этим объектом — делаем дальше.
Здравствуйте, serj.e, Вы писали:
SE>А теперь представим, что разработка ядра велась бы на плюсах. Огромное количество незнакомых друг с другом людей из разных организаций без единого начальства. Как организовать процесс, чтобы не прищемить друг друга? Очевидно, что каждому модулёчку для этого просто жизненно необходимо было бы выставлять наружу строго стандартизированные примитивные C-подобные интерфейсы, а не развесистые объектно-ориентированные+обобщённыe. А вся настоящая магия современного C++ поисходила бы камерно, в изоляции, не показываясь наружу. А это такой binary bloating, что мама не горюй.
С чего это было бы раздувание?
Дублирование кода? От языка не зависит, контролируется административно в проекте.
Инстанциация шаблонов? И так максимально уходят от этого (сравните, например, реализацию RB-дерева в Linux и FreeBSD).
Исключения, RTTI? Я уверен, что в ядре это всё было бы запрещено.
Зато вкусности просто в именах: namespaces, привязка методов к структурам-объектам. Инкапсуляция: всякие private и protected. Наследование — не так уже критично (сейчас делается на совместимости определений в началах структур), но можно и сделать явно.
Да, "C с классами" не настоящий C++, но для ядра пошёл бы великолепно.
SE>PS. Про время компиляции гипотетического современного разросшегося Линукса, будь он написан на современных плюсах, а также о требуемом железе для компиляции проектов подобных масштабов на C++ 17/20, я вообще промолчу.
А кто говорит про тяжёлую шаблонизацию? Нафиг не нужна.
Вот что могло бы помешать — это стандартная библиотека. Но для начала тут интересно, как Linux умудряется компилироваться в hosted режиме.
AG>>>Если эти объекты в памяти занимают по 5 байт, то исключений не будет (от слова вообще). M>>Почему? AG>Это из соображений — чтобы в конструкторе просто создать объект (ну и минимально инициализировать его).
Щито? AG>А уже все действия с этим объектом — делаем дальше.
И каким тут боком 5 байт? Почему не 4 или не 6?
Здравствуйте, vsb, Вы писали:
vsb>Он утвеждает, что когда читает код на C, то знает, во что он скомпилируется. Насколько он прав? Мне кажется, современные компиляторы настолько замудрённые, что там уже так просто не поймёшь, что во что скомпилируется. Какой-нибудь цикл развернётся в векторную инструкцию, какой-нибудь по 4 тела развернёт, какой-то не развернёт. Какую-то переменную засунет в регистр, какую-то не засунет. Как такое можно понимать.
Он скорее про выделение памяти, инициализицию и простоту понимания того, что стоит за строчкой
foo();
Как компилятор оптимизирует цикл от С и С++ не особо зависит.
Здравствуйте, varenikAA, Вы писали:
AA>Думаю идеальный в абсолютном выражении. Если мы не говорим об ограниченности ресурсов.
Если говорить об ограниченности ресурсов, то в первую очередь надо экономить мышление. Но, тут есть локальные проблемы и глобальные. На локальном уровне и когда решение можно понять одним взглядом, то большое значение имеет привычка (он же опыт). Глобально это когда задача сложна и речь может идти даже о выборе языка, архитектуры и метода построения системы. Понятно, что экономия на глобальном уровне не так очевидна, но дает больший эффект. Но, тема очень серьезная. И для отдельного и большого разговора.
То, что мы увидели на ролике можно получить еще более идеальный код. Обозначить удаление элемента из списка кодом 1, добавление кодом 2, все остальное кодом от 3 и т.д. Транслятор с такого языка проще пареной репы. А программирование вообще чепуха. Но, думаю вам такая экономия не понравится.))) Хотя почти идеал!!!
Здравствуйте, Privalov, Вы писали:
AA>>Справедливости ради замечу, что Линус говорит о работе с железом, вероятно речь не идет о бизнес-приложениях или вэбе.
P>Не так давно тут высказывались мнения, что веб нужно писать на Ассемблере.
Щетаю точнее авторететно заевляю што это правельная идейа!
Х>Вынужден повториться. Идеальный в смысле императивной парадигмы. Т.е. там где команды выполняются последовательно одна за другой.
И какое отношение последовательное вьіполнение имеет к вопросу?
Есть, вообще-то архитектурьі, где командьі работают параллельно.
КД>>>Получил ответ — "да по#ер". R>>Реально "похер" от МС?
_>легко. пруфы можно найти в недавно выложенных исходниках XP, поиском по словам "shit", "fuck" и т.п
Т.е. таки слив, жалко.
Х>>Вынужден повториться. Идеальный в смысле императивной парадигмы. Т.е. там где команды выполняются последовательно одна за другой. R>И какое отношение последовательное вьіполнение имеет к вопросу? R>Есть, вообще-то архитектурьі, где командьі работают параллельно.
Сори. Параллельное выполнение в императивной парадигме это частная фишка типа конвейерной обработки операции сравнения и перехода или отдельные потоки. Новая парадигма позволяет моделировать физические объекты так как, как это происходит в реальном мире. Без необходимости в прерываниях. Идет естественное распараллеливание моделирования функционирования объектов. Там идеальность выглядит по другому. И нет необходимости в циклах по причине иного определения и работы с множествами (группами). Это отдельный и длинный разговор. Если есть желание, то можем отдельно.
Здравствуйте, Холодный, Вы писали:
Х>Сори. Параллельное выполнение в императивной парадигме это частная фишка типа конвейерной обработки операции сравнения и перехода или отдельные потоки. Новая парадигма позволяет моделировать физические объекты так как, как это происходит в реальном мире. Без необходимости в прерываниях. Идет естественное распараллеливание моделирования функционирования объектов. Там идеальность выглядит по другому. И нет необходимости в циклах по причине иного определения и работы с множествами (группами). Это отдельный и длинный разговор.
Если у вас две руки и берёте за один раз по кирпичу в руку, вам придётся совершить 5000 итераций, чтобы перенести 10000 кирпичей. Если у вас 100 рук, то хватит 100 итераций. Но цикл всё равно будет.
А одновременно обрабатываемых понятий мало кто из нас удержит больше 7. Зато сама обратотка сложнее.
Пока что нет данных, что мозг работает иначе, чем событийный движок с пачкой задач, которые соревнуются за приоритеты.
X> Если есть желание, то можем отдельно.
Желание увести такие разговоры в личку обычно означает слабость позиции.
Здравствуйте, netch80, Вы писали:
N>Если у вас две руки и берёте за один раз по кирпичу в руку, вам придётся совершить 5000 итераций, чтобы перенести 10000 кирпичей. Если у вас 100 рук, то хватит 100 итераций. Но цикл всё равно будет.
1. Вы сформулировали задачу (перенести 10000 кирпичей) остальное ограничения которые вы сами придумали. Представьте что это уже дело компьютера. Заодно отмечу что задача сформулирована в терминах событий. Событие это изменение состояния памяти. Изменение памяти выполняется выражением. (в вырожденном случае это команда Move). Выражение это не что иное как высказывание в философском смысле. Т.е. классическое "Снег белый" — это некое выражение. (свойство некого объекта =белый). Истинность этого выражения и есть событие! Далее можем рассуждать как в Прологе. Высказывание это понятия. И далее логический разбор. Но, мы уходим от темы..
А тема в том, что определение истинности события это метафункция (см. работы Тарского) и может выполняться параллельно!
Осталось придумать событийную машину и язык который бы все это заставил выполняться. И тогда количество процесоров может привлекаться любое.. X>> Если есть желание, то можем отдельно.
N>Желание увести такие разговоры в личку обычно означает слабость позиции.
Я не люблю спорить. Просто разговор реально очень глубокий что б его здесь продолжать. Я разработал и архитектуру такого процессора и язык. Просто не лезу никуда. Слишком стар и амбиций таких нет. Если есть молодые и интересующиеся могу поделиться. Для тех кто мечтает миллиард (или больше) отжать. Особенно в области автоматизации. Легко.
Здравствуйте, netch80, Вы писали:
N>Пока что нет данных, что мозг работает иначе, чем событийный движок с пачкой задач, которые соревнуются за приоритеты.
Да. Вы правы. Мозг работает именно так.
Здравствуйте, AlexGin, Вы писали:
AG>Так, например, если я запросил (примерно) 1 KB памяти — то здесь никогда исключения не будет. Зачем тогда закладываться на это? AG>Если же я здесь (при создании нового объекта по new) загружаю большой массив данных (сотни MB или даже 1 GB) - AG>тогда да — сделать обработку исключения в конструкторе необходимо.
Ну строго говоря, ты и в том и в другом случае не получишь исключения при аллокации, но можешь получить SIGSEGV при первом обращении. Если будешь аллоцировать гигабайт, то есть шанс, что тебе "повезет", и место в адресном пространстве твоей задачи кончится быстрее, чем память в системе, тогда можешь и исключение получить. В 32-битном режиме шансы такого расклада ощутимо выше.
Я всегда проверяю результаты аллокации, хотя сложно утверждать, что от этого кому-то становится лучше.
Здравствуйте, so5team, Вы писали:
S>* отсутствие переопределенных операторов/конструкторов копирования (даже не будем сейчас про C++11 с сего move semantic). Из-за чего объекты TObj можно копировать с побитовым копированием значений указателя из одного TObj в другой. Что затем приведет к double free. Оператор/конструктор должен быть для такого объекта либо явно реализован, либо явно запрещен (в C++03 и более древних стандартах для этих целей был специальный трюк с объявлением оператора/конструктора в private секции без реальной реализации).
Надо сказать, эти явные запреты на копирование, как бы они не были синтаксически оформлены, жутко замусоривают код...
Здравствуйте, Pzz, Вы писали:
Pzz>Надо сказать, эти явные запреты на копирование, как бы они не были синтаксически оформлены, жутко замусоривают код...
Зато спасают от кучи ошибок. Так что цена оправдана.
Здравствуйте, so5team, Вы писали:
Pzz>>Надо сказать, эти явные запреты на копирование, как бы они не были синтаксически оформлены, жутко замусоривают код...
S>Зато спасают от кучи ошибок. Так что цена оправдана.
Замусоривание кода само по себе провоцирует ошибки. Так что сложно сказать, в какую сторону сдвинется баланс.
Здравствуйте, so5team, Вы писали:
Pzz>>Замусоривание кода само по себе провоцирует ошибки.
S>Так можно договорится и до того, что модификатор const замусоривает код.
Модификатор const глаза не позолит, в силу своей компактности.
С другой стороны, лично меня модификатор const ни разу еще не защитил от ошибки. А вот писать его в своих интерфейсах я забываю вполне регулярно. Лучше бы, все параметры по умолчанию были const, как в некоторых новомодных языках программирования.
Pzz>>Так что сложно сказать, в какую сторону сдвинется баланс.
S>В правильную, очевидно.
Pzz>Ну строго говоря, ты и в том и в другом случае не получишь исключения при аллокации, но можешь получить SIGSEGV при первом обращении.
Ну, overcommit memory — тоже никто не обещал.
Так что можно получит можно не получить как исключение так и SIGSEGV. Или SIGKILL от OOM
Виртуальный мир — опасная штука
Как много веселых ребят, и все делают велосипед...
[]
Pzz>Модификатор const глаза не позолит, в силу своей компактности.
Pzz>С другой стороны, лично меня модификатор const ни разу еще не защитил от ошибки.
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, varenikAA, Вы писали:
S>что бы вы здесь не говорили S>тк сторонник минимализма
Тоже бы наверно писал на си, раньше узнал про плюсы(ничего не понял) и шарпы(удивили не столько синтаксисом, хотя после паскаля было приятно везде ставить фигурные скобки, сколько простотой компиляции).
Сейчас кодирую на шарпах, ЯП не смотря на расскрученность и якобы современность таковым не является.
взять хотя бы вот такой код(не мой к счастью):
}
}
finally
{
if (File.Exists(packageName))
File.Delete(packageName);
}
}
ни catch, ни return, и самое главное, в finally код, который может бросить два исключения как минимум. C# даже не предупреждает об этом.
Т.е. единственный шанс узнать что что-то пошло не так это падение приложения.
Считаю, что c идеальный ЯП в качестве первого учебного ЯП. В дальнейшем должны обязательно изучаться Common Lisp(только не деалекты типа clojure) и что-то типа haskell(F#, Ocaml, Elm).
Здравствуйте, Nuzhny, Вы писали:
N>Кажется, что они всё своё плюсовое добро тестируют с помощью Application Verifier, в том числе и на нехватку памяти. Может быть, ты видел не исходники Винды и даже не исходники приложения, которое идёт вместе с ней?
Исходники венды -- понятие растяжимое. Ядро пишется на каком-то верифициремом гибриде
с и с++ (приводил заметку в жж сотрудника, которые разрабатывал что-то для графики,
он описывал процесс). Все остальное,user space, может писаться на чем угодно (на плюсах чаще всего).
Здравствуйте, sergey2b, Вы писали:
S>если бы Cтрауструп ставил Торвальдсу диагноз то это было бы норм (но как правило образованные люди тактичны и не опускаються до такого) S>а когда человек не решавший аналогичного уровня задач, это как бы странно
Сперва добейся?
Проблема Креатора не в том что он его то не добился, а в том что выдает утверждения даже не попытавшись их как о аргументировать. Демагогия нижайшего пошиба.
Здравствуйте, morgot, Вы писали:
M>Здравствуйте, Marty, Вы писали:
M>>Баян, было уже. Дедуля просто C++ не осилил
M>современные плюсы это какой-то сюр и треш, от изначального языка только название осталось.
M>Только Си спасет мир. Правда, последнее время и туда "умники" с комитетом то ООП хотят всунуть, то вот массивы динамические на этапе инициализации. Но все же.
DotNet код, скомпилированный в Native с помощью DotNet Core RT, вроде бы тоже можно вызывать из других прог аналогично через C совместимые вызовы?
Понятно, что они unsafe, но зато их много, свой RUST код можно писать safe, а вызовы внешних изолировать в небольшие фрагменты unsafe кода, что потом облегчает отладку и поиск ошибок.
