- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
// https://habr.com/company/JetBrains/blog/249479/
Привет, Хабр!
Некоторое время назад мы объявили конкурс — требовалось продолжить фразу:
Бьёрн Страуструп создал С++ 36 лет назад, и он до сих пор востребован и пользуется популярностью у разработчиков, потому что...
Спасибо всем участникам за массу положительных эмоций и разнообразные предположения о том, что же сделало C++ таким популярным.
Follow us!
НО в какой-то момент из-за buffer overflow заглючила прошивка в капсуле времени, и его отбросило в прошлое к динозаврам, которые разьебали его капсулу нахрен
Произвольными ограничениями? Сделайте мне плюсы под Сетунь. Или например попробуйте плюсовую стдлибу (которая часть стандарта) и свои сраные деструкторы заюзать в 8-битных говноконтроллерах.
Прикрутить кресты к контроллерам уже давно пытаются.
https://habr.com/post/149683/
У ардуинщиков вроде тоже какая-то кастрированная версия стдлибы есть.
> STL
> Я видел много сообщений, что STL на микроконтроллере — это плохо: она раздувает код и, делая сложные вещи простыми, подстрекает ими пользоваться. При этом умалчивается, что в STL есть и такие примитивы, как быстрая сортировка, которая значительно быстрее и компактнее qsort, или бинарный поиск, безопасные версии min и max. Вы правда знаете сакральный способ написать классические алгоритмы эффективнее других программистов?
Да, если речь идет об AVR-GCC, я уверен что я на ассемблере могу написать qsort, быструю сортировку и бинарный поиск быстрее и компактнее, чем я получу от компилятора. У AVR-GCC очень плохо с оптимизацией
Кстати, а для чего 8-битные AVR сейчас юзают в продакшене? Я ещё понимаю для DIY-говна всякого -- маленький порог вхождения, пятивольтовый интерфейс и корпус который легко запаять неопытными лапками. Но ведь 32-битные cortex'ы выходят и мощнее и дешевле (и жрут меньше, да)...
>и жрут меньше, да
Последние ревизии AVR жрут как стандартные stm32(по поводу low power чипов х.з.).
Лучше дождаться швабодных непатентованных контроллеров на RISC-V, вон Arm Holdings уже на них пробует бочку катить https://archive.fo/SkiH0 - довольно оперативно потерли свой GetTheFuckts
Практичность это не тогда, когда надо лепить ебучую лапшу из шаблонов, как это сделано например в бусте
Интересно, а в "1C" буква C правильно пишется кириллицей или латинницей?
Золотой середины? Что за хуйня вообще? Вот этот пиздец в бусте из шаблонов это по-вашему золотая середина? Какой вы можете назвать используемый на практике язык, который был бы сложнее плюсов? Или под сложностью что-то другое понимается?
Че, серьезно? Т.е. разработчиков под obj-c найти нынче нереально? Знание плюсов разве не подразумевает автоматически знание Си (учитывая что Си это почти подмножество плюсов)?
а он есть?
А когда у тебя все нчиная с NSObject не стандартизированно и имееца только в виде реализации под одну ОС и документировано там же на сайте apple, то как-то смешно говорить про продакшен использование Objc за пределами мака
https://opensource.apple.com/source/objc4/objc4-723/
ну-тоис можно под винду собрать
А то я не уверен, что код по ссылке выше соберётся даже на текущей макоси. Там вроде в notes Леопард упоминается. Но поразбираться можно. Есть NSObject даже
ObjC не мой любмый язык, а пытаться писать на нем под винду это какое-то анальное извращение имхо
зы: вы только не подумайте что я хочу сказать что ObjC говно. Для своего времени он был очень прогрессивным, и многие вещи (вроде месседжей вместо вызова методов) мне даже нравятся
Все это smalltalkство активно используется у скриптовихов (Ruby тут чемпион, то и Python тоже балуется) и ObjC единственный кто так умеет из НЕ скриптовых мейнстримов
- не понял
> сохранения комманд и выполнения их потом
- везде можно, где функции это first class citizens, или я не понял (2)
> сериализации дешевой
- g Codable
> в рантапйме спрашивать поддерживается-ли какой-то месседж (как рефлексия почти) итд.
- а вот это вообще вонючее говно...
Получаешь message и сразу же пересылаешь ее делегату. Попробуй так сделать в java, например: тебе придется явно каждый метод так описывать.
>> везде можно, где функции это first class citizens
Тебе же не function передают, а дергают метод. Ты просто получаешь message и ее аргументы, кладешь в коллекцию и потом дергаешь.
>>Codable
Причем тут это?
>>- а вот это вообще вонючее говно...
Ну именно на этом и сделаны делегаты же:
если мой делегат поддерживает message foo, то я ему ее передаю.
Хотя того же эффекта можно добиться через интерфейсы (протколы) с дефалтными пустыми реализациями
- forward invocation что ли?
> Причем тут это?
- пример дешёвой сериализации в языке без рантайма.
> Хотя того же эффекта можно добиться через интерфейсы (протколы) с дефалтными пустыми реализациями
- в Obj C нет дефолтных реализаций, есть @optional.
> Ну именно на этом и сделаны делегаты же:
- слава богу, и те и другие костыли в Свифте закопали. Правда, пока только наполовину...
Например, да. Пример: ты реализуешь протокол foo. В нем 94 метода.
Ты хочешь получить делегата в конструктор (init или как там), сохранить его в поле и 93 метода передать ему. А один выполнить сам.
В ObjC это делается легко. В Java очень сложно. В Kotlin завезли сахар и стало легко. В C# хз как с этим: раньше было плохо очень, может уже лучше.
>>- в Obj C нет дефолтных реализаций, есть @optional.
Я помню, я имел ввиду что это можно решить с помощью другого инструмента тоже.
В Java 8 и Kotlin есть дефолтные имплементации в интерфейсах (протоколах, в терминах ябла).
>>- слава богу, и те и другие костыли в Свифте закопали
Как же там делегаты работают?
- я понимаю, что метафора, но ёб же вашу мать!
> Ты хочешь получить делегата в конструктор (init или как там), сохранить его в поле и 93 метода передать ему. А один выполнить сам.
- ну да, только я не могу сходу придумать, где бы мне это понадобилось. А ты?
> Как же там делегаты работают?
- что значит как?) Так же и работают. Тебе ничто не мешает накостылить id<BeautifulProtocolWith321OptionalMetho ds> и потом ебошить respondsToSelector. Даже в Свифте.
Но лично я делаю протоколы на 10 сигнатур максимум и, если нужно, затыкаю часть пустой default implementation, но очень редко.
Огромное количество юзкейсов (см рефакторинг "замена наследования делегированием"). Кеш, прокси, логирование, проверка пермишеннов.
>> default implementation,
То-есть твой класс наследует несколько протоколов с пустыми имплементациями, и потом переписывает нужные? Ну, это тоже ок.
Кстати, тут тоже неплохо могут помочь default implementation, кмк. В общем, как не посмотри, а в Свифте всё то же, только лучше!
>>на 94 метода
Ну пускай на 10 методов. Все равно ручной оцтой.
>>Кстати, тут тоже неплохо могут помочь default implementation,
Могут, но в той же Java не бывает множественного наследования и если у тебя не два интерфейса(протокола) с дефалтными импелементациями а именно два класса то ты все равно в жопе.
Я верю что в свифте это решили еще более элегантно.
Я лишь говорю что на момент моего знакомтства с ObjC (а это был год так 2011й) ObjC умел то, что не умели на Java ни C#.
- зачем тебе делать override, если имплементация не меняется? Если класс-родитель держит какое-то состояние, не пойдёт ли всё по пизде с таким подходом?
> но в той же Java
- я не знаю, почему в этой беседе так часто фигурирует слово "Java", мне насрать на джаву, чувак!
> ObjC умел то, что не умели на Java ни C#
- ок. На мой взгляд, у Obj C была другая (ныне немного забытая) особенность, которая опирается на message dispatch и которая в начале 90-х действительно была революционной: распределённое выполнение. Отправляешь мессадж, а где его поймают и обработают тебе уже неинтересно: может, на этом компе, может, на соседнем, а, может, на ноде на атомном ледоходе, пробивающем себе путь в Арктике. Романтичная идея, разбившаяся о суровую реальность
Я могу интерсептнуть ее чтобы залогировать или проверить пермишен, например.
>>мне насрать на джаву, чувак!
Чтобы понять почему messages это хорошо надо понимать как бывает плохо (как в джаве).
А ты говоришь только как в ObjC и как в Swift, и я вполне верю что в Swift оно лучше.
>>распределённое выполнение.
Да, и это тоже.
Message это просто набор байт, который можно не только сохранить для дальнейшей обработки (чего нельзя без ручных костылей сделать в языках где messages нет) но и послать по сети.
Всё можно представить как акторы, посылающие друг другу messages (привет Эрлангу).
В общем это древний флейм про smalltalk-based vs simula-based.
ps: хотя есть и костыли конечно, тяжелое наследие обратной совместимости с сями: это бесконечные собачки для NSString, для NSArray, чтобы не совпасть с сями случайно итд
- о чём речь? String literal? "C" здесь ни при чём
Так же во многих языках есть литералы для массивов. Есть они и в си, но в Objc чотбыне клашиться с сями пришлось сделать
@[ ];
И наконец есть литералы для NSNumber: @42
зы: а, я понял в чем дело: такие литералы есть в C# и Java. Так что я , вероятно, опять о своем.
В C++ для правильных строк литералов нет
А NSArray как был без литералов? Там Vararg и Null-terminated?
Типа
[NSArray arrayWithObjects:@"Petux",@"Korochko", nil] ?
И есть форк от разрабов Darling https://github.com/darlinghq/darling-cocotron
Не звучит как очень вот уж production ready:)
Подозрительно это
А начался этот порочный круг с того, что Страуструп накостылил свою парашный препроцессор Cfront поверх сишки и сделал плюсы совместимыми с Си. Расчет был на то, чтобы можно было легко сишников подсадить на эту сраную крестопарашу, чтобы накопилось критическое количество написанного плюсоговна, и тогда уже будет точка невозврата (нужно будет это плюсоговно развивать, а значит обучать новых программистов, а еще надо допиливать сами плюсы, добавлять новые фичи в говностандарт). Так и вышло. Раньше плюсы не были таким переусложненным говном, и выучить плюсы, зная лишь Си, было достаточно просто.
Если б Страуструп делал плюсы несовместимыми с си (и по синтаксису и по семантике), это сраное говнопорождение б тупо не взлетело.
Короче, я ушел в дебри. По-моему надо смотреть в сторону DSL/eDSL, вот например https://ivorylang.org/ivory-introduction.html https://leepike.github.io/Copilot/
Ну и надо развивать средства верификации, теоремы доказывать там, зависимые типы. Вот например современные браузеры, которые ПОГОЛОВНО написаны на C++ и количество RCE уязвимостей под эти самые браузеры. И года не проходит, чтобы в каком-нибудь (ЛЮБОМ) популярном браузере не обнаружили RCE.
А еще эти блядские уязвимости Meltdown и Spectre, основанные на тайминг-атаках, которые вообще хер пойми как отловить на этапе проектирования. В общем всему жопа и всё говно. Надо писать свой язык и проектировать свой процессор.
Ты в курсе, что ты только что придумал GCC, который в обе стороны является бэкендом (для архитектур и для языков)? И кстати, угадай, какой главный язык, для которого используют gcc?
Ты сам ответил на свой вопрос :)
Семь километров — не крюк, j123123
Борманд, залогинься
> не умеет
Но ничто же не мешает реализовать для гцц эту платформу и этот язык? Ты только что хотел целую систему делать, я показал, что система уже есть, осталась меньшая часть работы. Можешь реализовать.
Кстати, llvm registry based что нехарактерно в целом для виртуалок
Это да, но не из необходимости, а чтобы фофан и чтобы потом кайфово захайриться куда-нибудь
Ну нет же, D и Rust по-моему объективно лучше C++ в его нише. Но это тоже какое-то говно.
давайти все писать на джаваскрипте, уже многие так делают