С точки зрения компиляции и последующей работоспособности это не составляло серьезную проблему. Возможно работало оно в целом хуже, чем работало бы на 2.6, но сам этот факт, что в ядре не было нативных потоков, каких-то глобальных проблем не доставил. Библиотечная реализация (использующая clone) в libpthread вполне закрывала потребности.
Я лично в 2015 году занимался портированием одной из ранних версий Qt 5 на систему с ядром 2.4 (не 2.2). Это возможно, но сделать непросто. Из коробки даже та версия (5.4 кажется) не работала на этом ядре, потому что требовала поддержки futex (одна из основных проблем, но не единственная). Решилось это нахальной заменой linux-layer на posix-layer (он тоже есть в составе кодовой базы Qt для систем вроде freebsd, но по умолчанию для линукса его выбрать нельзя). Естественно сам исходный код posix-слоя пришлось допиливать, потому что в 2.4 огромное число багов, которые ломают стандартное поведение современных реализаций posix, на которое рассчитывает Qt. Думаю, что при должной сноровке и на 2.2 можно было бы натянуть, но задача эта нетривиальная, требующая программирования и понимания того, как все это внутри работает.
Заказывал 1660 Super в прошлом году. Платил 15% с превышения. Платил онлайн, через личный кабинет таможенного представителя (реквизиты для входа пришли на почту), взяли 15% + 500р таможенный сбор, чек пришел также на почту. Посылку вёз из США через посредника mainbox, c последующей передачей на территории РФ службе доставки boxberry.
Просто первая цитата во-первых не может использоваться без контекста, потому что говорит о том, "что" было в начале пути. Во-вторых она несколько смещает поле зрения, что приводит к искаженному восприятию - создается впечатление, будто бы UB специально придумали, чтобы им пользоваться в коде. Однако это совсем не так.
Я прошу прощения, но человек писал про те компании где "топы" не решаются на такие действия и объяснял почему. Его комментарий по сути не затрагивает материал статьи, а лишь является пояснением к комментарию wolfer. Поэтому ваш посыл про "а вы не думали" как минимум несправедлив.
Это эволюционная особенность нашего мозга. Если что-то делалось до этого и получалось, то появление новшеств не принимается, т.к. несет опасность устоявшемуся порядку. Человек может сделать усилие и преодолеть этот природный триггер. Но чем старше человек, тем труднее ему это дается. Поэтому эти люди скорее не игнорируют, а стараются оставаться в "зоне комфорта".
И все-таки, я убежден, что можно достигать этих целей без высказывания оценочных суждений о собеседнике. Ибо, как вы правильно сказали, неадекватов в сети очень много, и они точно так же пользуются этими приемами. И отличить одних от других порой невозможно. Поэтому можно не удивляться ситуации, когда один адекватный человек спровоцировав другого адекватного человека, наученного троллями в интернете, получил в итоге неадекватный ответ.
Множество бед в мире от банального недопонимания.
У меня нет вопросов к содержанию ваших замечаний, а лишь только к форме.
Мой вопрос касался буквально следующего: вряд ли ваше замечание о глубине фантазии собеседника наставит его на путь истинный, а лишь создаст конфликтную ситуацию на ровном месте. Что в общем-то подтверждается дискуссией далее. И вам таки пришлось развернуть свою мысль, так почему бы не сделать это сразу, минуя все эти спорные фразы?
Меня очень печалит тот факт, что люди упускают такие простые вещи из виду.
Всегда удивляло такое отношение к собеседнику.
Если вы знаете больше, напишите что именно неправильно. Зачем начинать обсуждать качества личности человека, делать какие-то вывод на его счет?
Кстати, очень интересно было бы посмотреть на вашу реализацию common_type.
Могу сказать, что в моем случае — это как раз один из тех примеров, когда пришлось делать условную компиляцию. Для GCC 2.х реализация оказалась настолько нетривиальна, что брать ее как основную мне не позволила совесть.
Сама статья про другое, но написана она была по мотивам создания практически такого же набора инструментов, как у вас. Платформа только различается и целевые компиляторы.
Вы не подумайте, мне очень близка ваша идея строгого соответствия «букве» закона. Но я, как практик, при столкновении с подобными трудностями в своей реализации, делая выбор между «поддерживать фичу с оговорками» или «не поддерживать вовсе» выбираю первое :)
Взять, например, задачу определения наличия функции-члена класса с заданной сигнатурой, которая нерешаема в рамках стандартного С++98. Однако, эта возможность была необходима в инструментарии, который я создавал. Без нее было бы слишком неудобно им пользоваться. Поэтому я пошел на этот компромисс.
Также приходилось сталкиваться в ситуацией, когда невозможно написать общий код для всей линейки нужных компиляторов, и таки приходилось делать условную компиляцию. Т.к. баги-фичи одних компиляторов были взаимоисключающими относительно других. Общий знаменатель был невозможен.
Таки шашечки или ехать? :)
В бусте тоже встречаются workaround`ы с нестандартными особенностями, обложенные проверками под конкретные компиляторы.
Ведь если мы работаем в условиях такой плохой поддержки стандарта, то сетовать на несоответствие стандарту некоторым образом лукавство, особенно, если код обеспечивает требуемое поведение.
Поэтому тут надо выбирать что важнее.
PS. Да, и я в курсе этих особенностей, т.к. сам некоторым образом решал подобную вашей задачу (пример: habr.com/post/277727), но для линейки старых GCC и Intel под Linux и BSD. Попробуйте вашу реализацию на GCC 2.x, возможно найдется множество интересных локальных задачек по нахождению обходных путей.
Борландовские версии к сожалению не работают, сегодня проверил :) Я долго пытался состряпать workaround, но похоже пациент совсем плохо умеет SFINAE — ничего не вышло.
Если автору важно поддерживать Borland C++, то вполне понятно почему он не применил это решение.
… проблема возникает с неполным типом T[] (массив без указания длины). Дело в том что данный тип не определяется некоторыми компиляторами (C++ Builder) при специализации шаблона, и универсальное решение здесь я пока что не нашел.
С точки зрения компиляции и последующей работоспособности это не составляло серьезную проблему. Возможно работало оно в целом хуже, чем работало бы на 2.6, но сам этот факт, что в ядре не было нативных потоков, каких-то глобальных проблем не доставил. Библиотечная реализация (использующая clone) в libpthread вполне закрывала потребности.
Я лично в 2015 году занимался портированием одной из ранних версий Qt 5 на систему с ядром 2.4 (не 2.2). Это возможно, но сделать непросто. Из коробки даже та версия (5.4 кажется) не работала на этом ядре, потому что требовала поддержки futex (одна из основных проблем, но не единственная). Решилось это нахальной заменой linux-layer на posix-layer (он тоже есть в составе кодовой базы Qt для систем вроде freebsd, но по умолчанию для линукса его выбрать нельзя). Естественно сам исходный код posix-слоя пришлось допиливать, потому что в 2.4 огромное число багов, которые ломают стандартное поведение современных реализаций posix, на которое рассчитывает Qt. Думаю, что при должной сноровке и на 2.2 можно было бы натянуть, но задача эта нетривиальная, требующая программирования и понимания того, как все это внутри работает.
Он не говорил же такого. Зачем так передергивать?
Заказывал 1660 Super в прошлом году. Платил 15% с превышения. Платил онлайн, через личный кабинет таможенного представителя (реквизиты для входа пришли на почту), взяли 15% + 500р таможенный сбор, чек пришел также на почту. Посылку вёз из США через посредника mainbox, c последующей передачей на территории РФ службе доставки boxberry.
В общем мне придраться не к чему.
Просто первая цитата во-первых не может использоваться без контекста, потому что говорит о том, "что" было в начале пути. Во-вторых она несколько смещает поле зрения, что приводит к искаженному восприятию - создается впечатление, будто бы UB специально придумали, чтобы им пользоваться в коде. Однако это совсем не так.
Я прошу прощения, но человек писал про те компании где "топы" не решаются на такие действия и объяснял почему. Его комментарий по сути не затрагивает материал статьи, а лишь является пояснением к комментарию wolfer. Поэтому ваш посыл про "а вы не думали" как минимум несправедлив.
Это эволюционная особенность нашего мозга. Если что-то делалось до этого и получалось, то появление новшеств не принимается, т.к. несет опасность устоявшемуся порядку. Человек может сделать усилие и преодолеть этот природный триггер. Но чем старше человек, тем труднее ему это дается. Поэтому эти люди скорее не игнорируют, а стараются оставаться в "зоне комфорта".
Вы так говорите, как будто все эти вещи только в С++20 появились :) Они в языке были почти с самого начала.
gustedt.wordpress.com/2011/03/14/flexible-array-member
Множество бед в мире от банального недопонимания.
Мой вопрос касался буквально следующего: вряд ли ваше замечание о глубине фантазии собеседника наставит его на путь истинный, а лишь создаст конфликтную ситуацию на ровном месте. Что в общем-то подтверждается дискуссией далее. И вам таки пришлось развернуть свою мысль, так почему бы не сделать это сразу, минуя все эти спорные фразы?
Меня очень печалит тот факт, что люди упускают такие простые вещи из виду.
Если вы знаете больше, напишите что именно неправильно. Зачем начинать обсуждать качества личности человека, делать какие-то вывод на его счет?
Могу сказать, что в моем случае — это как раз один из тех примеров, когда пришлось делать условную компиляцию. Для GCC 2.х реализация оказалась настолько нетривиальна, что брать ее как основную мне не позволила совесть.
Вы не подумайте, мне очень близка ваша идея строгого соответствия «букве» закона. Но я, как практик, при столкновении с подобными трудностями в своей реализации, делая выбор между «поддерживать фичу с оговорками» или «не поддерживать вовсе» выбираю первое :)
Взять, например, задачу определения наличия функции-члена класса с заданной сигнатурой, которая нерешаема в рамках стандартного С++98. Однако, эта возможность была необходима в инструментарии, который я создавал. Без нее было бы слишком неудобно им пользоваться. Поэтому я пошел на этот компромисс.
Также приходилось сталкиваться в ситуацией, когда невозможно написать общий код для всей линейки нужных компиляторов, и таки приходилось делать условную компиляцию. Т.к. баги-фичи одних компиляторов были взаимоисключающими относительно других. Общий знаменатель был невозможен.
В бусте тоже встречаются workaround`ы с нестандартными особенностями, обложенные проверками под конкретные компиляторы.
Ведь если мы работаем в условиях такой плохой поддержки стандарта, то сетовать на несоответствие стандарту некоторым образом лукавство, особенно, если код обеспечивает требуемое поведение.
Поэтому тут надо выбирать что важнее.
PS. Да, и я в курсе этих особенностей, т.к. сам некоторым образом решал подобную вашей задачу (пример: habr.com/post/277727), но для линейки старых GCC и Intel под Linux и BSD. Попробуйте вашу реализацию на GCC 2.x, возможно найдется множество интересных локальных задачек по нахождению обходных путей.
Если автору важно поддерживать Borland C++, то вполне понятно почему он не применил это решение.
Проверил код ниже на C++ Builder 6 — работает.