Как стать автором
Обновить
3
0
Alexander Rodin @anti_smithhh

Reservoir Geologist

Супер! 👍🔥

Нашел опечатку в

Отображаются на панели Boolmarks.

Boolmarks -> Bookmarks

ipv4 без NAT вообще никак. просто к этому костылю все привыкли как к данности.

в ipv6 NAT нужен только частично: для легаси-v4 и/либо для узких специфичных задач.

если возможно, то извините, что не удержался поддержать оффтопик.

параллель не очень удачная: в отличие от термояда у кого-то ipv6 есть точно.

ChatGPT часто "выглядит" (ведет себя) очень умно, по-человечески. И всё же, нельзя забывать, что у него нет осознания как самого себя, так и выдаваемых им результатов.

тут неявно присутствует утверждение, что феномен Сознания базируется на каких-то других принципах, нежели чатЖПТ. Но несмотря на то, что поиски желанного доказательства особенности Сознания идут давно, результат пока неутешительный. Поэтому на иллюстрации вместо AI можно смело написать Сознание.

привет из будущего!

кто тут про нейронки скепсис сеял?

стал осваивать данную тулзу с целью прикрутить к своим мини-недо-проектам и обнаружил, что, например, наличие tristate в файлах ‘kconfig’ не вызывает ошибок при открытии утилитой kconfig-mconf например, но активизировать ‘третье состояние’ никак невозможно.. опция ‘modules’ тупо вызывает ошибку - не поддерживается парсером.

Стал штудировать kernel.org - обнаружил, что там ещё переменные и другие фичи есть. Но всё это не работает!

А вот парсер, идущий с сырцами ядра, - ./scripts/kconfig/mconf, всё умеет.

Никакие apt-update и тд не помогали. Все варианты не умели в ‘третье состояние’ и переменные.

РЕШЕНИЕ: из сырцов ядра просто заменил в системе пару бинарников:

1) ./scripts/kconfig/mconf -> /bin/kconfig-mconf

2) ./scripts/kconfig/conf -> /bin/kconfig-conf

всё стало работать так, как описано в документации.

Но осадок остался. Должно же работать ‘из коробки’ по идее 💁‍♂️ Как надо было бы нормально решать эту проблему?

из некритичного: я бы все же поправил с "придельно" на "предельно"

"В объявлении нашей функции  getTextFromImage мы указали ключевое слово await"
может не await, а async?

это прям хед-шот )

можно и НУЖНО, если третий свифт использовать.

для объектов без "владения" нужно @ObservedObject.

Но это все для третьего Свифта. На ранних версиях (о которых тут речь) возможно это еще не было отшлифовано.

всё еще "не взлетит"? или уже взлетел? как ситуация развивается?
а то из-за некоторых необновляемых девайсов на iOS10 возникает иногда желание вспомнить старый добрый UIKit.. правда, его я использовал только с ObjC по сути.

offtopic: «Так можно было бы и до 6-ти байт дойти, но кодировать ими уже ничего.»

в конце «нЕчего» ☺️

Если я не ошибаюсь:
1) с большой буквы - это объявление типа (это стандартное соглашение). Других вариантов вроде бегло не нашел.
2) с маленькой буквы - это либо собственно экземпляр (это тоже стандартное соглашение), либо в паре мест это выступает как ключевое слово... точнее, псевдо-ключевое (как я понял).
В общем, неоднозначность есть только по п.2, но вроде по контексту понятно, где что.

Наверное, если будут цитаты, можно будет более адресно ответить.

мне этого очень не хватало как раз перевести понимание на более интуитивный уровень.

кстати, мне кажется вместо «после команды in» должно быть «перед командой in»
Статья очень помогла.
Кстати, недавно наткнулся на инфу, которая вдруг раскрыла, что же за элемент проекта SpriteKit под таинственным именем «GameScene.sks»
Оказывается это что-то вроде аналога сториборда, но для спрайткита — визуальный редактор сцены!
Для заинтригованных ссылка тут
Выглядит не на 30% понятно, но заманчиво.
А можно ли где-нибудь найти реализацию этого «билдера»? Мне кажется, что на Swift он отсутствует, что несколько мотивирует портировать его туда.
А если и не портировать, то может какие-то идеи впитать.
Предвкушение чуда не оправдалось — примерно что-то подобное тоже получалось накидать, когда решил взглянуть на эту дилемму благодаря вашему замечанию. Раньше я вообще об этом не задумывался на столько серьезно. Поэтому в любом случае спасибо за повод разобраться и, возможно, переосознать!

И все же, тут есть над чем поломать копья.



Если такой код будет где-то не рядом с объявлением переменных

Объявление нелокальных переменных с неинформативными именами — это нередко целый букет систематических проблем уже само по себе. Это один из первых уроков, который я вынес когда-то из книжки «Чистый код» (кажется так она называлась), а потом и лично убедился, что мне содержательное именование переменных снимает львиную долю проблем.
Соглашусь так же, что реализация через методы дает дополнительный вариант «защиты» через содержательное именование самих методов. Такая опция для операторов кажется недоступна.

Но стоит ли так радикально ставить вопрос: либо только методы, либо только операторы?
Мне кажется, что истина посередине. Например: можно реализовать только однородные операторы (сложение/вычитание), которые подразумевают оба операнда однотипными.
Сделает это код более компактным, чем только реализуя через методы? Возможно.
Будет такой код более понятным относительно типов с операндами? Так же возможно.
Если по мне, то гибридный подход уже дает как минимум «probably Win probably Win»



можно прикинуть как это будет выглядеть в случаи с записью без операторов

Спасибо! Получилось, как у меня.
Здесь есть двоякий момент.
  1. 1) если создание временного объекта неизбежно (а так случается), то это придется делать вручную. В итоге:
    кол-во действий увеличится (объект нужно объявить и создать),
    способов ошибиться прибавиться (надо будет при поддержке кода отслеживать большее число элементов кода),
    читаемость кода ухудшится (мы будем видеть доп.информацию о том, что делает компилятор в перемешку с тем, что собственно отражает логику замысла разработчика).
    Но соптимизировать будет нечего.
  2. 2) а вот если создание временного объекта можно избежать, то это станет несколько очевиднее, чем в операторной записи. Например:
    a = b+c

    выполняет на одну операцию больше, чем
    a=b
    a+=c

    Но это друга уже дилемма: на этапе Отладки предпочтительнее видеть Что хотим Мы сделать, а на этапе Оптимизации (если она нужна в данном куске кода) Как это будет Реализовывать Компилятор.
    Бытует мнение, что всему свое время: для упрощения Отладки желательно иметь максимально понятную и прозрачную реализацию Задуманной логики, а на этапе Оптимизации желательно иметь Отлаженныйоттестированный) код, который заменяется на аналогичный оптимизированный, а аналогичность Отлаженного и Оптимизированного кода опять же тестится достаточно легко и элегантно… но это друга тема.


В любом случае! Если не касаться проблем из-за оптимизации во время отладки, то и тут есть компромисы вместо крайностей: если не определять бинарные операторы, а только унарные с присвоением, то мы получим невозможность неявного создания временных объектов и это будет, как я понимаю, полная аналогия с подходом через методы.
Причем, это тоже можно реализовать не радикально: либо выкидываем бинарные операторы, либо используем, а гибко:
объявляем и полный набор операторов, но неоптимальные/медленные/итд выносим в блок или файл, который откючается (у меня автоматически), если компиляция переводиться в режим Оптимизации.
То есть, пока отлаживаем — пишем нормальные однострочные понятные формулы почти в том виде, как они в тетрадке/презентации/учебнике записаны.
А когда оптимизируем — компилятор перестанет понимать некоторые места, и мы их заменяем на аналогичные (в чем помогут тесты) развернутые/оптимизированные/использующие_регистры/итд реализации.



Но тут прозрачны все действия, которые происходят с объектами.

Аблсолютно!
Для оптимизации это крайне важно — видеть (или понимать) действия компилятора «под капотом».
И тут надо либо всегда под бинарным оператором иметь привычку видеть создание объекта (что требует дополнительной вдумчивости), либо иметь явно выписанные элементарные действия (тут уж никуда не деться).
Вопрос только в том, сколько нужно потратить времени и сил на этапе Отладки, чтобы из такого кода «дизассемблировать» и рассмотреть Логику, ради которой это все затеяно? А сколько потом нужно времени, чтобы понять, что неправильно понял, и потом все же надеяться, что с энного раза все же ее правильно понял? А как такой код поддерживать? Как немного скорректировать в процессе доводок? Как найти ошибку? И далее по изодранному списку вечных проблем… (ради ухода от которых решили перейти с машинных кодов на компиляторы).
В общем, можно на эти вопросы давать разные ответы с разной пропорцией субъективность/объективность.
Но именно эти вопросы лично меня заставили когда-то признать поражение моей Ассемблерной религии и перейти на С++. Поэтому фараза
Ага, выглядит как ассмеблерная запись вашего кода
очень даже уместна. В данном случае это действительно шаг в ту сторону.
Нужен этот шаг?
На этапе Оптимизации — несомненно!
Нужно ли заниматься Оптимизацией неОтлаженного кода?
Тут надо себе ответить самостоятельно.



Ну и еще пара моментов, отчасти как повторение-переформулировка
  1. Наверное не стоит на уровне глобальной идеологии унифицировать противостояние операторов и методов
    Для некоторых мега-классов операторы могут только вредить, не иметь внятного смысла или хотя бы возможности быть оптимальными не только в компиляции, но и в плане читабельности.
    А для некоторых нано-структур даже Избегание создания временных объектов — это больше зло, чем накладные расходы из-за их использования, особенно, если эти классы-структуры могут целиком передаваться в паре регистров процессора.
  2. По моему продолжительному, но скромному опыту, складывается впечатление, что Оптимизировать во время Отладки (тем более Разработки) — это не очень прямой путь: для Отладки нужна прозрачная просматриваемая логика, а для Оптимизации нужен Отлаженный модуль/приложение, которое вот теперь действительно предстоит закодировать в самом прямом смысле!!


Кстати, считаю, что использовать в группе общий стандарт поддержи кода — это все же первоочередная ценность во многих случаях, чем преимущество форм записи.
Запутать действительно можно что угодно, но с разной степенью усилий. Предлагаю обсудить:

1) на сколько я владею вопросом, не касаясь формы записи, операторные функции и просто функции ничем не отличаются в описании: в обоих случаях, если не заглядывать «под капот», то можно только предполагать, какая использована реализация.

2) на сколько мне известно, в Cpp способы передачи аргументов и возврата значений регулируются идентично и для функций и для операторов: хоть по ссылке, хоть по значению. Единственная разница в том, что операторные функции можно вызывать и явно как функцию (a.operator+(&b)) и неявно через операторную запись (a+b). При чем, компилятор, вроде бы, всегда все сводит к первому варианту. А вот для методов/функций доступен только первый вариант нотации.

3) если не сложно, то хотелось бы увидеть «методичную» реализацию на конкретном примере. Возможно, на конкретике мне станет понятнее, так как попробовав сейчас посравнивать оба варианта, создалось четкое ощущение, что «методичный» вариант записи с трудом конкурирует по понятности с «операторным». Единственно, временные объекты пришлось выписывать явно, что «операторная» нотация конечно несколько маскирует от пользователя — это факт, тут надо понимать, что за записью кроется.

В общем, предлагаю такой пример для упражнения:
float t, k; // числа
Point2 a, b, c; // векторы с только двумя координатами икс и игрек
Trasfoator M; // какой-то оператор
a = b*t + c*k*M; // запись с перегрузкой

Информация

В рейтинге
4 682-й
Откуда
Долгопрудный, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Fullstack Developer, Server Administrator
Middle
От 666 $
Linux
MAC
Git
Bash
SWIFT
SwiftUI
Rust
Assembler
Atmel AVR ASM
Lua