Во-первых, вы сами сказали что код, который вы пишете можно взломать и закрытый код — чуть ли не единственная линия «защиты» от взлома. Не важно сколько контрактов у вас есть и сколько вы получаете — это не доказывает качетство или некачественность кода, главное как вы сами оценили свою работу.
Решение про «велосипедить с нуля» или нет должны принимать инженеры, а не руководство, и это решение должно приниматься на основе технических аргументов. Ведь может быть аргумент был «если мы только немного допилим существующий компилятор существующего языка, то как мы обоснуем милионные контракты?» Я не говорю что это именно так и было, но это тоже подходит под ваше «не с проста» и «руководство».
Можете делать закрытый проект с бекендом — никто не заставляет открывать. Хотя этот ваш security by obscurity говорит о недостаточной квалификации программистов для ваших «Серьёзных» задач. Или задачи недостаточно серьёзные, скорее всего.
А выгода простая, причём для вас же: в случае LLVM вы получаете рабочий фронтэнд clang, кучу машинно-независимых оптимизаций и готовой инфраструктуры для быстрой реализации не только бекенда, но и ассемблера, дизассемблера и некоторых других частей тулчейна. Не нужно всё велосипедить с нуля, понимаете?
> нет никаких гарантий, что объект не прекратит свое существование во время выполнения функции
Да и вообще любой object может быть освобождён, причём любым потоком! И любой другой поток может создать вашему потоку data race! И совсем никаких гарантий!
Да нет уже в современных процессорах и материнских платах никаких шин с общим доступом! Там везде выделенные point-to-point линки: QPI, PCI Express — всё это выделенные point-to-point линки, на каждом из которых ровно два устройства, обменивающиеся данными. Блокировать такие линки от доступа кем-то ещё нет никакого смысла, так как там больше никого и нет.
Вы не поверите, но это корректный код на C++ — почитайте стандарт. Если у вас это вызывает непонимание или смех, это ещё раз доказывает, что писать пытаться быть наставником для других, как в этой статье, — не ваш уровень.
Можно как в java. А можно так:
class Main { void main(); };
и обязать рантайм создавать экземпляр класса Main и вызывать у него функцию-член main(). Но смысла в этом никакого потому что ООП — это не «больше никогда не пишем non-member functions», да и C++ — не чистый ООП язык.
Строчка про sizeof() ни в стандарте C, ни в стандарте C++ не встречается. Но та же информация про размеры типов в стандарте C++ выражена более явно:
[basic.fundamental]p2:
There are five standard signed integer types: “signed char”, “short int”, “int”, “long int”, and “long
long int”. In this list, each type provides at least as much storage as those preceding it in the list.
Вы пытаетесь придумать уже третий пример на эту тему, но пока получается только fail. Вы не думаете что вам нужно просто почитать стандарт?
В данном случае, так как известно что файлов всегда ровно миллион, я бы применил uint32_t для номера файла. Но в общем случае стоит применить uintmax_t.
Если данные на диске, то вы ничего не итерируете, а осуществляете random access к файлу. Поэтому по стандарту Си (чтобы быть максимально педантичным отвечая на троллинговый вопрос) вам нужно использовать fpos_t вместе со стандатрными функциями из stdio.h.
Если быть более реалистичным и расширить кругозор до POSIX, то мы увидим off_t.
Согласно стандарту верно одно из двух: или size_t позволяет проитерировать миллион элементов или такой большой массив не поместится в память вашей машины.
Ага, даже не смешно. За сколько вы разработаете фронтэнд C++? Да ладно, даже чистого C11? А Clang или GCC достаются даром.
Решение про «велосипедить с нуля» или нет должны принимать инженеры, а не руководство, и это решение должно приниматься на основе технических аргументов. Ведь может быть аргумент был «если мы только немного допилим существующий компилятор существующего языка, то как мы обоснуем милионные контракты?» Я не говорю что это именно так и было, но это тоже подходит под ваше «не с проста» и «руководство».
А выгода простая, причём для вас же: в случае LLVM вы получаете рабочий фронтэнд clang, кучу машинно-независимых оптимизаций и готовой инфраструктуры для быстрой реализации не только бекенда, но и ассемблера, дизассемблера и некоторых других частей тулчейна. Не нужно всё велосипедить с нуля, понимаете?
Да и вообще любой object может быть освобождён, причём любым потоком! И любой другой поток может создать вашему потоку data race! И совсем никаких гарантий!
Да нет уже в современных процессорах и материнских платах никаких шин с общим доступом! Там везде выделенные point-to-point линки: QPI, PCI Express — всё это выделенные point-to-point линки, на каждом из которых ровно два устройства, обменивающиеся данными. Блокировать такие линки от доступа кем-то ещё нет никакого смысла, так как там больше никого и нет.
Очень интересно. У каких функций, по вашему мнению, есть деструктор и что он делает?
Автор написал так, как будто у всех функций деструктор есть, а main какая-то неполноценная.
class Main { void main(); };
и обязать рантайм создавать экземпляр класса Main и вызывать у него функцию-член main(). Но смысла в этом никакого потому что ООП — это не «больше никогда не пишем non-member functions», да и C++ — не чистый ООП язык.
Страуструп с вами не согласен:
www.stroustrup.com/bs_faq.html#Object-Oriented-language
Writing Java-style code in C++ can be as frustrating and sub-optimal as writing C-style code in C++.
Это правильное и очень красиво записанное утверждение, но этой строчки в таком виде в стандартах нет (а жаль, так нагляднее).
[basic.fundamental]p2:
В данном случае, так как известно что файлов всегда ровно миллион, я бы применил uint32_t для номера файла. Но в общем случае стоит применить uintmax_t.
Если быть более реалистичным и расширить кругозор до POSIX, то мы увидим off_t.