Russian Qt Forum
Ноябрь 24, 2024, 03:01 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 ... 3 4 [5] 6 7   Вниз
  Печать  
Автор Тема: как правильней писать указатель?  (Прочитано 42170 раз)
brankovic
Гость
« Ответ #60 : Февраль 16, 2011, 22:50 »

CChunkArray -- дека, только самодельная. А CChunkList, CSimpleList - вообще в stl/boost есть..

Edit: и все трое игнорируют конструкторы, что делает их юзабельными только для интов..
« Последнее редактирование: Февраль 16, 2011, 22:52 от brankovic » Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #61 : Февраль 17, 2011, 11:48 »

Дека значит deque, правильно? А Вы его щупали или просто так, хелп читали?  Улыбающийся
Прошу пояснить сколько элементов deque держит в одой "пачке" (подмассиве). Если стандартом это не оговаривается, на конкретной реализации популярного компилятора - напр MSVC2008 (который я обойти никак не могу).

Спасибо
Записан
BRE
Гость
« Ответ #62 : Февраль 17, 2011, 12:14 »

Дека значит deque, правильно?
Ага.

А Вы его щупали...
Щупать деки???!!! Фуууу.

... или просто так, хелп читали?  Улыбающийся
Не знаю как остальные, но я хелп не читал, мне соседка во дворе рассказывала.

Прошу пояснить сколько элементов deque держит в одой "пачке" (подмассиве). Если стандартом это не оговаривается, на конкретной реализации популярного компилятора - напр MSVC2008 (который я обойти никак не могу).
Когда ты придумывал свой дек, тебя этот вопрос почему-то не особо интересовал. Что поменялось?  Подмигивающий
Записан
brankovic
Гость
« Ответ #63 : Февраль 17, 2011, 13:04 »

Прошу пояснить сколько элементов deque держит в одой "пачке" (подмассиве). Если стандартом это не оговаривается, на конкретной реализации популярного компилятора - напр MSVC2008 (который я обойти никак не могу).

Стандартом не оговаривается. В gcc 512 * sizeof (T), но можно настроить. Кстати, в бусте может есть более гибкий вариант.

Edit: наврал, размер max (sizeof (T), 512), т.е. если sizeof (T) > 512, то в каждом чанке по одному элементу Грустный

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

Да, но Igors выбирает размер исходя из размера системных страниц памяти. Это правильная экономия, в противовес мнимой экономии на последнем кусочке. При больших объёмах данных это имеет смысл.

Благодаря этому комменту наконец понял, что хотел сказать Igors: дека при больших объёмах неоптимально распределяет память и это нельзя настроить. (в смысле надеюсь, что понял Улыбающийся)
« Последнее редактирование: Февраль 17, 2011, 13:17 от brankovic » Записан
BRE
Гость
« Ответ #64 : Февраль 17, 2011, 13:13 »

Да, но Igors выбирает размер исходя из размера системных страниц памяти. Это правильная экономия, в противовес мнимой экономии на последнем кусочке. При больших объёмах данных это имеет смысл.
Давайте обсудим эту правильную экономию.
В чем она заключается и причем здесь размер системных страниц памяти?
Записан
BRE
Гость
« Ответ #65 : Февраль 17, 2011, 13:27 »

Edit: наврал, размер max (sizeof (T), 512), т.е. если sizeof (T) > 512, то в каждом чанке по одному элементу Грустный
Строит глазки
А что тебя так расстроило?  Подмигивающий
Возьми любой свой проект и попробуй найти классы, объекты который > 512 байт и они хранятся у тебя в огромных количествах.
Записан
brankovic
Гость
« Ответ #66 : Февраль 17, 2011, 13:33 »

Да, но Igors выбирает размер исходя из размера системных страниц памяти. Это правильная экономия, в противовес мнимой экономии на последнем кусочке. При больших объёмах данных это имеет смысл.
Давайте обсудим эту правильную экономию.
В чем она заключается и причем здесь размер системных страниц памяти?

Захват больших кусков памяти маллок осуществляет напрямую у системы (mmap на линукс, на винде virtualalloc или что-то такое). Поэтому любой большой кусок кратен размеру страницы. Память в хвосте этого куска не вернётся при других маллоках и никогда не используется. Пример: вызвали malloc (40961), система выделила round_up (40961 / 4096) = 11 страниц по 4096, последняя страница содержит полезный 1 байт, остальное никогда не используется, пока не вернётся системе по вызову free.
Записан
brankovic
Гость
« Ответ #67 : Февраль 17, 2011, 13:37 »

Edit: наврал, размер max (sizeof (T), 512), т.е. если sizeof (T) > 512, то в каждом чанке по одному элементу Грустный
Строит глазки
А что тебя так расстроило?  Подмигивающий
Возьми любой свой проект и попробуй найти классы, объекты который > 512 байт и они хранятся у тебя в огромных количествах.


Расстроил очередной подводный камушек о котором я не знал. А деки я практически не использую, не нужны обычно, Кроме того у Igors явно используется для POD-типов, поскольку нет поддержки конструкторов, а POD-типы обычно маленькие.
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #68 : Февраль 17, 2011, 13:40 »

Да, но Igors выбирает размер исходя из размера системных страниц памяти. Это правильная экономия, в противовес мнимой экономии на последнем кусочке. При больших объёмах данных это имеет смысл.

Благодаря этому комменту наконец понял, что хотел сказать Igors: дека при больших объёмах неоптимально распределяет память и это нельзя настроить. (в смысле надеюсь, что понял Улыбающийся)
Да, именно так. На гигабайтах даже 512 - кошкины слезы. Но то "еще цветочки".
Вот мелкософтовскмй бриллиант

Код:
_STD_BEGIN
// DEQUE PARAMETERS
#define _DEQUEMAPSIZ 8 /* minimum map size, at least 1 */
#define _DEQUESIZ (sizeof (_Ty) <= 1 ? 16 \
: sizeof (_Ty) <= 2 ? 8 \
: sizeof (_Ty) <= 4 ? 4 \
: sizeof (_Ty) <= 8 ? 2 : 1) /* elements per block (a power of 2) */
Плачущий Плачущий Плачущий

"ХЗ" чем думал ихний программист. Ну как можно было втулить размер единица что противоречит самой идее контейнера? Реально работает так
Код
C++ (Qt)
deque <int> test1;  // 4 элемента в блоке (ой не густо)
 
struct Foo {
double m[3];
};
deque <Foo> test1;  // а так аж один :-(
 

Edit: и все трое игнорируют конструкторы, что делает их юзабельными только для интов..
Для POD структур. Стандартный подход (new с указанием места) здесь не очень подходит. Как правило распределенные элементы все равно приходится заполнять и вызов тысяч конструкторов ни к чему.

Пока не забыл
Код
C++ (Qt)
int * p = &vec[0];
 
За это в MSVC можно получить по рогам ("out of range" и все такое).

В общем "резвый старт" и законное желание попользоваться готовым на деле отливаются тоннами потерянного времени
Записан
BRE
Гость
« Ответ #69 : Февраль 17, 2011, 13:44 »

Захват больших кусков памяти маллок осуществляет напрямую у системы (mmap на линукс, на винде virtualalloc или что-то такое). Поэтому любой большой кусок кратен размеру страницы. Память в хвосте этого куска не вернётся при других маллоках и никогда не используется. Пример: вызвали malloc (40961), система выделила round_up (40961 / 4096) = 11 страниц по 4096, последняя страница содержит полезный 1 байт, остальное никогда не используется, пока не вернётся системе по вызову free.
А ты проверь.  Подмигивающий
Код
C++ (Qt)
#include <iostream>
 
int main( int, char ** )
{
       char *buf1 = new char [ 40961 ];
       char *buf2 = new char [ 40961 ];
       char *buf3 = new char [ 10 ];
 
       std::cout << (void *)buf1 << " " << (int)buf1 << std::endl
                         << (void *)buf2 << " " << (int)buf2 << std::endl
                         << (void *)buf3 << " " << (int)buf3 << std::endl;
}
 

И если будет интересно обсудим далее. Но менеджер памяти из libc ни про какие страниы не знает и работает с линейным куском памяти, который ему обеспечивает ядро. А вот ядро может оперировать кусками памятью только через страницы.
Записан
BRE
Гость
« Ответ #70 : Февраль 17, 2011, 13:46 »

Вот мелкософтовскмй бриллиант
По моему на всех заборах уже написано - не нужно пользоваться этой дрянью.  Улыбающийся
Записан
brankovic
Гость
« Ответ #71 : Февраль 17, 2011, 13:47 »

Код
C++ (Qt)
int * p = &vec[0];
 
За это в MSVC можно получить по рогам ("out of range" и все такое).
В общем "резвый старт" и законное желание попользоваться готовым на деле отливаются тоннами потерянного времени

По стандарту это UB, имеют право хоть выдать "hello world". Я думаю в релиз-версии не упадёт и исключения не выкинет.
« Последнее редактирование: Февраль 17, 2011, 13:59 от brankovic » Записан
brankovic
Гость
« Ответ #72 : Февраль 17, 2011, 13:58 »

А ты проверь.  Подмигивающий

судя по отсутствию #include <iomanip> этот код даже не запускался.. Может вы сами проверите? (просто я уверен в результате)

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

Это что-то непонятное. Какой-такой менеджер? Имеется ввиду malloc или кто?
Записан
BRE
Гость
« Ответ #73 : Февраль 17, 2011, 14:03 »

судя по отсутствию #include <iomanip> этот код даже не запускался..
скопируй этот текст в файл - filename.cpp
выполни g++ filename.cpp
появится файлик a.out (запускаемый)
запусти его
посмотри/посчитай

Может вы сами проверите?
Я уже проверил.

(просто я уверен в результате)
Напрасно.

Это что-то непонятное. Какой-такой менеджер? Имеется ввиду malloc или кто?
Да. malloc + free - называется менеджером памяти.
Записан
brankovic
Гость
« Ответ #74 : Февраль 17, 2011, 14:15 »

Код:
g++ ex.cpp
exx.cpp: In function ‘int main(int, char**)’:
exx.cpp:9: error: cast from ‘char*’ to ‘int’ loses precision
exx.cpp:10: error: cast from ‘char*’ to ‘int’ loses precision
exx.cpp:11: error: cast from ‘char*’ to ‘int’ loses precision

всё с 32 бит не расстанетесь Улыбающийся

Код:
[xxx@zzz ~]$ cat ex.cpp
#include <iostream>

int main( int, char ** )
{
    int const d = 40961;
    char *buf1 = new char [ d ];
    char *buf2 = new char [ d ];
    char *buf3 = new char [ 10 ];

    long b1 = (long) buf1;
    long b2 = (long) buf2;
    long b3 = (long) buf3;

    std::cout
              << (void *) buf1 << " " << b1 << " +" << b2 - (b1 + d) << std::endl
              << (void *) buf2 << " " << b2 << " +" << b3 - (b2 + d) << std::endl
              << (void *) buf3 << " " << b3 << std::endl;
}
[xxx@zzz ~]$ g++ ex.cpp
[xxx@zzz ~]$ ./a.out
0x800d02000 34373378048 +4095
0x800d0d000 34373423104 +4159
0x800d18040 34373468224
[xxx@zzz ~]$ g++ -v
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719  [FreeBSD]
[xxx@zzz ~]$

что и требовалось доказать. У вас-то на чём оно работает?
« Последнее редактирование: Февраль 17, 2011, 14:17 от brankovic » Записан
Страниц: 1 ... 3 4 [5] 6 7   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.16 секунд. Запросов: 23.