Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
public class ExampleW{
public static void main(){
Scanner input = new Scanner(System.in);
System.out.println("Give mark: ");
int mark = input.nextInt();
String Grade;
switch (mark){
case 100:
case 99:
case 98:
case 97:
case 96:
case 95:
case 94:
case 93:
case 92:
case 91:
case 90:{
Grade = "A+";
break;
}case 89:
case 88:
case 87:
case 86:
case 85:
case 84:
case 83:
case 82:
case 81:
case 80: {
Grade = "A";
break;
}case 75:
case 76:
case 77:
case 78:
case 79:{
Grade = "A-";
break;
}case 70:
case 71:
case 72:
case 73:
case 74:{
Grade ="B+";
break;
} case 69:
case 68:
case 67:
case 66:
case 65:{
Grade ="B";
break;
}
case 64:
case 63:
case 62:
case 61:
case 60:{
Grade = "C+";
break;
}case 50:
case 51:
case 52:
case 53:
case 54:
case 55:
case 56:
case 57:
case 58:
case 59: {
Grade = "C";
break;
}case 45:
case 46:
case 47:
case 48:
case 49:{
Grade = "D";
break;
}case 40:
case 41:
case 42:
case 43:
case 44:{
Grade = "E";
break;
}case 0:
case 1:
case 2:
case 3:
...
...
}default: {
Grade = "null";
break;
}}
}
public class ExampleW{
public static void main(){
Scanner input = new Scanner(System.in);
System.out.println("Give mark: ");
int mark = input.nextInt();
String Grade;
switch (mark){
case 100:
case 99:
case 98:
case 97:
case 96:
case 95:
case 94:
case 93:
case 92:
case 91:
case 90:{
Grade = "A+";
break;
}case 89:
case 88:
case 87:
case 86:
case 85:
case 84:
case 83:
case 82:
case 81:
case 80: {
Grade = "A";
break;
}case 75:
case 76:
case 77:
case 78:
case 79:{
Grade = "A-";
break;
}case 70:
case 71:
case 72:
case 73:
case 74:{
Grade ="B+";
break;
}case 69:
case 68:
case 67:
case 66:
case 65:
case 64:
case 63:
case 62:
case 61:
case 60:{
Grade ="B";
break;
}case 50:
case 49:
case 48:
case 47:
case 46:
case 45:
case 44:
case 43:
case 42:
case 41:
case 40: {
Grade ="C+";
break;
}case 39:
case 38:
case 37:
case 36:
case 35:
case 34:
case 33:
case 32:
case 31:
case 30:{
Grade ="C";
break;
}case 25:
case 24:
case 23:
case 22:
case 21:
case 20:{
Grade ="D";
break;
}
}
System.out.println("The mark "+ Grade + " is good");
}
}
}
Кстати, у STL куча реализаций (STLPort, Rogue Wave, Dinkum STL и прочие). У них перекрёстные зависимости заголовков могут отличаться. Да даже у форков одной библиотеки для разных компиляторов и разных платформ зависимости могут отличаться.
А представь, что реализация юзает разные по смыслу но одинаковые по названию платформозависимые функции, не описанные в самом стандарте. И т.к. код ничего явно не инклудил, он получает какую-то из них.
С header-only библиотеками связана проблема: всё, что использует реализация, нужно инклюдить, т. е. делать публичным для всех пользователей библиотеки.
Если же библиотека с раздельной компиляцией, то всё, от чего зависит только реализация и не зависит интерфейс, можно инклюдить только в c/cpp-файлы, не портя хедеры лишними зависимостями.
> Разве обязаьельно инклудить это говно в std?
ЯНИХУЯНЕПОНЯЛ.ЖПГ
> Нэйм пейсами это говно не решается?
Проблема в том, что то, что внутри использует какая-то библиотека, вылазит к тебе.
Импортируется какая-то бустовская либа, все эти имена доступны тебе. И теперь у тебя всё падает с ошибкой, потому что новый инклюд затащил через три колена какую-то функцию, которая стала находиться через ADL и оказалась лучшим кандидатом, чем оригинальная.
Я имел ввиду, библиотеку нельзя написать так, чтобы внутре нейсмпейса, например std, не было лишнего говна типа printf? Нельзя заинклудить stdio.h в какой-нибудь анонимный неймспейс?
А хотя в крестоговне всё равно прилетят макросы из других хедеров. Какой багор )))
> какой-нибудь анонимный неймспейс
Анонимный неймспейс не спасёт, он только даёт внутреннюю видимость. Единственный, кого это ебёт — линкер.
Вся проблема именно в том что include это тупой копипаст. В последних С++ это попытались решить модулями, в которых прописано, что именно экспортируется.
В принципе нормально. Заголовочные файлы можно импортировать, это даст доступ к сущностям, объявленным там, но не насрёт тем кто импортирует данный модуль. Если ты пишешь не модуль, а простую единицу трансляции, которую никто инклюдить не будет, то можешь смешивать импорты и инклюды в одном файле.
Единственная проблема — импортируемые заголовки не видят макросов, обявленных вне них (благодаря изоляции). Так что, если настройка библиотеки работает через определение макросов перед её включением, то нужно макросы определять либо на уровне компилятора (-dNDEBUG), либо использовать костыль под названиет «глобальный фрагмент модуля»
ЕМНИП в гцц/шланге это работает если в юнионе хранятся только POD. Иначе начинают работать с отдельными членами, как с несвязанными переменными, и может случиться UB, когда конпелятор решит подержать пока свежеприсвоенное значение на стеке и не записывать его, а другой член юниона в то время прочтут.
Судя по приведённым там примерам, увидит что другой член трогают и зафлашит всё как положено. Но надо именно явно обращаться, не через указатели. Иначе не зафлашит.
The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed:
- the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.
- any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.
- you can write object-oriented code (useful for filesystems etc) in C,
_without_ the crap that is C++.
И правильно. Кресты - кривоублюдочное говно с говноэксепшенами.
> Просто не юзай 90% стандартной либы и не пиши try и throw.
А также надо не юзать никаких библиотек, которые используют эти говноэксепшены и что-то из той 90% части стандартной либы, которой эксепшены нужны. В общем хуй че тогда можно поюзать, говно одним словом
> Если мы говорим конкретно о ядре, то и в сишной либе хуй чего можно поюзать. Ну разве что какие-то совсем базовые вещи в духе memcpy да strncpy.
Во-первых в сишной либе и так хуй что есть. Во-вторых stdatomic.h вполне можно поюзать. И stdalign.h например. Или это тоже базовые вещи? Что вообще считать за базовые, а что за "небазовые" вещи?
> Во-первых в сишной либе и так хуй что есть.
Тебе не скажут, что в твоей либе кучу вещей нельзя использовать в каких-то обстоятельствах, если и так там использовать нечего.
Лучший язык — брейнфак. Одинакого непригоден что для прикладного программирования, что для ядра, что для контроллеров.
Ну и в крестах ты вполне можешь поюзать атомики и кучу алгоритмов. Те же сортировки. Они или в принципе ничего не кидают или не кидают если твои типы ничего не кидают.
Сначала я не понимала, почему директор при разговоре со мной корчит рожи и думала: что же его так плющит? Потом выяснилось, что он мою мимику копировал
I've said this before, and I'll say it again: a standards paper is just so much toilet paper when it conflicts with reality. It has absolutely _zero_ relevance. In fact, I'll take real toilet paper over standards any day, because at least that way I won't have splinters and ink up my arse.
Затуманились речные перекаты
Не благодари.
Окончания были такие
- Ну не плачь,- сказала Мышка:
все равно кастрюле крышка!
-И это для Дятла такая наука,
Что он никуда не заходит без стука!
-Пожалуйста, я откажусь от короны,
Но можно сначала доесть макароны?
-Но тут Осьминог подошёл к Осьминогу
И в знак уваженья пожал ему ногу.
-Вчера крокодил улыбнулся так злобно,
Что мне до сих пор за него неудобно
Да и та на погоне
Скроется солнце в густых облаках.
:trollface:
это же так можно бы было битоебить...
> #include <iostream>
> std::printf
Кстати, а использование функций случайно прилетевших по транзитивной зависимости -- это не UB? Или просто implementation defined?
Думаю, это implementation defined.
Всё-таки транзитивность препроцессора -- зло.
Если же библиотека с раздельной компиляцией, то всё, от чего зависит только реализация и не зависит интерфейс, можно инклюдить только в c/cpp-файлы, не портя хедеры лишними зависимостями.
ЯНИХУЯНЕПОНЯЛ.ЖПГ
> Нэйм пейсами это говно не решается?
Проблема в том, что то, что внутри использует какая-то библиотека, вылазит к тебе.
Импортируется какая-то бустовская либа, все эти имена доступны тебе. И теперь у тебя всё падает с ошибкой, потому что новый инклюд затащил через три колена какую-то функцию, которая стала находиться через ADL и оказалась лучшим кандидатом, чем оригинальная.
А хотя в крестоговне всё равно прилетят макросы из других хедеров. Какой багор )))
Анонимный неймспейс не спасёт, он только даёт внутреннюю видимость. Единственный, кого это ебёт — линкер.
Вся проблема именно в том что include это тупой копипаст. В последних С++ это попытались решить модулями, в которых прописано, что именно экспортируется.
И как эти "модули" кобенируются с обычными .h файлами, инклудящимися через препроцессор?
Единственная проблема — импортируемые заголовки не видят макросов, обявленных вне них (благодаря изоляции). Так что, если настройка библиотеки работает через определение макросов перед её включением, то нужно макросы определять либо на уровне компилятора (-dNDEBUG), либо использовать костыль под названиет «глобальный фрагмент модуля»
Х.з., я даже с обычными хедерами всегда пишу такие настройки через -D. Чтобы заведомо рассогласования не было.
за #define SETTING 1 да еще и в правлиьном парядке надо пробивать щелбана
https://ideone.com/NCKGkG
Бон аппетит.
- у юниона есть только один активный член
- остальные члены ещё не начали или уже закончили жить
- поэтому обращение к ним UB
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Type-punning
Судя по приведённым там примерам, увидит что другой член трогают и зафлашит всё как положено. Но надо именно явно обращаться, не через указатели. Иначе не зафлашит.
С точки зрения стандарта это UB.
См. цитату Линуса ниже по тексту.
https://lore.kernel.org/lkml/Pine.LNX.4.58.0401192241080.2311@home.osdl.org/
The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed:
- the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.
- any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.
- you can write object-oriented code (useful for filesystems etc) in C,
_without_ the crap that is C++.
И правильно. Кресты - кривоублюдочное говно с говноэксепшенами.
Просто не юзай 90% стандартной либы и не пиши try и throw.
З.Ы. В стандарте нет никакого "размера кода", поэтому на размер кода это никак не влияет.
А также надо не юзать никаких библиотек, которые используют эти говноэксепшены и что-то из той 90% части стандартной либы, которой эксепшены нужны. В общем хуй че тогда можно поюзать, говно одним словом
И они пользуют только те 10% из стандартной крестоговнолибы, которой не нужны исключения, да?
И они пользуют только те 10% из стандартной крестоговнолибы, которой не нужны исключения, да?
Если мы говорим конкретно о ядре, то и в сишной либе хуй чего можно поюзать. Ну разве что какие-то совсем базовые вещи в духе memcpy да strncpy.
Если мы говорим конкретно о ядре, то и в сишной либе хуй чего можно поюзать. Ну разве что какие-то совсем базовые вещи в духе memcpy да strncpy.
Во-первых в сишной либе и так хуй что есть. Во-вторых stdatomic.h вполне можно поюзать. И stdalign.h например. Или это тоже базовые вещи? Что вообще считать за базовые, а что за "небазовые" вещи?
Тебе не скажут, что в твоей либе кучу вещей нельзя использовать в каких-то обстоятельствах, если и так там использовать нечего.
Лучший язык — брейнфак. Одинакого непригоден что для прикладного программирования, что для ядра, что для контроллеров.
Ну и в крестах ты вполне можешь поюзать атомики и кучу алгоритмов. Те же сортировки. Они или в принципе ничего не кидают или не кидают если твои типы ничего не кидают.
Даже Торвальдс сказал, что туалетная бумага полезнее стандарта, потому что она не оставляет чернил на жопе.
allocations behind your back just isn't a good choice for a kernel.
ну тут надо сказать, что прячет только STL. Сам С++ ничего не прячет
Но при этом bit fields.
Linus Torvalds