MSV>Для определенных задач это самая эффективная матрица. Думаю на этой матрице закончится мой многолетний труд над ними. Это самая мощная матрица из всех (ранее созданных).

Так вот он, создатель матриц!!! Когда перезагрузка на самую мощную?

Здравствуйте, djs_, Вы писали:

_>Здравствуйте, MikelSV, Вы писали:

_>А вы жалуетесь, что на вас не обращают внимания. Да каждый ваш вопрос — это просто праздник!
_>Их можно сразу постить в "Этюды для программистов".

MSV>>Вопрос был в том (По ходу дела я как-то неправильно его задал).

MSV>>char *edata, *ndata;

MSV>>Как это:
MSV>>memcpy(edata, &ndata, 4);

MSV>>Заменить на это (Просто не понимал, как правильно это написать):
MSV>>*(unsigned int*)edata=*(unsigned int*)&ndata;

_>Супер.
_>Вы же понимаете, что приводя edata, который (char *) к (unsigned_int *) и обратившись по этому адресу, вы скорее всего попортите чужую память?
Хм, странно, но у меня все работает.
Не понимаю. Если вы про размеры типов данны, то об этом я знаю и учитываю в разработке.

Если предлагаете сделать так: *(char *)edata=*(char *)&ndata; То нужного эффекта не получается, так как копируется только один символ.

_>Кроме того, вы используете указатель для хранения адреса на нужный вам указатель (масло маслянное).
_>Может в этом и есть тайный смысл, но почему бы в edata не хранить именно &ndata? Тогда edata = (char *)&ndata;

Пардон, но нафига мне адрес на ndata? ndata — простой указатель на новый блок данных.

Структура матрицы: [unsigned int size][char *nextdata][ char[x] data ]
Здесь я решил сделать без использования структур. Да, код писать сложнее, но более интересно.

Фокус прост: char *data, *edata, *ndata; — указатели на начало, конец и для прочих нужд.
все данные пишутся в блок данных(3) матрицы. Когда место заканчивается выделяю еще буффер, а в предыдущий блок пишу указатель на созданный.

Для определенных задач это самая эффективная матрица. Думаю на этой матрице закончится мой многолетний труд над ними. Это самая мощная матрица из всех (ранее созданных).

MSV>>Вопрос решен
Но люди еще лезут

Здравствуйте, MikelSV, Вы писали:

MSV>Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
Осталось дождатся перехода на 64 бита и получить много-много секса

MSV>>Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
MSV>>Хочется узнать самый простой способ

ДД>

ДД>ndata_t ndata;
ДД>ndata_t *edata;
ДД>...
ДД>edata = &ndata;
ДД>

Это я и так знаю. У меня *ndata и *edata.


MSV>Если предлагаете сделать так: *(char *)edata=*(char *)&ndata; То нужного эффекта не получается, так как копируется только один символ.
>А сколько нужно копировать?
адрес — 4 байта


>Это что-то вы вообще уникальное придумали. Как назвали? Паровозик?
Насчет уникальности не знаю. Скорее всего такие придуманы давно. К сожалению больше занимаюсь своими разработками и мало интересуюсь чужими.
Эта разработка называется UMatrix — Unlimited Matrix (Бесконечная матрица), причина и главная особенность (наверно других не нашлось) — возможность бесконечно длинной матрицы(Пока есть доступная память), без перемещения служебных данных в памяти.


>А чтобы было еще интереснее и эффективнее (в отношении использования памяти) используйте не т.н. "линейный односвязный список", а xor-связный список.
Что такое xor-связный список? Если это матрица с быстрым доступом к любому элементу матрицы, то это моя прошлая разработка LMatrix.

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


>Осталось дождатся перехода на 64 бита и получить много-много секса
Ну тут нужно будет поработать с логикой. И все пройдет. Нехорошо конечно оставлять это сейчас. Хотя просто нужно разработать новый стандарт, тоесть запихнуть битность в define.
Хотя лично я пока туда не хочу. В 2 раза больше памяти на указатели? Для меня это многовато.


>template <typename T, size_t block_size>
>class block_allocator
>{

А как этим пользоваться? Тоесть хотелось бы посмотреть работу(вставку, считывание) например block_allocator<char, 1024> ba;
Было б интересно сравнить скорости матриц. Так сказать: понять, чего ж я таки изобрел

Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
Проблема в том, что я не могу сделать это без memcpy, а так хочется. Оказывается нет у меня опыта в этом моменте.

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

Хочется узнать самый простой способ

Здравствуйте, MikelSV, Вы писали:

MSV>Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
MSV>Проблема в том, что я не могу сделать это без memcpy, а так хочется. Оказывается нет у меня опыта в этом моменте.
MSV>Помнится очень давно я так выпендривался через какую-то свою функцию. Компилятор много ругался, но работал нормально.
MSV>Хочется узнать самый простой способ

unsigned long ndata;
edata = (unsigned long)&ndata;

Здравствуйте, Nikopol, Вы писали:

N>Здравствуйте, MikelSV, Вы писали:

MSV>>Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
N>

N>edata = (unsigned long)&ndata;
N>

Во-первых, стандарт не определеят размер unsigned long. Во-вторых, не следует забывать про выравнивание: http://www.rsdn.ru/Forum/?mid=2634604

Автор: Посторонним В.
Дата: 26.08.07

.

Здравствуйте, MikelSV, Вы писали:

MSV>Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
MSV>Проблема в том, что я не могу сделать это без memcpy, а так хочется.

А что за данные и почему хочется именно с memcpy?

Здравствуйте, MikelSV, Вы писали:

MSV>Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
MSV>Проблема в том, что я не могу сделать это без memcpy, а так хочется. Оказывается нет у меня опыта в этом моменте.

MSV>Помнится очень давно я так выпендривался через какую-то свою функцию. Компилятор много ругался, но работал нормально.

MSV>Хочется узнать самый простой способ

void mycpy(void* p, void* data, int len){
    for(int i = 0; i < len; i++) ((char*)p)[i] = ((char*)data)[i];
}

Здравствуйте, SAV, Вы писали:

SAV>

SAV>void mycpy(void* p, void* data, int len){
SAV>    for(int i = 0; i < len; i++) ((char*)p)[i] = ((char*)data)[i];
SAV>}
SAV>

Если человек не смог воспользоваться стандартной функцией memcpy,
то и твоим велосипедом он тоже не сможет воспользоваться.

Здравствуйте, SAV, Вы писали:

SAV>Здравствуйте, MikelSV, Вы писали:

MSV>>Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
MSV>>Проблема в том, что я не могу сделать это без memcpy, а так хочется. Оказывается нет у меня опыта в этом моменте.

MSV>>Помнится очень давно я так выпендривался через какую-то свою функцию. Компилятор много ругался, но работал нормально.

MSV>>Хочется узнать самый простой способ

SAV>

SAV>void mycpy(void* p, void* data, int len){
SAV>    for(int i = 0; i < len; i++) ((char*)p)[i] = ((char*)data)[i];
SAV>}
SAV>

Люди, вы чего творите?

char *edata, *ndata;

Так работает:
memcpy(edata, &ndata, 4);

edata — буффер, ndata — новый буффер, адрес которого нужно вписать в edata (в первые 4 байта).


Вроде сделал:
*(unsigned int*)edata=*(unsigned int*)(char*)&ndata;
Просто я не мог просчитать это в памяти (своей головы). Обычный код таких проблем не вызывает.

>Если человек не смог воспользоваться стандартной функцией memcpy,
>то и твоим велосипедом он тоже не сможет воспользоваться.
Прошу не гнать.

А то что это велосипед это точно. Я хоть и большой любитель велосипедов, но я все-таки умудрился написать свою memcpy на ассемблере. Учись оптимизировать.

Я не хотел использовать memcpy, потому что она тормозила работу программы. Т.е. можно было обойтись одной строчкой c++ кода, без запуска функций.
Я, как большой любитель матриц (массивов по русски), пытался заставить новую матрицу( по логике более быструю) работать быстрее предыдущей. memcpy портила все дело. Щас новая матрица смогла вырваться вперед. И съэкономить 10% времени при заполнении данными. Мну счастлив.

Здравствуйте, MikelSV, Вы писали:

MSV>Люди, вы чего творите?

Судя по всему это ты творишь.

MSV>char *edata, *ndata;

MSV>Так работает:
MSV>memcpy(edata, &ndata, 4);

Так работать не будет.
Почему ты решишь, что надо брать адрес у ndata?

MSV>edata — буффер, ndata — новый буффер, адрес которого нужно вписать в edata (в первые 4 байта).

Это ты откуда взял?

Вот простой пример как работать с memcpy

 char *dest;
 char *src;
 size_t buffSize=100;
 
 // выделяем память для обоих буферов
 dest = new char[buffSize];
 src = new char[buffSize];

 // тут заполняем твой src так, как тебе надо.

 // теперь копируем
 memcpy( dest, src, buffSize);

Вот пример в MSDN:
http://msdn2.microsoft.com/en-us/library/8k35d1fx(VS.71).aspx

По моему все просто до безобразия...

Здравствуйте, bkat, Вы писали:
B>Так работать не будет.
B>Почему ты решишь, что надо брать адрес у ndata?

Мне нужно.

MSV>>edata — буффер, ndata — новый буффер, адрес которого нужно вписать в edata (в первые 4 байта).
B>Это ты откуда взял?

Программа у меня такая. И логика еёйная.

B>По моему все просто до безобразия...


Все просто до безумия. Чего вы к memcpy привязались? Я же от нее избавиться хотел, она программу тормозила. (что конечно же заметно только при специальных нагрузках).

А как она работает я еще в 2003 году знал.

вроде memcpy и реализуется на асме (проверьте в своей ОС). Если так, то какой более эффективный способ чем побайтовое копирование вы ожидаете?

Если велосипед не нравится — не катайтесь Меня вполне memcpy устраивает. Вероятно, просто недопонял вопрос.

Здравствуйте, MikelSV, Вы писали:

MSV>Все просто до безумия. Чего вы к memcpy привязались? Я же от нее избавиться хотел, она программу тормозила. (что конечно же заметно только при специальных нагрузках).

Почитай вот это:
http://www.rsdn.ru/Info/Howtoask.xml

Тяжело понять что тебе надо.

Здравствуйте, SAV, Вы писали:

SAV>Вероятно, просто недопонял вопрос.

не один ты такой

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, SAV, Вы писали:

SAV>>Вероятно, просто недопонял вопрос.

B>не один ты такой



Вопрос был в том (По ходу дела я как-то неправильно его задал).

char *edata, *ndata;

Как это:
memcpy(edata, &ndata, 4);

Заменить на это (Просто не понимал, как правильно это написать):
*(unsigned int*)edata=*(unsigned int*)&ndata;


Вопрос решен

Здравствуйте, MikelSV, Вы писали:

MSV>Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
MSV>Проблема в том, что я не могу сделать это без memcpy, а так хочется. Оказывается нет у меня опыта в этом моменте.

MSV>Помнится очень давно я так выпендривался через какую-то свою функцию. Компилятор много ругался, но работал нормально.

MSV>Хочется узнать самый простой способ

union
{
char* p;
int n;
} u;

u.n=5;

Здравствуйте, MikelSV, Вы писали:

А вы жалуетесь, что на вас не обращают внимания. Да каждый ваш вопрос — это просто праздник!
Их можно сразу постить в "Этюды для программистов".

MSV>Вопрос был в том (По ходу дела я как-то неправильно его задал).

MSV>char *edata, *ndata;

MSV>Как это:
MSV>memcpy(edata, &ndata, 4);

MSV>Заменить на это (Просто не понимал, как правильно это написать):
MSV>*(unsigned int*)edata=*(unsigned int*)&ndata;

Супер.
Вы же понимаете, что приводя edata, который (char *) к (unsigned_int *) и обратившись по этому адресу, вы скорее всего попортите чужую память?
Кроме того, вы используете указатель для хранения адреса на нужный вам указатель (масло маслянное).
Может в этом и есть тайный смысл, но почему бы в edata не хранить именно &ndata? Тогда edata = (char *)&ndata;

MSV>Вопрос решен

Здравствуйте, MikelSV, Вы писали:

MSV>Хм, странно, но у меня все работает.
MSV>Не понимаю. Если вы про размеры типов данны, то об этом я знаю и учитываю в разработке.

MSV>Если предлагаете сделать так: *(char *)edata=*(char *)&ndata; То нужного эффекта не получается, так как копируется только один символ.

А сколько нужно копировать?

_>>Кроме того, вы используете указатель для хранения адреса на нужный вам указатель (масло маслянное).
_>>Может в этом и есть тайный смысл, но почему бы в edata не хранить именно &ndata? Тогда edata = (char *)&ndata;

MSV>Пардон, но нафига мне адрес на ndata? ndata — простой указатель на новый блок данных.

Не знаю нафига...
Но вы писали буквально:

Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
Проблема в том, что я не могу сделать это без memcpy, а так хочется.

MSV>Структура матрицы: [unsigned int size][char *nextdata][ char[x] data ]
MSV>Здесь я решил сделать без использования структур. Да, код писать сложнее, но более интересно.

Ничем не сложнее. Просто в общем случае код будет медленнее, ну и памяти поменьше будет использовать иногда.
А чтобы было еще интереснее и эффективнее (в отношении использования памяти) используйте не т.н. "линейный односвязный список", а xor-связный список.

MSV>Фокус прост: char *data, *edata, *ndata; — указатели на начало, конец и для прочих нужд.
MSV>все данные пишутся в блок данных(3) матрицы. Когда место заканчивается выделяю еще буффер, а в предыдущий блок пишу указатель на созданный.

Это что-то вы вообще уникальное придумали. Как назвали? Паровозик?

MSV>Для определенных задач это самая эффективная матрица. Думаю на этой матрице закончится мой многолетний труд над ними. Это самая мощная матрица из всех (ранее созданных).




MSV>>>Вопрос решен
MSV>Но люди еще лезут

Хотите, чтобы игнорировали и не замечали вашего присутствия?

Здравствуйте, MikelSV, Вы писали:

MSV>Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
MSV>Проблема в том, что я не могу сделать это без memcpy, а так хочется. Оказывается нет у меня опыта в этом моменте.

MSV>Помнится очень давно я так выпендривался через какую-то свою функцию. Компилятор много ругался, но работал нормально.

MSV>Хочется узнать самый простой способ

если адрес edata выровнен по sizeof(void*), то можно просто:
*(void**)edata = &ndata;
если же не выровнен, то перенос побайтно

Здравствуйте, sokel, Вы писали:

S>Здравствуйте, MikelSV, Вы писали:

MSV>>Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
MSV>>Проблема в том, что я не могу сделать это без memcpy, а так хочется. Оказывается нет у меня опыта в этом моменте.

MSV>>Помнится очень давно я так выпендривался через какую-то свою функцию. Компилятор много ругался, но работал нормально.

MSV>>Хочется узнать самый простой способ

S>если адрес edata выровнен по sizeof(void*), то можно просто:
S>*(void**)edata = &ndata;
S>если же не выровнен, то перенос побайтно

как пример, простейший блочный аллокатор:

#define ALIGNED_SIZE(T) ((sizeof(T)%sizeof(void*))?(sizeof(T)/sizeof(void*)+1)*sizeof(void*):sizeof(T))

template <typename T, size_t block_size>
class block_allocator
{
private:
    void* free_obj;
public:
    block_allocator() : free_obj(0) {}
    inline void* allocate_obj()                
    {
        if(!free_obj) allocate_new_block();
        void* ret = free_obj;
        free_obj = *((void**)free_obj);
        return ret;    
    }
    inline void release_obj(void* p)        
    {
        *((void**)p) = free_obj;
        free_obj = p;
    }
private:
    void allocate_new_block()
    {
        void* new_block = malloc(ALIGNED_SIZE(T)*block_size);
        if(!new_block) throw std::bad_alloc();
        *((void**)new_block) = block_list;
        block_list = new_block;
        free_obj = (char*) new_block + sizeof(void*);
        char* cur = (char*) free_obj;
        for(int i=0; i<block_size-1; ++i)
        {
            char* next = cur+ALIGNED_SIZE(T);
            *(char**)cur = next;
            cur = next;
        }
        *(char**)cur = NULL;
    }
};

Здравствуйте, sokel, Вы писали:

S>Здравствуйте, sokel, Вы писали:

S>>Здравствуйте, MikelSV, Вы писали:

MSV>>>Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
MSV>>>Проблема в том, что я не могу сделать это без memcpy, а так хочется. Оказывается нет у меня опыта в этом моменте.

MSV>>>Помнится очень давно я так выпендривался через какую-то свою функцию. Компилятор много ругался, но работал нормально.

MSV>>>Хочется узнать самый простой способ

S>>если адрес edata выровнен по sizeof(void*), то можно просто:
S>>*(void**)edata = &ndata;
S>>если же не выровнен, то перенос побайтно

упс, немножко поправил...

как пример, простейший блочный аллокатор:

#define ALIGNED_SIZE(T) ((sizeof(T)%sizeof(void*))?(sizeof(T)/sizeof(void*)+1)*sizeof(void*):sizeof(T))

template <typename T, size_t block_size>
class block_allocator
{
private:
    void* free_obj;
public:
    block_allocator() : free_obj(0) {}
    inline void release_obj(void* p)        
    {
        *((void**)p) = free_obj;
        free_obj = p;
    }
    inline void* allocate_obj()                
    {
        if(!free_obj) allocate_new_block();
        void* ret = free_obj;
        free_obj = *((void**)free_obj);
        return ret;    
    }
private:
    void allocate_new_block()
    {
        free_obj = malloc(ALIGNED_SIZE(T)*block_size);
        if(!free_obj) throw std::bad_alloc();
        char* cur = (char*) free_obj;
        for(int i=0; i<block_size-1; ++i)
        {
            char* next = cur+ALIGNED_SIZE(T);
            *(char**)cur = next;
            cur = next;
        }
        *(char**)cur = NULL;
    }
};

Здравствуйте, MikelSV, Вы писали:
...

template<class TTo, class TFrom>
    TTo sized_cast(TFrom t2)
{
    STATIC_ASSERT(sizeof(TTo) == sizeof(TFrom));
    union U
    {
        TTo t1;
        TFrom t2;
    };
    U u;
    u.t2 = t2;
    return u.t1;
}

edata = sized_cast<int>(&ndata);

Здравствуйте, MikelSV, Вы писали:

MSV>Есть такая вещь: memcpy(edata, &ndata, 4); запись указателя на ndata в переменную edata.
MSV>Хочется узнать самый простой способ

ndata_t ndata;
ndata_t *edata;
...
edata = &ndata;

Здравствуйте, MikelSV, Вы писали:

MSV>А как этим пользоваться? Тоесть хотелось бы посмотреть работу(вставку, считывание) например block_allocator<char, 1024> ba;
MSV>Было б интересно сравнить скорости матриц. Так сказать: понять, чего ж я таки изобрел

для char использование такого аллокатора неоправдано, размер выделяемых объектов выравнивается по sizeof(void*)
а использовать его можно примерно так:

struct A
{
    // какие то данные
    int i;
    double d1;
    double d2;

    static block_allocator<A, 1024> allocator;
    // переопределяем операторы new и delete 
    void* operator new (size_t)                                                
    {
        return allocator.allocate_obj();                        
    }                                                                    
    void operator delete(void * to_free)                                
    {                                                                    
        return allocator.release_obj(to_free);                    
    }
};

 block_allocator<A, 1024> A::allocator;

int main() 
{
    A* pa1 = new A(); // при этом выделится блок на 1024 объекта 
    A* pa2 = new A(); // здесь память уже не выделяется
    delete pa1; // при удалении помещается в список свободных объектов
    delete pa2;
}

Здравствуйте, MikelSV, Вы писали:

>>А сколько нужно копировать?
MSV>адрес — 4 байта

Нет, вы определитесь, либо адрес, либо 4 байта.
Это как говорится две большие разницы.

MSV>Насчет уникальности не знаю. Скорее всего такие придуманы давно. К сожалению больше занимаюсь своими разработками и мало интересуюсь чужими.
MSV>Эта разработка называется UMatrix — Unlimited Matrix (Бесконечная матрица), причина и главная особенность (наверно других не нашлось) — возможность бесконечно длинной матрицы(Пока есть доступная память), без перемещения служебных данных в памяти.

Это называется односвязный список.
И он не бесконечно длинный. Даже при удачном стечении обстоятельств Вы сможете создать не более 350 млн записей, а реально — много меньше.

>>А чтобы было еще интереснее и эффективнее (в отношении использования памяти) используйте не т.н. "линейный односвязный список", а xor-связный список.
MSV>Что такое xor-связный список? Если это матрица с быстрым доступом к любому элементу матрицы, то это моя прошлая разработка LMatrix.

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

MSV>Но, как показывает практика именно линейный односвязный список обеспечивает самую быструю вставку данных. А при специальных задачах линейная матрица самая эффективная. Мои тесты показывают это.

Ну нет, это не самый быстрый алгоритм.
И реализация его как односвязного списка — тоже.

>>Осталось дождатся перехода на 64 бита и получить много-много секса
MSV>Ну тут нужно будет поработать с логикой. И все пройдет. Нехорошо конечно оставлять это сейчас. Хотя просто нужно разработать новый стандарт, тоесть запихнуть битность в define.
MSV>Хотя лично я пока туда не хочу. В 2 раза больше памяти на указатели? Для меня это многовато.

А вам не нужно туда хотеть — оно само придет
Да и при работе на 32 битной платформе для вас ничего не изменится.
И вариант с #define — не совсем правильный выход.

(Пока интернет снова не отключился.)

Здравствуйте, djs_, Вы писали:

_>Здравствуйте, MikelSV, Вы писали:

>>>А сколько нужно копировать?
MSV>>адрес — 4 байта

_>Нет, вы определитесь, либо адрес, либо 4 байта.
_>Это как говорится две большие разницы.

??? У нас адрес не размером 4 байта? Тогда какая между ними разница?

MSV>>Насчет уникальности не знаю. Скорее всего такие придуманы давно. К сожалению больше занимаюсь своими разработками и мало интересуюсь чужими.
MSV>>Эта разработка называется UMatrix — Unlimited Matrix (Бесконечная матрица), причина и главная особенность (наверно других не нашлось) — возможность бесконечно длинной матрицы(Пока есть доступная память), без перемещения служебных данных в памяти.

_>Это называется односвязный список.
_>И он не бесконечно длинный. Даже при удачном стечении обстоятельств Вы сможете создать не более 350 млн записей, а реально — много меньше.
Конечно не бесконечный. Но если физические ограничения снять, тогда бесконечная.

>>>А чтобы было еще интереснее и эффективнее (в отношении использования памяти) используйте не т.н. "линейный односвязный список", а xor-связный список.
MSV>>Что такое xor-связный список? Если это матрица с быстрым доступом к любому элементу матрицы, то это моя прошлая разработка LMatrix.

_>Нет, там смысл в том, что для адресации элементов списка используется в 2 раза меньше памяти.
_>Вы без труда найдете множество его описаний.

У меня оказывается получился развёрнутый связанный список. С обычным линейным я разобрался давно. (походу я вообще незнаком со стандартными названиями.)

Самое интересное то, что я изобретал-изобретал, а получается такое уже известно. За-то столько опыта приобрел.
Что такое xor-связный список понял, реализовывать лень. Появляются неоправданные операции при любых действиях с элементами списка. Я люблю перемешивать элементы (одна строчка для изменения положения), с xor это будет сложновато. Неэффективно.

MSV>>Но, как показывает практика именно линейный односвязный список обеспечивает самую быструю вставку данных. А при специальных задачах линейная матрица самая эффективная. Мои тесты показывают это.

_>Ну нет, это не самый быстрый алгоритм.
_>И реализация его как односвязного списка — тоже.
Как выяснилось это развернутый связанный список. Из моих разработок самый быстрый. Подскажите самый быстрый алгоритм? Очень хочу посмотреть, как будет работать.

>>>Осталось дождатся перехода на 64 бита и получить много-много секса
MSV>>Ну тут нужно будет поработать с логикой. И все пройдет. Нехорошо конечно оставлять это сейчас. Хотя просто нужно разработать новый стандарт, тоесть запихнуть битность в define.
MSV>>Хотя лично я пока туда не хочу. В 2 раза больше памяти на указатели? Для меня это многовато.

_>А вам не нужно туда хотеть — оно само придет
_>Да и при работе на 32 битной платформе для вас ничего не изменится.
_>И вариант с #define — не совсем правильный выход.
Буду ждать

Здравствуйте, MikelSV, Вы писали:

MSV>(Пока интернет снова не отключился.)

MSV>Здравствуйте, djs_, Вы писали:

_>>Нет, вы определитесь, либо адрес, либо 4 байта.
_>>Это как говорится две большие разницы.

MSV>??? У нас адрес не размером 4 байта? Тогда какая между ними разница?

Нет, совсем не обязательно 4 байта.

MSV>>>Насчет уникальности не знаю. Скорее всего такие придуманы давно. К сожалению больше занимаюсь своими разработками и мало интересуюсь чужими.
MSV>>>Эта разработка называется UMatrix — Unlimited Matrix (Бесконечная матрица), причина и главная особенность (наверно других не нашлось) — возможность бесконечно длинной матрицы(Пока есть доступная память), без перемещения служебных данных в памяти.

_>>Это называется односвязный список.
_>>И он не бесконечно длинный. Даже при удачном стечении обстоятельств Вы сможете создать не более 350 млн записей, а реально — много меньше.
MSV>Конечно не бесконечный. Но если физические ограничения снять, тогда бесконечная.

Нет, посчитайте, сколько памяти можно адресовать 4-мя байтами.
Если будет 32 Гб оперативной памяти, Вы сможете воспользоваться только 10%

Здравствуйте, djs_, Вы писали:

_>Здравствуйте, MikelSV, Вы писали:

MSV>>(Пока интернет снова не отключился.)

MSV>>Здравствуйте, djs_, Вы писали:

_>>>Нет, вы определитесь, либо адрес, либо 4 байта.
_>>>Это как говорится две большие разницы.

MSV>>??? У нас адрес не размером 4 байта? Тогда какая между ними разница?

_>Нет, совсем не обязательно 4 байта.
Да, можно и 8, но пока это лишь напрасный расход памяти.

MSV>>>>Насчет уникальности не знаю. Скорее всего такие придуманы давно. К сожалению больше занимаюсь своими разработками и мало интересуюсь чужими.
MSV>>>>Эта разработка называется UMatrix — Unlimited Matrix (Бесконечная матрица), причина и главная особенность (наверно других не нашлось) — возможность бесконечно длинной матрицы(Пока есть доступная память), без перемещения служебных данных в памяти.

_>>>Это называется односвязный список.
_>>>И он не бесконечно длинный. Даже при удачном стечении обстоятельств Вы сможете создать не более 350 млн записей, а реально — много меньше.
MSV>>Конечно не бесконечный. Но если физические ограничения снять, тогда бесконечная.

_>Нет, посчитайте, сколько памяти можно адресовать 4-мя байтами.
_>Если будет 32 Гб оперативной памяти, Вы сможете воспользоваться только 10%

Я пробовал придумать свою файловую систему. Решил размечать диск с использованием 4 байтовых адресов, так что меня этим не напугаешь.
А во вторых у меня нет 32Гб. Вот когда будут, тогда и решу, как лучше сделать.

Здравствуйте, MikelSV, Вы писали:

MSV>Здравствуйте, djs_, Вы писали:

_>>Здравствуйте, MikelSV, Вы писали:

MSV>>>??? У нас адрес не размером 4 байта? Тогда какая между ними разница?

_>>Нет, совсем не обязательно 4 байта.
MSV>Да, можно и 8, но пока это лишь напрасный расход памяти.

Нет, совсем не обязательно 8.

_>>Нет, посчитайте, сколько памяти можно адресовать 4-мя байтами.
_>>Если будет 32 Гб оперативной памяти, Вы сможете воспользоваться только 10%

MSV>Я пробовал придумать свою файловую систему. Решил размечать диск с использованием 4 байтовых адресов, так что меня этим не напугаешь.
MSV>А во вторых у меня нет 32Гб. Вот когда будут, тогда и решу, как лучше сделать.

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