- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
private static bool ProductGT10(Point p)
{
if (p.X * p.Y > 100000)
{
return true;
}
else
{
return false;
}
}-
C# / Говнокод #13354
+121
Классический пример из MSDN
http://msdn.microsoft.com/ru-ru/library/bfcke1bz.aspxЗапостил:
kegdan,
10 Июля 2013
Follow us!
придётся разжовывать.
Примеры по класическому ASP.NET'у тоже включают в себя код используя SqlDataSource, а не Entity или LINQ to SQL.
Разжовывать - оба кода имеют место быть. Мало-ли какие идеалы используются в отдельных компаниях.
А SqlDataSource написать можно быстрее:
Да и использование в качестве примера DAO/DAL только породит лишние вопросы.
Код:
Можно прочитать даже не зная языка, но зная школьную программу математики:
Если Х умножить на У больше 100 000, то вернуть true. Иначе вернуть false.
А вот код:
Уже подразумевает понимание не только математики, но и основ программирования на определённом языке.
Ведь, понимание того, какие инструкции будут выполнены, мне кажется важным.
В IL, байткод у обоих методов будет идентичен.
PS по ссылке у меня открывается статься "Predicate(T) Delegate" где нет этого примера
Это над минимум так писать:
А вообще, если твои ученики животные, которое не осилили примитивный Си-синтаксис, то они животные - и твоя ЦА животные, ибо этот код питуш, как в примере выше:
Зачем скобки вокруг выражения?
http://dev.fyicenter.com/Interview-Questions/C/Are_the_outer_parentheses_in_return_stat ements_r.html
http://stackoverflow.com/questions/161879/parenthesis-surrounding-return-values
раньше скобки были нужны.
Другой вариант - чтобы стейтмент был больше похож на другие управляющие структуры вроде if и for.
return a + b + c + d; - питушня.
А оно так и есть. Польская запись она для стековых машин. А таких сейчас мало, почти все машины регистровые. На том же x86 польская запись пригодится разве что при работе с FPU.
LLVM'овский IR - регистровый.
Насчет JVM трудно сказать, она же только наполовину стековая. При желании можно складывать в стек только аргументы операций, исполнять их и рассовывать результаты по локальным переменным...
P.S. Ну и я так думаю, что Царь не будет связываться с .net или jvm, а все-таки будет генерить нативный код.
Why don't you use gcc as the basis for your C# compiler?
...
The hard part is RTL (Register Transfer Language). This part of gcc is hard-wired to generate code for register-based CPU's such as i386, PPC, Sparc, etc. RTL is not designed for generating code for stack-based abstract machines such as IL.
Also, RTL loses a lot of the type and code structure information that IL needs in the final output file. By the time RTL gets the code, information about whether a value is an integer or an object reference is mostly lost. Information about the class structure of the code is lost. This information is critical for correct compilation of C# to IL.
https://habr.com/ru/post/209732/comments/#comment_8710245
> LCC был выбран, потому что в кодогенератор он передаёт кусочки графа программы, что идеально подходит для архитектуры Multiclet. При этом, в каждом линейном блоке графа нет ссылок на узлы из других блоков. Это соответствует концепции параграфов.
> «Монстры» же ориентированы на генерацию кода для чисто регистровых машин, к которым наши процессоры не относятся в полной мере: внутри параграфов у нас стоит потоковое (dataflow) описание вычисления. Поэтому мы не можем автоматически использовать оптимизации, которые есть в LLVM и GCC. При помощи абстракций, используемых в них для описания архитектуры целевой машины, такие потоковые машины не выражаются (по крайней мере, штатными API). Например, LLVM при оптимизации спокойно выносит общие выражения в линейные блоки за циклы, а в линейных блоках циклов ставит на этот результат ссылку, подразумевая, что она соответствует абстрактному регистру, который не меняется. Для нас разрешение такой ситуации — совсем не тривиальная задача.
> Поэтому нам приходится изобретать свой компилирующий велосипед. Надеемся, что в нём будет достаточно интересных фишек, чтобы привлечь к оптимизациям и разработке нормальных API сообщество.
т.е. в этом отношении он нихуя не лучше GCC
какой багор
а почему? Потому что железные процы обычно регистровые а виртуальные мащины типа йажа дотминьет -- стековые но всем похуй?
1. Как определить, уёбок я или нет?
2. Я мужик, поэтому мне не нравится Путин. Я же не ослоёб, чтобы мне нравилось всё, что движется.
> Я же не ослоёб
Сам спросил - сам ответил
But hang on a second! Gcj, the Java back-end for gcc, does stack machines! Why not do something like that?
Err ... no it doesn't. The Java bytecode stuff in gcj is not organised as an RTL back-end.
When gcj compiles Java, it performs parsing and semantic analysis in the front-end, like the other supported languages. Then the parse tree is sent in one of two different directions.
If gcj is compiling to native, the parse tree is handed to the RTL core of the compiler, and it takes over.
If gcj is compiling to bytecode, the parse tree is handed to a completely separate code generator that knows about Java bytecode.
Because gcj does NOT implement a bytecode RTL back-end for gcc, it cannot compile C, C++, etc down to bytecode. Java bytecode is a special case that only works for the Java front-end.
But what about egcs-jvm? Doesn't it compile C to Java bytecode?
It's a hack. The code that it generates is horrible, and does not conform to the usual conventions that the JVM requires. If one compiled Java code using this back-end, it wouldn't work with normal Java code due to the differences in calling conventions and what-not.
The biggest problem that the author of egcs-jvm he had was trying to work around the register machine assumptions in the code. The result wasn't pretty. He has said that it would be easier to throw the JVM away and invent a register-based abstract machine than try to make gcc generate efficient stack machine code.
Isn't there a gcc port to the Transputer, which is stack-based?
Yes there is, for an older version of gcc (2.7.2). The source can be found here.
...
Realistically, someone with a great deal of gcc knowledge needs to go into the gcc core, rip RTL completely out, throw it away, and replace it with something that knows about both register machines and stack machines.
Alternatively, someone could create a STL (Stack Transfer Language), that passes all languages through a separate code generator that knows about stack machines. Then we can write STL back-ends for IL and JVM bytecode. Both gcj and DotGNU would benefit from this.
Вдруг p это макрос, написанный ниасилятором макросов.
fxd.
UPD: а ну да, для того и внешние скобки.
И да, согласен что ЦА msdn.microsoft.com - жывотные :)
msdn.microsoft.com/ru-ru/library/bfcke1bz.aspx
Где здесь сабж, kegdan?
Неужели они заглянули в Говнокод и исправили?
P.S. Действительно, раньше там был пример, процитированный Кегданом:
http://web.archive.org/web/20091013032219/msdn.microsoft.com/ru-ru/library/bfcke1bz.aspx
...
...
Минуточку!