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

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

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

V>>>И все же, ниша языка формируется именно из-за качеств самого языка. Повышение надежности никак не сократит нишу С++, однако способно сильно эту нишу расширить. (Покажи мне любой "эффективный" код на С++, требующий реинтерпретации памяти, и я покажу тебе, как обойтись без нее без какой-либо потери эффективности).

V>>>Я повторяю предложение дать ЛЮБОЙ код, требующий хаков с памятью или приведением указателей/ссылок вниз по иерархии наследования, и переделаю его без этих хаков. Нравится/не нравится — это слишком субъективный фактор, в то время как обеспечиваемая языком надежность — конкретный.

_W>Имеется массив четвёрок struct vec3f_t { float x, y, z, _; }; в массив матриц 4x4 для API вроде OpenGL/Direc3D

обещал переделать — буду переделывать:
(подробности опущены, показана идея, как сохранить похожий внешний синтаксис, кстати, можно добавить конструкторы и еще всякие методы)

struct vec3f_t { 
    float row[4]; 
    float x() { return row[0]; }
    void x(float f) { row[0]=f; }

    float y() { return row[1]; }
    void y(float f) { row[1]=f; }
    
    float z() { return row[3]; }
    void z(float f) { row[3]=f; }

    float _() { return row[3]; }
    void _(float f) { row[3]=f; }

    float& operator[](int i) { return row[i]; }
}; 

typedef vec3f_t matrix4x4[4];

int _tmain()
{

    matrix4x4 a;
    a[0][0]=10;
    a[1][1]=20;
    a[2].z(30);
    a[3]._(40);

    std::cout << a[0][2] << a[0][0];
    return 0;
}

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

__W>Имеется embedded устройство, 32 мегабайта оперативки. 1 мегабайт для кода и данных, 1 мегабайт для стека. Нужно загрузить образ с DVD размером в 30 мегабайт.

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

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

_W>>Имеется embedded устройство, 32 мегабайта оперативки. 1 мегабайт для кода и данных, 1 мегабайт для стека. Нужно загрузить образ с DVD размером в 30 мегабайт.

_W>Ну или аналогичная задача — загрузить DOM-дерево за один malloc + 1 fread. Никакого парсинга.

Не разделяю восторга. На машине с другой архитектурой этот файл не прочитается. Могу загрузить за 1 malloc, + 1 fread, + парсинг (мне бы хватило 4-х байт на объект, если множество типов узлов конечное, т.е. не подлежит расширению).

Извини, зато такой вариант сделает формат файла независимым от платформы. Я не представляю, как ты таким фокусом перенесешь данные для 64 разрядного приложения, например. А это уже актуально

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

_W>Тупая такая задача. Распечатать указатель в двоичной системе счисления.

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

Хотя... ничего страшного нет, если мы приведем указатель к size_t. Опасность нас ждет при обратном приведении произвольного числа к указателю произвольного типа. Т.е. запретить именно эту операцию.

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

IT>>Ну разве что только "в отличии от x86".

AVK>А что тебе там не понравилось?

Экономия места мне там не понравилась. Систему команд можно было сделать в два раза проще выкинув короткие версии команд и все эти ldarg.0, .1, .2, .3. С примитивными типами тоже намудрили. ldc команд почему-то 4, а conv и ldind по полной схеме. Можно было иметь вообще по одной команде, если сопроводить её целевым типом или брать его со стека. Загрузка самого типа делается через задницу — ldtoken с последующим вызовом Type.RuntimeTypeHandle. Нельзя для этого было команду отдельную сделать? ldarg и ldloc — это суть одно и тоже. В общем, хватает там косяков. Видно, что делали не "выразительную и удобную" систему команд, а просто экономили байты, захломляя саму систему команд всяким мусором.

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

_W>Имется сишная библиотека. Она в callback передает void *. Как ты будешь без down-castа конвертировать void * в указатель на свои данные?

Тот же самый вопрос касается API осей. Да никак. Переходить на типизированные интерфейсы (в данном случае — это типизированные h-файлы, типа как в Windows.h c режимом STRICT)

Разумеется, где-то должна быть точка соприкосновения нативных интерфейсов и типизированного мира языка. Т.е. типизированная версия Windows.h — это уже хак сам по себе, ибо трактует DWORD как HANDLE и как бог его еще значет что. Но тут производитель ОСИ берет на себя ответственность за бинарную совместимость, а не программист-прикладник.

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

_W>Здравствуйте, _Winnie, Вы писали:
_W>>Здравствуйте, _Winnie, Вы писали:
_W>>>Здравствуйте, _Winnie, Вы писали:
_W>>>>Здравствуйте, _Winnie, Вы писали:
_W>>>>>Здравствуйте, _Winnie, Вы писали:
_W>>>>>>Здравствуйте, _Winnie, Вы писали:
_W>>>>>>>Здравствуйте, vdimas, Вы писали:

_W>Напиши аналог boost::optional или boost::variant.

Хм.. для variant необходимо что-то типа union. Советую посмотреть как это сделано в CORBA-стандарте. union в CORBA — это не просто размеченная область памяти, это область памяти с дескриминатором (прямо как классический variant). По спецификации мы можем извлекать данные только того типа, которые записали в union до этого. Стандарт С++ так же рекомендует именно такое использование union, правда не накладывает ограничений в виде какого-либо контроля.

В общем, сделать размеченный union частью языка, примерно как в спецификациях CORBA.

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

_W>Изменить яркость картинки struct RGB { byte r, byte g, byte b } image[N];, добавив к каждому пикселю фиксированное значение с насыщением (то есть, не выходя за пределы 255 — 200+100==255 .
_W>Если напишешь что то вроде for (...) { int tmp = pixel->r += value; if (tmp > 255) tmp = 255; pixel->r = 255 }, то я буду смеятся и плакать.

Если ты напишешь по-другому, то буду смеятьсяи плакать я, т.к. это — очевидный UB даже сейчас. Тебе никто не гарантирует детерминированную упаковку и выравнивание структуры RGB.

можно написать так byte image[3][N], или так byte image[3*N]. Мне приводить код для этого случая или и так понятно?

или так int32_t image[N] — тогда всю эту операцию можно делать именно так как ты имел ввиду, а для цветовых составляющих сделать акцессоры, типа так:

byte GetR(int32_t v);
void SetR(int32_t, byte value);

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

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


>long mantis(float); // некая нормализованная мантисса, умноженная на десятичный коэф, достаточной ширины
>extern const float Q_NAN; //и т.д.

Ну да. Только библиотеку надо писать. Сама она ниоткуда не появится.

>struct vec3f_t {
>std::cout << a[0][2] << a[0][0];
Передавать в консоль — это круто, но от меня ждут float *, а не символы.
см. DxSDK/MSDN SetVertexShaderConstant

>__W>Имеется embedded устройство, 32 мегабайта оперативки. 1 мегабайт для кода и данных, 1 мегабайт для стека. Нужно загрузить образ с DVD размером в 30 мегабайт.
>и? в чем прикол?
1+1+30 == 32.
В том, что нет места, что бы загрузить нечто в одно место, а потом распарсить его и записать его в другое место. Единственный выход — загрузка inplace всех структур данных.
И нет времени, что бы парсить — время загрузки игры по TCR Sony/Microsoft составляет 30 секунд. Подгружать приходится по ходу игры, на ходу.

>Не разделяю восторга. На машине с другой архитектурой этот файл не прочитается. Могу загрузить за 1 malloc, + 1 fread, + парсинг (мне бы хватило 4-х байт на объект, если множество типов узлов конечное, т.е. не подлежит расширению).
И не надо. Это файл собирается под определенную архитектуру. Так же, как и исполняемы файл. Под PlayStation2 — по одному, под X-Box — по другому(ух, объединённая оперативная и видепамять — это здорово!), под PC- по третьему , под Game Cube — по четвёртому.
Тебя же не смущает, что исполняемый файл с одной системы не запускается на другой, хотя она собирается из C++ и под ту, и под другую? Вот данные собираются точно так же.
Да, по сети его не передашь, но кому придёт в голову пересылать .exe с Win32 на Linux?

>+ парсинг
Memory Mapping, и используем кусок памяти как готовый объект! Никакого парсинга!
Возможно, делаем fixup таблицы указателей на виртуальные функции, их то в файле не сохранишь.

>Конкретный адрес указателя не имеет смысла, кроме значения NULL, и то ты не знаешь, чему оно равно на всевозможных платформах. Сорри.
Для отладки очень даже имеет значение. Если я там вижу что-то вроде BaadFooD... Или DeadBeef... или хочу понять, где оно лежит, на стеке, в куче или в код.

>Хотя... ничего страшного нет, если мы приведем указатель к size_t.
Ага! Я же говорил, ничего страшного в реинтерпретации нет!

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

>Да никак.
А обещал, что сможешь переписать любой код...

>Хм.. для variant необходимо что-то типа union.

Да нет.. скорее, struct variant { byte store[max(sizeof(T1), sizeof(T2), sizeof(T3)]. }; (очень грубо).

>byte image[3*N]
Ну, мне удобно рассматривать картинку как массив байтов для одних операций, и как набор структур RGB для других. А кастовать так память все равно придется, например в аксессоре, который возврщает RGB &(ссылку), когда я не хочу работать с байтами.
Я хочу одновременно и скорость, и удобство. А прагмы/аттрибуты упаковки есть у всех компиляторов.

V>учитывая инлайность и способности компиляторов, я уверен, что порожденный код не уступит твоей структуре RGB, зато будет более надежным и переносимым, т.к. не будет зависеть от опций компилятора в плане упаковки структур, т.е. не будет вероятности "промазать".

Я _очень_ много времени провожу с asm, который генерит компилятор.

Что бы заставить IntelC++ Compiler сгенерировать код под MMX надо много колдовать с его #pragmaми и циклами for. И получившийся код будет не намного более переносимым, чем assembler, а другие компиляторы по нему будут генерить неэффективный код. Всё равно его придется брать в #ifdef __INTEL_COMPILER.

--------------------

Писать под абстрактную плаформу невозможно. Пишут всегда под конкретную, даже если их много( Mozilla/Boost/STLPort другие кросс-платфоменные проекты).
Ты видел, сколько в них #ifdef для WorkAroundов? И стоит #error "unknown compiler"?

Andrei N.Sobchuck wrote:
>
> Pzz>Однако OS/2 совсем недавно снята с производства. И до того они ее
> Pzz>зачем-то исправно поддерживали, и даже имели небольшой круг вполне
> Pzz>лояльных пользователей...
>
> Крупным клиентам впарили 15 лет назад. Приходится поддерживать.

Раньше пополаму очень любили вставлять в банкоматы. Причем не
какую-нибудь, а самую древнюю 16-битную версию.

Теперь вот в банкоматы стали вправлять NT. Я недавно видел банкомат, у
которого сверху стандартной банкомантной фигни висит message box, в
котором написано, что один из системных сервисов не запустился.

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

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

Pzz>Теперь вот в банкоматы стали вправлять NT. Я недавно видел банкомат, у
Pzz>которого сверху стандартной банкомантной фигни висит message box, в
Pzz>котором написано, что один из системных сервисов не запустился.

Pzz>Как подумаешь, а что, если сервис, который деньги со счета списывает,
Pzz>запустится, а тот, который купюры выдает — нет, карточку вставлять
Pzz>становится страшно...

Это еще ладно. Я вот BSOD на банкомате видел. Вот это действительно страшно!

vdimas wrote:

> _W>Напиши аналог boost::optional или boost::variant.
> Хм.. для variant необходимо что-то типа union.

Нет. Внутри boost::optional/variant просто используется буффер, который
по разному интерпретируется.

> В общем, сделать размеченный union частью языка, примерно как в
> спецификациях CORBA.

Кхм. Вы доку на boost::variant смотрели?

--
С уважением,
Alex Besogonov (alexy@izh.com)

vdimas,

> Если бы для С++ существовали в настоящий момент ср-ва рефакторинга, типа тех, что мы имеем для Java и C# <...>

Xrefactory пробовал?

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

S>Единственное я не понял о каком СШарп идет речь 2.0?
S>Вроде в более раннем реинтерпретацией памяти была usafe ?

unsafe был с самого начала и с тех пор не менялся, в том числе и в 2.0.

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

IT>Экономия места мне там не понравилась. Систему команд можно было сделать в два раза проще выкинув короткие версии команд и все эти ldarg.0, .1, .2, .3.

Ну типа размеры сборок уменьшали. по байту на команду — можно много съэкономить.

IT> С примитивными типами тоже намудрили. ldc команд почему-то 4, а conv и ldind по полной схеме. Можно было иметь вообще по одной команде, если сопроводить её целевым типом или брать его со стека.

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

IT>Загрузка самого типа делается через задницу — ldtoken с последующим вызовом Type.RuntimeTypeHandle. Нельзя для этого было команду отдельную сделать?

А это уже не совсем система команд.

IT> ldarg и ldloc — это суть одно и тоже.

Не факт. Вполне возможен JIT, который может их интерпретировать по разному. Опять же дополнительный контроль.

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

IT>>Экономия места мне там не понравилась. Систему команд можно было сделать в два раза проще выкинув короткие версии команд и все эти ldarg.0, .1, .2, .3.

AVK>Ну типа размеры сборок уменьшали. по байту на команду — можно много съэкономить.

Вот я и говорю — экономисты, блин. Сколько они сэкономили? Процентов 30? А систему команд замусорили.

IT>> С примитивными типами тоже намудрили. ldc команд почему-то 4, а conv и ldind по полной схеме. Можно было иметь вообще по одной команде, если сопроводить её целевым типом или брать его со стека.

AVK>Они там что то говорили на тему того, что это дает возможность JIT делать более мощные оптимизации с учетом всяких SSE и разной разрядности целевых процессоров.

Особенно к разрядности. Большинство примитивных типов прибито гвоздями к i4.

IT>>Загрузка самого типа делается через задницу — ldtoken с последующим вызовом Type.RuntimeTypeHandle. Нельзя для этого было команду отдельную сделать?

AVK>А это уже не совсем система команд.

Ну так и newobj не совсем система команд, но тем не менее это есть и это удобно.

IT>> ldarg и ldloc — это суть одно и тоже.

AVK>Не факт. Вполне возможен JIT, который может их интерпретировать по разному. Опять же дополнительный контроль.

Ну вот JIT там у себя и разобрался бы. Ему то всё равно, он же машина.

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


AVK>unsafe был с самого начала и с тех пор не менялся, в том числе и в 2.0.

Менялся, но это не важно. Ввели инлайн-массивы (для ускорения работы с интеропом).

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

S>Вроде в более раннем реинтерпретацией памяти была usafe ?

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

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

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

VD>Менялся, но это не важно. Ввели инлайн-массивы (для ускорения работы с интеропом).

Интероп это не ансейф.

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

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

VD>>Менялся, но это не важно. Ввели инлайн-массивы (для ускорения работы с интеропом).

AVK>Интероп это не ансейф.

Ага. А бутылка не ложка. И?
Я говорю о то для на что было расчитано расширение языка. Хотя конечно кроме интеропа это дело кое-где еще может пригодиться.