Пописал на С++... долго думал :) - Философия программирования

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

VD>Другое дело, что практика показывает, что спец.процессоры явно уступают идее JIT-компиляции.

Оп-па, немного не так. Те спец-процессоры, которые были предназначены, например, для Java являлись лишь каким-нить обычным ядром процессора (MIPS в одном из вариантов), который производил ИНТЕРПРЕТАЦИЮ байт-кода. Понятное дело, что на интерпретации далеко не уедешь.

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

Кстати, Jit можно оставить и там, по крайней мере его оптимизирующий механизм.

--------------
Система команд .Net-машины весьма выразительна и удобна, в отличие от x86. В архитектуре x86 чуть ли не половина команд — это пересылка м/у регистрами и стеком, что однозначно показывает слабость архитектуры. Для архитектуры MC68000 соотношение нужных команд к "паразитным" гораздо лучше. Поэтому приложения, просто перекомпилированные для этого процессора (C/C++) показывают лучшее быстродействие при той же тактовой частоте процессора и порождают меньший бинарник.

Так что, смысл в специально "заточенном" аппаратном процессоре есть.

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

S>>Такая грустная песня об автоматической сборке мысора и ValueType для большого кол-ва кратко живущих экземпляров...

VD>Какое отношение КОРБА имеет к GC? И какое отношение имеют ValueType-ы к GC? Что-то я ничего не понял.

Большинство CORBA IDL компиляторов переводят IDL-сущность struct в ValueType в .Net. (т.к. IDL-struct не может иметь семантики null).

Другое дело, что у srggal что-то не так с интерфейсами, как мне показалось, ибо большие количества объектов передаются обычно как sequence<MyStruct>, которые отображаются на MyStruct[] в C#. Массивы вэлью-типов в .Net — весьма эффективны и не напрягают GC, так что у него просто что-то не так. Или может его ORB дополнительно выполняет боксинг каждого элемента при маршаллинге?

Тогда в сад этот ORB, пусть юзает нормальный.

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

H>AFAIK есть утверждение — "Более безопасная система менее удобна".

что удобнее — пароль или аппаратный ключ?
а что безопаснее?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VD>Стабы наверно все же генерируеются генераторами кода idl2xxx. Но причем тут ОРБ? Он то скорее всего на плюсах написан.

Нет, написанны они на дотнете, и выполнены как форматтеры каналов или же в виде самих каналов (у кого как), т.е. используют инфраструктуру .Net Remoting, и серверное приложение активируется так же как Remoting на TCP.

Вот пример инициализации:

_channel = new IiopChannel(_port);
ChannelServices.RegisterChannel(_channel);
s_serverAPI = new ServerApiImpl();
RemotingServices.Marshal(s_serverAPI, "MyUriPath/IServerAPI", typeof(IServerAPI));

VD>При передаче данныех ОРБ-у может быть два сценария.
VD>1. Создание объектной ссылки. Тогда ОРБ управляет жизнью объекта.

Remoting управляет временем жизни. Можно вмешаться через ILease и ISponsor.

VD>2. Сериализация состояния объектоа. Так вот вэлью-типа принципиально невозможно передаватьп по ссылке. Так что они должны обязательно сериализоваться. Альтернативной является боксинг, но при этом вэлью-тип превращается в ссылочный со всеми вытекающими последствиями.

Сериализации подлежат только сущности, описанные в IDL как struct или valuetype (не путать с ValueType в .Net).
Те, которые interface, имеют базовый стаб от MarshalByRefObject.

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

Зато... трафик у CORBA минимально возможный.

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

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

Крупным клиентам впарили 15 лет назад. Приходится поддерживать.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

S>Смущает, если STL и BOOST их не использует, то и использовать их будет меньтшинство, соответсвенно маштабы проблемы — малы. использующмй ещё сорок раз подумает что он делает, есди делает что-то нетривиальное. Для улучшения и были введены xxx_cast

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

Из всех xxx_cast с моей т.з. имеют право на жизнь только dynamic_cast и static_cast. Использование остальных кастов явно сигнализирует об ошибке проектирования, или попытке совместить несовместимое.

Я предлагал вымести поганой метлой const_cast и reinterpret_cast, оставить синтаксис (MyType)var, но наделить его семантикой static_cast, правда с некоторыми ограничениями. http://www.rsdn.ru/Forum/Message.aspx?mid=1451602&only=1

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

GZ>Не-а. Глубина падения и одновременно мощности С++ значительно больше.

GZ>Возьми к примеру наложение структуры на адрес в памяти. Чрезвычайно полезная фича в некоторых случаях, как и опасная.

Почему опасная? Эти же данные в памяти как-то очутились, надо лишь работать с памятью "типизированно". Простое наложение структур на адрес в памяти несет еще одну опасность (помимо неправильной реинтерпретации), а именно — работа с НЕИНИЦИАЛИЗИРОВАННОЙ памятью. Я не зря предложил сохранить сигнатуру operator new.

Если же эти данные готовит в памяти некое API или третьесторонний тул, дык, пусть он возвращает заведомо типизированные указатели.

GZ>Или взять к примеру инициализацию структуры нулевыми значениями через memset. Ты уже ее уничтожил, а фича также очень полезная.

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

Смотри:

// просто структура
struct S1 {
int i, j, k;
char a, b, c;
};

int _tmain(int argc, _TCHAR* argv[]) {
    S1 *s1 = new S1();
        // вот тут ты хотел сделать memset? А зачем??? :))
    memset(s1, 0, sizeof(S1));
    s1->i = 10;
    delete s1;
    return 0;
}

Вот что получили:

int _tmain(int argc, _TCHAR* argv[]) {
    S1 *s1 = new S1();
00401010  push        10h  
00401012  call        operator new (401070h) 
00401017  add         esp,4 
0040101A  test        eax,eax 
0040101C  je          main+1Fh (40102Fh) 
0040101E  xor         ecx,ecx 
00401020  mov         edx,eax 
00401022  mov         dword ptr [edx],ecx 
00401024  mov         dword ptr [edx+4],ecx 
00401027  mov         dword ptr [edx+8],ecx 
0040102A  mov         dword ptr [edx+0Ch],ecx 
    memset(s1, 0, sizeof(S1));
00401031  xor         ecx,ecx 
00401033  mov         edx,eax 
00401035  mov         dword ptr [edx],ecx 
00401037  mov         dword ptr [edx+4],ecx 
0040103A  mov         dword ptr [edx+8],ecx 
0040103D  mov         dword ptr [edx+0Ch],ecx

Сравни выделенное

и забудь впредь про memset.

GZ>Можно запретить указатели, но это уже не будет С++.

А это здесь при чем??? Выкинуть указатели из С++ просто никак нельзя при всем желании.

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

VD>Согласен со всем кроме:
VD>

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

VD>Это явно выдумка. Сила типизации в С++ несравнимо ниже. Статическая типизация анлогична. Джененирики устраняют последние потуги к динмическим приведениям типов.

Я не говорю, что дженерики чего-то там не устраняют. Сказать честно, я уже прилично устал от 1.1, но пока не вышел релиз 2.0 вынуждены работать и выпускать продукты на нем.

Я лишь сказал, что мне с довольно завидной регулярностью приходится пользоваться брейкпоинтами и пошаговой отладкой на C#, и это факт. На С++ у меня такая потребность возникала куда как реже.

Кстати, когда писал на VB/VBA, тоже без пошаговой отладки не обходилось.

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

VD>Начать можно с глосария: http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prmd_stp_pobw.asp

Hardware abstraction layer (HAL). A kernel-mode component that contains hardware-specific code that handles low-level hardware operations such as input/output (I/O) interfaces, interrupt controllers, and multiprocessor communication mechanisms. The HAL abstracts, or hides, hardware-dependent details from the rest of the operating system.

Нового ничего не прочитал

Судя по поставленным минусам и отсутсвию плюсов здесь
Мое мнение никто больше не разделяет, тем не менее я останусь при нем

Даже если потом Оконную подсистему в этой ОС сделают на TCL

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

S>>>Такая грустная песня об автоматической сборке мысора и ValueType для большого кол-ва кратко живущих экземпляров...

VD>>Какое отношение КОРБА имеет к GC? И какое отношение имеют ValueType-ы к GC? Что-то я ничего не понял.

V>Большинство CORBA IDL компиляторов переводят IDL-сущность struct в ValueType в .Net. (т.к. IDL-struct не может иметь семантики null).

V>Другое дело, что у srggal что-то не так с интерфейсами, как мне показалось, ибо большие количества объектов передаются обычно как sequence<MyStruct>, которые отображаются на MyStruct[] в C#. Массивы вэлью-типов в .Net — весьма эффективны и не напрягают GC, так что у него просто что-то не так. Или может его ORB дополнительно выполняет боксинг каждого элемента при маршаллинге?

Тогда в сад этот ORB, пусть юзает нормальный.

Наконец-то конструктив

Согласен с Вами sequence<MyStruct> отображаются на MyStruct[] в C#.

Чтобы не вдаваться в подробности, которые я к тому же изрядно забыл

.

В чем был корень проблемы:


    union ValueType switch (unsigned short)
    {
            case xxx:
                short iVal;
            case yyyy:
                long lVal;
                ....
    };

    struct Prop
    {
        ...
        ValueType Value; 
    };

   Prop[][] GetMyStructs(...);

Потом, когда Prop[][] станет не нужным, память не будет сразу же освобождена, и освобождение может начаться именно тогда, когда это не очень нужно, например, когда прийдется выделять Prop[][] в результате следующего вызовова GetMyStructs(). Если же инициировать GC вручную, от будет орсвобождаться не только эта память, которую надо освободить, но вся память будет анализироваться.

ЗЫ
прошу простить мне мой "французский" с терминами СШарп знаком не сильно, возможно такую работу с массивами можно назвать каким нить ёмким словом чтобы сразу стало понятно, но я его не знаю.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

GZ>int a[10,10] — просто двухмерный массив. Лежит одним большим куском.
GZ>int a[10][10] — jagged массив. Массив строчек.

здесь

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

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

Распечатай float. Не забудь про Q-NAN, S-NAN, +iINF, +0, -0, денормализованные числа.

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

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

S>>Смущает, если STL и BOOST их не использует, то и использовать их будет меньтшинство, соответсвенно маштабы проблемы — малы. использующмй ещё сорок раз подумает что он делает, есди делает что-то нетривиальное. Для улучшения и были введены xxx_cast

S>>

V>Струструп в "Дизайн и эволюция С++" говорил примерно следующее (за дословность не ручаюсь, но смысл передам):
V>"Такие введения как xxx_cast были специально введены именно в таком ужасном и бросающемся глаза виде, чтобы явно выделять опасные места прогаммы. В идеале хотелось бы, чтобы программисты избегали использования этих конструкций".

V>Из всех xxx_cast с моей т.з. имеют право на жизнь только dynamic_cast и static_cast. Использование остальных кастов явно сигнализирует об ошибке проектирования, или попытке совместить несовместимое.

V>Я предлагал вымести поганой метлой const_cast и reinterpret_cast, оставить синтаксис (MyType)var, но наделить его семантикой static_cast, правда с некоторыми ограничениями. http://www.rsdn.ru/Forum/Message.aspx?mid=1451602&only=1

Таки Уважаемый — убедили

ЗЫ
хотя когда-то мне приходилось и reinterpret_cast использовать.

ЗЫЗЫ
Возникло подозрение, что на этапе поддержки ПО, все остальные касты, которые Вы хотите выбросить, используются на право и налево в большинестве проектов. Поскольку обычно ведут уже другие люди, которым вдаватьася в подробности архитектуры неохота, либо исправление ошибки ( или не дай бог ипрувмент ) — требуют слишком много времени, и проще наплевать на всё и использовать эти конструкциии и работу с памятью.
Предвижу — Вы скажете, что если бы была заложена правильная Архитектура — то все -бы прохолдило на ура. Но ведь много проектов с неправильной, в этом плане архитектурой, которые продаются/используются/сопровождаются. Кроме того, я участвовал в проекте с Правильной Архитектурой, где только о ней и думали ( как сделать так чтобы потом ихменять было легко

), ничего хорошего из этого не вышло. В данный момент — одна из моих задач — соправождение продукта, он кривой, написан через задницу, исправлять ошибки в нем — мучение, не говоря уже об импрувментах, НО он хорошо продается и много копий уже стоит у заказчиков. Так что — язык должен мне отказать в возможности эффективно решать поставленную задачу? Т.е. вместо того, чтобы прсле 2х часовых поисков взять и интерпретировать буффер памяти по-своему, я должен 40 часов заниматься изменением архитектуры, и потом выходить на полный цикл тестировани?

ЗЫЗЫЗЫ
Видимо убедился я в Вашей правоте еще не полностью. Страуструп — прав этого надо избегать, но ИНОГДА от ЭТОГО НИКУДА НЕ ДЕТЬСЯ

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	От:	vdimas
	Дата:	27.10.05 05:20
	Оценка:

	От:	vdimas
	Дата:	27.10.05 05:29
	Оценка:

	От:	Дарней
	Дата:	27.10.05 05:36
	Оценка:	+2

	От:	vdimas
	Дата:	27.10.05 05:44
	Оценка:

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	27.10.05 05:47
Оценка:

От:	_Winnie	C++.freerun
Дата:	27.10.05 07:27
Оценка: