D весьма неплох, но последнее время тоже скатывается туда же куда и С++ — куча каких-то надстроек, «секретных атрибутов» и т.п. Изначальная стройность языковой концепции потеряна. Особенно это видно изучая исходники компилятора.
А по поводу организации памяти (в С++) — я вообще не заморачиваюсь и как правило обхожусь и без GC, и без RC, и без OB. Просто строю архитектуру программы так, что все объекты, создаваемые через new, организованы в единое дерево; у каждого объекта есть единственный владелец, он же отвечает за удаление. Никаких передач владения нет, объект создается в конкретном месте и в этом же месте и удаляется, при этом я свободно передаю указатели на эти объекты в другие места — просто такие указатели считаются «невладеющими» и нигде не хранятся, а просто используются.
Хоть что-то правильно сделали. Для физлиц тоже надо так сделать, так как по сути эта подпись — как паспорт, с ее помощью много чего можно сделать. И по идее увязать с предстоящим переходом на электронные паспорта.
Бывает, нужно перехватить обращение к целой группе полей (например к массиву объектов). На каждый объект бряк по памяти не поставишь, а были бы свойства — одна легкая модификация кода и готово.
Переопределение операторов скорее всего не будет работать. Можно переопределить operator=, но стоит только написать например "+=" и все сломается.
Нужна именно языковая поддержка. Не понимаю почему в С++ до сих пор не ввели. Помнится, в древнем С++Builder'е чуть ли не 98 года свойства уже были.
Тогда можно сказать что любое метапрограммирование — зло. Вы не видите кода, вы видите лишь какой-то генератор, который что-то генерирует.
Конечно, лексические макросы С/С++ не подарок, это очень древнее, кривое и уже давно устаревшее решение; лучше бы были синтаксические с глубокой интеграцией в компилятор и среду разработки с возможностью REPL и просмотра сгенерированного кода, но что есть — то есть.
А макросы, которые генерируют несколько функций — вполне нормально, если это какие-то неразрывно связанные функции (ну как геттер и сеттер), и изменение кода одной неизбежно влечет изменение кода другой.
Посмотрел пример — у вас просто генерируются функции — геттеры и сеттеры. А в коде все равно приходится вызывать get_x() и set_x()
Интересно когда свойства интегрируются в язык, так чтобы они синтаксически были не отличимы от переменных.
У меня обычно нет проблем с пониманием конкретного небольшого куска кода (если только это не какой нибудь мозгодробительный трехэтажный шаблон на c++). А вот охватить более высокий уровень бывает очень сложно. Если в незнаеомом проекте сотни и тысячи файлов с исходниками, огромное число классов и функций, используются незнакомые сторонние библиотеки… тут никакие комментарии не помогут. Средств высокоуровневого структурироания и документирования кода практически нет.
Он возвращает только одно из трех значений? Как обстоят дела с "несравниваемостью"?
Например в D существует целая группа операторов сравнения, учитывающая возможность несравнимости, в частности для всяких NaN.
Все конечно хорошо, но не следует забывать про софт, который вполне может потянуть за собой много всяких библиотек (если конечно линукс нужен чтобы не просто запустить и посмотреть, а для работы). И если с консольным софтом все просто, то с GUI не все так однозначно — тут главным является desktop environment.
Вся эта борьба с мошенничеством должна делаться не через лишение пользователей возможностей, а наоборот — для каждого приложения должны быть более детальные списки разрешений, которые к тому же можно отредактровать уже после установки, и приложение не должно знать, разрешено ему что-либо или запрещено. Допустим, тот же список звонков — если приложению запретить доступ к этому списку, то оно должно видеть пустой список, как будто разрешение есть, но никаких звонков нет.
Для картинок (и gif в том числе) во всех браузерах есть встроенная в контекстное меню команда «Сохранить». Для видео почему-то нет. То есть конечно можно поставить какой нибудь плагин к браузеру (но они не всегда корректно работают). Но по умолчанию — нет.
Лично мне очень не нравится, когда у меня отнимают возможность свободно делать с контентом что угодно — в первую очередь сохранять себе на диск.
Ну мне всегда были интересны именно языки программирования. Соответственно мозг работает в этом направлении. За 15+ лет программирования, борьбы с кривизной реального кода и несовершенством компиляторов и прочих инструментов разработки накопилось множество идей, которые я старательно записывал:) Сейчас это уже репозиторий на 15 мегабайт текстовых заметок.
Автор языка молодец, довел проект хотя-бы до беты. Хотя возможно на LLVM это не так уж и сложно. А мне свой язык все никак даже толком не начать, хотя идей и материалов достаточно, пока лишь иногда структурирую документацию. В свое время начал перерабатывать компилятор D, именно потому что там все свое, включая кодогенерацию.
Это действительно так, и это действительно некрасиво с точки зрения математики. Но понятно откуда это пошло — с С++овских итераторов begin() и end(), а там end() указывает за конец коллекции, а не на последний элемент, потому что иначе не сделать итерацию коллекций нулевой длины. Вот в Swift сделали оба вида диапазонов — и закрытые, и полузакрытые. Вполне логично и удобно, наличие обоих вариантов подчеркивает разницу между ними и уменьшает путаницу. Две точки для полузакрытых, три точки для закрытых. Можно даже мнемонически запомнить — три точки больше, значит и диапазон больше (включает последний элемент).
В D вроде бы используется arr[i] для индексирования с начала и arr[$-i] для индексирования с конца. То есть внутри контекста скобок доступна длина массива в виде символа $.
Жду того, когда создадут генную терапию, при которой организм сам на клеточном уровне откорректирует оптические параметры глаза до идеального состояния.
А по поводу организации памяти (в С++) — я вообще не заморачиваюсь и как правило обхожусь и без GC, и без RC, и без OB. Просто строю архитектуру программы так, что все объекты, создаваемые через new, организованы в единое дерево; у каждого объекта есть единственный владелец, он же отвечает за удаление. Никаких передач владения нет, объект создается в конкретном месте и в этом же месте и удаляется, при этом я свободно передаю указатели на эти объекты в другие места — просто такие указатели считаются «невладеющими» и нигде не хранятся, а просто используются.
Нужна именно языковая поддержка. Не понимаю почему в С++ до сих пор не ввели. Помнится, в древнем С++Builder'е чуть ли не 98 года свойства уже были.
Конечно, лексические макросы С/С++ не подарок, это очень древнее, кривое и уже давно устаревшее решение; лучше бы были синтаксические с глубокой интеграцией в компилятор и среду разработки с возможностью REPL и просмотра сгенерированного кода, но что есть — то есть.
А макросы, которые генерируют несколько функций — вполне нормально, если это какие-то неразрывно связанные функции (ну как геттер и сеттер), и изменение кода одной неизбежно влечет изменение кода другой.
Интересно когда свойства интегрируются в язык, так чтобы они синтаксически были не отличимы от переменных.
У меня обычно нет проблем с пониманием конкретного небольшого куска кода (если только это не какой нибудь мозгодробительный трехэтажный шаблон на c++). А вот охватить более высокий уровень бывает очень сложно. Если в незнаеомом проекте сотни и тысячи файлов с исходниками, огромное число классов и функций, используются незнакомые сторонние библиотеки… тут никакие комментарии не помогут. Средств высокоуровневого структурироания и документирования кода практически нет.
Он возвращает только одно из трех значений? Как обстоят дела с "несравниваемостью"?
Например в D существует целая группа операторов сравнения, учитывающая возможность несравнимости, в частности для всяких NaN.
А где все эти категории хранятся? Какая-то база? Расширенные атрибуты файлов?
А видео для взрослых после этого разрешат? :)
Лично мне очень не нравится, когда у меня отнимают возможность свободно делать с контентом что угодно — в первую очередь сохранять себе на диск.
Или для физлиц тоже можно заполнять такую форму?