Все дело в формулировке "следующего сразу за первым в том же адресном пространстве".
Есть не так много ситуаций, когда стандарт требует определённого размещения в адресном пространстве, и локальные переменные на стеке — не тот случай. Компилятор волен расположить их произвольным образом, следовательно, этот случай не применим. Во всяком случае именно так я понимаю позицию разработчиков gcc.
Да, про упоротые случаи, конечно же :) Но компилятор обязан гарантировать одинаковое поведение кода строго соответствующего стандарту С на любых, даже самых упоротой платформе. Поэтому стандарт написан так, чтобы быть своего рода общим знаменателем всех возможных платформ.
Вообще-то приведенная в статье цитата из 6.5.8 говорит об этом прямым текстом — "Во всех остальных случаях поведение не определено" (после списка валидных сравнений).
Потому что указатели не обязательно имеют численное представление, для которого арифметические операции имеют смысл. Представим себе такую архитектуру, где объекты разного типа имеют независимую систему адресации и может быть бесконечное количество указателей со значением "42", которые не равны друг другу (т.к. указывают на данные разных типов). Это вполне легально по стандарту С.
Антимонопольные структуры существуют в большинстве (всех?) капиталистических странах не просто так. Монополия естественным образом следует из неконтролируемой рыночной конкуренции и впоследствии уничтожает её же, потому любой свободный рынок должен быть немного несвободен, чтобы выжить.
Народ, если у вас есть мнение, то, пожалуйста, выразите его словами.
Человек, для которого ООП сводится к наследованию ("Не пользуйтесь ООП в ООП") — настолько далёк от понимания предмета, что нет смысла даже тратить время на объяснения — просто ставишь минус и идёшь дальше.
Я думаю, что это пережиток того времени, когда считалось, что высокий уровень абстракции и полный контроль над железом не совместимы. Иначе в таком делении просто нет никакого практического смысла.
Но про ассемблер неверно, так все такие языки позволяют писать платформозависимый код. В том же Rust inline assembly планируется как часть языка (емнип уже есть в nightly, но не stable сборках). В С на практике тоже, хотя это и не часть стандарта.
Для меня сейчас понятие "уровня" полностью сводится к наличию/отсутствию обязательного рантайма и возможности unsafe работы с памятью.
1) Быть контактным лицом, если кому-то что-то нужно от этой команды
2) Раз в неделю собираться на митинг тим лидов и озвучивать там важные для команды темы (и потом транслировать обратно результат)
почему у них
Потому что кому-то надо это делать :) Существенного влияния на зарплату это не оказывает.
у них есть метрики привязанные к зарплате
Нет, у программистов не существует никаких метрик. Но после больших факапов руководство может прислать грустный мейл о том, сколько это стоило компании и человеку будет очень стыдно :)
почему Вы считаете что группа Senior-разработчиков в команде не может выполнять задачи
Например, потому что я так не считаю :) Более того, в компании, где я работаю, вообще нет никакого строгого деления на ранги и никакого технического менеджмента, одни лишь только Software Engineer. При этом тим лиды есть, но они все — обычные разработчики, просто с дополнительными обязанностями. Впрочем, когда компания была меньше, не было даже их, и было ещё лучше.
Просто нужно нанимать людей, умеющих принимать решения самостоятельно — и изначально объяснять, что таких решений от них ждут.
Фундаментальная ошибка, как мне кажется — считать, что наличие тим лидв делает что-либо лучше и является самоцелью. По моему опыту горизонтальная иерархия в разработке всегда эффективнее вертикальной, но у неё есть одна существенная проблема — перестаёт работать после определённого размера команды из-за затрат на общение каждого-с-каждым.
И вот именно в этот критический момент роста имеет смысл разбиваться на команды поменьше и заводить тим лидов — чтобы вся социальная система не рухнула под собственным весом. При этом продуктивнее от этого никто не станет, даже наоборот, и хороший руководитель должен это понимать.
В таком контексте единственная ключевая обязанность тим лида — служить точкой обмена информацией между командами, и ничего более. А ключевые навыки — широкое (но не обязательно глубокое) знание всех систем, за которые отвечает команда и умение эффективно организовывать внешнюю информацию для внутреннего потребления.
Не внутреннюю, а публичную репу клона, просто там будут не все исходники. Да, разоряется, т.к. на консалтинге и двойном лицензировании мертвого форка денег не поднимешь.
Это довольно узкое видение причин, по которым компании могут выкладывать код в публичный доступ. Я куда чаще встречаюсь с ситуацией, когда выкладываются полезные, но непринципиальные для бизнеса библиотеки и их дальнейшие форки никого не волнуют. Основная цель в таком случае — PR, а вовсе не получение патчей.
Ключевой для бизнеса код выкладывается очень редко, вне зависимости от лицензии.
Насколько я помню, GPL — это борьба «копилефта» с «копирайтом» оружием последнего.
Да, это хороший вариант описать ситуацию вкратце. Ещё GPL очень удобен в контексте двойного лицензирования. Это вообще очень хорошая лицензия и у меня к ней нет никаких претензий.
К чему у меня есть очень много претензий, так это к столлмановскому двоемыслию, в котором подобная ситуация подаётся не просто как "свобода", но даже как "настоящая свобода" (в противовес "ненастоящей" BSD).
У GPL благородные намерения и я готов им симпатизировать, но давайте всё же называть вещи своими словами: политический идеал GPL — это коммунизм. Возможности общества в целом являются приоритетными, даже если это подразумевает ограничения для отдельного индивидуума. Вне зависимости от того, разделяете ли вы эти идеалы, подавать их под брендом свободы — лицемерно. Может быть множество уважительным причин ограничивать использование опубликованных исходников, но они всё равно останутся искусственными ограничениями.
Конечно вправе. Но не нужно при этом использовать лицемерные метафоры вроде "Это как называть замок в моей машине «ограничением», потому что он останавливает остальных от присвоения моей машины".
Что общего между копирайт лобби и поклонниками GPL? И те, и те считают, что создание точной копии информации без потери оригинала — воровство. Хотя существует достаточно количество людей, которые используют BSD-like не только осознавая полную потерю контроля, но и ставя это своей непосредственной целью.
1) более эффективная работа с процессорным кэшем инструкций при переключении между разными процессами использующими одну и ту же библиотеку
2) меньше размер пакета для развёртывания на сервере (полезно в основном владельцам бюджетных VPS с лимитами на upload)
3) централизованное получение security обновлений если авторы библиотеки серьёзно относятся к версионирования ABI
Я бы сказал что динамическая линковка строго лучше статической, но только для стабильных библиотек с строгой системой версий. Что почти никогда не применимо к пакетам cargo и им подобным, но можно ожидать от стандартной библиотеки.
И вот именно для того, чтобы облегчить слияние такого рода (`fetch pr-branch` + `rebase upstream/base` + `push upstream/base HEAD`) и была написана утилита, про которую я упоминул изначально. Чтобы можно было просто сделать `git hub pull rebase ID` и получить желаемую историю.
Это недостаточная связность на мой взгляд. Тут две проблемы:
1) Требование создавать по отдельному pull request на каждый баг фикс сильно отяжеляет разработку бюрократией (коммиты напрямую в основные ветки строго запрещены)
2) Типичное для ревью требование отделять коммиты с форматированием от коммитов с семантикой очень полезно и впоследствии при git bisect. Это касается и реализации больших фич — грустно было бы обнаружить, что проблема возникла из-за одного цельного коммита на +5000 -5000.
У сохранении истории коммитов есть, впрочем, свои недостатки. Главные — нужно настраивать CI для тестирования всех коммитов, а не только HEAD; не удобного способа проследить связь между коммитом и pull request. В планах попытаться решить последнюю проблему через https://git-scm.com/docs/git-notes
Все дело в формулировке "следующего сразу за первым в том же адресном пространстве".
Есть не так много ситуаций, когда стандарт требует определённого размещения в адресном пространстве, и локальные переменные на стеке — не тот случай. Компилятор волен расположить их произвольным образом, следовательно, этот случай не применим. Во всяком случае именно так я понимаю позицию разработчиков gcc.
Да, про упоротые случаи, конечно же :) Но компилятор обязан гарантировать одинаковое поведение кода строго соответствующего стандарту С на любых, даже самых упоротой платформе. Поэтому стандарт написан так, чтобы быть своего рода общим знаменателем всех возможных платформ.
Вообще-то приведенная в статье цитата из 6.5.8 говорит об этом прямым текстом — "Во всех остальных случаях поведение не определено" (после списка валидных сравнений).
Потому что указатели не обязательно имеют численное представление, для которого арифметические операции имеют смысл. Представим себе такую архитектуру, где объекты разного типа имеют независимую систему адресации и может быть бесконечное количество указателей со значением "42", которые не равны друг другу (т.к. указывают на данные разных типов). Это вполне легально по стандарту С.
Отличная новость, экономическая ситуация в глобальной IT отрасли явно нездоровая и хорошо, что этому уделяют всё больше внимания.
Антимонопольные структуры существуют в большинстве (всех?) капиталистических странах не просто так. Монополия естественным образом следует из неконтролируемой рыночной конкуренции и впоследствии уничтожает её же, потому любой свободный рынок должен быть немного несвободен, чтобы выжить.
Человек, для которого ООП сводится к наследованию ("Не пользуйтесь ООП в ООП") — настолько далёк от понимания предмета, что нет смысла даже тратить время на объяснения — просто ставишь минус и идёшь дальше.
Я думаю, что это пережиток того времени, когда считалось, что высокий уровень абстракции и полный контроль над железом не совместимы. Иначе в таком делении просто нет никакого практического смысла.
Но про ассемблер неверно, так все такие языки позволяют писать платформозависимый код. В том же Rust inline assembly планируется как часть языка (емнип уже есть в nightly, но не stable сборках). В С на практике тоже, хотя это и не часть стандарта.
Для меня сейчас понятие "уровня" полностью сводится к наличию/отсутствию обязательного рантайма и возможности unsafe работы с памятью.
Rust — низкоуровневый язык. Уровень определяется близостью к железу, а не фичами языка.
1) Быть контактным лицом, если кому-то что-то нужно от этой команды
2) Раз в неделю собираться на митинг тим лидов и озвучивать там важные для команды темы (и потом транслировать обратно результат)
Потому что кому-то надо это делать :) Существенного влияния на зарплату это не оказывает.
Нет, у программистов не существует никаких метрик. Но после больших факапов руководство может прислать грустный мейл о том, сколько это стоило компании и человеку будет очень стыдно :)
Например, потому что я так не считаю :) Более того, в компании, где я работаю, вообще нет никакого строгого деления на ранги и никакого технического менеджмента, одни лишь только Software Engineer. При этом тим лиды есть, но они все — обычные разработчики, просто с дополнительными обязанностями. Впрочем, когда компания была меньше, не было даже их, и было ещё лучше.
Просто нужно нанимать людей, умеющих принимать решения самостоятельно — и изначально объяснять, что таких решений от них ждут.
Фундаментальная ошибка, как мне кажется — считать, что наличие тим лидв делает что-либо лучше и является самоцелью. По моему опыту горизонтальная иерархия в разработке всегда эффективнее вертикальной, но у неё есть одна существенная проблема — перестаёт работать после определённого размера команды из-за затрат на общение каждого-с-каждым.
И вот именно в этот критический момент роста имеет смысл разбиваться на команды поменьше и заводить тим лидов — чтобы вся социальная система не рухнула под собственным весом. При этом продуктивнее от этого никто не станет, даже наоборот, и хороший руководитель должен это понимать.
В таком контексте единственная ключевая обязанность тим лида — служить точкой обмена информацией между командами, и ничего более. А ключевые навыки — широкое (но не обязательно глубокое) знание всех систем, за которые отвечает команда и умение эффективно организовывать внешнюю информацию для внутреннего потребления.
Это довольно узкое видение причин, по которым компании могут выкладывать код в публичный доступ. Я куда чаще встречаюсь с ситуацией, когда выкладываются полезные, но непринципиальные для бизнеса библиотеки и их дальнейшие форки никого не волнуют. Основная цель в таком случае — PR, а вовсе не получение патчей.
Ключевой для бизнеса код выкладывается очень редко, вне зависимости от лицензии.
Да, это хороший вариант описать ситуацию вкратце. Ещё GPL очень удобен в контексте двойного лицензирования. Это вообще очень хорошая лицензия и у меня к ней нет никаких претензий.
К чему у меня есть очень много претензий, так это к столлмановскому двоемыслию, в котором подобная ситуация подаётся не просто как "свобода", но даже как "настоящая свобода" (в противовес "ненастоящей" BSD).
У GPL благородные намерения и я готов им симпатизировать, но давайте всё же называть вещи своими словами: политический идеал GPL — это коммунизм. Возможности общества в целом являются приоритетными, даже если это подразумевает ограничения для отдельного индивидуума. Вне зависимости от того, разделяете ли вы эти идеалы, подавать их под брендом свободы — лицемерно. Может быть множество уважительным причин ограничивать использование опубликованных исходников, но они всё равно останутся искусственными ограничениями.
Конечно вправе. Но не нужно при этом использовать лицемерные метафоры вроде "Это как называть замок в моей машине «ограничением», потому что он останавливает остальных от присвоения моей машины".
Что общего между копирайт лобби и поклонниками GPL? И те, и те считают, что создание точной копии информации без потери оригинала — воровство. Хотя существует достаточно количество людей, которые используют BSD-like не только осознавая полную потерю контроля, но и ставя это своей непосредственной целью.
Есть ещё несколько плюсов:
1) более эффективная работа с процессорным кэшем инструкций при переключении между разными процессами использующими одну и ту же библиотеку
2) меньше размер пакета для развёртывания на сервере (полезно в основном владельцам бюджетных VPS с лимитами на upload)
3) централизованное получение security обновлений если авторы библиотеки серьёзно относятся к версионирования ABI
Я бы сказал что динамическая линковка строго лучше статической, но только для стабильных библиотек с строгой системой версий. Что почти никогда не применимо к пакетам cargo и им подобным, но можно ожидать от стандартной библиотеки.
Чтобы не было голословного обмена утверждениями, вот данные по актуальным компиляторам на x86_64 Arch Linux (
-O -inline+strip):(ldc-static и gdc-shared под рукой не было, но общая картина должна быть очевидна)
1) Требование создавать по отдельному pull request на каждый баг фикс сильно отяжеляет разработку бюрократией (коммиты напрямую в основные ветки строго запрещены)
2) Типичное для ревью требование отделять коммиты с форматированием от коммитов с семантикой очень полезно и впоследствии при git bisect. Это касается и реализации больших фич — грустно было бы обнаружить, что проблема возникла из-за одного цельного коммита на +5000 -5000.
У сохранении истории коммитов есть, впрочем, свои недостатки. Главные — нужно настраивать CI для тестирования всех коммитов, а не только HEAD; не удобного способа проследить связь между коммитом и pull request. В планах попытаться решить последнюю проблему через https://git-scm.com/docs/git-notes