Вы либо описываете этот нюанс в документации к своему ПО в разделе «Требования».
Либо пишете так, чтобы работа вашего кода не зависела от этих настроек.
Во всем мире с этим как-то борятся, а в PHP — это принципиально невозможно, что ли?
Или вы думаете, что в мире вне PHP не существует настроек системы, не зависящих от разработчика ПО?
Доказательством может быть только опыт.
Лично вы работали в окружении опытных спецов — вам очень повезло.
Нет, не так. ВАМ ОЧЕНЬ СИЛЬНО ПОВЕЗЛО, ЕСЛИ ВОКРУГ ВАС ОДНИ ПРОФИ.
В реальной жизни это большая и большая редкость.
В среднем человек любой квалификации довольно посредственнен как профессионал.
То, что вы еще не сталкивались с огромным числом не профи — говорит о вашем малом жизненном опыте.
И только.
Ваш частный случай — это всего лишь ваш частный случай.
Факты таковы, что большая часть людей даже ни разу не стремятся профессионально рости. Это касается любой профессии, а не только профессии программиста.
И, к сожалению, создатели третьих библиотек не всегда уважают стандарт и не всегда проверяют кросс-платформенность.
Я уже привел пример Яндекса, который может себе позволить нанять специалиста заметно выше среднего (и дело не только в деньгах, они могут позволить себе нанять специалиста даже потратив меньше, потому как все прекрасно понимают, что после Яндекса — все пути тебе открыты).
И тем не менее — видим огромные косяки. Там даже не так просто скомпилировать под Ubuntu другой версии…
А ведь это не какой то локальный продукт — их Cocaine базис облака Яндекс и распространяется свободно для любого желающего.
Для того, чтобы убедиться, что большинство С++ создают продукты такого же качества — достаточно побольше взять открытых проектов и попытаться их скомпилировать (даже не запустить!!! ) на различных системах.
Если я скажу что я делал это — и все очень часто плохо — это же не будет для вас доказательством? Вы можете это понять только самостоятельно.
Проблема с GUI решаема.
Совсем не обязательно создавать монолит. GUI (если у вас не нечто требовательное до 3D, к примеру) — вполне безболезненно может существовать отдельно от вычислительной части.
И, очень интересно, а что вы называете кросс-платформенностью своей системы? Где именно возможна ее работа, на каких ОС?
Вы не управляете своим собственным php.ini?
Такое бывает только на shared-хостинге, что при цене современных VPS/VDS — просто смешное ограничение (а очень хороший качественный shared даже дороже VPS/VDS — просто потому что там одна и та же базовая технология, но для shared админы хостера трудятся чуть больше).
Для более сложных систем есть Docker с его изоляцией и возможностью иметь свой индивидуальный файл php.ini для каждого куска вашей системы.
Си — это такой над-ассемблер. Таким его задумали, так надо было. И до тех пор пока на Си писали ядра операционных систем да драйвера — эти самые UB можно пережить.
Но когда речь идет о прикладном ПО, то планка совсем иная.
UB в Си побольше, чем в «любом языке», используемом для написания прикладного ПО, если в качестве любого рассматривать Python, Java, Go.
Если под «любым языком» вы понимаете C++ — тогда конечно, да, я с вами соглашусь.
Средний программист С++ (коих подавляющее большинство) понятия не имеет как писать 100% переносимый код.
Вы же приводите в пример просто «историю успеха».
Никто не спорит, что при желании на С++ можно писать переносимо.
Совсем другой вопрос — а какими это достигается усилиями, по сравнению с более естественными в этом отношении системами программирования. Ну например, Python и Go и Java…
В пределах одного select чтение происходит не случайным образом, а сверху вниз.
Если верхний канал ничего не дает прочитать, то будет произведена попытка чтения из следующего по списку.
Если второй канал ничего не дает прочитать, а default нет, то select останется заблокированным — будут предприниматься попытки прочитать из двух каналов.
После чего нет никакой гарантии какой канал будет прочитан первым.
Но мне все же представляется логичным помещать сигнализирующий о прекращении процесса done — в самый верх. Это на случай начального входа в select, когда мы еще не знаем — сразу же мы из него выйдем или будем заблокированы.
Ведь если процесс уже завершен ДО НАЧАЛА SELECT, то нам НЕ СЛЕДУЕТ ЧИТАТЬ НИЧЕГО ИЗ WQ, а правильным будет сразу выйти по ветке done.
Это при условии, что когда дело доходит до чтения wq, туда УЖЕ записано.
Если будут перерывы при записи wq, то select соскользнет в закрытый done и go-routine завершится.
Си был создан для замены ассемблера при создании операционной системы.
Сейчас же его применяют и для прикладного ПО, где спускаться на столь низкий уровень нет необходимости (тем более сегодняшние компиляторы очень хорошо оптимизируют).
Но Си все так же остается всё таким же «ассемблерно-близким», хотя для большей части продуктов, создаваемых с его помощью — таких вольностей не требуется, они только увеличивают риски косяков…
Зачем мы пишем прикладное ПО на «почти ассемблере» до сих пор?
Речь шла о ЗАКРЫТИИ done. Закрытый канал прекрасно читается.
Я постоянно использую подобную методу — создаю фиктивный канал chan struct{}, в который никто никогда не пишет, а использую этот канал для сигнализации, что объект/структура/сервис более не используется — просто вызвав close(done).
Это разблокирует все select и корректно завершает go-routines
Но это требует серьезных ДОПОЛНИТЕЛЬНЫХ затрат или просто СПЕЦИАЛЬНЫХ знаний.
Я утверждаю, что львинная часть Сипласпласовцев таковыми не очень то и стремится овладеть сосредоточившись на своей узкой задаче.
Ну не должен язык, претендующий на базовый, быть таким ненадежно-непредсказуемым.
Чтобы было понятно о чем речь и что проблема решаема в принципе — сравните, сколь небольшими усилиями делается переносимая программа на Python или Go.
С С++ не сравнить — это просто небо и земля.
В Python и Go если разработчику и нужно с чем то бороться при этом — то с отдельными аспектами не POSIX API (Windows). Что как раз ожидаемо и логично.
С С++ дополнительно приходится бороться с различиями в компиляторах и библиотеках — даже в пределах ОДНОЙ платформы.
P.S.:
Яндекс приведен как контора, которая может позволить себе разработчиков уровня выше среднего. И если даже они косячат со своими базовыми вещами (эта штука, что я привел — занимается запуском и мониторингом контейнеров с другим ПО в кластере Яндекса) — то что же ожидать от основной массы?
Не должен быть язык таким. Это плохое свойство. Существенный недостаток. Никак он не может претендовать на системный, базовый.
Ты как человек без образования, прочитавший медицинскую энциклопедию — сразу нашел у себя все болезни, которых и в помине нет.
Протокол для проверки регистрации не нужен. Неуместное упоминание левых статей, не относящихся к делу.
Делается по другому — тебя задерживает один человек, а составляет протокол — другой человек.
По факту никто не тратит на это время. Но формально ты можешь быть задержан хоть ДПС, хоть ППС, хоть кем угодно.
Другое дело — что им это не интересно.
Пример с участковым и нарушением ПДД: участковый просто не имеет нужных бланков и не знает как что заполнять, ему это задержание не будет плюсом от начальства и пр. и пр. Но это вторичные причины.
Задерживать тебя могут ЛЮБЫЕ сотрудники полиции. Хоть из «детской комнаты» — если они штатные сотрудники.
Умственные способности на грани фантастики — откуда на таком сайте полиция, да и по другим моим сообщения видно кто я.
Есть лишнее время? Не хочешь проверить регистрацию сразу — сядешь в обзьянник на 3 часа, дело-то. «Похожий на вас гражданин отжал телефон тут недалеко, мы обязаны проверить вас»
1С: Предприятие — это ОЧЕНЬ ГИБКО ДОРАБАТЫВАЕМАЯ система.
Львинная доля бабла идет не с продаж, а с доработок под КОНКРЕТНОГО КЛИЕНТА.
Стоимость доработок может превышать стоимость «коробки» в десятки и даже сотни раз — легко.
Тем самым вы и подтвердили мое утверждение.
> но жизнь, не без моей помощи, наставила их на путь истинный.
Разумеется, кто же будет делать лишнюю работу в здравом уме и твердой памяти?
С C++ этой работы слишком много, вот в чем дело.
Либо пишете так, чтобы работа вашего кода не зависела от этих настроек.
Во всем мире с этим как-то борятся, а в PHP — это принципиально невозможно, что ли?
Или вы думаете, что в мире вне PHP не существует настроек системы, не зависящих от разработчика ПО?
Уровень вашей зарплаты зависит не от инструмента, а от квалификации.
И от понимания куда с вашей квалификацией вы можете податься.
С PHP ситуация следующая:
Есть много работы, но и есть много дешевой рабочей силы.
Это позволяет легко начать работать.
С Node ситуация такая:
Работы намного меньше, её еще надо поискать, но и рабочей силы меньше.
Поэтом средняя планка зарплаты — выше. Но найти работу сложнее.
Если вы стали профи PHP, то не совершайте ошибку — не конкурируйте с индусами за плошку риса. Не толкайтесь с ними локтями на дешевом рынке.
Идите в сложные системы — и заработок вас приятно поразит.
Лично вы работали в окружении опытных спецов — вам очень повезло.
Нет, не так. ВАМ ОЧЕНЬ СИЛЬНО ПОВЕЗЛО, ЕСЛИ ВОКРУГ ВАС ОДНИ ПРОФИ.
В реальной жизни это большая и большая редкость.
В среднем человек любой квалификации довольно посредственнен как профессионал.
То, что вы еще не сталкивались с огромным числом не профи — говорит о вашем малом жизненном опыте.
И только.
Ваш частный случай — это всего лишь ваш частный случай.
Факты таковы, что большая часть людей даже ни разу не стремятся профессионально рости. Это касается любой профессии, а не только профессии программиста.
И, к сожалению, создатели третьих библиотек не всегда уважают стандарт и не всегда проверяют кросс-платформенность.
Я уже привел пример Яндекса, который может себе позволить нанять специалиста заметно выше среднего (и дело не только в деньгах, они могут позволить себе нанять специалиста даже потратив меньше, потому как все прекрасно понимают, что после Яндекса — все пути тебе открыты).
И тем не менее — видим огромные косяки. Там даже не так просто скомпилировать под Ubuntu другой версии…
А ведь это не какой то локальный продукт — их Cocaine базис облака Яндекс и распространяется свободно для любого желающего.
Для того, чтобы убедиться, что большинство С++ создают продукты такого же качества — достаточно побольше взять открытых проектов и попытаться их скомпилировать (даже не запустить!!! ) на различных системах.
Если я скажу что я делал это — и все очень часто плохо — это же не будет для вас доказательством? Вы можете это понять только самостоятельно.
Проблема с GUI решаема.
Совсем не обязательно создавать монолит. GUI (если у вас не нечто требовательное до 3D, к примеру) — вполне безболезненно может существовать отдельно от вычислительной части.
И, очень интересно, а что вы называете кросс-платформенностью своей системы? Где именно возможна ее работа, на каких ОС?
Такое бывает только на shared-хостинге, что при цене современных VPS/VDS — просто смешное ограничение (а очень хороший качественный shared даже дороже VPS/VDS — просто потому что там одна и та же базовая технология, но для shared админы хостера трудятся чуть больше).
Для более сложных систем есть Docker с его изоляцией и возможностью иметь свой индивидуальный файл php.ini для каждого куска вашей системы.
Но когда речь идет о прикладном ПО, то планка совсем иная.
UB в Си побольше, чем в «любом языке», используемом для написания прикладного ПО, если в качестве любого рассматривать Python, Java, Go.
Если под «любым языком» вы понимаете C++ — тогда конечно, да, я с вами соглашусь.
Средний программист С++ (коих подавляющее большинство) понятия не имеет как писать 100% переносимый код.
Вы же приводите в пример просто «историю успеха».
Никто не спорит, что при желании на С++ можно писать переносимо.
Совсем другой вопрос — а какими это достигается усилиями, по сравнению с более естественными в этом отношении системами программирования. Ну например, Python и Go и Java…
Человек незнамомую ему терминологию перепутал «кастрация» и «обрезание» — имхо, в моей версии анекдот более тоньше звучит.
Если верхний канал ничего не дает прочитать, то будет произведена попытка чтения из следующего по списку.
Если второй канал ничего не дает прочитать, а default нет, то select останется заблокированным — будут предприниматься попытки прочитать из двух каналов.
После чего нет никакой гарантии какой канал будет прочитан первым.
Но мне все же представляется логичным помещать сигнализирующий о прекращении процесса done — в самый верх. Это на случай начального входа в select, когда мы еще не знаем — сразу же мы из него выйдем или будем заблокированы.
Ведь если процесс уже завершен ДО НАЧАЛА SELECT, то нам НЕ СЛЕДУЕТ ЧИТАТЬ НИЧЕГО ИЗ WQ, а правильным будет сразу выйти по ветке done.
Если будут перерывы при записи wq, то select соскользнет в закрытый done и go-routine завершится.
Сейчас же его применяют и для прикладного ПО, где спускаться на столь низкий уровень нет необходимости (тем более сегодняшние компиляторы очень хорошо оптимизируют).
Но Си все так же остается всё таким же «ассемблерно-близким», хотя для большей части продуктов, создаваемых с его помощью — таких вольностей не требуется, они только увеличивают риски косяков…
Зачем мы пишем прикладное ПО на «почти ассемблере» до сих пор?
Да, там кое-где код написано не универсально. Но дело не только в этом.
Дело не только в СТАНДАРТНОМ С++. Там еще куча ЗАВИСИМОСТЕЙ.
Все от вас зависит только в ПРОСТЕЙШЕМ ПО, которое вы пишете сами.
Как только начинаете использовать внешние вещи (библиотеки) — количество сюрпризов увеличивается.
Вплоть до багов в такой казалось бы базово-универсальной вещи как Boost, не говоря уже о более специфичных библиотеках…
Я постоянно использую подобную методу — создаю фиктивный канал chan struct{}, в который никто никогда не пишет, а использую этот канал для сигнализации, что объект/структура/сервис более не используется — просто вызвав close(done).
Это разблокирует все select и корректно завершает go-routines
Уже не решится проблема. Очевидно.
Компилятор, зависимый от платформы, который не должен пропускать подозрительные вещи.
В Си же можно накосячить «втихую».
Но это требует серьезных ДОПОЛНИТЕЛЬНЫХ затрат или просто СПЕЦИАЛЬНЫХ знаний.
Я утверждаю, что львинная часть Сипласпласовцев таковыми не очень то и стремится овладеть сосредоточившись на своей узкой задаче.
Ну не должен язык, претендующий на базовый, быть таким ненадежно-непредсказуемым.
Чтобы было понятно о чем речь и что проблема решаема в принципе — сравните, сколь небольшими усилиями делается переносимая программа на Python или Go.
С С++ не сравнить — это просто небо и земля.
В Python и Go если разработчику и нужно с чем то бороться при этом — то с отдельными аспектами не POSIX API (Windows). Что как раз ожидаемо и логично.
С С++ дополнительно приходится бороться с различиями в компиляторах и библиотеках — даже в пределах ОДНОЙ платформы.
P.S.:
Яндекс приведен как контора, которая может позволить себе разработчиков уровня выше среднего. И если даже они косячат со своими базовыми вещами (эта штука, что я привел — занимается запуском и мониторингом контейнеров с другим ПО в кластере Яндекса) — то что же ожидать от основной массы?
Не должен быть язык таким. Это плохое свойство. Существенный недостаток. Никак он не может претендовать на системный, базовый.
Протокол для проверки регистрации не нужен. Неуместное упоминание левых статей, не относящихся к делу.
Делается по другому — тебя задерживает один человек, а составляет протокол — другой человек.
По факту никто не тратит на это время. Но формально ты можешь быть задержан хоть ДПС, хоть ППС, хоть кем угодно.
Другое дело — что им это не интересно.
Пример с участковым и нарушением ПДД: участковый просто не имеет нужных бланков и не знает как что заполнять, ему это задержание не будет плюсом от начальства и пр. и пр. Но это вторичные причины.
Задерживать тебя могут ЛЮБЫЕ сотрудники полиции. Хоть из «детской комнаты» — если они штатные сотрудники.
Есть лишнее время? Не хочешь проверить регистрацию сразу — сядешь в обзьянник на 3 часа, дело-то. «Похожий на вас гражданин отжал телефон тут недалеко, мы обязаны проверить вас»
1С: Предприятие — это ОЧЕНЬ ГИБКО ДОРАБАТЫВАЕМАЯ система.
Львинная доля бабла идет не с продаж, а с доработок под КОНКРЕТНОГО КЛИЕНТА.
Стоимость доработок может превышать стоимость «коробки» в десятки и даже сотни раз — легко.