для intel процессоров — это размер регистра

но вообще, конечно, геморроя там много, например в 16-разрядной модели памяти intel используется адресация сегмент:смещение, и указатели могут быть дальние (сермент и смещение) и ближние (только смещение)

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

у меня еще один вопрос новичка - а как делать clear() для двумерного массива?

пробегаться циклом и делать remove?

а что в элементах массива лежит?

да у меня что-то даже просто с int-ами не выходит - пишет source/gui/text/textpanel.d(77,11): Error: template object.clear cannot deduce function from argument types !()(int[][]), candidates are: /Library/D/dmd/src/druntime/import/object.d(1909,6): object.clear(T : Value[Key], Value, Key)(T aa) /Library/D/dmd/src/druntime/import/object.d(1914,6): object.clear(T : Value[Key], Value, Key)(T* aa)

Я написал так: Несколько слов нужно сказать о типе size_t. Долгое время размер int совпадал с битностью микропроцессора т.е. во время господства 32-битных систем размер int был де-факто равен 32 битам. Однако с появлением 64-битных систем появилась проблема, что нужно или расширять размеры int или вводить новый тип. Для целого ряда операций было достаточно int'а равного 32 битам и так же очень не хотелось ломать обратную совместимость. Поэтому был введен новый тип под названием size_t который был привязан уже не к фиксированному числу, а к максимально возможному целочисленному типу для данной платформы. — Критикуйте

то есть массив объявляю как int[][] a;

Я написал так: Несколько слов нужно сказать о типе size_t. Долгое время размер int совпадал с битностью микропроцессора т.е. во время господства 32-битных систем размер int был де-факто равен 32 битам. Однако с появлением 64-битных систем появилась проблема, что нужно или расширять размеры int или вводить новый тип. Для целого ряда операций было достаточно int'а равного 32 битам и так же очень не хотелось ломать обратную совместимость. Поэтому был введен новый тип под названием size_t который был привязан уже не к фиксированному числу, а к максимально возможному целочисленному типу для данной платформы. — Критикуйте

не максимальный целочесленный, а всё-таки размер указателя

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

size_t это uint/ulong, ptrdiff_t - int/long

у меня еще один вопрос новичка - а как делать clear() для двумерного массива?

ты хочешь что очистить?

я хочу очистить массив от массивов (:

можно очистить сам массив массивов: a.length = 0

которые в нем есть

да, прочитал об этом, а это правильно?

короче, расставляем точки над i, в object.d есть такая штука: version(D_LP64) { alias ulong size_t; alias long ptrdiff_t; } else { alias uint size_t; alias int ptrdiff_t; }

не максимальный целочесленный, а всё-таки размер указателя

а максимальный тип получается равен максимальному размеру указателя?

да, прочитал об этом, а это правильно?

в чём сомнения?

D_LP64 — это Pointers are 64 bits

как-то непривычно и странно выглядит. и - если у меня массив массивов объектов, то они как там потом по памяти - соебер их сборщик мусора или нет (вечно беспокоюсь)?

gc жи есть ☝️

gc жи есть ☝️

да все сомневаюсь в нем (:

отпусти это и живи спокойно)

ну или не отпускай и беспокойся)

ну в простых задачах норм

@deviator просто выше же обсуждали что размер указателя зависит от компилятора %)

как-то непривычно и странно выглядит. и - если у меня массив массивов объектов, то они как там потом по памяти - соебер их сборщик мусора или нет (вечно беспокоюсь)?

Иногда GC доставляет боль, может напишу об этом в статье

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

@deviator просто выше же обсуждали что размер указателя зависит от компилятора %)

не от компилятора, а от платформы

@deviator просто выше же обсуждали что размер указателя зависит от компилятора %)

чёт я пропустил, и это вроде не совсем так. да и я не понял на какой сообщение ответ)

Иногда GC доставляет боль, может напишу об этом в статье

было бы познавательно. потому что читаю переводную прессу, вроде бы понятно, но все равно сомнения порой терзают

не от компилятора, а от платформы

https://www.viva64.com/ru/k/0044/ "размер указателя зависит от конкретной реализации компилятора и не связан напрямую с разрядностью используемой платформы"

так мы ж про Ди

а тут все иначе?

а тут все иначе?

"кто как хочет, так и д..."

делает

Теоретически я могу представить что компилятор с++ эмулирует 64битный указатель на 32битной платформе

делает

да

Чтобы сохранять совместимость.

?

Чтобы сохранять совместимость.

какая-то странная теория

совместимость чего с чем?

короче, конкретно в D size_t и ptrdiff_t зависит от размера указателя платформы, так написано в object.d, я выше кинул)

Чтобы говнокодеры могли хардкодить 64битные адреса и это работало бы на 32 битах )

старого 64 битного кода с новой 32битной платформой, которая умеет в 64-битные указатели?

https://dlang.org/spec/type.html#size_t

Чтобы говнокодеры могли хардкодить 64битные адреса и это работало бы на 32 битах )

брррр жесть какая

Или более человечный вариант - когда на 32битной платформе надо скомпилировать 64битный код

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

"type that is large enough to represent an offset into all addressible memory" т.е. максимально возможные размер смещения?

да

адрес это и есть смещение

но только положительные

Опубликовал свою NodeJS-поделку. В первом раунде у неё было 558 секунд, во втором померла из-за ограничений по памяти на ноду (1.4 гига), о которых я не знал. Было понятно, куда доделывать, но не успел - а сейчас уже не интересно. Там особенного ничего наверное нет, но если у кого-то результат был хуже, то можно подглядеть, как работало у меня. Спасибо за конкурс ? https://github.com/oleggromov/hlc2017

Кстати если бы я шел в решении не от навороченных фреймворков к простым решениям а наоборот, может и повыше место занял бы :)

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

там командой можно было участвовать?

Нет конкурс одиночный

Можно было поучаствовать командой, но никому не сказать. :)

Интересный тред пошел https://www.linux.org.ru/news/development/13651713/page8?lastmod=1504599904979#comment-13659347

Я читал что в в Go указатели какие-то обрезанные. Вопрос. В чем их обрезанность?

Они Евреи))) (без обид, просто не сдержался)

в Go нет адресной арифметики

тоесть указатели там полноценные?

ERROR: S client not available

т.е. можно объявить указатель, получить указатель на переменную (&) и разыменовать его

Но я к примеру не могу сделать +1 к указателю?

да

а где адресная арифметика бывает полезна?

это штука опасная)

ну, скажем, в Си массив — это просто указатель на его начало, соответственно, по массиву можно пройтись, просто увеличивая значение указателя)

строки так удобно обрабатывать, потому что они в Си заканчиваются нулем, и возможны такие конструкции: void processString(char *str) { char *s = str; do { //do something with string } while(*(++s) != 0); }

а где адресная арифметика бывает полезна?

Не в D )

Не в D )

в плане?

Кстати, а как понять какие функции можно в режиме betterC использовать, а какие нет? к примеру canFind в betterC не работает

Я же вроде говорил, что на d не сталкивался с необходимостью её где либо использовать

Кстати, а как понять какие функции можно в режиме betterC использовать, а какие нет? к примеру canFind в betterC не работает

Как я понял только пробовать

ну и сразу можно отбросить все, что работает с GC

а как по ним понять то что они его юзают?

вот, кстати betterC — это тот случай, когда в D может пригодиться адресная арифметика)

а как по ним понять то что они его юзают?

как минимум все, что принимает на вход или возвращает динамические массивы и объекты)

я же правильно понимаю, что betterC — это D с отключенным GC?

я же правильно понимаю, что betterC — это D с отключенным GC?

Не только

ну и с вырезанным D рантаймом за ненадобностью

Ну да

Знаю только mir, из тех что используют betterC

а где адресная арифметика бывает полезна?

Где нет gc, где ветер в поле

Кстати, а как понять какие функции можно в режиме betterC использовать, а какие нет? к примеру canFind в betterC не работает

Там в спеке написано, что именно не работает в режиме betterC

ну и с вырезанным D рантаймом за ненадобностью

Не полностью вырезанным, к сожалению. Пилю ось на D и так я долго возился с этим рантаймом, шописец

Там в спеке написано, что именно не работает в режиме betterC

Что не работает, но не написано какая часть std работает

Что не работает, но не написано какая часть std работает

Никакая, считай. Стд - фобос

Ну не весь

Что-то из core может работать

я вот сейчас читаю, вроде, в BetterC можно юзать замыкания, а они используют GC вроде как

в смысле, делегаты

Всё что с метапрограммированием должно работать