Аа, понял

В целом если замыканий нет, то this.outer равен null, то есть компилятор достаточно умен. чтобы не захватывать контекст

но накой он вообще создает поле this.outer?

впрочем это такой мелкий оверхед, что можно не парится, но лучше static вставить

Одним полем меньше?

ага, ну и защита от ошибки. мало ли случайно замыкание сделаешь :)

Короткое замыкание причем

аж искрит

ага, эдакий костыль

Это не костыль, далеко не костыль. Дружественные функции, к примеру, довольно полезны при перегрузки бинарных операций (<<, >>, +, -, etc.) и при написании юнит-тестов. Если примеров мало, то другие можешь посмотреть в книге Бьёрна Страуструпа "Язык программирования С++".

Это не костыль, далеко не костыль. Дружественные функции, к примеру, довольно полезны при перегрузки бинарных операций (<<, >>, +, -, etc.) и при написании юнит-тестов. Если примеров мало, то другие можешь посмотреть в книге Бьёрна Страуструпа "Язык программирования С++".

В плюсах да

местами без них трудно

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

реальные костыли тоже очень полезны... для инвалидов. но лучше все же когда они не нужны, верно?

Давай мы не будем устраивать холивар на эту тему, хорошо?

Давай мы не будем устраивать холивар на эту тему, хорошо?

это не холивар. не надо путать полезность и костыльность

костыли полезны почти всегда

Меня сначала обескуражила иная система приватности после перехода с плюсов на D. Но стоило немного подумать и стало очевидно, что так намного лучше. Наконец-то никаких дебильных френд-функций

Кстати, "Язык программирования С++" сильно устарела. Я по ней учил C++ на первом курсе, в 1995 году

По мне так Страуструп ваще не авторитет

Не, он авторитет. В С++. А у нас тут D, так что тут он не авторитет

Но вообще, соглашусь с Eugene: костыльность это одно, а полезность это другое. И это даже не взаимоисключающие понятия

Не, он авторитет. В С++. А у нас тут D, так что тут он не авторитет

Ну, лично для меня, он и в C++ не авторитет.

Ну, лично для меня, он и в C++ не авторитет.

А кто для тебя авторитет тогда?

Для меня особо авторитетов нет, я стараюсь сам анализировать инфу. В C++ прислушиваюсь к Саттеру и Мейерсу, немножко к Александреску.

Страуструпа уважаю как создателя C++, но его взгляды на развитие C++ мне представляются несколько старперскими.

например, он зарезал static if

но это мой личный взгляд, я никому его не навязываю.

Страуструпа уважаю как создателя C++, но его взгляды на развитие C++ мне представляются несколько старперскими.

Мне тоже. Вообще, плюсы на мой взгляд, едут в дальнейшее усложнение языка, а не его элегантности, выразительности и простоты

тривиальный конструктор или таки конструктор по-умолчанию?

Я имел ввиду конструктор без аргументов. В моём понимании конструкторы по умолчанию — это не только конструктор без аргументов (тривиальный), но и копирующий конструктор и конструктор переноса (на знаю есть ли он в D)

Почему так думаешь?

Ну самый простой способ выяснить баг это или выпилилил из языка

Потому что T.init должно быть известно во время компиляции без исполнения дополнительного кода. (Если правильно помню.)

Это не оправдыывает запрет на конструктор без аргументов. Например struct A { void * _ptr = null; ... } Значение для инициализации определено. Но я не могу определить конструктор, для того что бы присвоить _ptr какое то осмысленное значение. По-моему нелогично.

Это не оправдыывает запрет на конструктор без аргументов. Например struct A { void * _ptr = null; ... } Значение для инициализации определено. Но я не могу определить конструктор, для того что бы присвоить _ptr какое то осмысленное значение. По-моему нелогично.

Т.е. структура даже во время компиляции должна ссылаться на что-то?

возможно тут работает логика что .init и дефолтный конструктор должны иметь одно и то-же поведение и следовательно достаточно .init

Т.е. структура даже во время компиляции должна ссылаться на что-то?

Не понял вопрос. В моём примере у указателья есть значение во время компиляции: нулевой указатель. Потом в конструкторе я хотел бы переопределить одно из полей. Не вижу проблем.

возможно тут работает логика что .init и дефолтный конструктор должны иметь одно и то-же поведение и следовательно достаточно .init

Ну может. Но всё равно так себе решение.

Вот тут нашёл решение: https://forum.dlang.org/post/ealzckbomansfskupdoj@forum.dlang.org предлагают создать класс и разместить его на стеке. С помощью шаблона scoped

Не понял вопрос. В моём примере у указателья есть значение во время компиляции: нулевой указатель. Потом в конструкторе я хотел бы переопределить одно из полей. Не вижу проблем.

В default конструкторе? На что же он будет ссылаться? ИМХО, это всё лишнее.

Вот тут нашёл решение: https://forum.dlang.org/post/ealzckbomansfskupdoj@forum.dlang.org предлагают создать класс и разместить его на стеке. С помощью шаблона scoped

А это вообще изврат.

Так можно же при объявлении структуры проинициализировать ее поля

S mystruct = {a:6}

Так можно же при объявлении структуры проинициализировать ее поля

Сейчас напишу пример, что бы было понятно

У меня где то в коде на С или С++ есть функции для создания/удаления и манипулирования объектом. я хочу их обернуть в коде на D вот так private extern (C) { void * make_a(); void del_a(void *a); void a_meth(void *a); } struct A { private: void *_ptr; public: this() { _ptr = make_a(); } ~this() { del_a(_ptr); } void meth() { _ptr.a_meth(); } }

Вот так не скомпилится: struct A { void *_ptr = make_a(); ... }

init() добавить.

А из-за этого странного ограничения я вынужден делать так: private class A { private: void *_ptr; public: this() { _ptr = make_a(); } ~this() { del_a(_ptr); } void meth() { _ptr.a_meth(); } } public alias DA = scoped!A;

init() добавить.

Не, костыль же.

Это один из тех случаев, когда приходя в новый язык, люди приносят с собой свои старые подходы.

Это один из тех случаев, когда приходя в новый язык, люди приносят с собой свои старые подходы.

Ну может быть. Не спорю, что не постиг ещё все особенности языка :) Но init() выглядит ещё большим костылём чем scoped

Ну может быть. Не спорю, что не постиг ещё все особенности языка :) Но init() выглядит ещё большим костылём чем scoped

А для меня наоборот.

Засоряет клиентский код.

А scoped что делает?

А scoped что делает?

https://dlang.org/library/std/typecons/scoped.html

Да я помню мне как то это понадобилось. Но вроде я легко обошел.

А scoped что делает?

На стеке аллоцирует класс

Да я помню мне как то это понадобилось. Но вроде я легко обошел.

Поделись лёгким способом :)

Уже забыл :) но, вроде я что то типа фабрики сделал

Функция которая возвращает подготовленную структуру

Уже забыл :) но, вроде я что то типа фабрики сделал

Ну это опять init будет :)

Засоряет клиентский код.

Это всё субъективно. Вы гонитесь за тем, что.. важно ли?

Это всё субъективно. Вы гонитесь за тем, что.. важно ли?

Тут уж все зависит от задач. Трудно написать "быстро, дешево и хорошо"(с)

Это всё субъективно. Вы гонитесь за тем, что.. важно ли?

Люблю когда в клиентском коде все прозрачно и предсказуемо. А init() — это дополнительные соглашения. Объекты моей структуры надо создавать не как обычно, а через статическую функцию. Код загрязняется. Можно так делать, но не элегантно.

Аллоцировать класс на стеке может быть небезопастно, не?

О, начали сворачивать внутри std в доках. Удобнее стало

Аллоцировать класс на стеке может быть небезопастно, не?

Вот не знаю как она внутри устроена. Но я думаю там что-то вроде placement new т.е. вполне безопасно

Вот не знаю как она внутри устроена. Но я думаю там что-то вроде placement new т.е. вполне безопасно

В доках пишут "unsafe", так что у меня сомнения

В доках пишут "unsafe", так что у меня сомнения

щас посмотрю исходники :)

Люблю когда в клиентском коде все прозрачно и предсказуемо. А init() — это дополнительные соглашения. Объекты моей структуры надо создавать не как обычно, а через статическую функцию. Код загрязняется. Можно так делать, но не элегантно.

Прозрачно и предсказуемо. Но в то же время вы скрываете операции в конструкторах по умолчанию. Т.е. другим разработчикам нужно обязательно знать конструкторы в каждом типе, иначе для них код не прозрачен.

Лично я бы сделал выбор в лишнее соглашение, чем рисковал бы вылетами

О, 2.079 вышла

Интересно, где можно прочитать чейнджлог?

https://dlang.org/changelog/2.079.0.html

Прозрачно и предсказуемо. Но в то же время вы скрываете операции в конструкторах по умолчанию. Т.е. другим разработчикам нужно обязательно знать конструкторы в каждом типе, иначе для них код не прозрачен.

Так зачем им знать что там в конструкторе длеается? Библиотечный код предоставляет интерфейс, клиентский код его использует. А детали реализации клиентского кода не касаются.

о, @nogc исключения подвезли, отлично)

круто!

Я привык искать чейнджлог на гитхабе :D

Так зачем им знать что там в конструкторе длеается? Библиотечный код предоставляет интерфейс, клиентский код его использует. А детали реализации клиентского кода не касаются.

Ну мало ли закон нарушают

Так зачем им знать что там в конструкторе длеается? Библиотечный код предоставляет интерфейс, клиентский код его использует. А детали реализации клиентского кода не касаются.

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

Меньше времени где? В разработке или в рантайме?

Я имел ввиду конструктор без аргументов. В моём понимании конструкторы по умолчанию — это не только конструктор без аргументов (тривиальный), но и копирующий конструктор и конструктор переноса (на знаю есть ли он в D)

Конструктор без параметров и конструктор по умолчанию - это одно и то же. Тривиальный конструктор, в терминах C++ - это конструктор, который ничего не делает. Конструктор без параметров (по умолчанию) может быть как тривиальным, так и нетривиальным.

В C++ классы могут быть PODами, а могут и не быть. В D структуры - это всегда POD-ы, поэтому они не могут иметь нетривиальных конструкторов по умолчанию и конструкторов копирования.

а также виртуальных методов.

Компилятор может перемещать (move) структуры тупым memcpy не вызывая вообще никаких методов.

В С++ и структуры POD'ы

В С++ и структуры POD'ы

Нет. В C++ структуры - это классы с видимостью членов по умолчанию public. больше они ничем от классов не отличаются.

Т.е. они могут содержать методы?

О.о

Получается, что да

Кажется я больше писал на С, чем на С++

Даже не знаю, радоваться или грустить

Т.е. они могут содержать методы?

они могут все, вплоть до наследования и виртуальных методов.

Нда

В чем смысл структуры тогда

В чем смысл структуры тогда

Ни в чем, для совместимости с C оставили.

Я всю свою жизнь жил в неведении

бывает

многие ли из вас знают, что в D можно вот так делать? https://glot.io/snippets/eyty1bffd6

В мануале про структуры D есть сравнительнач таблица т про c++ тоже