а указатели обязательно ининтить через null при объявлении?

в D, по-моему, нет

ну я вот тоже поичтал мануалы - вроде как при объявлении переменных их ининтить нулем не нужно. а сегодня наткнулся вот на что: It is always a good practice to assign the pointer NULL to a pointer variable in case you do not have exact address to be assigned. This is done at the time of variable declaration. A pointer that is assigned null is called a null pointer.

компилятор сам должен следить за инициализацией

https://www.tutorialspoint.com/d_programming/d_programming_pointers.htm

предлагаю написать тестовую программу: объявить указатель и посмотреть, будет ли он null)

в D должен быть

(:

вроде должен

да, пишет, что null

стало быть автор статьи перестраховывается

традиция такая у тех, кто имел дело с Си, потому что там переменные не инициализируются)

лучше перебдеть, чем недобдеть

у меня тоже прямо руки чещутся null вписать везде

(:

как-то надежнее выглядит просто так, со стороны глядя.

в случае с D есть все что надо для того, чтоб null вообще не было в коде

ну в методах же надо порой вставлять

можно пойти дальше, в случае с D есть все для того, чтобы не пользоваться указателями)

а структуры укак же?

можно пойти дальше, в случае с D есть все для того, чтобы не пользоваться указателями)

а почему нет?

а структуры укак же?

ref?

нет что?)

ref для меня лично не сильно очевиден

есть действительно все что надо для того, чтоб не пользоваться указателями

я про это и говорю

я его понимаю пока как алиас для & но наверняка ошибаюсь, глубоко еще не читал

я про это и говорю

я подумал, что это сарказм. Прошу прощения

я его понимаю пока как алиас для & но наверняка ошибаюсь, глубоко еще не читал

в таком случае лучше рассматривать ref как указатель, который всегда указывает на конкретную область памяти)

ну а массив структур - тоже без указателей городить?

да

непривычно (:

а где вообще в массив структур можно воткнуть указатель?)

я имею в виду нечто, как в С++, struct a; std::vector <a*> array; array.push_back(new a() );

в D это будет просто a[] arr; arr ~= a();

Только в примере на С++ это не массив структур, а массив указателей на структуры. В массиве структур они последовательно лежат одна за другой, как в примере на D, а в примере Андрея структуры будут раскиданы по памяти фиг знает как, а в массиве один за другим будут лежать указатели на них. Оба варианта имеют смысл, у каждого свои достоинства и проблемы.

тут еще нужно помнить, что структуры в D создаются на стеке)

Только в примере на С++ это не массив структур, а массив указателей на структуры. В массиве структур они последовательно лежат одна за другой, как в примере на D, а в примере Андрея структуры будут раскиданы по памяти фиг знает как, а в массиве один за другим будут лежать указатели на них. Оба варианта имеют смысл, у каждого свои достоинства и проблемы.

да, массив указателей, наструктуры, поспешил с названием

имеет ли смысл тогда на D вовсе обходить стороной указатели?

имеет смысл везде обходить указатели

У меня такой вопрос назрел. Никто не поверял, прокатывает ли в D хак, подобный C++, когда помечаешь метод как final, и компилятор перестает искать его в таблице виртуальных методов?

в спецификации такое указано, но я не проверял

имеет ли смысл тогда на D вовсе обходить стороной указатели?

Я бы сказал действовать по ситуации. Если напрашивается указатель и ref плохо подходит почему-то - используем указатель.

Про final методы: почему ж это хак? Это их назначение, практически, классическая оптимизация.

Я бы сказал действовать по ситуации. Если напрашивается указатель и ref плохо подходит почему-то - используем указатель.

у меня просто представление такое, С++-ное, наверное, когда создаешь нечто типа myClass* a = new myClass(); а потом указатели хранишь по массивам и что надо, то и делаешь. в D я пока в голове не сложил, как лучше делать и поэтому мешаю в кучу то ref, то указатели, а еще и классы сразу являются ссылками. потому путаюсь.

В D классы и структуры — это разные вещи)

это я заметил (:

ну, собственно, из этого и вытекает ненужность указателей)

вместо хранения массива указателей на структуры можно использовать массив классов)

ну или тех же ссылок на структуры)

или даже самих структур)

Да, в таких случаях (а они очень часты) достаточно просто классов, там указатели уже убраны под капот.

но тут нас поджидает другой сюрприз: если нам нужен гарантированный деструктор при выходе из области видимости, то придется использовать структуры)

но тут нас поджидает другой сюрприз: если нам нужен гарантированный деструктор при выходе из области видимости, то придется использовать структуры)

scoped можно использовать

получается так, что то, что я лепил в С++ внутри класса как class myClass{ classTwo* class2; } можно писать без звезды. и передача в фнукцию, например, тоже пойдет без указателя, а просто, типа, foo(myClass class)

scoped можно использовать

да, и он просто обернет класс в структуру с деструктором)

да, и он просто обернет класс в структуру с деструктором)

Но все же внешне это класс

Хотя на самом деле структура

но тут нас поджидает другой сюрприз: если нам нужен гарантированный деструктор при выходе из области видимости, то придется использовать структуры)

вот, честно говоря, когда только-только начал изучать D, дцумал, что таких сюрпризов не будет (: теперь же на все готов применять destroy

да, и он просто обернет класс в структуру с деструктором)

вот оно как. почитаю об этом.

вот, честно говоря, когда только-только начал изучать D, дцумал, что таких сюрпризов не будет (: теперь же на все готов применять destroy

ну это проблема любого языка со сборкой мусора

да просто я как думаю, по-деревенски, если все равно есть проблемы и тонкости по уборке, то что new/delete в С++ что нюансы с GC - jlby xjhn

один чорт то есть (:

сборка мусора гарантированно позволяет избежать ошибок программиста, связанных с утечкой памяти

ну вот внутри у меня в классе будут С-функции, которые с памятью работаю по-своему. и за ними надо следить.

но за это приходится платить оверхедом сборщика мусора и несколько бОльшим потреблением памяти

ну вот внутри у меня в классе будут С-функции, которые с памятью работаю по-своему. и за ними надо следить.

а зачем они там будут?

ERROR: S client not available

и потому мои небольшие ожидания, что можно немного расслабиться, идут прахом (:

ну библиотека какая-нибудь, например, SDL2

или allegro5

собственно, обертки над такими делами делаются, со всех сторон обкладываются тестами, и дальше используются именно обертки)

именно для того, чтобы не тянуть C-функции работы с памятью в остальной проект

магии, увы, не существует)

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

да по-разному, я подозреваю)

(:

я так понимаю, если функции сишные в бинде имеют nogc и nothrow то по-любому придется самому суетиться?

nogc и nothrow — это всего лишь подсказки компилятору, что внутри функции не будет операций, которые приводят к сборке мусора и ничто не выкинет исключение

а если в бинде функции сишные, то суетиться в любом случае придется

ну что ж - так тому и быть. спасибо за объяснения.

У меня вопрос по диапазонам. Есть ли понятие ленивые диапазоны?

они все вроде как ленивые должны быть

по возможности, конечно

ну если явно их не превратить во что-то

так они ленивые

а как работает метод .array который преобразует диапазон в простой массив

собирает все в кучу и возвращает массив

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

ага

а если у диапазона нет конца, будет ой

и если быть точным, .array — это не метод, а шаблон, объявленный в std.array, который для любого Range возвращает динамический массив типа ForeachType!Range[]

внутри он работает как appender

Олег https://2r4s9p1yi1fa2jd7j43zph8r-wpengine.netdna-ssl.com/files/2017/09/websight.gif

ссылки есть только в параметрах функций

вот еще вопрос по наследованию. есть родительский класс со свойством int a; чтобы это свойство увидеть в наследнике, надо обязательно в родительском оформить,например, @property int a(){} ?

просто используй а

оно видно в наследнике если оно public и protected

а. у меня private, потому и не дает, наверное

понятно