Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
0
final class Point {
public final int x;
public final int y;
public Point(int x, int y) {
this.x = x;
this.y = y;
}
// state-based implementations of equals, hashCode, toString
// nothing else
}
is "just" the data (x, y). Its representation is (x, y), its construction protocol accepts an (x, y) pair and stores it directly into the representation,
it provides unmediated access to that representation, and derives the core Object methods directly from that representation.
And in the middle, there are grey areas where we're going to have to draw a line.
Other OO languages have explored compact syntactic forms for modeling data-oriented classes: case classes in Scala, data classes in Kotlin, and record classes in C#.
These have in common that some or all of the state of a class can be described directly in the class header -- though they vary in their semantics
(such as constraints on the mutability or accessibility of fields, extensibility of the class, and other restrictions.)
Committing in the class declaration to at least part of the relationship between state and interface enables suitable defaults to be derived for many common members.
All of these mechanisms (let's call them "data classes") seek to bring us closer to the goal of being able to define Point as something like:
record Point(int x, int y) { }
[u]https://openjdk.java.net/jeps/359
https://cr.openjdk.java.net/~briangoetz/amber/datum.html[u]
Запостил: 
3.14159265,
19 Октября 2020
Follow us!
Records cannot extend any other class, and cannot declare instance fields other than the private final fields which correspond to components of the state description. Any other fields which are declared must be static. These restrictions ensure that the state description alone defines the representation.
Records are implicitly final, and cannot be abstract. These restrictions emphasize that the API of a record is defined solely by its state description, and cannot be enhanced later by another class or record.
Прошло 25 лет и в «Йажа» наконец-то завезли Сишный struct;
record Point(int x, int y) { }
struct Point {int x; int y;}
Пужулуйста, подожите ещё лет 5, пока мы допилим передачу на стеке и компактные аллокации.
Are records the same as value types?
With value types coming down the road through Project Valhalla, it is reasonable to ask about the overlap between (immutable) data classes and value types, and as whether the intersection of data-ness and value-ness is a useful space to inhabit.
Records and value types have some obvious similarities; they are both immutable aggregates, with restrictions on extension. Are these really the same feature in disguise?
When we look at their semantic goals, we can see that they differ. Value types are primarily about enabling flat and dense layout of objects in memory.
В общем:
https://www.youtube.com/watch?v=Fm5Ust7vEhk
зашел написать ровно вот это
Как и в TS
#:~:text= в движке MediaWiki означает подсветить жёлтым указанный текст. Эту фигню можно обрезать.
Нашёл про эту питушню. Это из какого-то черновика протокола, реализована в Хроме 80+:
https://stackoverflow.com/questions/62161819/what-exactly-is-the-text-location-hash-in-an-url
https://en.m.wikipedia.org/wiki/URI_fragment#Examples
теперь ленивые фронтосраки вообще забьют на якоря, потому что гугел в очередной раз подумал за них
Если бы в Сишке стандартизировали #pragma pack(1) или другую подобную фичу, вот эту бойлерплейт-питушню с equals можно было бы заменить одним memcmp.
Заодно компилер мог бы высирать ворнинги про возможный unaligned access.
Но меня больше всего веселит что жавухи ПРИНЦИПИАЛЬНО отказались от наследования.
А в коко датаклассы и в c# можно
>ПРИНЦИПИАЛЬНО отказались от наследования.
Ну вот сравнение бы у нас могло и обламаться.
Разве ли ребенок родителю с такими же полями?
А родитель ребенку?
В коко дата классы не наследуются
Поскольку гцц бекпортировали эту фичу у мс.
А шланг старается не отставать от гцц.
https://docs.microsoft.com/en-us/cpp/preprocessor/pack?view=vs-2019
https://gcc.gnu.org/onlinedocs/gcc/Structure-Layout-Pragmas.html
>придётся эмулировать невыровненные чтения софтварно
Ну выдавать ворнинг: внимание, ваша программа будет жутко тупить.
Вот ту же #pragma once почему бы не добавить? Она вроде никому ничего плохого не сделает, зато куча бройлейрплейта уйдёт.
Не понятно, почему не завести такое. Может быть потому, что где-то его сложно реализовать?
З.Ы. Хотя считали бы хеш от контента да и всё. Если файлы физически одинаковые, какой смысл их инклудить 2 раза? Инклуд гарды точно так же бы отработали в них.
а не воткнёт по пифомансу?
Не осилил? Оставайся C89-совместимым, делов-то.
Тем более в крестах (и в сишке) сплошь и рядом такое.
— Corner case?
— Сам себе злобный багор.
https://ideone.com/83sfAO
И массивы тоже.
https://ideone.com/RooEZm
Хотя копировать структуры и массивы можно (тут именно копируются значения, а указатель не изменяется):
https://ideone.com/VrSjb0
Стабильную сортировку полей в порядке убывания размера алаймента.
Но иногда уместнее паковать по 32-битным границам
Чтобы чтение char[3] шло одним 32-битным куском. Или сортировка сугубо опциональна?
Х.з., сомнительная какая-то оптимизация. Мы же не знаем какой там паттерн обращений будет, вдруг там просто рандомный доступ. Такое уже только руками раскладывать. Ну а сортировка стабильная как раз ради того, чтобы такие конструкции не сломать.
может получица фолс шаринг, да?
К слову, на видюхе фолс шаринг вообще печально может закончиться, судя по вулкановской доке. Просто упидорасит тебе зафолсшаренный кусок, кеш то некогерентный.
Как минимум на кеш-лайн.
Там ещё есть прикол с ассоциативностью, что например каждые 4 мегабайта попадают в одну и ту же кеш-линию.
Да и правильно. Почему бы просто не вложить структуру как поле, как это десятилетиями делали в сишке?
Ну какой нафиг наследник из структуры с джвумя дополнительными полями?
> Records cannot extend any other class
> These restrictions emphasize that the API of a record is defined solely by its state description, and cannot be enhanced later by another class or record.
https://openjdk.org/projects/valhalla/design-notes/state-of-valhalla/01-background
https://openjdk.org/projects/valhalla/design-notes/state-of-valhalla/02-object-model
https://openjdk.org/projects/valhalla/design-notes/state-of-valhalla/03-vm-model
А то пишут, пишут… Комитет, JEPы какие-то… Голова пухнет. Взять все, да как в Сишке…