Как стать автором
Обновить
1
0

Пользователь

Отправить сообщение
Предположу, что эксперименты на мышах банально дешевле.
Кальмарообразные щупальца мельком показывают в официальном трейлере фильма.
Очень люди любят вспоминать законы Азимова, и при этом забывают, что практически весь сборник «Я, робот» как раз о том, что эти законы слишком наивны и нифига не работают.
> Мы просто обалдели
> И ещё больше удивились
Для этого и нужно читать стандарт языка, чтобы не полагаться на имперические знания, почерпнутые из общения с одной платформой, при переходе на другую платформу. Там еще много таких интересных мест в стандарте есть, которые на вашем компайлере могут работать совсем не так, как вы привыкли на vc++/g++ ;)
> каждая инструкция их использующая как бы осуществляет неявное приведение этих данных к тому типу, с которым она работает
Правильнее будет сказать «интерпретирует данные, как данные того типа». Потому что приведение обычно подразумевает изменение формата и/или внутреннего представления (например: приведение int к string, приведение float к int), хотя и не всегда, а инструкция не меняет данные, а просто предполагает, что они уже в нужном ей формате.
> тема довольно мутная всё равно
Ну так пост именно об этом: у нас в обороте куча терминов, которые в разных контекстах имеют разное значение, и куча сущностей, которые в разных контекстах обозначаются разными терминами. И мы часто путаемся, потому что увидев термин, не знаем, какой контекст имелся ввиду, или сами используем термин не из того контекста, когда имеем ввиду какую-то сущность.
2.2 Character sets
The basic source character set consists of 96 characters: the space character, the control characters representing horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters [...]
[...]
The basic execution character set [...] shall [...] contain all the members of the basic source character set, plus control characters representing alert, backspace, and carriage return, plus a null character.


Про кодировки ни слова. Языку не интересно, как эти символы кодируются битами и машинными байтами, но байт в языке С определен как «at least large enough to contain any member of the basic execution character set». Если завтра авторы gcc решат заменить внутреннее представление символов с ASCII на UCS-2, — это их право. Тогда каждый символ будет занимать два машинных байта, но все еще один сишный байт.

> Так что я не вижу ошибки в своём мнении.
Ваше мнение прямо противоречит параграфу 5.3.3 стандарта.

Обратите внимание, что вы упали именно в ту яму, которая описана в посте: термин байт имеет множество смыслов в зависимости от контекста, и мы сейчас спорим о том, чем он является, а чем — нет, но используем разные контексты. Так что спорить мы можем бесконечно, пока не осознаем бессмысленность этого занятия (в контексте языка С прав я, в контексте UTF-8 правы вы: в RFC термины byte и octet используются как взаимозаменяемые, и octet определен как 8 бит).
Ну серьезно. Сишной документации под рукой нет, но есть спек с++98, который вряд ли сильно отличается от с98 в этой части. Цитирую:

1.7 The C++ memory model
The fundamental storage unit in the C++ memory model is the byte. A byte is at least large enough to contain any member of the basic execution character set and is composed of a contiguous sequence of bits, the number of which is implementation-defined.


3.9.1 Fundamental types
Objects declared as characters (char) shall be large enough to store any member of the implementation’s basic character set


5.3.3 Sizeof
The sizeof operator yields the number of bytes in the object representation of its operand. [...] sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1;


Параграф 1.7 дает определение байта в контексте языка С++, 3.9.1 предъявляет к char такие же требования по размеру, которые предъявлены к байту в параграфе 1.7, параграф 5.3.3 явно говорит, что размер char равен одному байту.

Судя по всему, вы думали о байте в контексте кодировок, а там в этот термин вкладывается немного другой смысл :)
> размер типа int в «языке С»?

Стандарт выдвигает следующие требования:
1) sizeof(char) == 1 (char всегда 1 байт, число битов в байте не зафиксировано, но должно быть «достаточно, чтобы поместился описанный в стандарте набор символов»).

2) sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)

Дальше все зависит от среды сборки/исполнения. Указать только язык в данном случае недостаточно для задания полного контекста.
Мой опыт говорит как раз об обратном: если сразу задуматься, что нужно сделать, кому какие данные и в каком формате нужны, как изменения затрагивают разные части проекта, — то можно написать детальную документацию на всё, согласовать изменение со всеми заинтересованными сторонами, а потом отдать написание кода джунам, потому что эта задача становится тривиальной.
И наоборот — если сразу влезть в код и начать что-то менять без того, чтобы предварительно подумать, то получится игра в перетягивание одеяла: что-то поменяли, что-то от этого сломалось, его починили, но сломалось что-то другое, неделю рефакторили какой-то модуль, но потом оказалось, что он теперь не состыкуется с каким-то другим, и нужно откатывать все изменения… В результате вся та же работа по согласованию все равно будет делаться, только в процессе тратится куча лишнего времени на написание и переписывание кода, а что-то, что сломалось, может остаться незамеченным.
Сроки при этом растягиваются на порядок (и их становится невозможно нормально оценить заранее, что приводит к срывам и кранчам со всеми вытекающими), а качество всей системы заметно страдает (что еще больше усугубляет ситуацию). И чем больше проект, тем сильнее все это проявляется.

> а потом под нее подгонять код?
Писать код по спецификации, да. Намного проще и на порядок-два быстрее, чем по-ковбойски бросаться в написание кода без предварительного включения головы.

> вот так просто взять и составить документацию по всем API и тех. задание по ней — это анрил
Как раз наоборот, написать весь код так, чтобы все работало и не было костылей на каждом шагу без предварительного планирования — анрил.

Но я уже выше писал, что, похоже, неправильно оценил вид проектов, с которыми местная публика в основном работает, а в вашей кухне я не разбираюсь. Возможно, в вашем случае мой опыт и неприменим.
> А сложные системы что, прям реально по водопаду живут?

Более-менее. По крайней мере подход «за две недели добавим вот эту фичу, а как добавлять следующую, будем думать потом» работает очень плохо. Приходится много думать и планировать наперед, иногда на год-два вперед. Иначе код за год настолько зарастает костылями, что второй год целиком уходит на разгребание бардака, а не на развитие функционала. Примеров больших проектов, которые через пару лет разработки начали переписывать все с нуля — масса, и часто причина именно в этом: разгрести старый говнокод оказалось дороже, чем написать заново с нормальным планированием.

> если требования поменялись к цвету кнопок, то как в документации согласовали, так и кодим.

Зависит от масштабов изменения. Часто — да, реализуют по предыдущей версии документации, а новую функциональность вносят только в одной из следующих итераций, после согласования новой документации.

> останавливаем разработку на время согласования обновленной документации?

Тоже случается. Если изменение значительное и много чего ломает, то оказывается дешевле заморозить разработку этой фичи или даже всего проекта, пока не будет ясности с требованиями. Продолжать писать код, когда не понятно, что же он должен делать в конце — лишняя трата времени.
Лучше в это время занять программистов всякими низкоприоритетными задачами, которые было бы неплохо сделать, но вечно не хватает времени. В больших проектах таких задач всегда вагон и маленькая тележка.
Я исхожу из предположения, что с задачей придется разобраться до окончания работ, и если уж от этого не убежать, то будет на порядок (а иногда и на два) дешевле сначала разобраться с задачей, а потом писать код, а не писать и переписывать код, пока не станет понятно, что же он в конце концов должен делать.

Но судя по комментариям, мое предположение о том, что задачу на каком-то этапе все равно нужно будет понять, является ошибочным.
> «а по описанию мы подумали, что оно иначе выглядеть будет».
Именно поэтому первым в цепочке стоит product design, который включает в себя описание функциональности и скетчи интерфейсов для пользователя. Пока эти аспекты не согласованы с заказчиком, нет смысла начинать писать код.

Я, наверное, неправильно понял о чем речь в статье. Тут, похоже, собрались разработчики именно «хтонических чудовищ», наподобие одноразовых сайтов-визиток для заказчиков, которые сами не знают, чего хотят и не в состоянии оценить, чего же им в конце концов наваяли. В этой области, конечно, и подходы другие, и опыта построения сложных систем, которые должны by design работать и развиваться в течение многих лет, набраться негде.
Только тогда я не понимаю, откуда в этих сайтах-визитках берутся API, для которых может понадобиться документация, но я много чего не понимаю в вашей кухне.
> Документация это не ТЗ.
А где я говорил иначе?

Порядок действий очень простой: Product spec (чего хочет заказчик) -> Tech Spec (как это реализовать технически в рамках текущей кодовой базы, как меняются архитектура, базы данных, API; как писать все не-тривиальные новые части) -> обновление технической документации -> согласование изменений (до того, как потратили кучу времени на написание кода) -> код -> тестирование на соответствие имплементации и документации.

Если начать писать код до того, как полностью разобрались с задачей или договорились со всеми заинтересованными сторонами, поимеешь кучу косяков и потратишь намного больше времени.
> Это работает только для сферических проектов в вакууме.
Я тоже так думал в первые несколько лет своей карьеры. Потом понял, что как раз наоборот: без этого нормально не работает ни один проект, для которого вообще имеет смысл писать документацию.
> писать всё ручками.
> я глубоко убеждён что [этот способ] в корне неверен. Дело в том, что он порождает документацию, которая всё время [...] отстаёт от объекта документации.

Дело в том, что если сначала пишется API как получится, а потом пост-фактум под него пишется документация, то качество этого API будет стремиться к нулю или даже дальше в минус бесконечность. При правильном подходе, документация пишется на этапе проектирования и всегда опережает код. А код и тесты пишутся уже в соответствии с документацией. При таком подходе, и код будет чище, и если имплементация в результате будет отличаться от документации, тесты это покажут.

> «правильный» подход, состоит в том, чтобы генерировать документацию по исходникам автоматически.
> Специально обученный парсер пробегает по исходникам, вычленяет особым образом оформленные комментарии с документацией.

Какая разница, хранится документация в отдельном файле или в комментариях в файле с исходниками, если она все равно пишется пост-фактум, и никто не заметит, если какие-то ее части не будут соответствовать реализации? Если этап проектирования пропустили и правят код по наитию, скорее всего, интерфейсы будут меняться много раз по ходу работы, и кое-где забудут обновить комментарий с описанием.

Дальше не читал.
Как там с поддержкой драйверов (radeon), стима и современных игр? Есть смысл вместо винды поставить, или пока не стоит?
В винде вроде есть такая фича, что если обновлениям нужно что-то сделать после загрузки, то формируется одноразовый токен для доступа к диску. Естественно, до следующей загрузки этот токен лежит где-то в открытом виде и может быть использован злоумышленником.
Отключается где-то в настройках windows update.
> США своими санкциями… как декларируется, пытаются помочь именно простым гражданам
Ну так и помогают. В конце концов простые граждане поймут, что что-то их руководство делает не так, и сменят это руководство, чем нанесут себе пользу.
Правильно, что запретили.

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

автопилот с открытым кодом — бредовая идея

А можете пояснить почему?

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность