The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Обзор проблем в коде на C/C++, вызванных неопределённым поведением компилятора

07.07.2017 10:43

Джон Регир (John Regehr), профессор университета штата Юта, участвующий в разработке Clang и занимающийся исследованиями в области неопределённого поведения программ, подготовил полезный для разработчиков обзор ситуаций, при которых поведение программы становится неопределенным и приводит к получению проблем с использованием памяти и указателями при сборке разными компиляторами. В статье не только описаны возникающие проблемы, но и предложены способы для их выявления, а также оценена эффективность применения для обнаружения неопределённого поведения типовых отладочных инструментов, таких как Address Sanitizer (ASAN), UndefinedBehaviorSanitizer (UBSan), MemorySanitizer (MSan), ThreadSanitizer (aka TSan) и Valgrind.

  1. Главная ссылка к новости (https://blog.regehr.org/archiv...)
  2. OpenNews: Дэниэл Бернштейн выступил с инициативой создания Си-компилятора для защищённого ПО
  3. OpenNews: Оптимизация кода компилятором может привести к появлению проблем безопасности в приложениях
  4. OpenNews: В DNS-сервере BIND устранен серьёзный сбой, возникший из-за изменений в оптимизаторе GCC
  5. OpenNews: Разработчики Mozilla столкнулись с проблемой производительности в GCC 4.5
  6. OpenNews: Линус Торвальдс выступил с резкой критикой GCC 4.9.0
Лицензия: CC-BY
Тип: английский / Практикум
Ключевые слова: undefinedbehavior, debug, memory, gcc, clang
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (161) Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, A.Stahl (ok), 11:12, 07/07/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +31 +/
    Во-первых -- 3 галлона пива господину Регеру за очень краткие и ёмкие кусочки кода.
    Во-вторых г-н Регер показал, что UB это обычно результат наркоманского кода.
    Арифметика указателей? Ок, все мы её в той или иной мере используем, но нужно знать и меру.
    Самое важное правило (все новички о нём знают[сами для себя и выводят], а вот люди с опытом часто забывают) -- код должен быть простым и понятным. В 21 веке компиляторы лучше оптимизируют под платформу чем человек. Поэтому нужно писать простой и понятный код. Эффективный код -- удел компилятора. Да, некоторые моменты (обход прямоугольной матрицы и т.п.) до сих пор актуальны, но это не усложняет код и вполне вписывается в концепцию здравого смысла.
     
     
  • 2.2, Zoolander (?), 11:38, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Как думаете, почему профессионалы подвержены болезни усложнения кода? У них крыша едет? Или они думают, что все могут в памяти держать?
     
     
  • 3.3, Iaaa (ok), 11:45, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тоже вижу слишком часто неоправданное усложнение. Может "не солидно", "что я как джун какой-то писать буду"?

    Ну а вообще, "Real Programmers don't comment their code. If it was hard to write, it should be hard to understand." (c)

     
  • 3.4, A.Stahl (ok), 12:04, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +16 +/
    Многие профессионалы сталкиваются с ситуацией, когда они сами пишут и проектируют.
    Соответственно они это делают как им удобно.
    Вот, например, я -- терпеть не могу шаблоны. STL использую, но сам не пишу. Это такой мой "бзик". Также я не уловил прелесть смартпоинтеров. У меня и с обычными указателями никаких проблем нет. Нахрена мне умные?
    А вот теперь представь, что я  -- тимлимд (а я на плюсах ~10 лет пишу, так что опыт имеется и на такую должность вполне могу упасть). И как себя будет чувствовать молодёжь, которая ни асма ни Си не нюхала? Я со своими требованиями буду для них "придурок, усложняющий код, когда можно написать auto". И они будут правы. И я буду прав. Вот так.
    Это разница в поколениях и мировоззрениях. Классическая проблема отцов-сыновей.
     
     
  • 4.7, Crazy Alex (ok), 12:15, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А exception safety, move semantics, вот это всё - тоже игноришь? Их без умных указателей не особо реализуешь... То есть можно конечно, но возни же куча.
     
     
  • 5.11, A.Stahl (ok), 12:50, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Исключения не люблю, а вот move semantics почти не нужно если у тебя всё хорошо с обычными указателями. Если писать в Ява-стиле, то да -- эта штука реально спасает. Сишнику это не очень критично. У сишника не часто бывают нюансы когда ты "передаёшь эстафету" и умираешь:) Да и сишник всегда может передать указатель и забыть/забить.
    Но да, иногда эта штука крута и прикольна. Но ничего такого.
     
     
  • 6.17, Crazy Alex (ok), 13:57, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Создать объект и отдать его контейнеру - это редкая операция? А если нет - то либо умные указатели, либо move semantics, либо с ровного места теряем в производительности на копированиях объектов.
     
     
  • 7.21, A.Stahl (ok), 15:04, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Я обычно передаю указатель. Редко бывает, когда объект нужен много кому и непонятно кто должен его удалять.
     
     
  • 8.26, Crazy Alex (ok), 15:36, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А у меня - как-то через раз. Лежит себе вектор указателей на объекты, чему-то один из них понадобился - оно его получило. Сохранило где-то или нет - с умными указателями мне не интересно, как и то, как соотносятся сроки жизней контейнера и клиента. Для стаистики, например - самое оно. Посчитал, сложил, дал интерфейс, забыл.
     
     
  • 9.29, Аноним (-), 15:58, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Код является простым когда простой инспекцией удается выловить границы жизни объекта без того чтобы тратить время на анализ исполнения. Как раз с умными, автоматическими, неявными операциями и указателями код не становится простым и понятным, получается такая "вещь в себе". Так что лучше явно.
     
     
  • 10.31, A.Stahl (ok), 16:15, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Красиво казал. Меня там минусуют, но они не совсем понимают суть. Я не против новых "фишек", просто некоторые нюансы мне не нравятся. Не более того.
    Я просто стараюсь оставлять код очевидным. Очевидным даже для сишников (я и сам такой), а не только для плюсовиков, которые следят за последними стандартами.
    Я не против. И никогда не использовал положение чтобы что-то запрещать. Просто некоторые вещи я не использую (даже не не использую, а избегаю использовать). Не более того.
     
     
  • 11.54, Crazy Alex (ok), 21:58, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Фишка в том, что "очевидный для сишников" и "очевидный для плюсовиков" - вещи разные, и чем больше масса кода, тем больше  в них противоречие.

    Подход сишника - "каждый конкретный кусок должен быть ясен вплоть до примерного набора инструкций процессора". Подход плюсовика - "каждый конкретный кусок должен быть ясен в терминах алгоритмики и тех понятий, в которых мы пишем, а ниже лезем только при явной необходимости -  и желательно один раз, добавляя новое понятие". То самое implementation hiding, loose coupling и подобное. Идеальный пример здесь - шаблоны (в которых мы реализуем что-то очень общее) и при нужде - их специализации (где лезем в детали).

     
     
  • 12.60, Аноним (-), 22:33, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это лишь ваше представление которое основано, к сожалению, на незнании или малоо... текст скрыт, показать
     
     
  • 13.69, Crazy Alex (ok), 01:40, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ох как забавно.

    Подход "узнаем как должно работать и реализуем сразу" (велосипед, как правило) - это студенческая наивность. Потому что вменяемый разработчик вообще на любом языке будет думать не просто "как должно работать", а как обеспечить минимум багов, как упростить поддержку, как дать разумные возможности расширения, как реализовать обработку ошибок, как учесть многопоточныость и прочее. И это всё собственно реализацию может превосходить в разы по размерам и сложности.

    Так вот сюрприз - всякое "правильное" ООП, шаблоны (которые паттерны) и подобное - как раз об этом. Чтобы сделать заведомо известными, проверенными способами. Которые не только сами по себе хороши, но и другие люди их сразу поймут и будут знать, что с этим кодом делать и чего ждать.

    Ну а "вот и я уперся в свое время и больше я ООП не трогаю если только не приходится" это вообще мило. Может, у вас просто мозгов не хватило? Судя по первой части - вполне может быть.

     
     
  • 14.74, Аноним (-), 04:17, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Очень забавно потому что вот это - вменяемый разработчик вообще на любом языке ... текст скрыт, показать
     
  • 12.80, pripolz (?), 11:34, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Подход сишника - "каждый конкретный кусок должен быть ясен вплоть до примерного набора инструкций процессора". Подход плюсовика - "каждый конкретный кусок должен быть ясен в терминах алгоритмики и тех понятий, в которых мы пишем, а ниже лезем только при явной необходимости -  и желательно один раз, добавляя новое понятие".

    броо! +!!!
    А вообще я редкостный хейтер всего кроме Си (хотя писал на 100 языках), потому, что вот эта философия новой школы "я приложу старания, для того, чтобы НЕ ЗНАТЬ, как это работает внутри" это ... сами понимаете. Не просто палка в колесо, а супер заумная палка, героически внедряемая под покровом ночи.

     
     
  • 13.100, Vkni (ok), 17:51, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А вообще я редкостный хейтер всего кроме Си (хотя писал на 100
    > языках), потому, что вот эта философия новой школы "я приложу старания,
    > для того, чтобы НЕ ЗНАТЬ, как это работает внутри" это ...
    > сами понимаете. Не просто палка в колесо, а супер заумная палка,
    > героически внедряемая под покровом ночи.

    А вы и так не знаете, не переживайте. Даже пишущий на ассемблере не знает, как оно будет выполняться на современном процессоре унутре. Даже в каком порядке.

    Более того, язык Цэ разработан для однопроцессорной машины типа PDP, как известно. Соответственно, на других машинах, типа Itanium/Эльбрус или видеокарты или многопроцессорные Sparc/Power, он работает несколько неоптимально.

     
     
  • 14.124, Аноним (-), 01:44, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А вы и так не знаете, не переживайте. Даже пишущий на ассемблере не знает, как оно будет выполняться на современном процессоре унутре. Даже в каком порядке.

    Это и не нужно, во-первых. Во-вторых речь не о машинном исполнении была.

    > Более того, язык Цэ разработан для однопроцессорной машины типа PDP, как известно. Соответственно, на других машинах, типа Itanium/Эльбрус или видеокарты или многопроцессорные Sparc/Power, он работает несколько неоптимально.

    Ложное утверждение. Как будет работать на процессорах зависит от того как напишешь, что напишешь и во что это будет оттранслировано в конечном счете. Кстати, в отличии от С++, на Си можно формировать нужные для компилятора единицы трансляции которые нельзя и нельзя будет сформулировать в рамках новомодных и "правильных" догм С++. Надеюсь вы сами догадаетесь почему оно так.

     
     
  • 15.127, Vkni (ok), 02:08, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, на каком-то уровне приходится останавливаться Ну можно остановиться на а... текст скрыт, показать
     
     
  • 16.129, Аноним (-), 02:46, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Зачем вообще вы снова асм тянете, я не пойму Вот люди пишут на java и не парятс... текст скрыт, показать
     
     
  • 17.130, Vkni (ok), 02:56, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем вообще вы снова асм тянете, я не пойму.

    Ветка такая. См. несколько комментов выше.

     
     
  • 18.133, Аноним (-), 05:48, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    В 12.54 Crazy Alex написал свое ОГРАНИЧЕННОЕ (!) понимание программирования в Си на что мне пришлось дать в 12.60 ему ортогональный ответ.
    Вижу вы согласились с предложенным в 12.54 толкованием, но если если вы следили за веткой 12.54 -> 12.60, то должны были понять что ситуация осталась спорной.
    Получается что вы все время апеллируете к асму только из-за ограниченного понимания Си прользователем Crazy Alex ? Ничего не смущает?
     
     
  • 19.135, Vkni (ok), 07:29, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Получается что вы все время апеллируете к асму только из-за ограниченного понимания
    > Си прользователем Crazy Alex ? Ничего не смущает?

    Я писал недавно зарегистрировавшемуся товарищу на букву p.

     
     
  • 20.140, Аноним (-), 16:14, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Точно, сообщение 12.80 от пользователя pripolz. Но это не меняет ситуацию с постоянным обращением к асму.
     
  • 11.61, Аноним (-), 22:41, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я не кравиво сказал, а рассказал как оно обстоит в реальном программировании. У меня складывается ощущение что местные кто печатает здесь заумные термины, на практике их используют примерно ноль раз. Мне нравится философия Java и еще больше нравится Си, но не вычурное ботанство С++ потому что используя "фишки" С++ ты себя просто заковываешь в кандалы. Я не вижу преимущество в С++, даже банальные перегрузки операции часто вызывают семантическую неоднозначность. То есть надо лезть и разбираться. Убого и долго.
     
  • 10.52, Crazy Alex (ok), 21:45, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Умные указатели сложность, в общем, не особо прибавляют, если дать себе труд раз в жизни разобраться, как они работают. Поскольку они стандартны - только один раз и надо это сделать. И тоже будет всё просто - только на других предпосылках. Там случаев-то - раз-два и обчёлся - https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#R - пяток экранов на все принципы.
     
     
  • 11.59, не программист (?), 22:23, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Я хорошо знаю и умею использовать умные указатели и для меня это уже пройденный этап. Я просто хотел указать на ситуацию когда от них больше проблем чем пользы.
     
     
  • 12.68, Crazy Alex (ok), 01:31, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Единственная "Ситуация, когда от них больше вреда, чем пользы" - это когда в программке пятьсот строк, десяток классов и один автор. Для всего, что сложнее "простой инспекцией выловить границы жизни объекта без того чтобы тратить время на анализ исполнения" - идея заведомо идиотская. Там уже надо думать не о вылавливании сроков жизни, а о том, чтобы гарантировать и существование, и своевременное уничтожение объектов - в том числе в чужом коде, который про ваши внутренние соглашения понятия не имеет и человеком, который впервые видит ваши интерфейсы (а в реализацию в принципе не полезет). Смарт поинтеры дают для этого стандартный, понятный любому квалифицированному плюсовику инструментарий.
     
     
  • 13.71, Аноним (-), 03:55, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Вы вообще программировали что-нибудь серьезное Когда вы будете думать о том как... текст скрыт, показать
     
  • 6.58, Аноним (-), 22:19, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А как же Вы обрабатываете ошибки? Я Плюсы знаю неплохо, но пишу на чистом Си. Простые задачи выношу в Питон. На обработку ошибок в Си, выставления errno и т.п. уходит иногда до половины кода (с учётом библиотеки под эти дела). Мне всегда было интересно, как у серьёзных проектов на плюсах дела с обработкой ошибок обстоят. try... намного увеличивают количество кода и уменьшают читабельность. Я уже не говорю, что я не смогу вызвать конструктор стекового объекта внутри try..., т.к. ограничу объект его областью видимости. Но в то же время программа должна корректно обрабатывать ошибки и реагировать на них. Так как Вы обходитесь без исключений то?
     
     
  • 7.81, pripolz (?), 11:52, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    я всю обработку ошибок кладу в макрос, в котором и печать в лог номера строки ко... текст скрыт, показать
     
     
  • 8.119, Аноним (-), 22:47, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, у Вас по сути примерно такая же обработка ошибок, как и у нас. А про плюсовиков, - да, скорее всего такая тенденция есть с языками более высокого уровня. Потому и спрашивал про серьёзные проекты. Ведь выделение памяти в ресурсоёмких приложениях должно быть проверяемым. Я например, в случае невозможности выделить память, просто сбрасываю кэш. Будет работать медленнее, но зато будет. Правда тут тоже нюансы, - другие приложения, на которые идёт завязка могут просто скрешиться. В том же GTK нет смысла обрабатывать полноценно ошибки, т. к. сам GTK в любой момент может сделать assert на невыделенной памяти. Но это проблема частично решаемая разными способами.
     
  • 8.121, Vkni (ok), 23:54, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Освобождение ресурсов при выходе обеспечивается goto ErrorLabel вместо простого return;

    Их должно быть несколько, если выделяются сразу несколько ресурсов. И не перепутать порядок. А если ресурсы выделяются/освобождаются в цикле, то так уже не получится сделать:

    for( int i = 0; i < 5; i++)
    {
        f = fopen(file[i],"rt");
        ...
          <глобальная ошибка>
        ...
        fclose(f);
    }

     
     
  • 9.126, pripolz (?), 02:08, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    инициализация нулями спасёт мир

    for (int i = 0; i < 5; i++)
        if (f[i])
            fclose(f[i]);

     
     
  • 10.128, Vkni (ok), 02:14, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > инициализация нулями спасёт мир

    Это костыль под конкретный случай. Взять какую-нибудь другую структуру и опа.

     
  • 10.131, pripolz (?), 03:29, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > инициализация нулями спасёт мир
    > for (int i = 0; i < 5; i++)
    >     if (f[i])
    >         fclose(f[i]);

    упс, не по теме написал. Сори.

     
  • 9.136, Аноним (-), 09:15, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    У нас на метки с освобождением ресурсов и восстановлением уходит до половины тела функций. В функциях инициализации их может быть и 10, и 15. А если цикл с выделением памяти, к примеру,  - то подобные куски кода выгоднее выносить в отдельные функции. По ошибке обходить цикл в обратку и всё освобождать. Тогда код основной функции будет более читабельным.
     
  • 5.13, yet another anonymous (?), 12:56, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > exception safety, move semantics, ...  Их без умных указателей не особо реализуешь...

    Бред.

     
     
  • 6.18, Crazy Alex (ok), 14:00, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Говорю же - можно, но морока. Придётся самому отслеживать все случаи, когда надо прибить указатель - а ради чего?

    Что характерно - это ж не я придумал, можете любого плюсового гуру поглядеть - здесь разногласий нет с того самого 11-го года.

     
     
  • 7.22, yet another anonymous (?), 15:05, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    move не имеет к *_ptr отношения. *_ptr подразумевают move. (при достаточно полной реализации). Поэтому "для реализации move-семантики нужны умные указатели" --- набор слов, не складывающийся в осмысленную фразу.

    Если фраза подразумевала
    "при релизации move-семантики объекта обязательно нужны умные указатели", то тоже бред выходит: это зависит от объекта.

    > А exception safety, move semantics, вот это всё - тоже игноришь? Их без умных указателей не особо реализуешь...

     
     
  • 8.23, Crazy Alex (ok), 15:31, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Нет. Подразумевалось "умные указатели радикально упрощают реализацию move-семантики". Если у тебя поля - обычные указатели, тебе надо для каждого выяснить, как именно он инициализируется, кто им владеет и так далее. Если умные - из типа всё очевидно и есть стандартные правила обращения с ними. Когда речь не о программках из десятка классов - это принципиально.
     
     
  • 9.35, yet another anonymous (?), 17:18, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Т.е. второй вариант.

    Мне нравится такой подход: неявно подразумевается вполне определённая реализация с вполне определёнными предположениями/гарантиями/etc. Все остальное объявляется несущественным/неактуальным/безнадёжно устаревшим и т.п. Так держать! Вы победитель!

     
     
  • 10.53, Crazy Alex (ok), 21:51, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Оно везде так. Называется "best practices". Использование ничего-то отличающегося надо обосновывать, потому что для этого отличающегося нет сто раз проверенных методов применения, возможных граблей и их обходов, оценок эффективности, готовых инструментов и прочего. В софте это, собственно, гораздо слабее выражено, чем в других областях инженерии, так что не вам бы плакаться.
     
  • 4.25, kai3341 (ok), 15:35, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Или ещё вариант: на этапе проектирования закладывается больше гибкости и универсальности.
    Если она вся не используется, код переусложнён. Тогда говорят "Фу, оверинжениринг".
    А вот если её становится недостаточно, начинается адище.
     
  • 4.34, anonymous (??), 17:13, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > И они будут правы.

    Они будут правы.

    > И я буду прав.

    А вот вы не будете. Будете старым пердуном, который не успевает за ритмом развития инструмента, но прикрывается словами о простоте и 10 годах опыта.

     
     
  • 5.82, pripolz (?), 12:30, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> И они будут правы.
    > Они будут правы.
    >> И я буду прав.
    > А вот вы не будете. Будете старым пердуном, который не успевает за
    > ритмом развития инструмента, но прикрывается словами о простоте и 10 годах
    > опыта.

    Почитайте книгу "Современный и эффективный С++". Там автор докажет вам, что auto - тот ещё фрукт. В конце он приходит к выводу, что инициализируя auto "хорошо бы добавить статик каст". Т.е. уже начинается борьба ради ауто.

    Так что, всё как раз наоборот. Они не будут правы (просто не знают проблем), а он прав будет, потому что знает, а не не знает.

     
     
  • 6.97, anonymous (??), 17:32, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > В конце он приходит к выводу, что
    > инициализируя auto "хорошо бы добавить статик каст".

    Правда? Может вы что-то не так вычитали? А если так, то замените auto на что-то конкретное вот в таком случае, например:
    [code]auto local_fn = [&](auto & a) {...};[/code]
    Ну или static_cast вставьте где-нибудь, где вам больше нравится.

    А еще попробуйте обойтись без auto внутри шаблонов, что-то вроде:
    [code]template<typename A, typename B> auto f(A a, B b) {
      auto tmp = a + b;
      ...
      return tmp + 1;
    }[/code]

    > Так что, всё как раз наоборот. Они не будут правы (просто не
    > знают проблем), а он прав будет, потому что знает, а не
    > не знает.

    Он как раз не знает. И не использует то, чего не знает и боится.

     
  • 6.99, Vkni (ok), 17:46, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Почитайте книгу "Современный и эффективный С++". Там автор докажет вам, что auto
    > - тот ещё фрукт.

    Можно ссылку?

     
     
  • 7.105, pripolz (?), 19:29, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Почитайте книгу "Современный и эффективный С++". Там автор докажет вам, что auto
    >> - тот ещё фрукт.
    > Можно ссылку?

    Там ниже в беседе кидали на магаз О-Райли. Effective Modern C++ Майерса.

     
     
  • 8.110, Vkni (ok), 19:57, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Там ниже в беседе кидали на магаз О-Райли. Effective Modern C++ Майерса.

    А-аа, Майерс. Просто modern C++ - это в разные времена совершенно разное.

     
  • 3.5, Crazy Alex (ok), 12:08, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    1) Профессионалы часто пишут что-то большое, и долго. Со временем качество кода в проекте неизбежно падает, и приходится колдовать. Нет, рефакторинг возможен (точнее, окупается) не всегда.

    2) Профессионалы часто правда могут спокойно переварить довольно сложный код, а не только "думают", что могут. И как сложный его не воспринимают. Это вполне развиваемый навык, просто времени много уходит.

     
     
  • 4.66, Алконим (?), 01:23, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Если будет падать качество кода, то упадёт и скорость разработки, и проект упрётся в стену. У професионалов, качество кода к концу проекта растёт а не падает, скорость разработки растёт, возможности растут. Это сложно, это нужно знать и уметь процесы и методики, это геморойно и не связано с програмированием вообще, но оно того стоит когда нужно выиграть клиента. Клиенты сейчас умные пошли — заказывают проект сразу в двух конторах (часть там, часть там), а потом избавляются от неудачника через несколько месяцев и передают их часть третей конторе, и т.д. Так что про «неизбежно падает» рассказывай нашим конкурентам а не нам.
     
     
  • 5.76, Вареник (?), 08:08, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Любой проект постепенно обрастает заплатками и требует специальных мер от команды, чтобы не превратиться в "лапшу".
     
  • 5.77, Вареник (?), 08:13, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Написать модуль по спеку - не совсем жизненный цикл проекта.

    Тот же проект потом еще кучу контракторов/сотрудников переживет, сотни патчей и часто - несколько хозяев (т.е. тех самых "заказчиков"). И вот тогда уже можно говорить о качестве кода - когда проект сменил трех владельцев, десятки не связанных между собой сотрудников и в нем все еще можно разобраться и принципы модульности, архитектуры остались соблюдены.

     
  • 5.79, Аноним (-), 11:22, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Полностью поддерживаю. В нашей команде качество кода растёт со временем. Во-первых, программисты становятся более опытными и учатся друг у друга, а во-вторых, приходится делать рефакторинг старого кода при добавлении новых функций. Рефакторинг иногда бывает длительным, но себя полностью окупает, т.к. дальнейшая разработка и внедрение новых функций будет идти на порядок быстрее.
     
  • 3.9, Аноним (-), 12:30, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Желание того что-бы их код работал так как они решили, а не как вздумается компилятору ( сегдня быстрее, завтра медленнее)
     
  • 3.117, anonymous (??), 22:26, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Как думаете, почему профессионалы подвержены болезни усложнения кода?

    я за 15 лет вокруг как раз вижу что становясь профессионалами люди начинают упрощать код

     
  • 2.14, Аноним (-), 13:15, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > В 21 веке компиляторы лучше оптимизируют под платформу чем человек.

    Скажи это новым появляющимся языкам программирования или таким языкам как C#, у которого компилятор в принципе не имеет право заниматься тщательной оптимизацией.

     
     
  • 3.30, Анончик (?), 16:04, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> В 21 веке компиляторы лучше оптимизируют под платформу чем человек.
    > Скажи это новым появляющимся языкам программирования или таким языкам как C#, у
    > которого компилятор в принципе не имеет право заниматься тщательной оптимизацией.

    Ну, в этом есть и один плюс - C# либы/екзешники из-за этого очень легко восстановить до нормального кода вплоть до комментариев.

     
     
  • 4.36, Аноним (-), 17:29, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > C# либы/екзешники из-за этого очень легко восстановить до нормального кода вплоть до комментариев.

    Я про JIT говорил. Первоначальная компиляция в CIL (как и у Java в их промежуточный байт код) происходит вообще без оптимизаций, отсюда да, можно всё восстановить.

    А вот с JIT'ом у C# (ладно-ладно, не C#, а CLR) есть некоторые проблемы вплоть до того, что если в цикле for у тебя стоит return, а не break с последующим return, то разность скорости выполнения этого цикла for достигает чуть ли не 2 раз (возможно, я утрирую, не помню точных цифер, но общий смысл такой).

     
  • 4.37, _ (??), 17:54, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • –5 +/
    У нормальных людей есть исходники с комментами, дока, и мэйл лист с аффтарами.
    Но вантузятники должны страдать! (С)
     
     
  • 5.57, Анончик (?), 22:13, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У нормальных людей есть исходники с комментами, дока, и мэйл лист с
    > аффтарами.
    > Но вантузятники должны страдать! (С)

    RE занимаются не только вантузятники и не только на вантузе.

     
  • 2.24, Ivan_83 (ok), 15:32, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Это не отменяет 100500 вариантов написания popcnt, для начала, которые хер компелятор распознает чтобы заменить на popcnt, да и сам popcnt не везде есть.
    И получается что лучше один раз хорошо написать этот низкоуровневый кусок руками чтобы он гарантированно работал везде быстро.

    Есть ещё 100500 разных вумных ручных оптимизаций базовых математических операций, которые нужны для работы с длинными числами.
    Это всё никакой компелятор тебе не оптимизирует.

    Но да, там где можно написать понятно и упростить лучше так и делать, с этим трудно спорить.

     
  • 2.33, Comdiv (ok), 16:53, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Во-вторых г-н Регер показал, что UB это обычно результат наркоманского кода.

    Это проблема восприятия маленьких понятных примеров. Для того, чтобы показать примеры, возникающих в настоящих условиях всем придётся потрудиться получше: и автору, и читателю. Гораздо проще накидать наркоманских примеров, но это совсем не значит, что это действительно главная причина появления проблем.

     
     ....нить скрыта, показать (63)

  • 1.6, Crazy Alex (ok), 12:13, 07/07/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ещё один с "С/С++"? То, о чём он говорит, ловится любым приличным современным линтотулзом для плюсов, потому что сейчас на плюсах так писать вообще не принято.
     
     
  • 2.10, RazrFalcon (ok), 12:34, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Каким образом линтер ловит выход за пределы массива и use after free?
     
     
  • 3.19, Crazy Alex (ok), 14:29, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Очень просто - ругается на попытки использовать сишные массивы и голые сишные указатели. В плюсах это bad practices, и давно.
     
     
  • 4.145, Анонимный Алкоголик (??), 10:20, 10/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Очень просто - ругается на попытки использовать сишные массивы и голые сишные
    > указатели. В плюсах это bad practices, и давно.

    Ну то есть никак не находит выход за пределы массива. Что показывает практическую негодность этого вашего "линтера".

     
  • 2.15, A.Stahl (ok), 13:26, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >потому что сейчас на плюсах так писать вообще не принято.

    Ну это ты загнул.

     
     
  • 3.20, Crazy Alex (ok), 14:36, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не загибал:
    https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#R
    https://isocpp.org/wiki/faq/containers
     
  • 3.28, Ordu (ok), 15:46, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, это не он загнул Просто кто-то отстал от развития практик применения C л... текст скрыт, показать
     
     
  • 4.38, A.Stahl (ok), 18:02, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >boost

    Это отдельная тема. Специфическая тема. Не моя тема.

     
     
  • 5.41, Ordu (ok), 18:42, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    При чём здесь моя или не моя Из наблюдений за копошением вокруг разных язык... текст скрыт, показать
     
     
  • 6.43, yet another anonymous (?), 19:09, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хмм... Что-то в вашей позиции есть интересное. По крайней мере, даже Страуструпу понадобился пинок в виде ребят из университета Ватерлоо и Степанова.
     
     
  • 7.45, A.Stahl (ok), 19:58, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пинок инженера инженеру это всегда хорошо.
    Хотя я и не рад смотря куда развиваются плюсы.
     
     
  • 8.62, Аноним (-), 22:59, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Плюсы с самого начала были не до конца продуманным костылем. Почитайте труды критиков в адрес плюсов и Страуструпа конца 80х и середины 90х. Сила критики бывает такой что иногда это даже затягивает.
     
     
  • 9.85, pripolz (?), 14:01, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Плюсы с самого начала были не до конца продуманным костылем. Почитайте труды
    > критиков в адрес плюсов и Страуструпа конца 80х и середины 90х.
    > Сила критики бывает такой что иногда это даже затягивает.

    Можно поподробнее? Авторство, ссылочку? С удовольствием бы почитал, интересуюсь этой темой. Сам искал что-то подобное, но кроме эмоциональных экспрессий Линуса ничего не нашёл.

     
     
  • 10.94, Аноним (-), 17:08, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    К сожалению я не могу дать вам ссылок, т.к. не нашел и не сохранил. Я это читал много лет назад когда знакомился с обероном. Не думал что со временем будет сложно найти в интернете знания, себе не скачивал.
     
  • 10.98, Vkni (ok), 17:43, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно поподробнее? Авторство, ссылочку? С удовольствием бы почитал, интересуюсь этой темой.

    Unix Haters Handbook, страница 203 и далее. Но надо понимать, что сейчас ЦэПэПэ движется в несколько другую сторону - тащит всё из ML/Haskell'а, как и хотели авторы UHH.

     
  • 6.87, pripolz (?), 14:06, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Рекоммендую к прочтению код какого-нибудь авторитетного ... текст скрыт, показать
     
     
  • 7.88, Ordu (ok), 14:29, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    gt оверквотинг удален Да-да, я знаю Всё можно написать на ассемблере Но заче... текст скрыт, показать
     
     
  • 8.90, pripolz (?), 14:43, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да-да, я знаю. Всё можно написать на ассемблере. Но зачем?

    Чтобы кода было меньше, а технологий больше. Вообще все любители высокоуровневых языков тыкают в ассемблер. Это от незнания реалий ассемблера. Где он применяется и зачем.

    > Десять секунд использования гугла и: http://www.boost.org/users/uses_open.html
    > Там ещё есть ссылочки на не-OSS проекты, если интересно глянь туда.

    сплошной ноунейм

     
     
  • 9.91, Ordu (ok), 15:32, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    На ассемблере будет меньше кода Ха Ты попробуй писать на ассемблере Или на C ... текст скрыт, показать
     
     
  • 10.92, pripolz (?), 16:02, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Или на C будет меньше кода? Ну-ну.

    именно так. На си будет меньше кода.

    > Что за манера вообще лезть со своей демагогией в разговор умных людей?

    Ты себя-то называешь умным человеком?

    > Опять демагогичный перевод стрелок. Речь идёт о гипотетической тормознутости кода, использующего
    > boost, ты начинаешь говорить о распространённости кода, использующего boost.

    Речь о том, что за свои "15 лет продвижения программирования вперёд" буст ничего не добился.

     
     
  • 11.101, Vkni (ok), 17:53, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > именно так. На си будет меньше кода.

    Только если не использовать ООП и шаблоны там, где это не надо. Ручная эмуляция компилятора C++ аля Glib2 и прочие извращения код только раздувают.

     
     
  • 12.103, pripolz (?), 18:38, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    1 Фишки Glib не пересекаются с фишками компилятора С вообще начнём с этого ... текст скрыт, показать
     
     
  • 13.111, Vkni (ok), 20:07, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Тем не менее, их эмуляции классов можно было бы сделать на С проще Вместо пре... текст скрыт, показать
     
  • 12.116, Аноним (-), 22:24, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Только если не использовать ООП и шаблоны там, где это не надо.

    Практика показывает что ненадо чуть менее чем везде.

     
  • 11.107, Ordu (ok), 19:49, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Опять демагогичный перевод стрелок. Речь идёт о гипотетической тормознутости кода, использующего
    >> boost, ты начинаешь говорить о распространённости кода, использующего boost.
    > Речь о том, что за свои "15 лет продвижения программирования вперёд" буст
    > ничего не добился.

    Ты специально учился где-то демагогии или самоучкой? Очень похоже на второе: специально обученные делают это не столь очевидно.

     
  • 7.102, Vkni (ok), 17:55, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Рекоммендую к прочтению код какого-нибудь авторитетного проекта с 10 летним возрастом.
    > openssl например, или ffmpeg. Вы там найдёте всё: ООП, шаблоны, фабричные
    > функции, и многое другое.

    Если держать себя в руках, то на ООП на С++ получится лучше, т.к. не надо вручную возиться с vptr/vtable. Другое дело, что от обилия возможностей у многих в руках начинает свербить.

     
     
  • 8.104, pripolz (?), 19:21, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    1 то, что ты называешь возможностями я называю ограничениями 2 Пример очень п... текст скрыт, показать
     
     
  • 9.112, Vkni (ok), 20:09, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > - это невозможность в некоторых случаях сохранить совместимость разных версий API/ABI
    > после расширения. Этот вопрос у С++ников как правило вообще не поднимается,

    Вот конкретно здесь мы его неоднократно поднимали с CrazyАлексом, arisu и д.р.

    Ситуация даже хуже, чем вы излагаете. Если я беру один и тот же проект с плагинами, компилирую их разными версиями gcc/clang и т.д. бинарная совместимость не гарантирована. Даже с учёто того, что исходник абсолютно один и тот же.

    Но, возможно, это действительно ситуация разряда "сгорел сарай, гори и хата" - с С++ной реализацией наследования и обратной бинарной совместимостью действительно полный Пэ.

     
  • 4.39, _ (??), 18:16, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Опыи фортрана, лиспа, кобола и кучи других - выкинули?
    Ну в таком ключе С++ тоже выкинут.


    И кстати, то как ты это описал - это не профессия, это - религия.

     
     
  • 5.42, Ordu (ok), 18:54, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Опыи фортрана, лиспа, кобола и кучи других - выкинули?
    > Ну в таком ключе С++ тоже выкинут.

    Я не совсем понял к чему это. Но опыт фортрана, лиспа, кобола и кучи других неприменим непосредственно в C++. Этот опыт надо переосмыслить, надо попробовать его привнести в C++ и так, и эдак, надо почистить этот опыт от того, что не нужно в C++. А после этого опыт фортрана, лиспа, кобола и кучи других станет опытом C++.

    И да, C++ тоже выкинут со временем. Но не в обозримом будущем.

    > И кстати, то как ты это описал - это не профессия, это
    > - религия.

    Что именно? Я описал два разных взгляда на ситуацию, какой из них для тебя выглядит религией? Вера старых пердунов в то, что те практики, которые они применяли десятилетиями всегда будут лучше любых новых? Или вера в то, что программирование развивается и как искусство, и как ремесло, и как профессия, что развитие это неизбежно, а борьба с ним бесполезна и контрпродуктивна?

     
     
  • 6.44, yet another anonymous (?), 19:13, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > ... Но опыт фортрана, лиспа, кобола
    > и кучи других неприменим непосредственно в C++. Этот опыт надо переосмыслить,
    > надо попробовать его привнести в C++ и так, и эдак, надо
    > почистить этот опыт от того, что не нужно в C++. А
    > после этого опыт фортрана, лиспа, кобола и кучи других станет опытом
    > C++.

    Да, Степанов свои идеи сначала на Lisp'е реализовывал. C++ как мультипарадигменный язык подошёл лучше.

     
  • 4.47, Аноним (-), 20:22, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Литература, обобщающая опыт всех тех тысяч (или десятков/сотен
    > тысяч) программистов, которые писали на C++,

    Можно пару-тройку ссылок на литературу (хотя хватит и имен/названий, отсутсвие перевода не помеха) "как писать на современных плюсах"?
    А то ведь графоманов-любителей много, без опыта нарвешься на какой нибудь "шыдевр", от которого у тех, кто в теме, волосы на *опе дыбом становятся.

     
     
  • 5.50, Crazy Alex (ok), 21:31, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Из того, что я видел - лучше всего именно гайд под редакцией Страуструпа/Саттера на https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md. В C++ Faq также есть и рекомендуемые книги причём разные варианты с учётом бэкграунда. Ну и Мейерс, "Effective Modern C++".
     
     
  • 6.55, Аноним (-), 22:00, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Благодарю. Будем посмотреть.
     
  • 5.56, Ordu (ok), 22:09, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно пару-тройку ссылок на литературу (хотя хватит и имен/названий, отсутсвие перевода
    > не помеха) "как писать на современных плюсах"?
    > А то ведь графоманов-любителей много, без опыта нарвешься на какой нибудь "шыдевр",
    > от которого у тех, кто в теме, волосы на *опе дыбом
    > становятся.

    Мейерс. http://shop.oreilly.com/product/0636920033707.do

     
  • 5.65, Аноним (-), 23:19, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Очень рекомендую к просмотру, т.к. без нормальной критики вы не поймете язык полностью: https://flyx.org/2014/04/24/cpp_sucks/


     
     
  • 6.67, Crazy Alex (ok), 01:24, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как бы наоборот. Для того, кто не поварился в плюсах с пол-года хотя бы этот текст - бессмысленный набор слов. А вот потом можно и поглядеть. Правда, тогда будет понятно, что это всё либо чушь, либо мелочные придирки - а так не интересно.
     
  • 6.72, Vkni (ok), 03:58, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Очень рекомендую к просмотру, т.к. без нормальной критики вы не поймете язык
    > полностью: https://flyx.org/2014/04/24/cpp_sucks/

    Там, мягко говоря, далеко не всё описано. И по шаблонам с STL он как-то очень слабо проехался. Нет, например, классического упрёка, что в STL везде торчат итераторы, а должны быть регионы. Ну, а синтаксис шаблонов - это просто редкостное уродство.

     
     
  • 7.75, Аноним (-), 04:21, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен и поэтому автор предусмотрительно написал

    > Disclaimer: This list is not and will never be complete (but I may update it if I'm bored). It also contains strong language.

     
  • 4.73, Vkni (ok), 04:02, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Нет, это не он загнул. Просто кто-то отстал от развития практик применения
    > C++ лет на десять.

    Лучшая практика применения современного C++ - это "можешь на нём не писать - не пиши".

    > под предлогами вида "мне синтаксис не нравится"?

    Синтаксис - это, вообще-то, первое, что видно в программе. Ну зачем же сразу в дерьмо читателя макать со всеми std::...? И это, надо сказать, подход boost'a.

     
     
  • 5.83, Ordu (ok), 12:33, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> под предлогами вида "мне синтаксис не нравится"?
    > Синтаксис - это, вообще-то, первое, что видно в программе.

    И чё с того? Ты в курсе что предпочтения в эргономике тренируются? Они не просто приобретённые, они приобретаемые. Разговоры про на вкус и цвет разные фломастеры -- это разговоры неудачников. Научиться видеть C++ код как красивый не сложнее, чем научиться им пользоваться. Даже если этот код видится тебе уродливым. Отказываться от инструмента потому, что тебе не нравится его внешний вид -- это очень странно. Можно отказываться потому, что инструмент не подходит для круга решаемых задач. Могут быть другие разумные причины. Но отказываться исходя сугубо из личных предпочтений, не связанных с тем, насколько этот инструмент полезный -- это очень странно.

     
     
  • 6.93, Vkni (ok), 16:43, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Научиться видеть C++ код как красивый не сложнее, чем научиться им пользоваться.

    Зачем нужно видеть красоту в примерах из boost'а, где в глазах просто рябит от символов <, >, ::, {} и адового кол-ва подчёркиваний?

    > Отказываться от инструмента потому, что тебе не нравится его внешний вид -- это очень странно.

    Отказываются не по этому, а потому, что язык безумно переусложнён. И поэтому не так хорошо предсказуем, как более простые.

     
     
  • 7.108, Ordu (ok), 19:54, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Научиться видеть C++ код как красивый не сложнее, чем научиться им пользоваться.
    > Зачем нужно видеть красоту в примерах из boost'а, где в глазах просто
    > рябит от символов <, >, ::, {} и адового кол-ва подчёркиваний?

    Для того, чтобы использовать C++ максимально эффективно.

    >> Отказываться от инструмента потому, что тебе не нравится его внешний вид -- это очень странно.
    > Отказываются не по этому, а потому, что язык безумно переусложнён. И поэтому
    > не так хорошо предсказуем, как более простые.

    Может быть другие отказывают по этим причинам. Но в этом треде я не слышал ни одной причины, кроме "мне не нравится внешний вид".

     
     
  • 8.113, Vkni (ok), 20:16, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Для того, чтобы использовать C++ максимально эффективно.

    Кто это вам сказал?

    > Может быть другие отказывают по этим причинам. Но в этом треде я
    > не слышал ни одной причины, кроме "мне не нравится внешний вид".

    Это потому, что вы не хотите видеть другие причины. С другой стороны, синтаксис, приводящий к излишней многословности - это недостаток языка. Сравните, например:

    template< class RandomIt, class Compare >
    void sort( RandomIt first, RandomIt last, Compare comp );

    и

    val sort : ('a -> 'a -> int) -> 'a array -> unit

    или

    sortBy :: (a -> a -> Ordering) -> Seq a -> Seq a

     
     
  • 9.114, Ordu (ok), 20:58, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Опыт десятков и сотен тысяч программистов, которые писали на C в различных сти... текст скрыт, показать
     
     
  • 10.115, Vkni (ok), 21:57, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > У меня есть склонность считать себя умнее всех остальных, но когда этих остальных на несколько порядков больше чем меня, и работа ими проделанная ещё больше, я всё же склонен засунуть своё ЧСВ поглубже с глаз долой и доверять специалистам.

    Я совершенно не уверен в том, что статистика наведена правильно. Вообще, руководства, пестрящие std:: и прочими излишними многословиями заствляют задуматься.

    > Ссылки в студию. Где тут упоминаются другие причины, которые я не хочу видеть?

    Ну вот проблемы с ABI были, обсуждалось выше. Отсутствие pattern-matching'а (я знаю про библиотеку одного моего знакомого), слишком сильное использование препроцессора.

    > И, смотрите-ка, разница уже не столь велика оказывается.

    Разница в объёмах двукратная при том же объёме информации. И никуда от неё не деться.

    Разделение на first/last - это в 99% лишняя информация. Но там, где это нужно, делают срезы - slice, аля SML - http://sml-family.org/Basis/vector-slice.html#VECTOR_SLICE:SIG:SPEC

     
     
  • 11.120, Ordu (ok), 23:43, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, это заговор ZOG Они подтасовывают данные, пишут лжеруководства и вообще вво... текст скрыт, показать
     
     
  • 12.122, Vkni (ok), 00:09, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Это не заговор Просто некоторые люди варятся в одном и том же добре уже довольн... текст скрыт, показать
     
     
  • 13.123, Ordu (ok), 01:14, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А Ну да Наконец-то всем на радость Мы теперь нашли слова такие Те что лучше о... текст скрыт, показать
     
     
  • 14.125, Vkni (ok), 01:57, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А. Да. Я понял. Вам опять синтаксис не нравится? import в java/python
    > лучше? (require ..) в CL? use в rust?

    Конечно, import/uses/open значительно лучше. Они ведь подразумевают развитую систему модулей, а не паразитирование на допотопном однопроходном линковщике.

    > Препроцессор и темплиты -- это способы кодогенерации.

    Вы не поверите, но любой ЯВУ - это способ кодогенерации. Чересчур широко обобщаете. :-)

    > Я не знаю, как там в Ocaml'е, но в lisp'е макроязык --
    > это что-то с чем-то. В racket его ещё довели до ума,
    > типизацию ему приделали -- вообще няшка.
    > В rust тоже очень неплохо получается. Так что на один
    > неудачный опыт ocaml'а, есть три удачных
    > опыта других. Может они там в ocaml'е что-то не то делали?

    Да у них тоже нормально типа получилось, ан люди не пользуются.
    Переехали на ppa. Посмотрим, что у этих будет лет через 5.

    > Ещё раз скажу вам: красивым будет любой привычный язык.

    У меня опыт владения ЦэПэПэ где-то лет 20 уже. Ocaml'а - десяток.

     
     
  • 15.138, Ordu (ok), 14:04, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Ещё раз скажу вам: красивым будет любой привычный язык.
    > У меня опыт владения ЦэПэПэ где-то лет 20 уже. Ocaml'а - десяток.

    Видимо, опыт опыту рознь.

     
     
  • 16.141, Vkni (ok), 16:22, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Разумеется - я и другие языки знаю.
     
  • 15.148, yet another anonymous (?), 11:35, 10/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Конечно, import/uses/open значительно лучше. Они ведь подразумевают развитую систему модулей, а не паразитирование на допотопном однопроходном линковщике.

    Превед, GOLD! ;)

     
     
  • 16.162, Vkni (ok), 07:45, 12/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Превед, GOLD! ;)

    С этой точки зрения разницы между ld и ld.gold нет. Одна, в целом, фигня.

     
  • 4.84, pripolz (?), 12:50, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > код, по сравнению с кодом всяких хипстеров, которые городят темплит на
    > темплите. Но, когда я вижу такого рода людей сегодня, вообще не
    > знаю, что думать. Сейчас же есть литература, которая объясняет, что в
    > C++ есть, как это следует использовать, и почему именно так, а
    > не как-нибудь иначе. Литература, обобщающая опыт всех тех тысяч (или десятков/сотен
    > тысяч) программистов, которые писали на C++, которые читали чужой код, которые
    > занимались рефакторингом кода, поддержкой его, которые много думали о том как
    > лучше писать, которые экспериментировали с C++ с момента его появления. И
    > вот так брать и выкидывать этот опыт в окно с формулировкой
    > "мне синтаксис не нравится"... Вон из профессии, ничтожество.

    Ещё через 5 лет стиль ещё сильнее "отточится" на +200 страниц к стандарту. И выйдет ещё литература, объясняющая новые костыли проблемами старых.

    Сейчас я тебе кое-что покажу:
    Вот класс - это изначально структура данных + набор методов с ней. В с++ структура и методы принудительно жёстко связаны. А если я захочу написать один метод для 3х классов? А если я захочу подгрузить метод из динамически загруженной либы, которую пользователь выбрал где-то? Это уже проблема архитектуры языка. Приятного времяпрепровождения в профессии.

     
     
  • 5.86, Ordu (ok), 14:05, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ещё через 5 лет стиль ещё сильнее "отточится" на +200 страниц к стандарту. И выйдет ещё литература, объясняющая новые костыли проблемами старых.

    Да. Программирование не стоит на месте, развивается. Методов всё больше. Какой кошмар.

    > Сейчас я тебе кое-что покажу:
    > Вот класс - это изначально структура данных + набор методов с ней.
    > В с++ структура и методы принудительно жёстко связаны. А если я
    > захочу написать один метод для 3х классов?

    Если ты захочешь, то это значит что ты неудачник. Либо тебе досталась уродская задача, либо ты выбрал не тот подход к её решению. Если у тебя есть три аргумента, каждый из которых является дочерним от класса A, и таких дочерних классов у A три штуки -- B, C, D, то тебе придётся писать 3^3 реализаций методов -- (B, B, B), (B, B, C) (C, D, B), (C, C, D), и так далее. 27 долбаных функций. Если ты добавишь к A ещё один дочерний класс, то количество методов скакнёт до 64. Поверь мне, ты повесишся раньше, чем допишешь эту программу. Причём вне зависимости от выбранного языка: этот заморочный диспатч можно сделать хоть на ассемблере, проблем-то? Но вот степенная зависимость количества реализаций методов от количества типов -- это убийственно.

     
     
  • 6.89, pripolz (?), 14:32, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Да. Программирование не стоит на месте, развивается. Методов всё больше. Какой кошмар.

    программирование стоит на месте. Хорошие программы, взрывающие мозг - это bash, qemu, openvpn. Там поставлена интересная абстрактная задача. Сегодня "революцией" называют docker. Это просто смешно.

    > Если ты захочешь, то это значит что ты неудачник. Либо тебе досталась
    > уродская задача, либо ты выбрал не тот подход к её решению.

    Типичный пример ограниченности мышления. Если я захочу, чтобы моя программа легко собиралась на любом железе и ос, то наверное я.. псих? А если я захочу, чтобы она потребляла меньше 200 мб оперативки, то я кто? Романтик? А если я захочу не писать каскад из классов-хелперов?


    > Если у тебя есть три аргумента, каждый из которых является дочерним
    > от класса A, и таких дочерних классов у A три штуки
    > -- B, C, D, то тебе придётся писать 3^3 реализаций методов
    > -- (B, B, B), (B, B, C) (C, D, B), (C,
    > C, D), и так далее. 27 долбаных функций. Если ты добавишь
    > к A ещё один дочерний класс, то количество методов скакнёт до
    > 64.

    Намёк не понят. Хочешь наследование - положи структуру в структуру.


     
     
  • 7.96, Vkni (ok), 17:20, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > программирование стоит на месте.

    Очень, очень костная штука. Хиндли-милнер, несчастный, был открыт за 20 (двадцать) лет до возникновения шаблонов в С++.

     
  • 7.106, Ordu (ok), 19:32, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если тебе так кажется, то разуй глаза и посмотри по сторонам Даже алгоритмы сор... текст скрыт, показать
     
     
  • 8.109, Vkni (ok), 19:57, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Кстати тут вариант ещё щадящий, потому что функция
    > коммутативна, и тебе придётся писать не N^2 конкретных реализаций метода distance,
    > а N*(N-1)/2.

    Ага. Потому, что формулы разные. По крайней мере для евклидовой метрики.

     
  • 8.132, pripolz (?), 04:53, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если всё ещё не понятно, о чём я, то возьми ассемблер, C,
    > bash, или любой другой язык, который тебе по душе, и попробуй
    > реализовать такую функцию. В процессе написания кода ты быстро поймёшь, о
    > чём я вещаю. Кстати тут вариант ещё щадящий, потому что функция
    > коммутативна, и тебе придётся писать не N^2 конкретных реализаций метода distance,
    > а N*(N-1)/2.

    Именно так, совершенно непонятно. При чём тут принудительная связь между данными и методами, которые применимы к этим данным?
    Я указал на то, что если будет метод "расстояние между точкой и прямой" - то его по канонам С++ нужно будет обязательно выполнить либо в классе "прямая", либо в классе "точка", либо в классе "фигура". Что приведёт к ОГРАНИЧЕНИЯМ на уровне языка. Эти ограничения будут касаться ABI, и приведут к появлению всякого лишнего кода. Возможно придётся использовать такую "возможность", как friend class, короче думать о реализации.
    Твой пример с generic расстоянием между фигурами мне ни о чём не сказал. Ну допустим будет много реализаций. Что это меняет? Если тебе предложат написать такую программу, ты что, откажешься? Не функцию, а программу. Расстояние между фигурами. Фигур 10 типов. Это задача для неудачников по твоему?

     
     
  • 9.134, Vkni (ok), 05:55, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Я указал на то, что если будет метод "расстояние между точкой и прямой" - то его по канонам С++ нужно будет обязательно выполнить либо в классе "прямая", либо в классе "точка", либо в классе "фигура".

    В C++ это можно сделать разными методами и использовать ООП совершенно не обязательно. В частности, в данном случае лучше всего использовать шаблоны.

    template <class A, class B> double distance( const A &, const B &)

    И инстанциировать это хозяйство для разных пар, поскольку формулы для разных пар действительно разные.

     
     
  • 10.137, pripolz (?), 11:11, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > В C++ это можно сделать разными методами и использовать ООП совершенно не
    > обязательно. В частности, в данном случае лучше всего использовать шаблоны.
    > template <class A, class B> double distance( const A &, const B
    > &)
    > И инстанциировать это хозяйство для разных пар, поскольку формулы для разных пар
    > действительно разные.

    а в рантайме такой темплейт подхватит заранее неизвестный тип фигуры?

     
     
  • 11.142, Vkni (ok), 16:39, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > а в рантайме такой темплейт подхватит заранее неизвестный тип фигуры?

    Нет, конечно. Но основная проблема тут не в языке, а в предметной области - у вас нет единой формулы для расчёта дистанций между фигурами разной формы.

    А вот если она найдётся, то значит можно её написать с учётом каких-то встроенных свойств фигур, и сделать всё на шаблонах.

    Например, если можно написать функцию расстояния от фигуры до точки, то можно написать единый алгоритм вычисления минимизацию суммы этих расстояний. И тогда он подхватит в compile-time заранее неизвестный тип фигуры, у которого будет distanceToPoint.

    Но это не ООП, а generic, т.е. шаблоны, т.е. практически функциональное программирование.

     
  • 9.139, Ordu (ok), 14:50, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты путаешь каноны ООП с канонами C Современный C не любит наследование и с ... текст скрыт, показать
     
     
  • 10.143, Аноним (-), 18:26, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Очередная порция словесного поноса.
     
  • 10.144, pripolz (?), 23:33, 09/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Современный C++ не любит наследование и с подозрением относится к ООП.

    Исключительно забавное заявление.
    Во первых потому, что ООП - это шаблон проектирования. FILE * стандартной библиотеки Си - типичный ООП.
    Во вторых заявление забавно потому, что получается, что С++ комьюнити начинает соглашаться с тем, что всё это время двигалось не в ту сторону. Вчера они объясняли тебе, ПОЧЕМУ наследование - это хорошо, а сегодня.. они вернулись обратно. Программирование стоит на месте.

    Потому что у него нет причин куда-то двигаться. Был ассемблер, всё было нормально. Но есть у ассемблера недостаток - он непереносим на другой проц по определению. И появился Си. Именно поэтому.
    Си сегодня выкинуть невозможно. Представь, что удалили все программы, написанные на си (пусть не считая ОС и драйверов). Что останется?
    А вот Джаву например удалить можно. Вообще ничего не изменится. И С++ тоже. И Rust с его отсутствием наследования.

     
     
  • 11.150, Vkni (ok), 14:59, 10/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Вчера они объясняли тебе, ПОЧЕМУ наследование - это хорошо

    Окститесь, 20 лет прошло с тех пор.

     
     
  • 12.151, pripolz (?), 18:24, 10/07/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Окститесь, 20 лет прошло с тех пор.

    То есть, современный С++ не просто не любит наследование, а ДАВНО не любит наследование?
    Ещё более забавно.
    Вы не говорите, что "ordu преувеличил, С++ всё ещё любит наследование".
    Как же специальные костылики для решения проблемы ромба?

     
     
  • 13.152, yet another anonymous (?), 20:06, 10/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > То есть, современный С++ не просто не любит наследование, а ДАВНО не любит наследование?

    Ещё более забавно.

    См.:

    Elements of Programming by A. Stepanov.

     
  • 13.153, Vkni (ok), 03:05, 11/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > а ДАВНО не любит наследование?

    Хуже - ОЧЕНЬ ДАВНО не любит наследование. Если бы не Степанов с STL, а дальше Александреску с метапрогразмом, этот С++ давно бы выкинули на помойку. Ибо наследование, виртуальные функции и т.д. лучше реализовано в Яве, в С#, Delphi, ну и других языках.

    У С++ ниша языка с относительно мелким рантаймом и возможностью очень глубокой оптимизации. Классы же с виртуальными функциями, наследованием, указателями и т.д. сильно тормозят. А шаблоны, несмотря на ряд косяков (синтаксис, отсутствие раздельной компиляции), позволяют делать с одной стороны достаточно высокуровневый, а с другой стороны, оптимизированный код.

    Есть даже места, где RTTI вообще нафиг отключают, а значит выключают и "объектно-ориентированное-программирование на С++".

     
     
  • 14.154, pripolz (?), 12:14, 11/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А шаблоны, несмотря на ряд косяков синтаксис, отсутствие раздельной компиляции ... текст скрыт, показать
     
     
  • 15.155, Vkni (ok), 12:21, 11/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > - потому что процесс генерации прозрачен и понятен.

    Во-первых, нет. Он понятен только до определённого момента - пара ступеней вложенности, после чего это всё превращается в лапшу.

    > - тут не нужно вспоминать тонкости синтаксиса, минимальное кол-во боли при ревизии.

    В С++ тонкости синтаксиса - это STL с её идиотскими back_inserter и прочей фигнёй. Шаблоны, всё-таки, очень даже обозримы.

    > - самое важное: гибкость. Можно нагенерить любую идею.

    Если потребовалось что-то серьёзное, берём любой лёгкий высокоуровневый язык, и генерируем себе спокойно нормальный Cшный или C++ный код значительно лучше, чем на языке препроцессора или шаблонов.

    > Короче, препроцессор - это свобода.

    Свободы в Питоне хоть попой ешь, в результате приходится тестировать всё, что может сломаться и даже не может сломаться.

     
     
  • 16.156, pripolz (?), 13:30, 11/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > пара ступеней вложенности

    Ни разу в жизни не сталкивался. Вообще шаблоны - большая редкость. Применение шаблонов ИМХО обосновано только из соображений производительности. Тогда, когда нельзя использовать указатель на функцию потому, что это запорет оптимизацию в сильно вложенном цикле.
    Так или иначе, у меня лично есть большие сомнения, превратится ли при таком подходе код в кашу. Ну будет иерархия из нескольких файлов, что такого.

     
     
  • 17.157, anonymous (??), 14:01, 11/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> пара ступеней вложенности
    > Ни разу в жизни не сталкивался. Вообще шаблоны - большая редкость.

    В каком чудном мире вы живете?

    PS. Это же вы где-то в этой теме сказали, что программировали на 100 языках? Можно список из ТОП-30 хотя бы?

     
     
  • 18.158, pripolz (?), 14:25, 11/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > PS. Это же вы где-то в этой теме сказали, что программировали на
    > 100 языках? Можно список из ТОП-30 хотя бы?

    Было преувеличение. Если по порядку, то
    Dark Basic,
    Visual Basic 98 (VB6),
    Free Basic,
    Matlab,
    CMD/BAT,
    VBScript,
    Bash,
    Python,
    fasm,
    Java (совсем-совсем немного),
    Emacs Lisp.

    Всё кроме BAT/CMD по мелочам.
    В профессиональном С/С++ 2 года.
    Вот и раскрыта таенка))

     
     
  • 19.161, Vkni (ok), 02:25, 12/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну почти всё закрыто. Не хватает JavaScript'а, языков семейства ML и Пролога.
     
  • 19.163, anonymous yet another (?), 08:29, 12/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Было преувеличение. Если по порядку, то

    Дневник молодого поэта: "Всю ночь писал стихи о любви. Закрыл тему."

     
  • 14.160, anonymous yet another (?), 23:06, 11/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > ... а дальше Александреску

    А вот это уже мешки синтаксического сахара. Так и до диабета недалеко.

     
  • 9.149, Анонимный Алкоголик (??), 11:48, 10/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Если тебе предложат написать такую программу, ты что, откажешься? Не функцию, а программу.
    > Расстояние между фигурами. Фигур 10 типов. Это задача для неудачников по
    > твоему?

    Вы не поняли. Речь была о том, что в языке вам не хватает средства выразить некий метод (функцию) для трёх классов хотя бы. Один при чём. Метод. Предлагать нам за вас разработать и представить к рассмотрению такого рода метод не стоит...

     
  • 5.118, Vkni (ok), 22:28, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот класс - это изначально структура данных + набор методов с ней.
    > В с++ структура и методы принудительно жёстко связаны. А если я
    > захочу написать один метод для 3х классов?

    Haskell, классы типов и т.д.

    instance Show Double where
        show d = ...

    Проблема в том, что даже с ними хочется большей гибкости. Например, определить два разных вариантов печати числа.

     
  • 5.147, Анонимный Алкоголик (??), 11:12, 10/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А если я захочу написать один метод для 3х классов?

    :-) Когда захотите, изложите как полагается. Выдающееся может получиться желание.
    Потому что пока это выглядит довольно бессмысленно. "один метод для 3х классов". Поэтому вряд ли вы сможете таки захотеть...

     
  • 4.146, Анонимный Алкоголик (??), 10:39, 10/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >Вон из профессии, ничтожество.

    Совершенно верно. Вон. Наплодилось вас, проталкивателей "стилей"...
    Норовящих пояснить о плохой практике массивов... :-)

     
     ....нить скрыта, показать (82)

  • 1.16, Игорь (??), 13:56, 07/07/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Полезно, спасибо!
     
  • 1.27, manster (ok), 15:45, 07/07/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    И все таки почему например chromium начинает притормаживать, захлебываться и с трудом возвращать память при открытии ~+10 вкладок.
     
     
  • 2.40, _ (??), 18:18, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Потому что по сложности современный браузеры вплотную приблизились к операционным системам (С)  ?
     
     
  • 3.46, Аноним (-), 20:21, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Абсолютная чушь. Вдумайся в значение слова "браузер" (что означает обозреватель) и ты поймешь что даже до офисного редактора браузер не подошел. В офисном редакторе кроме проигрывания медиа можно например редактировать БД.
     
     
  • 4.48, anomymous (?), 21:17, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ойййй. Для начала хотелось бы посмотреть на полноценную динамику в "офисном редакторе". С возможностью загрузки кусков текста и перехода к другим документам. А там подумаем.
     
     
  • 5.63, Аноним (-), 23:02, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вы кроме WordPad что-нибудь встречали?
     
  • 4.49, Соня (??), 21:24, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Тем не менее вся эта webня выглядит ужасающе сложно. Даже потрясающе сложно для просмоторщика документов со скриптами. Я бы не смог реализовать весь "стандарт"
     
     
  • 5.64, Аноним (-), 23:06, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это для вас лично. Скрипты - это вообще огромный туnой костыль. В целом там ничего сложного, просто объем.
    Примерно сложного: аллокатор памяти в операционной системе.
     
     
  • 6.78, angra (ok), 09:01, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Тебя совсем не смущает, что аллокаторы памяти были созданы для многих десятков ОС и справляются с этой задачей студенты одиночки, а вот полноценных браузерных движков меньше десятка за всё время получилось?
     
     
  • 7.95, Аноним (-), 17:13, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Столь дилетантская попытка сравнения позорна для технического ресурса. Вы дейтвительно думаете что браузерный движок это сложно? - Это очень объемно, но не сложно.
     
     
  • 8.159, Соня (??), 19:19, 11/07/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Много всего что по отдельности не сложно, но со странным поведением и так далее, да?
    Типа как скопировать настройки столетнего компьютера где использовали костыли, поверх них ещё костыли, потом ещё костыли для частичной нейтрализации эффекта тех костылей, прикручивали новые вещи разными странными способами, так? Я правильно понял?
    Но там нет особенно непонятных идей, сложных алгоритмов и всего такого?
    Вся сложность в этой массе и всех возможных способах её работы, сложной логике получившейся ...получившегося продукта.
    Все так?
     
  • 2.51, Crazy Alex (ok), 21:36, 07/07/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Потому что современные "браузеры" - безумная попытка сделать рантайм для GUI-приложений из того, что для этого не предназначено в принципе, причём с десятком одновременно реализованных моделей лайаута и логикой на динамическом языке. Кадавр получился - мама не горюй. То, что это вообще как-то ворочается - чудо само по себе.
     
     
  • 3.70, manster (ok), 03:04, 08/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет, с пару тройкой вкладок все относительно хорошо :)

    Проблемы начинаются когда некоторые сайты пытаются искать flash-player для прокрутки рекламы, которого давно нет (отключал явным образом из chromium, до этого тормоза были еще больше) ...

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:


    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру
    Hosting by Ihor