- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
abstract class Department {
constructor(public name: string) {}
printName(): void {
print("Department name: " + this.name);
}
abstract printMeeting(): void; // must be implemented in derived classes
}
class AccountingDepartment extends Department {
constructor() {
super("Accounting and Auditing"); // constructors in derived classes must call super()
}
printMeeting(): void {
print("The Accounting Department meets each Monday at 10am.");
}
generateReports(): void {
print("Generating accounting reports...");
}
}
function main() {
let department: Department; // ok to create a reference to an abstract type
department = new AccountingDepartment(); // ok to create and assign a non-abstract subclass
department.printName();
department.printMeeting();
//department.generateReports(); // error: department is not of type AccountingDepartment, cannot access generateReports
print("done.");
}
Follow us!
```cmd
C:\temp>C:\dev\TypeScriptCompiler\__buil d\tsc\bin\tsc.exe --emit=jit C:\temp\1.ts
Department name: Accounting and Auditing
The Accounting Department meets each Monday at 10am.
```
Ну либо кидать исключение, если вызывающая функция недооценила размер буфера.
Но чтобы это работало нужны явные фреймпоинтеры (тот самый ebp).
> невинная
Ну какой-нибудь TempRef<T> не особо невинно выглядит. Понятно, что обычную ссылку на такое брать нельзя.
Так то да, в теории эта строка ему могла достаться от ещё более вложенных вызовов. Тогда свои локалки уже не обрезать. Ну без оверхеда на перемещение к началу своего фрейма.
Фиг знает, на самом деле...
У тебя только будет багор, если локальные переменные на стеке содержат указатели на другие локальные переменные на стеке. Двигая куда-то такую питушню, тебе надо и все указатели пересчитывать, да и к тому же где-то надо записывать, что вот там-то и там-то указатели, и если двигаем, то эти указатели надо модифицировать. А если ты не сырые указатели хранишь, а например у тебя там где-то на стеке формируется xor-linked list, где указатели в чистом виде не присутствуют?
Кстати, о ксор-линкд листах: я взял указатель на foo, кастанул в intptr_t, прибавил 42, потом отнял 41, потом отнял 1, потом кастанул в указатель.
Это же не УБ? А все ваши попытки отследить и пропатчить указаители сломаются.
или не сломаются? Или вы все аргументы у всех инструкций для работы с памятью будете двигать?
> Тогда мне надо учить js и давать уроки в нем. Но бекэнд сидит на…, постой, а если мы на бэкенде перейдем на js. А еще лучше на TypeScript перейдет и фронтэнд и бэкенд. Тогда я буду учить студентов на этом языке. Походу учебы студенты сами будут выбирать специализацию. А команды будут получать готовый полуфабрикат. Эврика!
но компилируемый тупескрипт явно будет подмножеством обычного тупескрипта, вряд ли в нем какой-нибудь там eval() будет работать. Кстати, eval() в тупескрипте будет жабаскрипт выполнять, а не тупескрипт, так что нужен еще и транспилер, лол. https://github.com/Microsoft/TypeScript-wiki/blob/master/Using-the-Compiler-API.md#a-simple-transform-function
Блядь, какое же говно. Обмажутся своими транспиляторами-полифилами, блядь
Вот за скалу и F# не скажу
Посмотри на типизацию в Haskell, OCaml, Standard ML.
>мейнстримных говен
да ладно?
На нем сейчас почти все пишут, кому нужен джаваскрипт. Современные фронтэндеры новые проекты точно на голом JS не начнут
https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-languages-loved
По нему видно, что они скорее возьмут TS, чем JS (благо интероп бесплатный)
Алсо, на TS написан VSCode, а это охулион строк кода (вместе с плагинами) и они плодятся каждый день
Хуево он написан, лучше б они на своем C# его писали
Ну да, там еще на первом месте Rust, только мейнстримом он почему-то не является. А еще есть такая хрень, как voluntary response bias
https://web.ma.utexas.edu/users/mks/statmistakes/biasedsampling.html
> Voluntary response samples: If the researcher appeals to people to voluntarily participate in a survey, the resulting sample is called a "voluntary response sample." Voluntary response samples are always biased: they only include people who choose volunteer, whereas a random sample would need to include people whether or not they choose to volunteer. Often, voluntary response samples oversample people who have strong opinions and undersample people who don't care much about the topic of the survey. Thus inferences from a voluntary response sample are not as trustworthy as conclusions based on a random sample of the entire population under consideration.
Про bias согласен, ты бы вот в таком сурвее участвовать не стал, а хипстер стал бы.
Но если взять всё множество людей, называющих себя программистами, то бОльшая часть среди них будут как раз те, которые пишут на JS или TS и на SO, разве нет?
Я думаю что далеко не все программисты зарегистрированы на SO. Вот например я там зареган, но ни одного вопроса и ни одного ответа у меня нет. Все мои вопросы обычно уже кем-то задавались, и я их легко нахожу через тот же гугл.
Как ты думаешь, какой процент от всех программистов в мире сидит на SO и на подобных им сайтах?
Что понимать под "сидит"? Гуглит какую-то хрень, находит в выдаче гугла ответ и переходит туда? Зарегистрирован? Зарегистрирован и активно задает-отвечает на вопросы?
А насколько активно?
https://meta.stackexchange.com/questions/269334/
> In September, there were 32,025 generous users who posted five times or more on the Stack Exchange network (including, SO, SF, etc.)
Теперь осталось узнать, 32025 это сколько от общего числа программистов? Мне кажется что это даже меньше 1%
Хорошо, какие у нас есть еще источники по теме популярности языков?
TIOBE, кажется, не разделяет TS и JS.
Вот тут утверждается
Did you know that 54% of frontend developers prefer TypeScript over JavaScript?
https://tsh.io/blog/why-use-typescript/
Это опять опросы какие-то? Более адекватной метрикой будет количество кода, ежедневно выкладываемое на гитхаб на TS и на JS. Или например количество людей, пишущих по работе на TS и на JS. Мало ли кто там что предпочитает. Я вот например считаю что D в режиме betterC это лучше чем C, но прошивки к контроллерам я все равно на C пишу.
Какой процент всего написанного в мире кода выкладывается на гитхаб, и как вычесть из него старый код (я говорил о новых проектах, старые могут быть и на JS)
Как вообще можно определить популярность языка?
Допустим я утверждаю, что самый популярный язык это Delphi.
Как доказать, что я не прав?
> Как доказать, что я не прав?
Ну например проверь количество доступных вакансий на Delphi, и сопоставь с вакансиями для других языков.
В случае TS и JS есть проблема: множество "JS" будет включать в себя и "TS" тоже (потому что они обычно пишутся через запятую), и нужно сравнивать кол-во TS вакансий и кол-во JS вакансий без упоминания TS.
Есть ли у нас такая статистика?
ой, да ладно!
самое главное, что определенный сорт кодеров (которые протестуют на житхабах прямо посриди суппозитория) подвержен всяким поветриям сильнее любого руснявого хомячка из одноватников
помню какой-то из покойных кодопоисков показывал статы под язык
но рантайма хаскеля там нет.
А в TS'е этот теггед юнион просто в ядро JS'а зашит.
Всё-таки фишка была в том, чтобы конпелятор прямо во время запихивания проверял, что ты туда неподходящее говно не суёшь.
правда тут багор может случиться
еще ts лучше c# тем что имеет unknown
но он там дорогой, а в JS без разницы
в unknown можно положить, что угодно, а достать из него можно только явно проверив тип
по сути ты откладываешь проверку типов на время исполнение (и на программиста)
динамик примерно тоже самое
ну ок, дайнамик это как анноун плюс эни)
анноун же нужно в эни кастануть чтобы что-то вызвать?
в C# еще есть object (примерно как void*), он тоже похож на анноун (его нужно кастануть чтобы дернуть метод) но он вероятно боксит вауле тайпы
вот вам без unkown
Ня мой няискушённый взгляд, её можня упростить вот так:
И нячего ня изменится.
я объясню
мой пример
твой пример:
Сделай, пожалуйста, типизацию правильня — так, чтобы оня работала согласня демонстраци MAKAKИ.
>Сделай, пожалуйста, типизацию правильня
извини, взгляды на типизацию от фанатов джавы и крестов 2000-х мне не очень интересны
можешь сделать сама, это будет сделать проще чем то что я сделал
если типизация не будет давать мне выражать то что я хочу выразить - то нахуй такую типизацию
для фанатов джавы и с++ 2000 типизация - это способ скомпелять программу, поэтому вы никакими категориями кроме ограничения мыслить не можете - шаг в сторону и конпелятор по жопе ремнем даст
Проверки чего имення? В чём заключается эта проверка?
преттиер у меня проверяет что отступ 4 пробела и точки с запятой везде
линтер проверяет чтобы конста в свиче не было
кастомный линтер проверяет чтобы в аргументов хука не было зависимостей которые я объявил как статические
тайпскрип проверяет что типы которые выводятся из функций можно привести один к одному
А зачем тебе это нужня? Зачем, няпример, может понядобится преттиер, понятня: чтобы код красивый был. А зачем тебе проверять, что типы, которые выводятся из функций, можня привести один к одному?
Всё, это единственный её смысл. И имення запретом няписания някоторых синтаксически корректных конструкций статическая типизация, действительня, обеспечивает пусть и (очень) далеко ня гарантию, но хотя бы повышение шансов корректной работы программы.
лично мне типизация нужна чтобы доказать корректность работы программы
>И имення запретом няписания някоторых синтаксически корректных конструкций статическая типизация
да-да очень интересно продолжайте
Да откуда вы лезете...
Один залечивает, что может доказать корректность программы в рамках простенькой системы типов мейнстримного языка. Другой залечивает, что совпавшие имена функций и типы аргументов, внезапно, дают ему какие-то гарантии и контракты...
З.Ы. Если в рамках системы типов даже не получается описать что делает функция, о какой корректности может быть речь? 90% контракта в комментах и документации остаётся.
Но переопределять значения слов и правда не стоит. Без общего словаря людям будет трудно общаться
А в каком смысле их нядо воспринимать? Философском? Поэтическом?
А надо в маркетологическом, когда у каждого слова стоит звёздочка и требуется пояснение?
внезапно совпавшие имена типов дают какие-то контракты
то, что ты лично ты понимаешь под контрактами что-то другое, это как бы твои собственные трудности дела
Какую-то часть контракта (совсем небольшую) они формализуют, я согласна.
Какая-то часть кривых/хуёвых/тормозных программ при проверке этого контракта, безусловно, отсеивается. Но далеко не все.
Но блин, я же не буду утверждать, что юнит-тест доказывает корректность моей функции.
> юнит-тест доказывает корректность
- ну в общем именно это он и делает: доказывает корректность на некотором наборе аргументов. на произвольном наборе он понятное дело бесполезен
Ну вот есть у тебя функция:Часть контракта записана формально: функция принимает кнопку.
Часть контракта записана няформально: функция рисует эту кнопку.
Я одна что ли считаю, что "функция рисует эту кнопку" -- тоже важная часть контракта?
нет гарантий – нет контракта
но это мы уже на третий круг пошли вроде
На, изучай:
https://ru.wikipedia.org/w/?curid=484455
...путём запрета части синтаксически корректных конструкций. Всё* правильня.
*Ну, кроме того, что в мейнстримных язычках "корректность работы" можня доказать исключительня ручкой и бумажкой.
Чтобы синтаксически ограничить множество программ, отбросив те из них, семантика которых нам совсем уж не нравится.
> гарантию корректной работы
Ну-ну.
А типизация разве не к синтаксическому уровню относится? Она ведь ничерта не понимает в семантике программы, просто проверяет какие-то правила.
Или я туплю?
Представь синтаксическое дерево для такого кода
А вот для такого уже хуй
Да, но по сути ведь мы на ноды в AST наклеиваем некие этикетки, на которых написан тип. И проверяем, что какие-то правила для этих типов выполнены. О том, какую семантику потом будет иметь это AST, конпелятор во время тайпчека даже не задумывается.
Dialyzer выводит типы:
Т.е. он знает, что плюсик работает только для намов, и что иф идёт после него, поэтому в первом случае он на основе сёмантики заключает, что функция всегда упадёт. А во втором случае он проходит по обеим веткам, т.е. он знает сёмантику ифа.
Так что не знаю, не знаю.
Какие правила тебе проверяет модификатор volatile в C и C++?
Что значит против?
Я двумя лапками за типизацию, но я осознаю её ограничения.
https://youtu.be/TGRDYpCmMcM?t=1635
Она тебе дала определение типизации по Пирсу. А он вовсе не какой-то джава мэн.
https://www.youtube.com/watch?v=IJgkocKRmtg
У нас же тут приличный форум.
> Система типов — это гибко управляемый синтаксический метод доказательства отсутствия в программе определенных видов поведения при помощи классификации выражений
языка по типам вычисляемых ими значений.
что-то не вижу тут ничего про ограничения
> отсутствия в программе определенных видов поведения
this
ничего про ограничения я опять же не вижу
И, конечно, таким образом мы никоим образом ня ограничиваем множество синтаксически корректных программ, запрещая программисту писать часть из них, нят-нят! Ведь ограничения — это для бумеров из прошлого века.
У нас есть множество синтаксически корректных программ. система типов - это метод доказательства корректности, мол, вот есть подмножество правильно типизированных программ и в нем нежелательных поведений нет, а есть множество нетипизированных программ и в них нежелательные поведения есть
Собственно говоря, ничего не мешает написать неправильно типизированную программу, просто мы с точки зрения системы типов считаем ее содержащей нежелательные поведения
и только те кого в детстве пиздил компилятор и у кого опции запустить неправильно типизированную программу нет - те считают что типизация что-то там запрещает
Т.е. в тайпскрипте это просто предупреждения, а не ошибки, обрывающие конпеляцию?
Да, но какой смысл что-то там проверять, а потом не использовать результаты этой проверки?
Ты реально после каждого коммита перечитываешь результаты проверки типов глазками и сам принимаешь решение, стоит ли запускать получившуюся хуйню?
вопрос как использовать результаты и нахуя из другой плоскости
- скажи что-то по-схемерски
Ошибки системы типов прерывают компиляцию, но их можно заткнуть аннотацией.
Забавно, что изначально статическая типизация была нужна компилятору, чтобы отличать как миниум целые от чисел с плавающей точкой
А теперь она нужна программисту в первую очередь)
Ну он мог бы въебать там discriminated union и наказать программиста хуёвым пирфомансом. В общем-то JS/TS так и сделают.
тормозило поди
А доказательство проблемы остановки подозрительно няпоминает доказательство теоремы о неполняте, что вкупе с соотношеняем Карри-Ховарда намекает ня неку-ю фундаментальную связь. В связи с этим сами някайте про правильное определение "доказательства" и "корректности".
тут наверное должны заплакать авторы IDE для скриптовых языков)
(имеются ввиду IDE со всякими инспекциями а-ля Intellij)
Авторы IDE для крестов смотрят ня этих неженок с нядоумением! (≧◡≦)
Няпоминаю, что определение синтаксической корректности программы ня крестах эквивалентно проблеме останова.
Что мне тогда тут на говнокоде делать?
Останутся в итоге одни Ротоёбы: у них-то с полом никаких пробелм нет
https://ru.wikipedia.org/wiki/Вторичноротые
Такие дела.
Какой бластопор )))
Не парься, сестрёнка. Нас тут скоро будет большинство, а потом ГК закроют за пропаганду.
2. Есть его подмножество: синтаксически корректные программы, у которых сошлись типы
3. У него есть подмножество корректных программ, то есть тех , которые выдают верный (в соответствтии с ТЗ) результат для всего множества входных параметров
Под словом "корректная программа" обычно понимают "3"
Парсер, строящий AST, гарантирует нам 1.
Статический анализ типов гарантирует 2.
А вот 3 можно доказать или всякими коками, или перебором всех входных параметров (примерно этим занимаются юнит тесты, с какой-то вероятно надеждой на индукцию:)), но так как тесты проверяют не все входные параметры, то на самом деле корректность и они не доказывают
Ты применил термин "корректность" к 2 вместо 3, и тем вызвал волну бугурта
Даже не совсем так. В 1. есть подмножество 4, не-Тьюринг полных программ, использующих только структурную (ко)?рекурсию. В нём можно доказать соответствие контрактам.
Так-то наверное можно и статически корректность регулярных выражений доказать.
Ну ты упомянул кок, а он не Тьюринг-полный. А в целом, Тьюринг-полнота не особо-то и нужна в большинстве случаев, так что зачем ей ограничиваться.
Система типов запрещает тебе писать синтаксически корректные программы, нярушающие т`иповые контракты. Ня этом её функции заканчиваются.
Когда ты запускаешь программу, някорректную с точки зрения типизации, ты всего лишь отказываешься от типизации, ня более того. В этом смысле единственная разница между тайпскриптом и джавой образца 1998-го года — это то, что от типизации тайпскрипта ты можешь отказаться, а от типизации джавы — нят.
я объяснил как мог почему ты так считаешь и почему не можешь считать по-другому
если не получилось объяснить - штош
Вот тебе простая задачка ня ночь: няпиши программу, корректную с точки зрения системы типизации, но няправильно типизированную. Это, очевидня, сделать можно, поскольку зумерские системы типов ничего ня запрещают и ня ограничивают.
Чтобы всё таки запустить някорректную с т.з.СТ программу (хотя казалось бы: зачем запускать някорректную программу?), тебе нужно отказаться от типизации, только и всего. Твоя свобода от запретов — иллюзия, мистер Андерсон.
неужели так сложно понять?
Простой пример:
С точки зрения системы типов этот код някорректен. Система типов мне запрещает такое писать. Одняко я могу сказать компилятору, что на мнение системы типов мне понякать, и тогда компилятор успешно скомпилирует эту программу. Имення компилятор мне разрешил творить ерунду: компилятор, а не система типов!
ну ты же написала
Так я и в джаве такое могу няписать, смотри:
И пример ня TypeScript, и пример ня Java някорректны с точки зрения системы типов.
Одняко компилятор TypeScript может проигнорировать ошибки типизации, а компилятор Java — ня может. Вот и вся разница: не в системе типов, а в компиляторах.
я и говорю что запрещают и ограничивают конпеляторы а не системы типов
Компилятор проводит статический анализ программы и если у нее не сходятся типы, то компиляция падает
Если что-то не позволяет сделать система типов (например приравнять целое к указателю) то и компилятор этого не позволяет.
система типов ничего не позволяет и не запрещает. Это способ разметить множество програм на 2 подмножества и все
> Это способ разметить множество програм на 2 подмножества и все
Отлично
Назовем первое подмножество "корректно типизированные программы"
Компилятор проверяет, что твоя программа относится к первому подмножеству
Нахрюки на "джаву 2000х" связаны не с тем, что компилятор форсил статическую проверку, а с тем, что система типов была насколько убога, что невозможно было написать "корректно типизированную программу" не наплодив говна, бойлерплейта и копипасты
Так что виноват не компилятор, а система типов
Все давным-давно поняли точку зрения друг друга. Но спорить то о чём-то надо )))
У вас множество программ с "нежелательным поведением" не так сильно бьёт по яйцам, вот и вся разница (мы тоже можем запустить часть программ забив на их "нежелательное поведение").
Но зачем расставлять типы, выполнять проверку и... не пользоваться её результатами я, наверное, никогда не пойму. Мартышкин труд какой-то. Почему бы не взять вместо этого обычный JS?
Привет, undefined!
С тебя NaN рублей
> С тебя NaN рублей
Ну, по крайней мере из-за этого на другом конце программы у случайного юзера поле с полом не превратилось в ящик шрёдингера.
ну вот я сконпелял прогу, высрались ошибки, я получил результат что моя прога говно и пошел ее деплоить
только с конпелируемых языках фейл конпелятора значит что проги в итоге не будет
В джаве ты можешь скастить всё к Object, в C++ ты можешь вообще reinterpreter_castнуть что угодно во что угодно
Такая программа упадет в рантайме*, как и в JS
> моя прога говно и пошел ее деплоить
Всегда так делаю
*упадет она в джаве и C#
В С++ будет UB
ты не можешь обмануть систему типов. Если система типов говорит что код валиден а он не валиден то это значит что система типов такая
обмануть можно конпелятор
и ограничить и запретить может конпелятор
система типов только говорит, относится ли програ к подмножеству правильно типизированных или нет
А что такое "система типов"? Ну вот допустим есть в Си тип uint8_t и тип uint64_t. Предположим, кто-то спрашивает: "Зачем мне uint8_t если есть более жирный тип uint64_t? Очевидно ведь, что можно всегда использовать самый жирный тип, а если нужно чтобы после перехода за 255 становилось 0, просто используй битовую маску или находи остаток от деления на 256, и все будет круто.".
Какой будет ответ, и будет ли он иметь отношение к тому, что система типов запрещает писать какие-то программы, нарушающие какие-то там контракты?
[wiki]
совокупность правил в языках программирования, назначающих свойства, именуемые типами, различным конструкциям, составляющим программу — таким как переменные, выражения, функции или модули
[/wiki]
>Какой будет ответ
КМК, система типов не отвечает на вопрос "какой тип нужно использовать", а только лишь гарантирует, что для выражения
A = B
все возможные значения типа "B" отображаются на значения из множества типа "A"
Типы это совокупность каких-то там правил. Гениально
Шерлок Холмс и доктор Ватсон летели на воздушном шаре. Но был такой сильный туман, что они заблудились. Но вот порыв ветра, облака рассеиваются, Шерлок Холмс и доктор Ватсон приземляются и видят человека, пасущего овец.
— Скажите, любезнейший, а где мы находимся? — спрашивает доктор Ватсон.
Подумав, пастух отвечает:
— В гондоле воздушного шара.
Новый порыв ветра подхватывает шар, и Шерлок Холмс с доктором Ватсоном летят дальше.
— Ох, уж эти математики! — восклицает Холмс.
— Постойте, Холмс, но как вы догадались?
— Это элементарно, Ватсон! Он ответил, подумав. И дал совершенно верный, но совершенно бесполезный ответ.
Нет, всё значительно сложнее. В GCC есть __attribute__ ((may_alias)) для типа, который говорит, что вот эта переменная может быть по адресу, где есть какая-то другая переменная другого типа, допстимые множества она никак не ограничивает. Есть _Atomic в Си, который для того, чтобы переменная менялась и читалась атомарно, допстимые множества она никак не ограничивает. Типы это очень сложный концепт, и не всегда типы нужны чтобы компилятор на что-то там ругался если что-то не так как надо.
А volatile?
А register?
А storage class?
Конечно же относится. А что, нет?
> А volatile?
> А register?
> А storage class?
Да, да, да.
Я не математик, но мне кажется, что тип это множество значений
Какие значения добавляет/удаляет ключевое слово "volatile"?
Математики наверное тут бы не согласились. Тут я плаваю, так что можете оспаривать. Множества определяются через предикаты, а типы – по конструкции.
В теории множеств имеет смысл следующее утверждение: "множество X – это множество элементов, для которых верен предикат is_X".
В теории типов подобное утверждение смысла не имеет, т.к. для типа X предикат is_X верен по конструкции.
При subtyping, где предикаты вида is_X всё-таки имеют место, тем не менее нельзя определить новый тип через произвольный предикат.
Как-то так. Теория типов и теория множеств оперируют обе оперируют некими коллекциями, но на этом сходство оканчивается.
>нельзя определить новый тип через произвольный предикат.
хм, вообще какие-то попытки имеются: я могу указать множество значений типа и из него сделать новый тип, но совсем случайный предикат указать нельзя
Так какое же правильное определение типа?
А вам правильное с точки зрения какого академика?
КМК, этот вопрос равнясилен вопросу "в каком языке ООП правильное".
storage class -- нет.
Давайте уже определение типа тогда, потому что если тип это множество значений (ну окей, плюс еще множество допустимых действий над ними) то volatile всё равно выпадает
_Atomic int, volatile int и int имеют разную операционную семантику. Просто они выглядят очень похоже.
Система типов в данном случае не даёт их бездумно смешивать между собой.
а как это связано с типами?
>Система типов в данном случае не даёт их бездумно смешивать между собой.
Вообще не дают смешивать только указатели, то есть тип всё еще определяется множеством значений и множеством допустимых операций над объектом?
"register" это storage class. У "register" в Си есть такое интересное свойство, что на него нельзя взять указатель.
Все еще думаешь что не имеет?
Не имеют потому что что?
"int" и "_Atomic int" — это просто два разных типа с разными множествами допустимых знячений, ня более того.
"int" и "_Atomic int" имеют разные множества допустимых значений? И в чем же они разные?
И если это два разных типа, каким образом это не имеет отношение к теории типов?
Да. В первом можня хранить только int(0), int(1), int(2) и так далее, а во втором — только "_Atomic int"(0), "_Atomic int"(1), "_Atomic int"(2) и так далее.
> И в чем же они разные?
Я бы сказала "в конструкторе", но, боюсь, тогда дальше по цепочке придётся копипастить какую-нябудь лекцию по теории типов. Так что скажу просто: символами перед открывающей скобочкой.
> И если это два разных типа, каким образом это не имеет отношение к теории типов?
Очень просто: достаточня убрать пробел после "_Atomic" и объявить, что все типы, имена которых нячинаются со слова "_Atomic" (няпример, "_Atomicint"), будут иметь семантику атомарных.
а конструктор существует зато)
В вики есть весьма ротозейское определение типа
In computer science and computer programming, a data type or simply type is an attribute of data which tells the compiler or interpreter how the programmer intends to use the data
В таком случае мы можем считать, что множество значений у int и {const,volatile,_Atomic} int одно и тоже (это подмножество N зависящее от sizeof(int)), но вот множество действий (how the programmer intends to use the data) у него разное.
В твоем же варианте эти множества значений разные (хотя и отображаются на то самое подмножество N и друг на друга биективно)
Получается два способа определения типа
* просто множество значений (и тогда int(1) != const int(1))
* множество значений и множество операций (и тогда int(1) == const int(1))
Какое же из них ближе к академическому?
У каждого типа свои конструкторы.
И чем отличается "int"(0) от "_Atomic int"(0) ? Символами перед открывающей скобочкой? А еще чем-нибудь отличаются?
> Я бы сказала "в конструкторе", но, боюсь, тогда дальше по цепочке придётся копипастить какую-нябудь лекцию по теории типов.
В Си есть _Atomic, но никаких конструкторов нет. Или речь про какие-то другие конструкторы?
> Так что скажу просто: символами перед открывающей скобочкой.
Не только.
>Очень просто: достаточня убрать пробел после "_Atomic" и объявить, что все типы, имена которых нячинаются со слова "_Atomic" (няпример, "_Atomicint"), будут иметь семантику атомарных.
Как из этого следует, что это не имеет отношения к теории типов?
С точки зрения системы типов — больше ничем.
То, что в глубинах язычка для типов, нязвания которых нячинаются с "_Atomic ", определены какие-то встроенные функции, ведущие себя особым образом, к теории типов имеет довольно опосредственное отношение.
> Или речь о какие-то другие конструкторы?
Да, о других.
> Как из этого следует, что это не имеет отношения к теории типов?
Так, что это всего лишь детали реализации конкретного языка. Для типов, нязвания которых нячинаются с "_Atomic ", сишка определяет один нябор функций; для типов с "volatile " или "register " — другой (для последних ня определяет функцию "взять адрес", например).
А то, что для _Atomic гарантируется атомарное чтение и запись? Вот допустим пишу я lock-free структуру данных, надо чтобы у меня там не было состояния гонки, и я через _Atomic делаю некоторые штуки, атомарное сравнение с обменом, ну типа если в эту локфри структуру никто прямо сейчас не пишет, и какая-то функция туда что-то записать хочет, то помечаем в эту _Atomic переменную, что структура занята, потом что-то в этой структуре меняется, и потом она опять помечается как свободная. Потом я этот код формально доказываю на отсутствие race condition на какой-нибудь хрени типа Coq. И теперь _Atomic это про систему типов? Или как вообще? Т.е. _Atomic будет иметь отношение к системе типов только если в компилятор встроят особую питушню для проверки локфри, которая будет учитывать семантику _Atomic?
Т.е. на уровне проверки типов мы убедились, что атомики с обычными числами не смешивают.
А на уровне операционной семантики мы уже можем рассматривать гонки и всё такое. И там, грубо говоря, у lvalue int и lvalue _Atomic int разная семантика load'ов.
Но можно сказать, что у них разное множество операций.
Не существует операции деления для строк, не сущетвует какой-нить "CAS" для не атомарной хрени
Ага. И не существует операции для отрицания int 0x80000000. Поэтому программа с таким отрицанием не well-formed и конпелятор имеет право аппроксимировать её какой-то другой.
Заметь, что проверку типов это говно проскочило.
Т.е. если в Си добавить специальный уровень проверки lock-free структур данных, учитывающих _Atomic, то тогда _Atomic уже будет иметь отношение к теории типов? Т.е. "что-то имеет отношение к теории типов, если компилятор или интерпретатот языка как-то это по-особому проверяет", так что ли?
Вообще, я бы сказала, что статическая типизация – это всё, что позволяет нам сказать, что программа, проходящая тайпчек, не содержит каких-то поведений by construction.
Отстутсвие сложений строк с числами – один из типов таких поведений, но не единственный.
Умножаю. В няиболее обобщённом виде это, разумеется, верня. Но, к сожаленяю, j123123 такое определение ня устроит.
> Есть uniqueness/affine/linear types
Таки они где есть? Теорий типов очень много, я (неняучня) описываю самую базовую, которая имеется в абсолютном большинстве типизированных языков (и, няверное, во всех мейнстримных).
Uniqueness были в Mercury (заместо моняд), linear types популяризировали в Rust.
Во всяких хаскелях, коках, идрисах и прочем таком академическом. Линейные типы в Clean есть https://ru-lambda.livejournal.com/131849.html
>Умножаю. В няиболее обобщённом виде это, разумеется, верня. Но, к сожаленяю, j123123 такое определение ня устроит.
Конечно не устроит. Если мне надо хранить много значений от 0 до 255 в массиве, и я могу использовать или массив из uint8_t или массив из uint16_t или массив из uint32_t или массив из uint64_t то это не имеет отношения к тому, чтобы пройти или не пройти тайпчек. И не имеет отношение к тому, что что-то там не содержит каких-то поведений by construction. Но зато это будет иметь отношение к тому, сколько в контроллере просрется памяти на стеке или на хипе или в статической области.
Типы не только чтобы там что-то проверять и гарантировать, а ими еще можно память экономить.
А есть ссылка на авторитетный источник, что вот теория типов размеры не рассматривает?
* Теория типов размеры ня рассматривает;
* Теория типов цвета ня рассматривает;
* Теория типов длины ня рассматривает;
* Теория типов зелёных слоников ня рассматривает;
* Теория типов летающих ня орбите чайников ня рассматривает;
...
Так что чтобы утверждать, что теория типов что-то рассматривает — нужня няйти об этом упоминание в ней.
> И можно ли считать википедию авторитетным источником?
Можно, если считать её авторитетным списком ссылок ня источники.
Ну хорошо, в каком авторитетном источнике указан полный и конечный список того, что теория типов рассматривает? Ну, чтобы можно было сказать "вот теория типов только это это это и это рассматривает, а всё остальное - не рассматривает"?
https://plato.stanford.edu/entries/type-theory/ — вот, няпример, авторитетный источник с краткой выжимкой по теме.
Блин, ну вот, скинула ссылку — а оня легла.
Почему в любой? Что мне мешает придумать свою теорию типов, где рассматривались бы размеры?
Но да, ты спокойня можешь придумать свою теорию типов с любыми нужными тебе свойствами. В конце концов, пример линейных типов, описывающих эффекты, выходящие за рамки того, что можня получить простым описанием нябора допустимых знячений, выше уже приводили.
Просто введение размера в битах в теорию типов выглядит нясколько бессмысленно: если теория типов работает с няборами допустимых знячений (моя работает, няпример), то у каждого типа появляется размер нябора допустимых знячений, размер в битах из которого тривиальня выводится при помощи теории информации.
Правда, если подняться чуть повыше и рассмотреть тип "int" в языке "Python", то окажется, что множество его допустимых знячений бесконечно, и фиксированного размера в битах у няго просто нет.
Я спрашивал про такой источник, где было бы написано, что теории типов в принципе возможны только о таких сущностях. Этот источник (он у меня уже открывается) не содержит строгого утверждения в духе "теории типов можно строить только про это, про это и это, а теории типов о чем-то другом невозможны вообще никак никогда".
> Просто введение размера в битах в теорию типов выглядит нясколько бессмысленно: если теория типов работает с няборами допустимых знячений (моя работает, няпример), то у каждого типа появляется размер нябора допустимых знячений, размер в битах из которого тривиальня выводится при помощи теории информации.
А если это какой-нибудь double, где дофига всяких NaN?
https://en.wikipedia.org/wiki/NaN
For example, a bit-wise IEEE 754 single precision (32-bit) NaN would be
where s is the sign (most often ignored in applications) and the x sequence represents a non-zero number (the value zero encodes infinities). The first bit from x is used to determine the type of NaN: "quiet NaN" or "signaling NaN". The remaining bits encode a payload (most often ignored in applications).
> А если это какой-нибудь double, где дофига всяких NaN?
Детали реализации конкретных языков программирования. Хороший, кстати, пример: моей примитивной теории типов в принципе плевать, какие там у тебя даблы под капотом, она рассматривает только няборы знячений. А уж в каком виде эти знячения представлены "в железе" — вопрос вторичный. Можешь использовать IEEE 754, можешь дроби, можешь десятичные числа с плавающей точкой прикрутить. Для моей теории типов это совершенно ня важня.
Умение абстрагироваться от деталей и выделять общие закономерности очень полезно, рекомендую.
Ну так размеры каких-то типов это вполне себе о типах. И кстати если сделать в том же Си структуру с uint64_t и uint8_t внутри, и потом сделать массив таких структур, внезапно окажется, что размер массива из-за выравнивания будет не n*(sizeof(uint64_t)+sizeof(uint8_t)). Теория информации тут почему-то не работает.
> А уж в каком виде эти знячения представлены "в железе" — вопрос вторичный. Можешь использовать IEEE 754, можешь дроби, можешь десятичные числа с плавающей точкой прикрутить. Для моей теории типов это совершенно ня важня.
Если рассматривать 32-битный single precision IEEE 754 и если я хочу доказать, что такая-то функция никогда не вернет NaN или какую-нибудь бесконечность, то мне надо будет копаться в деталях реализации, что так-то работает округления, так-то работают такие-то функции, и при таком-то множестве входных данных функция всегда возвращает что-то из такого-то множества выходных данных. Так что это не всегда вторично.
Правильня, и это — абсолютня не интересные детали реализации конкретного язычка.
Я уже приводила пример: у типа "int" в "Python" нят и ня может быть фиксированного размера в битах, и это никоим образом ня влияет ня мою теорию типов.
> и если я хочу доказать, что такая-то функция никогда не вернет NaN
...то при помощи теории типов ты можешь это доказать очень просто: создав новый тип "FloatWithoutNan", в котором ня может быть NaN, и сделав его возвращаемым типом функции (после чего до завтипов останется рукой подать!).
Для теории типов эти детали абсолютня ня важны.
Они не интересны ровно до тех пор, пока у тебя оперативной памяти дохрена, которую можно на всякую срань без проблем проебывать.
И вообще, с т.з. кого или чего они не интересны? С т.з. некоторой абстрактной теории типов - возможно. С точки зрения программиста, который что-то пишет под контроллеры - это очень даже важные детали. Типы используют не только чтоб что-то там протайпчекалось, но и чтоб память экономить, и я про это писал в https://govnokod.ru/27520#comment647636
Про которую мы и ведём речь во всём этом треде.
> С точки зрения программиста, который что-то пишет под контроллеры - это очень даже важные детали
С точки зрения водителя грузовика в теорему Пифагора было бы неплохо ввести поправки ня ветер. И что?
В теории типов Аксёновой тип — это нябор знячений, отличных от всех остальных нязависмых няборов, а проверка типов — доказательство того, что в переменную (включая параметр функции) никогда ня будет записано знячение из несоответствующего нябора (типа). Всё, таким типам даже именя не нужны.
Конкретная реализация ТТА может привязать к конкретным типам какие угодня свойства — имя, размер, константность, атомарность, волатильнясть, may_alias, цвет, запах, высота — что угодня — и анализировать эти свойства так, как конкретной реализации удобня.
Только к изнячальной теории типов это никак ня относится: оня как оперировала няборами знячений, так и оперирует, нязависимо от того, какие свойства ты ня них няклеил.
Точно так же, как в теорему Пифагора можня ввести поправки ня ветер для рассчёта расхода топлива — исходная теорема от этого никак ня изменится.
Ну давайте придумаем такую теорию типов
Есть ли такое в каком-нибудь языке? Так ли это бессмысленно?
Ня мой взгляд, размер в битах вводить в какую-либо теорию типов (именно в теорию, а не в описание типа) всё же излишне, поскольку это слишком низкоуровневые подробности, которые конкретная реализация языка программирования может легко проверить и без всяких там теорий. То есть "bits 3" в твоём примере может служить ня столько свойством типа, сколько "ассертом", который "раскрывается" во что-то такое:.
govnokod - эффект
(where \(\Pow(X)\) is the class of subclasses of a class \(X)\) can be surjective; that is, \(F\) cannot be such that every member \(b\) of \(\Pow(X)\) is equal to \(F(a)\) for some element \(a\) of \(X\).
– какая ма-те-ма-ти-чес-ка-я дристня )))
как там в 2011? прежнева переизбрали?
Jul 22, 2020 - In the past few years, numerous conservative news outlets have been outright banned as sources for facts on Wikipedia, including Breitbart News. The finding against Fox News came after numerous prior attempts to downgrade the company’s status.
а если ты выберешь другую архитектуру, то у тебя будет другой байтордер
или вместо DDR3 будет DDR2
или даже вовсе не SDRAM а BEDO какое-нить
или даже не DRAM а SRAM на защелках
или не будет кеша в процессоре
или не будет страничек, а будут только сегменты
или вовсе не будет ни того, ни другого
или будет байт не восьмибитный
Все это имеет такое же отношение к теории типов, как и количество свободного места у тебя в стеке, разве нет?
Тогда мне нужно будет особым образом дрочиться с этим не-8-битным байтом если мне надо экономно хранить много чисел в интервале от 0 до 255.
> Все это имеет такое же отношение к теории типов, как и количество свободного места у тебя в стеке, разве нет?
Приведи реальный пример чего-то, что имеет отношение к теории типов.
В miniagda были т.н. sized types, где размер терма был частью типа. Там это использовалось для termination checking, но при желании sized types, думаю, можно прикрутить для статической проверки свободного места на стеке.
Для статической проверки места на стеке надо рассматривать то, как именно там программа заоптимизируется конкретным компилятором. Если компилятор соптимизирует рекурсию в цикл, требования к стеку будут сильно меньше.
А вот про всякие глобальные или статические локальные переменные судить уже проще. Хотя и их компилятор/линкер может почистить на определенном этапе, например убрав глобальный массив, к которому никто никогда не обращается.
Предположим, компилятор реально смог в компилтайме доказать через какую-то питушню, что какие бы байтики из /dev/random не прочитались, "find_max(data, 1000)" и "sort(data, 1000, [](char a, char b){return a < b; })[999]" будет иметь одинаковое значение. А если б я допустим накосячил и написал "sort(data, 1000, [](char a, char b){return a < b; })[0]" то компилятор бы сказал что-то типа "я не могу гарантировать что max_elm == max_elm2 всегда выполняется" - это вот о типах или не о типах?
Теория типов — это же просто альтернативный язык ма-те-матики.
Поэтому, если ты сделаешь ма-те-матическую модель сишки, то это будет "о типах".
Посмотри в сторону separation logic, Есть проект iris[1] там ухитрились придумать такие типы, которые описывают арифметику указателей с кучей и бог знает чем.
У них вроде даже какое-то подобие семантики няшной уже есть на куритсе.
[1] https://gitlab.mpi-sws.org/iris/
В вышеприведенном примере никаких описываемых программистом в явном виде "типов" (кроме этого вот char) нет. Есть функция find_max() и компилятор видит ее код. Есть функция sort() и компилятор тоже видит ее код. Компилятор допустим умеет рассуждать над всякой такой хренью, и он может формально доказать, что вызов вот той функции для data даст такой же результат, как и вызов другой функции для data, независимо от того, что там в data записано. Получается что "тип" это семаника (ма-те-ма-тическая модель) кода? Хуйня какая-то.
Встретил типы - убей типы
Кстати да, если CHAR_BIT > 8, у меня типа uint8_t вообще не будет.
То есть мы можем ввести ключевое слово "Хуятомик", при использовании которого будет мигать numlock на клавиатуре
С точки зрения системы типов это будет другой тип, а что там мигает не важно?
С атомиком правда интереснее: есть алгоритм, который без него тупо некорректен
Задача системы типов — доказать, что при любых входных данных твоя программа никогда ня вызовет функцию с аргументом, знячение которого не входит во "множество" (набор) допустимых знячений типа соответствующего параметра функции. Всё, остальные твои локфри, волятили и коки — это какие-то расширения системы типов, нядстройки няд ней, которых можня делать сколько угодня.
> Так, что это всего лишь детали реализации конкретного языка.
И что? Любая система типов это детали реализации конкретного языка
Ма-те-матического
Если система типов — это деталь реализации, то где же, кхм, реализация?
Ну она будет Тьюринг-полной, если у мозг человека может хранить неограниченное количество информации, и если та теория типов достаточно мощная чтобы ей описывалась какая-нибудь машина Тьюринга. Поскольку мозг человека все же конечен, состоит из конечного числа нейронов и синапсов, вряд ли он является полным по Тьюрингу.
> Что ей посчитать можня?
Это надо открыть ту книгу "ramified theory of types" 1908-го года и разобраться, что там за типы, и что ими можно считать.
А зачем?
> А после уже можня будет делать утверждения о том, является ли оня деталью реализации какого-то языка, или нят.
А что такое "язык"?
Чтобы делать обоснованные утверждения?
> А что такое "язык"?
Тебя нужня спросить. В своём комментарии я говорила про языки программирования, про какой язык няписал ты — ня зняю, могу лишь подозревать.
Ну а почему б тебе не разобраться и не рассказать?
>Тебя нужня спросить. В своём комментарии я говорила про языки программирования, про какой язык няписал ты — ня зняю, могу лишь подозревать.
Если речь про языки программирования, то тогда да, не для всякой вообразимой системы типов есть какой-то готовый язык программирования, реализующий такую систему типов.
Ты хорошо постарался сломать мне парсер, но я всё-таки понял твой тейк. В целом, да, даже на плюсовый тайпчекер найдётся reinterpret_cast.
Ну типа такого. У ме-ня Пирс бумажный, точное определение лень перепечатывать.
Я просто сделал так, чтоб все скалярные типы были одинаковые.
То есть это или T либо массив от T либо массив от массивов от T и так далее рекурсивно
Буткемп же видел задачу в том, чтобы принимать любые типы, но выводить их типы в качестве юниона в результат
То есть ты можешь флэтнуть массив строк и массив буленов, а в итоге получить юнион от буленов и строк
В каких-то случаях такие решения могут иметь смысл: например флэтнуть массив кошек и собак, и потом померить у всех размер хвоста
мой пример с динамиком это фуфло, а пример на тс с анноун это типа заебок? а в чём разница?
d: FJCVTZS
Сначала в JS сделали флоат вместо интеджера (number), а затем пришлось пилить железо для него
Мы Вам перезвоним.
так-то что-то похожее можно и в шарпе намутить на одних интерфейсах
Если буфер в куче, и вызываемая функция сделает ему realloc, то его адрес изменится. Это плохо. Поэтому пойдём дальше: будем (n+1)-м аргументом передавать не адрес буфера, а адрес переменной, указывающей на буфер (указатель на указатель). После возврата из вызываемой функции вызывающий код должен учесть новое значение адреса.
https://ideone.com/2B6rzG
После возврата можно скопировать из кучи в свой стек и сделать free.
Раньше было соглашение вызовов «cdecl» — стек чистил вызывающий. В архитектуре «amd64» от него отказались.
[Источник не указан 0 дней]
Скорее от stdcall отказались.
https://en.wikipedia.org/wiki/X86_calling_conventions
== 32 бита ==
Caller clean-up: cdecl, syscall.
Callee clean-up: pascal, stdcall, куча нестандартных fastcall, register, vectorcall.
== 64 бита ==
Caller clean-up: Microsoft x64 ABI, Microsoft vectorcall, System V AMD64 ABI.
Да, я ошибся. Всё наоборот. Стек чистит вызывающий, как у cdecl, только добавили размещение аргументов в регистрах.
Ну это потомки fastcall'а, на самом деле. Хм, там callee всё-таки был.
* На самом деле, с убиранием никто сейчас не парится и место под аргументы вызываемых функций просто зарезервировано в фиксированном фрейме.
А почему не парятся? потому что стек на x64 такой большой, что всем похуй на место от тех двух с половиной функций, что не влезли в пять (или с колько там?) параметров через регистры, и тронули стек?
Дрочить указатель на каждый вызов и тем более на каждый аргумент смысла никакого.
Как-то так, если забить на редзоны и теневой блок:
| ... args for callees ... | ... locals .... | ret |
ага, ну то есть мы откладываем "очистку" на потом.
Что-то я не вижу тут твоего поведения
что я делаю не так?
Для студии это особенно актуально т.к. по виндовому соглашению shadow зона нужна. И резервировать её перед каждым вызовом не особо удобно.
может gcc бы и сделал так, включи я -O3, но он тогда мне всё заинлайнит нахер)
Шедоу зона это вроде место, где коля может хранить регистры, которые не должен портить? Чем это отличается от sysv ред зоны?
зы: да, на студии 2017 репродьсится
А редзона находится ниже фрейма функции: [rsp-128; rsp). Обычно её юзают листовые функции, которым никого не надо вызывать. Просто чит, чтобы не двигать rsp лишний раз ради локалок. Ядро и системные либы гарантируют, что они не будут туда срать. Но если ты пишешь ядро, использование редзоны надо запрещать иначе проц запишет туда что-нибудь во время прерываний.
Редзона получается позволяет листовым функциям существовать "в стеке" родителя, лол
Не... Она формально за пределами фрейма. Это очень тонкий лёд. Просто на данной платформе все договорились, что в эту область срать не будут и твой код может эту область юзать не резервируя её через уменьшение rsp.
Ядру во время прерываний пофиг т.к. у него свой стек, а сигналы просто отступают от rsp на это расстояние.
а какая разница?:)
Это же папкин фрейм, папка просто туда не срёт.
Ядерный стек вроде с юзерным никак не связан, это понятно, а для сигналов видимо пришлось вносить костыль
Нет! Это вообще ничейная зона под всеми фреймами. В том и прикол. Ты владеешь только тем, что выше rsp.
Грубо говоря, я могу пользоваться ею до первого вызова функции
Но я понял твою мысль: зона находится по ту сторону от SP (не где BP, а наоборот)
Винда:
Коля на винде ныкает в тень содержимое трех регистров
Прыщи:
Четырёх.
У них был переводчик с одного процессора на другой?
там как раз была такая же нездоровая система с додикейтед регисторз, которую штеуд по 2021 года дотащил
В ядре есть их лист, из кернел спейс а можно по нему походить, но есть ли что в ``/proc``?
https://www.kernel.org/doc/html/latest/admin-guide/mm/pagemap.html
Кстати, совсем забыл про e820
Там хоть страничек и нету, но есть инфа о регионах памяти
Мне была нужна физическая память: список пейдж фреймов.
Особым бонусом список указывающих на них страниц процессов
Видал RAMMap?
Вытеснять странички в своп, насколько я понимаю, оно будет с виртуальной стороны. А аллокатору больше интересен список свободных регионов.
Так что, скорее всего, в явном виде карты физической памяти нигде нет и тебе придётся по всем процессам бегать чтобы её собрать.
Грубо говоря один питух знает про PFN и физические страницы (фреймы) и какие-то их свойства, а поверх него уже тусят виртуальные питухи.
Есть вот kpagecount, например
This file contains a 64-bit count of the number of times each page is mapped, indexed by PFN.
Так что если физ страница за номером 42 замаплена куда-то, то там будет число.
В этом и проблема. Ну будет у тебя инфа в духе "занято, 1 использование". А чьё это и зачем? Да хуй бы знал, этим другая подсистема занимается.
Кстати, можно написить расширение для windbg (теперь и на JS, лол!) которое бы это делало.
Только чтобы зырить PTE нужно включать ядрёный дебагер, и переключать его в конь-текст процесса
Оно так-то нахуй не нужно конечно, я уже забыл зачем я хотел это знать
2. через выделение в стеке максимального размера строки
лол это как?
чтобы там стек хранить?
См. https://govnokod.ru/25602#comment477597
чтобы реализовывать абстрактную фабрику стратегий, разумеется
class MMIONamespace implements OutputNamespace
пишите на джэй-эс, наслаждайтесь мощными процами!11
А сишнички пусть пирдоляца с mmuless
https://stackoverflow.com/questions/310974/what-is-tail-call-optimization
Но я, мечту свою лелея,
Решил проблему гениально:
Успокоился и поставил себе более реалистичные цели.
начинаешь называть себя в женском роде
Почему такой случай важен? Очень часто удаётся заменить CALL на JMP, сэкономив при этом место в стеке и сократив цепочку возвратов.
нафига они вообще создают такие??
Немножко беременный.
Вроде в этом и отличие между интерфейсом и абстрактным классом.
> А слово «abstract», чтобы нельзя было создать экземпляр?
Я думаю конпелятор в 99% случаев и сам бы его вывел по наличию abstract на методах. Но остаются всякие утилитарные базовые классы, у которых все методы имеют какие-то заглушки. Вот для них, видимо, это слово и сделали. Чтобы зафорсить абстрактность даже если ни одного абстрактного метода.
Ну и хз где тут говнокод. Очевидно, что в явно заданном Department нет метода generateReports. Это так работает практически во всех типизируемых языках...
В абстрактном классе могут быть методы. Часть реализована, часть нет.
Если хотя бы один метод абстрактный (не реализованный) то это и не говнокод вовсе.
Как бы ты еще реализовал например "шаблонный метод"?