Указание определенного адреса памяти для указателя

@BlackStoneBlack · Регистрация: 10.05.2016

Студворк — интернет-сервис помощи студентам

Добрый день всем. Сидел, баловался с памятью и вдруг задумался: а можно ли указатель определять на конкретный адрес? Чтобы было понятнее, вот примерный простенький код:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <iostream>
using namespace std;
 
template<class Type>
struct Node
{
    Node<Type>* next = nullptr;
    Type* value = nullptr;
};
 
int main()
{
    Node<int>* list = new Node<int>();
    list->value = new int(1);
    list->next = list + 1;
    list->next->value = new int(80);
 
    cout << list << "\t" << *(list->value) << "\t" << list->next << "\t" << *(list->next->value) << endl;
 
    return 0;
}

По сути, если такой код можно считать безопасным, то следующим шагом было бы определение класса List, в котором перегружался бы оператор [], т.е. к элементам списка можно было бы обращаться по индексу:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
template<class Type>
class List
{
public:
 
    /* <...> */
    
    Type& operator[] (const size_t index)
    {
        return *(list + index);
    }
 
    void add(const Type& element)
    {
        Node<Type>* temp = list + size - 1;
        temp->next = temp + 1;
        *(temp->next->value) = element;
        size++;
    }
 
    /* <...> */
 
private:
 
    Node<Type> list;
 
    size_t size = 0;
}

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

@Zirak · 29.10.2020, 20:08

Ты пытаешься из списка сделать массив. Зачем?

@_stanislav · 29.10.2020, 20:14

Сообщение от BlackStoneBlack

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

менеджер кучи кто в известность поставит что ты по адресу list + 1 разместил int(80), так делать нельзя

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

Добавлено через 1 минуту

Сообщение от BlackStoneBlack

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

загугленно

@BlackStoneBlack · 29.10.2020, 20:48 **[ТС]**

Сообщение от Zirak

Ты пытаешься из списка сделать массив. Зачем?

Например, банальное ускорение работы со списком. В том же C# в типе List переопределен оператор [] и есть свойсво Count, возвращающее количество элементов. Но вообще, это просто интерес.

Сообщение от _stanislav

менеджер кучи кто в известность поставит что ты по адресу list + 1 разместил int(80), так делать нельзя

Вот именно поэтому у меня и были сомнения по этому поводу.

Сообщение от _stanislav

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

Да, я уже примерно стал доходить до этого.

Сообщение от _stanislav

загугленно

Спасибо, понял, в каком направлении копать.

@TheCalligrapher · 29.10.2020, 20:55

Сообщение от BlackStoneBlack

Чтобы было понятнее, вот примерный простенький код:

Совершенно не стало понятнее, при чем здесь "указатель на конкретный адрес".

Сообщение от BlackStoneBlack

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

Нет, разумеется. В коде написана полная бессмыслица:

C++
1
2
3
4
    Node<int>* list = new Node<int>();
    list->value = new int(1);
    list->next = list + 1;
    list->next->value = new int(80);

Кто вам разрешил лезть в list + 1? Там нет памяти.

@Zirak · 29.10.2020, 21:08

Сообщение от BlackStoneBlack

В том же C# в типе List переопределен оператор []

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

@BlackStoneBlack · 29.10.2020, 21:29 **[ТС]**

Сообщение от Zirak

Я почти на 100% уверен, что там просто нужное количество раз переходится по next

Возможно, я исходники там не ковырял.

Сообщение от Zirak

Конечно, можно завести дополнительный ассоциативный массив, где ключ это индекс, а значение - нужный указатель. Но с таким подходом уже и список не нужен.

Да, согласен. Хотя с изменением размера массива уже не все так хорошо, как хотелось бы. Хотя и существует тот же класс vector. Надо будет пошариться в его исходниках

IGPIGP · 30.10.2020, 00:08

Сообщение от Zirak

Я почти на 100% уверен, что там просто нужное количество раз переходится по next.

https://docs.microsoft.com/en-... etcore-3.1
То есть, этот список не совсем список. Совсем не список, вернее. Это массив в динамической памяти. Если я правильно понял, о каком списке в шарпе идёт речь.

Добавлено через 5 минут
О более новом List<T> из System.Collections.Generic
https://docs.microsoft.com/en-... etcore-3.1
они пишут похожее нечто:

Сообщение от MS cave

Remarks

The List<T> class is the generic equivalent of the ArrayList class. It implements the IList<T> generic interface by using an array whose size is dynamically increased as required.

@Annemesski · 30.10.2020, 11:42

Сообщение от BlackStoneBlack

Например, банальное ускорение работы со списком

Это не ускорение работы со списком, а создание помеси бульдога с носорогом - зачем?

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

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

Если же так велико желание получить преимущества обоих вариантов, то более верным подходом будет использование чего-то одного, а в случаях когда будут уместны преимущества второго построить это второе на основе первого. Например: в некоем приложении работаете со списком поскольку в основном требуется последовательный доступ, но возникает ситуация когда требуется многократно выполнить серию операций требующих произвольного доступа, тогда выпускаете на основе списка массив указателей на его элементы и выполняете обработку - по мере надобности массив можно уничтожать и выпускать заново.

@Zirak · 30.10.2020, 20:40

Сообщение от Annemesski

Суть списка - последовательный доступ к элементам и в этом разрезе список работает быстрее массива

Это очень сильное заявление. Навскидку, разыменовывание стоит заметно дороже одной операция сложения.

@TheCalligrapher · 30.10.2020, 20:52

Сообщение от Annemesski

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

Что за невероятная феерическая белиберда?

Вычисление следующего адреса в массиве - на порядки (!) более легкая и эффективная операция, чем тяжеленное чтение готового значения указателя на следующий элемент из памяти.

Более того, последовательный доступ к массиву астрономически боле эффективен еще и потому, что элементы массива гарантированно расположены один за другим в памяти, что делает массив идеальной кэш-дружественной структурой данных. Для списка этого не гарантируется, что в общем случае просто убивает эффективность последовательного прохода по списку.

Сообщение от Annemesski

Например: большинство алгоритмов сортировки для списка будут быстрее чем для массива,

В реальности же все наоборот.

IGPIGP · 30.10.2020, 21:31

Annemesski, не горюйте. Список видит своих защитников) Мы им ответим. Так вот например:
Сколько список не корми, а у него итераторы всегда валидны.То есть: Удаляй не удаляй, а всё равно получишь - валидный итератор.
Но нельзя путать лист с шарпом. У них ilist не лист ienumerable не 'энумерабле. Крибле- крабле и те списки, что ArrayList и List<T> на поверку массивы (внутренне). Это наверное, чтобы ни кто не догадался. А списки у них живут во в таких местах:
https://docs.microsoft.com/en-... etcore-3.1
LinkedList<T> - о -как !

IGPIGP · 30.10.2020, 21:45

del дубликат

@Annemesski · 30.10.2020, 21:55

TheCalligrapher, TheCalligrapher, как на счет вычисления и разыменования? Или в массивах указатели разыменовывать не надо?

@TheCalligrapher · 30.10.2020, 22:32

Сообщение от Annemesski

как на счет вычисления и разыменования? Или в массивах указатели разыменовывать не надо?

1. "Разыменование"? Разыменование, что есть чтение (или запись) полезного значения элемента из памяти присутствует в одинаковой мере и в массиве, и в списке. То есть в общем итоге в массиве такое разыменование одно, а в списке их два. Замечаете разницу?

Однако, еще раз, как я сказал выше, в массиве разыменование в общем случае намного более эффективно, ибо массив лежит в памяти последовательно, т.е. обладает идеальнейше дружественным поведением по отношению к процессорному кэшу и к механизмам prefetch. А это один из самых важных факторов эффективности.

2. "Вычисления"? Я же ясно сказал выше: вычисление адреса элемента массива - на порядки более эффективная операция, чем чтение указателя из памяти.

@Annemesski · 30.10.2020, 23:05

Сообщение от TheCalligrapher

вычисление адреса элемента массива - на порядки более эффективная операция

с этим я и не спорил

Сообщение от TheCalligrapher

а в списке их два.

посыпаю голову пеплом.

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

ПС: Ок, лучший ответ снимаю.

IGPIGP · 31.10.2020, 00:58

Сообщение от Annemesski

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

Не только. И возможно даже не столько. Список хорош стабильностью итераторов. Кроме того, он хорош возможностью выделения памяти по-элементно. Это и слабость и сила. Например, в случае реализации цепочек (backets) для хеш-таблиц, есть предположение (надежда), что коллизий не должно быть много, но тем не менее не известно в каком месте возможно сильное отклонение от среднего. Тут сочетание экономности и медлительности вполне оправдано. И еще важен случай, когда список может разворачиваться в тип элемента. В языке JAM строка - основной тип и списки строк - основной контейнер. Гибкость этого языка поразительна.

Новые блоги и статьи Все статьи Все блоги /
Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .	Изучаю kubernetes lagorue 13.01.2026 А пригодятся-ли мне знания kubernetes в России?	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .
Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .

Указание определенного адреса памяти для указателя

Решение

Решение

@Zirak 76 / 68 / 10 Регистрация: 11.07.2016 Сообщений: 320
	29.10.2020, 20:08
	Ты пытаешься из списка сделать массив. Зачем? 0

IGPIGP Комп_Оратор) $Эксперт по математике/физике$ 9005 / 4706 / 630 Регистрация: 04.12.2011 Сообщений: 14,003 Записей в блоге: 16
	30.10.2020, 21:31
	Annemesski, не горюйте. Список видит своих защитников) Мы им ответим. Так вот например: Сколько список не корми, а у него итераторы всегда валидны.То есть: Удаляй не удаляй, а всё равно получишь - валидный итератор. Но нельзя путать лист с шарпом. У них ilist не лист ienumerable не 'энумерабле. Крибле- крабле и те списки, что ArrayList и List<T> на поверку массивы (внутренне). Это наверное, чтобы ни кто не догадался. А списки у них живут во в таких местах: https://docs.microsoft.com/en-... etcore-3.1 `LinkedList<T>` - о -как ! 0

IGPIGP Комп_Оратор) $Эксперт по математике/физике$ 9005 / 4706 / 630 Регистрация: 04.12.2011 Сообщений: 14,003 Записей в блоге: 16
	30.10.2020, 21:45
	del дубликат 0

@Annemesski 2670 / 1333 / 479 Регистрация: 08.11.2016 Сообщений: 3,683
	30.10.2020, 21:55
	TheCalligrapher, TheCalligrapher, как на счет вычисления и разыменования? Или в массивах указатели разыменовывать не надо? 0