Здравствуйте, 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;

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;
Было б интересно сравнить скорости матриц. Так сказать: понять, чего ж я таки изобрел

Здравствуйте, 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Гб. Вот когда будут, тогда и решу, как лучше сделать.

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

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

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