- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
Top 5 most loved languages:
Rust: 86.1%
TypeScript: 67.1%
Python: 66.7%
Kotlin: 62.9%
Go: 62.3%
Top 5 most dreaded languages:
VBA: 80.4%
Objective-C: 76.6%
Perl: 71.4%
Assembly: 70.6%
C: 66.9%
Top 5 most wanted languages:
Python: 30.0%
JavaScript: 18.5%
Go: 17.9%
TypeScript: 17.0%
Rust: 14.6%
А в антирейтинге нормальные пацанские языки: VB, Пёрл, Асм, Сишка.
Зачем? Зачем?
VBA же, а не VB.
А на VBA только троянов внутри документов опердень внутри экселек.
Или там как питон и питон в lldb или гимпе или куда его там заембедили
Кстати, видел полезное использование макроса в ворде в одной газете в прошлом веке.
Там текст форматировался в размер гранки, которую потом отдавали в типографию вроде
Только apiшки разные. Так это один язык.
Vb очень сильно отличается от VB.net, VBScript или QBasic. Там действительно пропасть.
Но ведь реакт и *уй — говнище.
АнгулярЖс самый лучший клиентский фрейворк. На нём даже нгк написан.
Зачем уважающему себя программисту активно сидеть на сайте с вопросами, ответами и _рейтингом_? Лично я там зарегался только когда не мог что-то нагуглить, поэтому хотел задать новый вопрос. Но удобный поиск по уже заданным вопросам избавил меня от этой необходимости, с тех самых пор в свой аккаунт я уже не заходил )))
В итоге, что нам показывает эта статистика? Не мнение, может быть, 2% нормальных программистов, не знающих про говнокод, а потому срущих на стаке, а мнение 98% ламерков, прошедших курсы HTML/PHP/JS и не осиливших что-либо сложнее скриптушни или языка "который как сишка тока безопасный даже думоть не надо!"
Доброе утро, oaoaoammm.
Поэтому, если беглый гуглинг вопроса не дал результатов, то на «SO», скорее всего, на него тем более никто ответить не сможет.
у меня не очень много вопросов на so, но почти на все из них есть ответы и ответы вполне себе адекватные.
если на so нет твоего вопроса, то как на нём появится ответ на твой вопрос? 🙂
то ли дело qaru.site
вы вам перезвоним
SO лишь срез всего айти. Думаю дело в общем обанскиливании профессии.
В которую народ активно ломится, не потому что любит программировать. А просто за баблом.
Я сделал забавное наблюдение, зарплаты в «most dreaded» сильно ниже средних цифр, а «most loved» сильно выше.
https://insights.stackoverflow.com/survey/2020#work-salary-and-experience-by-language
Может дело и вовсе не в языках, а народ просто жаждет денег?
Люди любят деньги и комфорт работы
Ещё вчера люди учились на экономистов, юристов или барменов и смотрели на кодеров как на задротов и недолюдей.
А сегодня только услышав, сколько вечнозелёных получает «Колька, Иркин брат», бегут в погромисты.
На волне «войти в айти», они дружно рассказывают о своих мечтах быть «айтишником», как они любят кодинг.
И как им мама в детстве на ночь читала Кнута. И какая заебатая штука ТайпСкрипт, а Rust вообще чудо.
Надо было чего попроще. Типа html.
PHP: 62.7%
Но я был искренне удивлён, когда увидел, что народ больше страшится Ассемблера и Сишки, чем «PHP».
«За баранкой был под мухой...»
ты просто сказку не знгаешь
https://www.joelonsoftware.com/2001/12/11/back-to-basics/
не vb, но vbs
VBScript is the dinkiest language on earth and ASP programming consists of learning about 5 classes, only two of which you use very often. And only now do I finally feel like I know the best way to architect an ASP/VBScript applicatio
https://englishplusplus.jcj.uj.edu.pl/texts/lord-palmerston-programming/fulltext/index.html
риальне питух
Я немного пробовал это учить. Просто отвратительная, ублюдочная копия Ecma (ещё того, куцего, времён IE4-5).
Спольски понять можно. VBA в Экселе получился лютой годнотой. На тот момент технология просто революционная.
Но VBA для браузера, тут уж извините.
Это выкидывая за скобки немаловажный момент, что его поддерживал только IE, во времена своей славы.
А с VBS ты можешь и в ASP (классик) и в IE и в WSH, и всюду, куда заембедят.
Но не выстрелило.
У MS вообще было много идей, которые выглядели здраво и правильно (яб тоже так сделал) но почему-то не вышло
Бейсик изначально ведь и позиционировался как простая скриптуха для быстрого прототипирования.
С этой точки зрения JS и Питон — эволюционировавший на следующую ступень Бейсик.
А разработчики «TypeScript» этого так и не поняли, сотворив мерзкую, осклизлую, болотную недожабу для браузеров.
- а как надо было?
Изначальный ЖС был гораздо ближе к идеалу. Туда бы хороший type inference прикрутить и тупизацию.
Я уже много раз про это писал.
Идеальный язык где ты пишешь.
a=1
А все ненужная питушня доопределяется сама
const a:int=1;
Изначальный ЖС был функционален.
А прототипуха, это мелочь, без неё можно было и обойтись.
Кстати, для "JS"-дебилов: имейте в виду, что для превращения числа-строки в целое число необязательно использовать "parseInt" - можно просто умножить строку с числом на 1.
А как панять это ты зашедовил переменную декларнув новую или старую переписить пытаешься?
И тогда заставлять явно писать мудификатор.
Ситуация довольно редкая, потому от этого только польза.
> выдавать ошибку при shadow.
ну, такое
А тогда классическое:
var a=1
Смысл в том чтоб const был по умолчанию.
но там нужнописать val
val -- r/o
var -- r/w
Это не то. Хуйня.
Неявный const очень сильно всё упрощает, и избавляет от целых КЛАССОВ ошибок.
Типа переопределения ниже по функции и захватов в лямбдах.
А классическое == убивается на корню:
Компилятор это отловит, т.к. это переприсваивание константы.
if (x=2){ //тут ошибка, хотели x==2
Компилятор это отловит, т.к. это переприсваивание константы."
Если компилятор и так "понимает", что имелось в виду, почему бы ему сразу на лету не переделать некорректный код и не выполнить то, что подразумевал пользователь?
хочешь -- пиши =
хочешь -- ==
компилятор пускай сам доумкает, не маленький же
С без вал есть такой проблем как установка значен по умолчанию
в петухе это Noneом решают
val petuz: String //в питонге было бы petuz = None
if (..) {
petuz = "A"
} else {
petuz = "B"
}
Везет же некоторым...
> ну, такое
https://govnokod.ru/28254
если потеребонькать ширину таблички по нажатию на кнопаньку, то да
если SPA во все поля с файербейзами и рагулярами, то жс вообще ни о чём
Минимум всякого синтаксичесого хлама private, public, protected. Без наследования.
Вся приватность как в сишке (кишки не видны через h-файлы интерфейс модуля) или как в жс, локальные переменные прячутся в замыкании.
У тебя есть модуль компиляции. В этом модуле я могу куда угодо залезть и что угодно потрогать
А вот снаружи этого модуля пусть будет явный интерфейс с документацией.
Пакетная видимость это вообще глупость
Именно.
Вроде, а джву тоже что-то похожее завезли jigsaw
это такое буэ, что страшно сказать
> или как в жс
this is undefined
так заябись же! Мне вот хочется явно описать API моего модуля
Как мне это сделать?
В "Word"-е.
З.Ы. Это было бы смешно, если бы авторы некоторых либ реально так не делали.
сгенерь документацию из исходников
а вообще отойдите от меня, мужчина, от Вас сильно пахнет нафталином
ну вот у меня есть три класса. В каждом два метода.
Из них только два класса это публичное апи, и еще один метод из третьего.
или даже не классы, а функции
Как мне сделать так, чтобы клиенты моей либы не заюзали другие классы?
>нафталином
Ну так человечество же идет по пути регресса)
- откуда я знаю, как это делается в языке, на котором ты пишешь? погугли
Потому что если я не вынесу это в интерфепсы, то буду вынужден открыть класс целиком.
А как это делатся в твоем язуе?
В моём языке я просто посылаю нахуй ООП с его классами и интерфейсами, пишу нормальный процедурный код и теку.
у тебя документация делается путём создания интерфейсов?
Документация путем документирования API в том числе
Что не так?
начешуя мне копаться в твоих сырцах, чтобы про апи почитать
Можно назвать эти классы случайными наборами букв и цифр. Если, конечно, без классов вообще никак - ну любишь ты БДСМ.
- не понял, в твоём языке модификаторы public и private означают что-то более другое?
Internalов в моем языке в чистом виде нет, но их пытаются туда завезти
и ты его ещё форсишь после этого?)
>это такое буэ, что страшно сказать
Возможно открою тайну.
Но интерфейсы есть в КАЖДОМ современном промышленном языке: C++, C#, Java, TypeScript, Python, Go, Rust (trait) итд.
не считая крестов
я беру питон
пишу одно файло
импорчу его и теку
сишка не осилила многопроходный компилятор, теперь до сих пор жрёт говно. это подаётся как невиданное достижение. ну обалдеть)
пишу одно файло
импорчу его и теку
Та же хуйня с "PHP".
Я беру сишку. Пишу int main() и теку.
но можно использовать IDE, оно сгенерит их длятебя
но точно так же оно и для .h сгенерит
Я написал реализацию, тыркнул кнопкой, и попросил вынести ее декларацию в .h файл
это ещё более-менее
а в жабе это зачем руками делать?
а если в IDE, то оно сгенерит его.
В общем смысл в том, что
ничем не хуже
но первое все ругают, а второе нет
почаму?
В public interface Petushok {
Буковок больше.
Им за буковки платят.
Интерфейсы есть не только в ЙАЖЕ, а вообще везде.
и в го не надо
и в питоне не надо
и даже в великом и ужасном лишпе - нет, не надо
у вас молоко убежало
ты можешь в сишечке тоже .c файлы распостранять, и с ними компилироваться
А как в свифте выглядит SDK?
Форварды к объективному си поди?
вот я написал супер-полезную функцию getFoo().
Я не хочу тебе ее сырцы давать, но могу тебе продать ее реализацию в виде .dyld или .so (забыл, в чем разница на ябле) чтобы ты с ней скомпилирвался динамически
Ну или продать тебе .lib, чтобы ты статически
Как ты компирилируешь свой код без .h файлов?
Чтобы можно было его юзать из объективной сишки?
А потом вылазят .h-файлы, llvm, биндинги сишные, вотэтовотвсё.
Сидят на полностью ворованной инфраструктуре да и покрякивают.
- я не рефлексирую по этому поводу)
просто разделение на .h и .с это, на мой взгляд, рудимент, а вы ещё это в 2020-ом году предлагаете в качестве "инновации" добавить в js
Может показаться что это «троллинг». Однако здесь абсолютно серьёзно.
Есть модуль isTen.
Внутри него объявлены всякие foo, bar.
Мы хотим чтобы они не торчали наружу, засирая глобальную видимость.
Наружу торчит только функция isTen.
Добиться этого можно разными способами. private/public один из вариантов. Как я уже отметил далеко не наилучший.
nodejs module.exports по духу как тот же extern, позволяет «увидеть» функцию или константу из других модулей. Да, там ещё есть поправки на линковку, но в целом.
> nodejs module.exports
- это ж оно и есть?
Поздравляю! Мы изобрели h-файл!
Чем не явный список экспорта?
Businesses and organizations
TSD Desalination, an Israeli start-up
Texas School for the Deaf, U.S.
Transylvanian Society of Dracula
Turin School of Development, Italy
University of Wales Trinity Saint David, a university in the U.K.
TSD - Tunisian Software Development, Tunis , a Waste management IT consulting company
Government
Technical Services Division, another term for the U.S. CIA's Office of Technical Service
Treatment, Storage, and Disposal Facility; see HAZWOPER
Treasury Solicitor's Department, U.K.
Trilateral Security Dialogue, part of the Quadrilateral Security Dialogue
Science and medicine
Target-to-skin distance, a measurement in external beam radiotherapy
Tay–Sachs disease, a genetic disorder, fatal in its most common variant
Temperature-dependent sex determination
Thermionic specific detector, another term for nitrogen–phosphorus detector
Total sleep deprivation, a parameter in sleep and memory studies
если у тебя есть ещё обжсишные или сишные инклуды, которые ты хочешь сделать публичными, ты их в этот хедер добавляешь
я не знаю, даёт ли он что-то для чистого свифта, по крайней мере, нигде не встречал упоминаний. думаю, это ради консистентности
хедеры
на случай, если кто-то приебётся, что там импорты, а не инклуды
я чот думал, что их надо в обязательном порядке помечать как @objc, но это только для рантайма
ну и свифтовые типы должны быть представимы в objc
в свифте как минимум есть llvm'ный modulemap
только руками его никто не трогает почти никогда за исключением редких случаев
а если ты захочешь эти колеса (.so, .dll) юзать, то тебе надо или полностью полагаться на динамику, или... ... СКАЧИВАТЬ СТАБЫ
СТАБЫ БЛЯДЬ
PEP-484.
Для статической валидации кода.
Угадай, похожи ли они на .h файлы?
как сделать библиотеку на свифте и распостранить ее в виде скомпилированного кода?
или у вас есть как раз тул, чтобы сгенерить этот .h файл налету из кода?
Про modulemap для затравки
https://stackoverflow.com/questions/47036023/what-is-export-in-module-modulemap-file-inside-each-framework
https://clang.llvm.org/docs/Modules.html#export-declaration
а как он выглядет?
а, ок
А это как раз modulemap
Это разные вещи
modulemap генерируется автоматом при сборке. Но можно и руками, емнип
В тонкой настройке экспорта я честно не силён, надо вникать в доку по llvm.
Но там много можно разного делать, например, создавать модули из голых сишных исходников
И клиент потом компилируется против этого .h файла.
Кстати, что за браузер?
Звучит очень смешно, т.к. в го приципиально отказались от ооп, однако зачем-то завезли:
Видимо, потому что «не надо».
Разделение реализации и API достаточно очевидная концепция.
Особенно в контексте обсуждения модификаторов public/private.
МАКАКА даже пример дал:
https://govnokod.ru/26961#comment576261
я ж никогда не поверю, что ты не знаешь разницы между interface в %LANGNAME% и хедерами в сишке.
ты троллируешь
но я не ведусь(
Речь не о разнице. А о схожести.
h-файлы немного по-уебански сделаны, через из-за чего пришлось выдумывать precompiled headers и прочую питушню.
Но их суть отделить API от его реализации.
>ты троллируешь
Даже gcc пишут что это интерфейсы.
https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html
только ж они всё-таки про разное
наличие interface в Go не заставляет язык иметь ещё и интерфейсные файлы отдельно
Так в Сишке тоже можно объявлять в одном файле сигнатуры функций и чуть ниже писать их реализацию.
А в явах/шарпах тоже принято писать интерфейсы в отдельных файлах.
На самом деле это логично.
И на практике во всех RPC типа WSDL, SOAP принято поставлять стабы в отдельных файлах.
Которые по сути те же интерфейсы.
в Си тебе нужно иметь хедер для своей библиотеки. и при этом писать его руками.
в других языках* эти хедеры даже если и есть, то пишутся машиной и людьми обычно не редактируются
вон Макака говорит, что какая-то сишная ИДЕ тоже умеет сигнатуры в хедер копировать. это прогресс.
а то, что таким образом в сишке достигается инкапсуляция, так это чудесно и я про это знаю. только других способов-то там по идее и нет 🙂
* не считая ожидаемо C++ и совершенно внезапно Лажи, ну и обжси до кучи
А в WSDL для библиотеки нужны стабы. В чём отличие-то?
>и при этом писать его руками
Не обязательно.
Вообще не вижу корреляции между функцией IDE сгенерить h-файл и возможностями языка.
а так отличие в том, что ты свои дефиниции мейнтейнишь в одном файле, а не в двух
А разве в свифте когда объявили protocol, его не нужно мейтенить в двух местах (объявлении и реализации)?
если ты говоришь про имплементацию протокола, так это уже совсем другая сущность. её может и не быть в данном конкретном модуле.
Поменяли протокол — нужно поменять реализацию, верно?
вот тебе пример на C++, как я его понимаю (если в чём проебу, старшие товарищи поправят)
у тебя есть абстрактный класс
он описан в .h файле
.cpp файла у него ведь нету, верно? (ну даже если есть, то только лучше для моего примера)
есть наследник абстрактного класса.
у него есть и .h, и .cpp
то есть это три файла
в Свифте протокол в одном файле и реализация в другом файле
это два файла
выигрыш в полтора раза
масштабируй даже на небольшой проект на ~1000 файлов, нифига себе экономия энтропии
а кто там что потом меняет и рефакторит, это вообще к теме разговора не относится
https://php.ru/
когда ставишь компилять, сражаешься на мечах на стульях в коридоре
всё равно всё в шаблонах через шаблоны
/green
то тогда конечно меняем в браузерах js на C++
если захочется конструктор там позвать
Когда в хедере у тебя ХуёМоё с единственным полем - указателем на ХуёМоёИмпл. А ХуёМоёИмпл лежит в цппшнике вместе с реализацией методов ХуёМоё.
Ну и твой вариант с тремя файлами тоже часто встречается.
В крестах дохуя вариантов отстрелить себе ногу так то.
Стабильное ABI. Методы не виртуальные, на их порядок и количество насрать. А все кишки спрятаны в реализации и их можно менять как хочешь без переконпеляции клиента.
Qt это юзает, к примеру.
нет ничего идеального
И так, и так 2 раза.
И так, и так при изменении .h нужно всё переконпиливать.
И так, и так, вся логика в .cpp
В чём удобство?
ты свой ХуёМоё экспортировал в длл
в приложении клиента импортируешь ХуёМоёЛиб.длл, но компилятор клиента также должен знать как минимум о размере объекта ХуёМоё, чтобы выделить ему, например, 56 байт на стеке (для этого вместе с длл ты поставляешь и хедер), скомпилил, собрал, молодец
теперь ты решил, что в ХуёМоё надо хранить на одно приватное поле больше - int dick_length_;
пересобрал ХуёМоё.длл - всё, клиент пошёл по пизде, его теперь тоже надо пересобирать
2) Если я добавляю int dick_length_ в impl, то почему это не должно распидорасить клиента, у которого размер приватного поля impl увеличится? Или там укококозатель храницца?
ABI
> укококозатель
https://en.cppreference.com/w/cpp/language/pimpl
господи, даже на дцпреференс статью сделали для тебя, что за анскильность задавать такие вопросы в интернете
Я же сказал, что это мне запутывает навигацию по коду. Если смысла нет, то нахуя?
2) Там указатель, в этом и минус подхода. Но в случае с интерфейсом и фабрикой он тоже будет.
Если ты хочешь максимум пирфоманса, ты вынужден светить кишками наружу.
Либо просто привык после какого-нибудь Qt.
Тогда да, имеет смысл. Но вряд ли из-за этого.
> теперь ты решил, что в ХуёМоё надо хранить на одно приватное поле больше - int dick_length_;
Какая кресто-инкапсуляция )))
Абасракция потекла по штанине.
Удобство в том, что у этой хренотени крайне стабильное ABI. Ты в любой момент можешь выпустить новую версию либы с новыми фишками или полностью перехуячить реализацию. И старые клиенты будут совместимы с этой дллкой.
Кстати, в ХуёМоёИмпл методы совсем не обязательны. Можешь юзать его в методах ХуёМоё просто как структуру.
У жабьего свинга так сделан UI, например.
Есть иерархия классов компонентов, которая ниухя не делает, а только передает все вызовы лук-н-филу. Ну и паралленая ей иерархия компонентов лук-н-фила
Я пишу код в терминах компонентов ничего не зная про конкретный лук и фил
Тут Лук и Фил явлюятся как бы Пимплом из примера.
Дело тут конечно не в аби, а в возможности сменить лук и фил.
Но чем-то похоже
Pimpl не настолько гибкий в плане поштучной подмены компонентов. Да и "импл" часто просто структура без методов.
В жабе нету ТАКОЙ проблемы с ABI. Точнее, она есть, но менее страшная.
Добавление приватного метода не сломает ничего, ведь все говно виртуальное все равно.
Добавленрие поля хз, но вроде тоже оно там по имени, а не по индексу.
Так что там пимпл в чистом виде не нужен
>Добавленрие поля хз, но вроде тоже
Там в каком-то смысле ещё хуже.
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/Serializable.html
The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException. A serializable class can declare its own serialVersionUID explicitly by declaring a field named serialVersionUID that must be static, final, and of type long.
However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class serialVersionUID fields are not useful as inherited members.
разумсеется, добавление поля это всегда пизда серилизации бинарной
но мыж не про нее.
Моя помнит, что в одном веб фреймоворке (struts?) контрорллеры implements Serializable, и Idea советовала писать всем serialVersionUID
И все как дураки писали его в каждый контроллер
>may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization.
стабильненкок
теперь я понимаю, почему у нас GSon
В плане ABI проблем конечно меньше. Но при использовании RPC-технологий (а это в ынтырпрайзе частый гость) они как бы возвращаются вместе с сериализацией.
В Йажа всё-таки есть более-менее рабочая инкапсуляция. И сериализационных и ABI-проблем меньше.
То есть безболезненно добавить приватное поле пожалуй можно, только осторожно и c transient.
Но «перегенерить стабы и скелетоны» когда-то давно было довольно частой ситуацией во времена корбы и рми. Даже при неизменном классе, а например при обновлении версии jvm с 4ой на 5ю.
Это же кресты ебаные. В них нет никакой логики.
СиПлюсТруп вдобавок к имеющемуся в сишке механизму инкапсуляции (headers) сделал ещё один (классы с приватными полями).
Где можно «прятать» поля.
Механизм ожидаемо оказался полным говном, т.к. приватные поля хоть и не видны, но влияют на размер структуры.
И к тому же в их содержимое всегда можно посмотреть скастив структуру в массив.
То есть поставленные цели не достигнуты: ни сокрытия, ни абстрагирования достигнуть не удалось.
Какой бугор))
Кстати читал, что в древних юниксах (может в 70-х?) иногда не распостранялись .h файлы, а только документация.
Ты просто вызывал функцию по имени, и надеялся, что переписал ее сигнатуру верно
Но добавление приватново поля это делать реализации
изменение реализации не должно ломать ABI!!
иначе как обновлять либу не перекококококпилруя клиента?
Либо у тебя структура в паблике и часть ABI, либо ты её прячешь но начинаешь дрочить кучу.
Либо ты делаешь ёбаный хак с резервированием места - для клиента поля не видны, только char buf[N].
Но в ООП совершенно естественно добавить приватное поле. Интерфейс класса не изменится.
Я на жабе так могу же сделать? а на крестах нет?
Если ты все методы сделаешь виртуальными, а поля клиенту не покажешь - всё будет как в жабе.
Если ты поля клиенту покажешь, даже приватные - они станут частью ABI, клиентов придётся пересобирать, зато работать будет быстрее и аллокатор можно не дрочить.
Просто жаба тебе выбора не даёт, вот там это и выглядит "естественно".
вопрос про приватные поля, они же не виртуальеуые.
>Если ты поля клиенту покажешь, даже приватные - они станут частью ABI,
Воот)))
Так что приватность она такая не очень приватная как-бы.
Инкапсуляция кап-кап.
А ты потом думаешь такой: "таак, если я переименую поле, то клиент не сломается, а если поменяю тип то ему пизда"
>Интерфейс класса не изменится.
Ахаха. Наивный. Почитай про java serialVersionUID.
>Но в ООП совершенно естественно добавить приватное поле.
Именно поэтому я против «ООП».
Они не сделали инкапсуляцию данных или абстракцию, скрывающую детали реализации от пользователя API.
Они просто сделали говно на котором писать нельзя.
И в этом и заключается фокус.
Но далее говноооп нам экспортирует публичные методы интерфейса на которых мы уже и пытаемся что-то сваять.
Очевидно, что сваять ничего нельзя - поэтому отовсюду торчат фасады, обёрточки, pimpl-указатели.
Это вообще стандартная практика.
Ещё один паттерн, сделать енум с ид параметров и хуйнуть flexible array member.
приватное поле нужно только твоему коду, коду клиента оно не известно
На С:
На С++:
Детали get_int опущены, но теперь ты хочешь добавить супер охуенный кэш, который ускоряет функцию в 100 раз, но для этого нужна дополнительная память, и нужно поменять структуру:
В крестах ты сделаешь это без изменения аби, а в сишке - нет.
Я и в сишечке могу отдать тебе структуру с указателем на непрозрачную структуру с указателями на функции, не?
Или он Конардо косплеит?
Клиент сам память для стейта не выделяет, так чта ему срать и ссать на то, сколько он там чего занимает. Хоть каждый день структуре поля меняй.
А вот если мы хотим чтобы памятью заведовал клиент, тут уже сложнее.
Если ты анскильный птушный лох, то безусловно.
Потому я уже устал вам объяснять, что массив — единственная нужная структура данных.
И чем вы быстрее это поймёте, тем будет лучше.
В Сишке пацаны используют flexible array member. Пока ооптухи делают поля приватными и рвут стек.
То есть С+Труп сделал свою реализацию сишных хедеров через public/private.
И свою реализацию линковки, через виртуальные функции.
Но этот подход соснул хуйца и мы возвращаемся к .h и extern "C".
Ахахаха.
но можно фабрику абстрактных синглтонов написать, конечно)
(но это и будет та самая единица компиляции, которой надо форвард-декларацию на конкретный ХуёМоё иметь)
можно сделать IoC, чтобы ХуёМоё сам себя зарегистрировал в каком-то реестре, как плагины делают, а потом абстрактная фабрика хуяк хуяк - нашла во мху енота и отдала
на что только люди не пойдут, лишь бы не использовать шаблоны через шаблоны!
This.
Но можно и просто фабричную функцию рядом с интерфейсом оставить, если это что-то внутреннее. Кишки с полями в хедер не торчат - и ладно.
если он пьюр то нету
кода в .h файла быть не должно (если это не шоблон)
ничего не заставляет тебя иметь по отдельному хедеру на класс, боже упаси!
сри двадцать восемь классов в одном .c файле, и теки
А разве в ObjC так нельзя? Разве не могу я и декларацию и дефиницию описать в .m файле, если снаружи никто не будет иметь к нему доступ?
Кстати: в си ты можешь получить декраларцию из дефиниции если ты компилируешься вместе. Ну тебе не надо явно описывать интерфейс.
В джаве ты можешь получить ее даже в рантайме (просто нельзя выбирать какие методы выдать)
А как в обжс? там всегда-всегда надо было писать @interface и @implementation?
Я не помн. нихуя
или не знаю
что за предрассудки
кресты не сишка, лучше иметь инлайн, где он нужен, чем течь от джампов
Но если не инлайн, то точно не надо. Исправишь там одну букву, и будет все перекомпилироваться же, и еще одно и тоже
Можно юзать несколько прекомпайлед хедеров, по одному на подсистему например. Тогда не всё, а только десяток-другой файлов.
Вариант про инлайн мне понятен, а еще есть юзкейсы?
Потом, конечно, ты будешь ждать пока соберутся остальные. Но они не всегда нужны.
А если есть, то конечно лучше разбиваться на подсистемы
Это и так всегда полезно
Впрочем, наверняка в твоем прооекте есть такой .h файл, троганье которого приведет к битве на мечах
У нас в проекте кстати с модульностью хуево
Я постоянно вынужден перекомпилировать чужой код. Надо всё на модули разбить
Поэтому что-то у тебя будет на инлайнах и инклудах, чтобы работало побыстрее. Что-то будет на интерфейсах или пимпл чтобы изоляция получше и конпеляция побыстрее.
От жабаёбов никогда не слышал рассуждений мол private static будет быстрее, чем дернуть метод у другого класса через его инстанс, например
а на остальных языках лалки интернет-магазины пишут
очевидно же
https://govnokod.ru/26961#comment576217
с этим говном мамонта сталкиваюсь по большим праздникам (хотя тут уместнее антоним)
думаю, что это технически должно быть возможно, ведь в общем приватные методы класса в обжективе так и пишут: делают экстеншн в .m файле и текут
пиздец конечно там атмосфера
>а вы ещё это в 2020-ом году предлагаете в качестве "инновации"
Да, в Сишке есть киллер-фича: линкер. А ЖСах и Йажах его нет.
Спольски писал про это.
https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-have-a-linker/
Вместо линкера в мире лалок принято ебошить: http://c.d.n/pitux.latest.js. А потом эпично ломаться, когда latest меняет api.
Те что похитрее используют уёб-пак. Но до уровня Сишка-с-линкером по-прежнему не дотягивают, отдавая мегабайты ненужной хуйни. Это я не упоминаю -flto
Вот эту стадию скриптухи почему-то так и не освоили.
>Then, it removes any library functions that your program does not use.
Именно поэтому я за импорт Сишных концептов и технологий будущего во все новомодные языки.
Но меня и правда бесит отсуствие линкера. И как результат многие мегабайты жс-кода, кучи фрейморков ради одной кнопочки или автокомплита.
вебпак называется. Линкер статический. Динамически тоже можно линковаться через всякие JS AMD, но ты не хочешь
Я знаю:
>>Те что похитрее используют уёб-пак.
Только он не умеет того, что умеет сишный линкер.
А именно выбрасывать из фреймворков неиспользуемые функции.
и ты верно сказал, что у линкера он сосет конечно
хотя вроде умеет выпиливать ненужные модули, но вот ненужный символ из модуля небось не может
зы: ахаха, как мы синхронно
это был вынужденный костыль, чтобы не инклюдить тела функций в каждую единицу компиляции, чтобы потом линекер охуел и сказал "я два раза два раза не повторяю", но и хоть как-то компилятору намекнуть, что это имя функции всем известно, и принимает она вот такие аргументы (первый компиляторам было даже похуй че она там принимает, известна, и на том спасибо, а если неизвестна - то ворнинг, пусть линекер разбирается)
среди практически современников ранней сишки уже были виртовские языки (мудула?), которые как раз и должны были уже отделить мух от котлет, но VHS победил Betamax, а питушки продолжают кипятить и в 2020 году
Я было повёлся на это, а в итоге это оказалось той же хуетой.
Вообще кошернее наоборот. Ты пишешь интерфейс, а IDE генерит заглушки для реализации.
но обычно же не так
обычно ты пишешь реализацю, и в процессе рождается понимание, как из нее абстракцию сделать
или нет?
ты ты сначала пишешь интерфейс и тест, а потом код?
* делает хоть как-то
* делаем на это тест
* переписываем по уму
я могу каждый день противоположные позиции отстаивать, потому что никогда ни в чем не уверен, кроме базовых истин вроде пхп -- говно
У меня та же хуйня со всеми остальными языками.
да, это говнино, особенно когда это надо явно каждый раз писать
уй знает, почему не сделать как в C++ (и вроде как с#) хотябы
> Без наследования.
да. Наследование лучше никогда не
кстати, в коко все классы по умолчанию закрытые и методы их финльные
В сишке тоже структы по умолчанию закрытые, а методы финальные )))
Интерфейсы надо описывать явно
Именно потому я за
- очередная хипстерская мода. "мы настолько анскильные, что боимся отсабкласситься, кабы чего не вышло"
Там еще и все методы вротуальные, лал
Потому отцы все классы в жабе делают final по умолчанию (это еще в эффектив жава написано): планируйте наследование явно или запрещаейте его
А потому что только Программист знает, что валидно, а что нет.
Он царь и бог, а не житель анально огороженной крепости с надсмотрщиком как в джава
Если ты открыл класс, и не написал явно "не наследуйтесь, бляди" (а так никто не пишет) то ты невольно сформировал у пользователя либы ожидание
Давай еще раз:
В сишечке если ты хотел экспортировать какой-то функционал из либы, то ты должен был
* написать код в .c файле
* написать интерфейс в .h файле
* отдать .h файл клиенту
Внутри .c файла ты мог еще 100500 функций написать, клиенту похуй.
Потом пришли жабоебы, и сказали, что .h файлы это говно.
И сделали так, что клиент может дергать твои методы напрямую. Интерфейса ему не нужно: он берет реализацию и дергает ее методы. Ты можешь скомпилироваться используя реализацию классов, беря декларацию оттуда прямо
Вопрос: что делать, если ты не хочешь экспортировать класс целиком, а только часть его методов?
Невозможно сделать методы internal для .jar файла.
Можно только package visible, но это почти никто не делает, потому что у тебя будут другие пакеты тоже.
И тогда джависты говорят: сделай интерфейс, и отдай его клиенту.
А это ровно тоже самое, что и .h файл. Вот один в один.
И все этим отлично пользуются. И при этом кукаречат, что хедеры -- говно.
Хотя они тоже самое используют.
Понял мою мыслю?
даже в шарпе есть интернал
не говоря уже про более новые языки
но я хз работает ли оно на уровне методов
Наследование создаёт больше проблем, чем решает.
а про то, что макака в двух разных местах проповедует абсолютно противоположные вещи)
я за явное лучше неявного
лучше написать final, когда ты понимаешь, что он тебе реально нужен, чем сидеть тупить помнить, а какой же мудификатор здесь по умолчанию
но авторам котлина виднее, конечно
он нужен в 99% случаев
Потому его логично сделать умолчанием
я ж не написал, что final нужен всем в 99% случаев
он может быть нужен
и потом разработка это не только либы
я пишу конечное приложение и буду постоянно биться лбом о мудрость авторов котлина?
final нужен в 99% случаев, потому что наследование в 99% случаев не нужно.
>постоянно биться лбом о мудрость авторов котлина?
если ты будешь каждый класс делать открытым и не абстрактным, то будешь писать open конечно
Если у тебя каждый класс открытый, то возможно стоит пересмотреть архитектуру
если я пишу приложуху, то какая хер разница, опен у меня там или жопен
> потому что наследование в 99% случаев не нужно
- попробуй пописать на UIKit совсем без наследования
Ща про наследование объясню.
Автор библиотеки должен управлять ожиданием клиентов: он должен говорить им, что является частью API (и не поменяется) а что может поменяться.
Как только ты сделал открытый класс, от которого люди могли занаследоваться и переопрелеить методы (напомню, что они все вротуальные) то всё: ты не можешь поменять кишки класса не сломав нахуй клиентов.
если выбирать между JS и TS то выбор вроде бы очевиден:) Так что они всё таки сделали лучше.
Другой вопрос, что всю скриптопарашу надо обоссать и сжечь нахуй уже давно, и заменить ее нормальными современными языками с нормальной стат типизацией, с выводом типов, кококок-вариантностью нормальной (а не анальной, как жобе) с сахаром итд
Нахуй нужно всё это говно?
Эти языки сейчас в тренде, потому и вот
видео из утубчика (h264 какой нито) он же на проце деокдируется, да? тоись на виде окарточку срать (ну если не считать там скорость работы памяти)?
В хроме флаги есть, проверь
спасибо
то есть декодирует видео карта?
так
стоп
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Hardware accelerated
OpenGL: Enabled
Hardware Protected Video Decode: Unavailable
Rasterization: Hardware accelerated
Skia Renderer: Enabled
Video Decode: Hardware accelerated
Vulkan: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
вот тут я вижу, что хром юзает видяху для WebGL и канваса (2д), ну это и понятно
а про кодеки пока не очень (я анскильный, говорил уже)
всегда ли пижже делать это на видео? а как поступают виндрплееры, когда играют древний mpeg там?
кстати, вендоры видеокарт предоставляют тулы чтобы смотреть их загрузку? Операционкин шедулер то про них не в кеурсах
https://tr3.cbsistatic.com/hub/i/2016/05/27/ca82b0fc-f484-4043-a40a-6924dd74351a/fig-a-5-23.png
ну мож там и gpu нет отдельного, хотя какая рознице
и чего там ? покаж скрин?
а как винда знает чем оно занято? драйвер видяхи репортует?*
бывает gpu-z оказываект
https://www.techpowerup.com/download/techpowerup-gpu-z/
На графике видно конкретно, что video decode работает.
спасибо)
Видимо просто отношение busy/total по времени. А то, что видюха на расслабоне крутится на низкой частоте не учли.
а попробуй gpu-z
В прыщах в настройках нвидии те же 30% и 500-600МГц.
Кстати спасибо за идею. Надо во что-нибудь поиграть перед сном, а то отопление ещё не дали.
а есть cpu burn для cpu, который грузит все ядра на 100%. Я и сам такой могу написать, причем иногда случайно) цпу бёрном я проверял раньше, что куллер правильно стоит
Есть такой же для gpu?
Я просто в 3дмарке стресс-тест гонял когда охлаждение системника проверял. 200+ ватт он с неё вполне выжимает.
На самом деле, интересно было бы нейросетки на ней погонять. Тензорфлоу вроде умеет юзать тензорные ядра.
амазон спецом продает облака с крутыми видео именно ради этого
Приведи реальный пример.
Там все упиралось в цпу именно, IO там не было практически
если бы я делал его в несколько потоков, то мог бы нагреть процессор, не?
Я сделал это не умышленно, конечно
зато я раз написал примерно такое же говно на event треде в десктопном софте, и не смотря на низкую загрузку цпу (если у тебя 8 ядер, то одним ядром проц сильно не убьешь) гуй приложения лег)
в общем засрать проц не сложно)
Еще 15 лет назад на высокую загрузку цпу всем было боль-мень все равно, а теперь у всех ноутбуки, и пользователи жалуются, что у них куллер гудит и батарея кушается(
хотя наверное загрузка cpu != его температуре
можно загрузить 100% без SSE и FPU и будет не так горячо, да?
Просто до tj max у меня даже cpu burn не смог, а уж его наверное с SSE писали..
Тащемто tj max я видел только на одном ноуте, и как оказалось, там между кулером и процом было кусок какой-то пленки)) ноут был чиненный-перечиненный, ну и видимо там питух пробегал
кстати, о температураз
знаешь про https://occlub.ru/news/hardware/3863-u-novykh-protsessorov-intel-core-i9-za-1000-pod-kryshkoj-ne-pripoj ?
В случае с i7-7700K снятие крышки и замена «жвачки» на жидкий металл в отдельных случаях снижает температуру работы на ошеломляющие 20 градусов.
На 5ГГц получилось только 6 гипертредов из 12 запустить без троттлинга.
Резать жалко, вот соберусь новый покупать - тогда можно попробовать по приколу.
На последних поколениях вроде опять металл начали заливать.
для них и так спец процы есть
но моб быть семерка
Ну и вдруг у тебя не на декодирование, а тупо на обслуживание приемки мпег чанков с сервера.
Ещё надо разобраться какой кодек пришел (профиль и тд)
А вот всякие косинусные преобразования и все что дальше скорее всего уже видюха.
Верно ли, что для любого видео кодека это актуально, то есть любое современное видео в принципе полезно делать на карте?
Просто если не может, то плюс видяхи еще в том, что не надо кучу говна туда-сюда гонять.
Кстати, добрался ща до машинки i7-3770 с GTX 560 ti (гпу gf114)
Видео на 1080 на утубе нагрузило карту на 7% (судя по gpu-z) а у цпу ядра на 8-10% загружены
Отключил hardware acceleration.
Теперь ядро на 45% загружено, а gpu на один.
Всё теперь понятно
Навскидку, в своей памяти ему удобнее будет декодить. А потом скопировать. Она всё-таки поближе, чем память видюхи.
А так то и проц видюхе и видюха процу могут в память срать.
хром может передавать это карте или декодить на цпу в зависимости от поддержки кодека и карты хромом
ок
спс
intel_gpu_top
Так что если играть в распоследние игры или считать что-то на видюхе не собираешься - впизду её.
у меня видяхи давно нет, вопрос скорее теоретический
DXVA2
Software codecs and software video processors can use DXVA to offload certain CPU-intensive operations to the GPU. For example, a software decoder can offload the inverse discrete cosine transform (iDCT) to the GPU.
ага
Оно оптимизируется, конечно, если матан вспомнить. Но все равно вычислений дохуя.
Кобенирование кусков картинок и мыльный фильтр полегче будут.
играй в VA VA (до)
вот тут надо смотреть
chrome://gpu
Вот если загрузка CPU не упадёт, то уже нужно пердолиться.
d++ дело говорит. Зависит от формата же. Ютуб совсем недавно AV1 выкатил в прод.
И с сервера уже может AV1 приходить, без спроса. И ни одна видяха его пока не умеет декодить.
И VP9 кстати тоже, если комп старше 5 лет.
А что, так делать не нужно?
тут пишешь любой вопрос в любой тред и в течение минуты тебе на него отвечают
мне вот иканус, д++ и борманд всё объяснили
надо прогу которая из коментов в говнокоде делает посты
Пи вроде предлагал
Кстати в ФФ наконец-то завели libva для X11. Вот только недавно. 2k20.
а до этого прыщевики всё рендерили на проце и рисовали через протокол X примитивами 2Д чтоли??? Или тоже через DRI, но всё таки тупо 2Д?
Там есть такой замечательный примитив как загрузка прямоугольника из буфера.
ну в общем понятно: я рендерю на CPU в памяти, а потом загружаю в карту.
Через текстуру в OpenGL можно ещё выводить.
Х.з., может ещё какой-то способ есть, о котором я не знаю.
З.Ы. Но эти преобразования очень криво работают. По сути только RGB, BGR, RGBA и ABGR. Остальное у меня не получалось запустить, цветовые маски игнорятся.
VA-API video decode/encode interface is platform and window system independent but is primarily targeted at Direct Rendering Infrastructure (DRI) in X Window System on Unix-like operating systems
The main motivation for VA-API is to enable hardware-accelerated video decode at various entry-points (VLD, IDCT, motion compensation, deblocking) for the prevailing coding standards today (MPEG-2, MPEG-4 ASP/H.263, MPEG-4 AVC/H.264, H.265/HEVC, and VC-1/WMV3).