Тут вынужден был писать тест на С++. В общем, то объем плевый. Но тем неменее давно я не получал столько внеполового секса на ровном месте. Большая часть этого секса была связана с общением с WinAPI, но один случай свяазанный именно с плюсами мне очень понравился. Собственно им я и хочу поделитсья. Написал я вот такой код:
_tprintf(_T(" (%d MHz)", 2200));
вместо 12345 естественно была перменная, а вместо _tprintf CString::Format, но не в этом дело. Компилятор его съел без вопросов. Каково же было мое удивление когда он вместо:
(2200 MHz)
вывел:
(-1782216848 MHz)
— подумл я.
PS
Думаю, самый зоркие уже догадались в чем проблема. Я тоже довольно быстро догадался, но впечатлиение осталось. Собственно им и делюсь.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Думаю, самый зоркие уже догадались в чем проблема. Я тоже довольно быстро догадался, но впечатлиение осталось. Собственно им и делюсь.
Ага, legacy C конструкции — то ещё уродство. Настоящий джедай пишет так:
VD> свяазанный именно с плюсами мне очень понравился.
Я все больше и больше убеждаюсь в том, что:
1) те, кто умело программирует на C++ никогда не называют его "плюсами";
2) те, кто называет C++ "плюсами" и даже вместо тега "ccode" используют тег "c#" очень часто расплачиваются за свое неуважение.
Видимо, вышеописанное есть одно из важнейших свойств языка.
Уважайте язык. Помните о мудрости, которая заключена в нем.
Здравствуйте, tarkil, Вы писали:
T>Здравствуйте, VladD2, Вы писали:
VD>>Думаю, самый зоркие уже догадались в чем проблема. Я тоже довольно быстро догадался, но впечатлиение осталось. Собственно им и делюсь.
T>Ага, legacy C конструкции — то ещё уродство. Настоящий джедай пишет так:
T>
Ко всем, кто принял участие в обсуждении этого вопроса.
А не кажется ли Вам, господа, что сие есть глубокая философия на мелком месте? Как известно, можно сделать весьма глубокие философские выводы даже из наблюдения скорлупы разбитого яйца. А уж из программерской ошибки... ух!
P.S. Убедительно прошу тему скорлупы и яйца (а равно и курицы) далее не развивать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ко всем, кто принял участие в обсуждении этого вопроса.
PD>А не кажется ли Вам, господа, что сие есть глубокая философия на мелком месте? Как известно, можно сделать весьма глубокие философские выводы даже из наблюдения скорлупы разбитого яйца. А уж из программерской ошибки... ух!
Согласен
PD>P.S. Убедительно прошу тему скорлупы и яйца (а равно и курицы) далее не развивать.
А вот это зря...
Сейчас появится Великий и Ужасный СГ и быстренько докажет, что это всё вообще фигня на фоне Оберона, особенно C#, и вообще Оберон тоже фигня на фоне нового супер проекта Вирта (о котором тот в целях борьбы с синтаксическим оверхедом упорно молчит), потом его раскатает тонким слоем Влад, Gaperton заявит о том, что мол и это тоже фигня, потому что уже давно есть в функциональных языках — а если нет, то значит и не надо, в промежутке мы с Sincler'ом наконец выясним, сколько потоков бывает в винде, а AVC наконец докажет, что C++ — это Паскаль, который Страуструп похитил у Вирта и переписал, специально уродуя и дьявольски посмеиваясь. Под это безобразие будет получено N-ное количество балов (за бушующий креатив) и только модератор в очередной раз подумает, что пора бы переностить философию в Священные войны...
Здравствуйте, VladD2, Вы писали:
VD>Тут вынужден был писать тест на С++. В общем, то объем плевый. Но тем неменее давно я не получал столько внеполового секса на ровном месте. Большая часть этого секса была связана с общением с WinAPI, но один случай свяазанный именно с плюсами мне очень понравился. Собственно им я и хочу поделитсья. Написал я вот такой код: VD>
VD>_tprintf(_T(" (%d MHz)", 2200));
VD>
VD>вместо 12345 естественно была перменная,
Влад, если ты не видишь, что пишешь, то никакой язык программирования тебе не поможет. НЕ спеши. Тише едешь -- дальше будешь.
Здравствуйте, AndreyFedotov, Вы писали:
PD>>P.S. Убедительно прошу тему скорлупы и яйца (а равно и курицы) далее не развивать.
AF>А вот это зря... AF>Сейчас появится Великий и Ужасный СГ и быстренько докажет, что это всё вообще фигня на фоне Оберона, особенно C#, и вообще Оберон тоже фигня на фоне нового супер проекта Вирта (о котором тот в целях борьбы с синтаксическим оверхедом упорно молчит), потом его раскатает тонким слоем Влад, Gaperton заявит о том, что мол и это тоже фигня, потому что уже давно есть в функциональных языках — а если нет, то значит и не надо, в промежутке мы с Sincler'ом наконец выясним, сколько потоков бывает в винде, а AVC наконец докажет, что C++ — это Паскаль, который Страуструп похитил у Вирта и переписал, специально уродуя и дьявольски посмеиваясь. Под это безобразие будет получено N-ное количество балов (за бушующий креатив) и только модератор в очередной раз подумает, что пора бы переностить философию в Священные войны...
Не понял! А где же я с Ruby? И _vovin со Smalltalk? Ты думаешь, мы в стороне стоять будем?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
AF>Сейчас появится Великий и Ужасный СГ и быстренько докажет, что это всё вообще фигня на фоне Оберона, особенно C#, и вообще Оберон тоже фигня на фоне нового супер проекта Вирта (о котором тот в целях борьбы с синтаксическим оверхедом упорно молчит), потом его раскатает тонким слоем Влад, Gaperton заявит о том, что мол и это тоже фигня, потому что уже давно есть в функциональных языках — а если нет, то значит и не надо, в промежутке мы с Sincler'ом наконец выясним, сколько потоков бывает в винде, а AVC наконец докажет, что C++ — это Паскаль, который Страуструп похитил у Вирта и переписал, специально уродуя и дьявольски посмеиваясь. Под это безобразие будет получено N-ное количество балов (за бушующий креатив) и только модератор в очередной раз подумает, что пора бы переностить философию в Священные войны...
Здравствуйте, VladD2, Вы писали:
VD>Думаю, самый зоркие уже догадались в чем проблема. Я тоже довольно быстро догадался, но впечатлиение осталось. Собственно им и делюсь.
Казалось бы, а при чем тут .NET ?
new RSDN@Home(1.2.0, 618) << new Message(); std::head::ear << "Chris Rea — Curse of the traveller";
Здравствуйте, VladD2, Вы писали:
VD>Тут вынужден был писать тест на С++. В общем, то объем плевый. Но тем неменее давно я не получал столько внеполового секса на ровном месте. Большая часть этого секса была связана с общением с WinAPI, но один случай свяазанный именно с плюсами мне очень понравился. Собственно им я и хочу поделитсья. Написал я вот такой код: VD>
VD>_tprintf(_T(" (%d MHz)", 2200));
VD>
VD>вместо 12345 естественно была перменная, а вместо _tprintf CString::Format, но не в этом дело. Компилятор его съел без вопросов. Каково же было мое удивление когда он вместо:
Да Влад , я вот всегда говорил, что warnings должны быть включены на максимальном уровне.
Здравствуйте, VladD2, Вы писали:
VD>Думаю, самый зоркие уже догадались в чем проблема. Я тоже довольно быстро догадался, но впечатлиение осталось. Собственно им и делюсь.
Казалось бы, причем здесь правописание.
В общем, модератор забань себя. (это шутка!)
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Под это безобразие будет получено N-ное количество балов (за бушующий креатив) и только модератор в очередной раз подумает, что пора бы переностить философию в Священные войны...
А ты хитрый! Мы еще не успели ничего этого сделать, а ты уже нашел способ получить себе все наши баллы! Я протестую!
VladD2,
> один случай свяазанный именно с плюсами мне очень понравился.
Он не с этим связан. Причина в сочетании выбора инструментов, требующих высокого внимания к деталям (sprintf), и отсутствия этого качества у пользователя.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
E>Не понял! А где же я с Ruby? И _vovin со Smalltalk? Ты думаешь, мы в стороне стоять будем?
E>
Прошу прощения Евгений , список героев, принимающих активнейщее участие в ристалище столь общирен, что я не упомянул весьма многих из достойнейших, ограничившись лишь теми, с кем вёл благочестивые беседы совсем недавно...
Здравствуйте, eugen1001, Вы писали:
E>Да Влад , я вот всегда говорил, что warnings должны быть включены на максимальном уровне.
Да, варнг был. Только я F5 нажал.
В общем, тут дело не в наличии или отсуствии варнингов. Тут дело в откровенно хреновом проектировании языка. Хорошо спроектированный язык просто не допустил бы такую ситацию.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
Ш>Влад, если ты не видишь, что пишешь, то никакой язык программирования тебе не поможет. НЕ спеши. Тише едешь -- дальше будешь.
Я вижу что пишу. А от опечаток никто не застрахован. Что до языка, думаю, ты прекрасно понимашь, что никакой язык кроме С/С++ не пропустит такую лажу.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А не кажется ли Вам, господа, что сие есть глубокая философия на мелком месте? Как известно, можно сделать весьма глубокие философские выводы даже из наблюдения скорлупы разбитого яйца.
Кому извесно?
PD> А уж из программерской ошибки... ух!
Это ошибки не программистов. Это ошибки дизайнеров языка, т.е. архитекторов. Потому и вопрос филосовский.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, tarkil, Вы писали:
T>Ага, legacy C конструкции — то ещё уродство.
Ага. Вот тольк они везде. В том же MFC почему-то нет возможности просто прибавить число к строке. А я знаете ли привык к хорошему.
T> Настоящий джедай пишет так:
T>
Ну, на то они и джедаи. Мне же нужно было просто информцию о тесте вывести в клипборд. CString::Format() для этого как-то удобнее нежели возня с потоками. Как-то проще видеть всю строку целиком.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>"warning C4002: too many actual parameters for macro '_T'".
Ага. Вот только если нажать F5 в студии, то видишь только результат. Я просто не ожидал, что компилятор так хладнокровно отнесется к такой ошибке. Шутка ли? В макрос с одинм параметром засунили 2, а компилятор только придупредил о чем-то.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, sch, Вы писали:
sch>Я все больше и больше убеждаюсь в том, что: sch>1) те, кто умело программирует на C++ никогда не называют его "плюсами";
Да ладно тебе за всех расписываться
sch>2) те, кто называет C++ "плюсами" и даже вместо тега "ccode" используют тег "c#" очень часто расплачиваются за свое неуважение.
Кстати, настоящие плюсовики, ну те которые самые настоящие, используют реальный тег для C++, а не его синоним "ccode".
sch>Видимо, вышеописанное есть одно из важнейших свойств языка. sch>Уважайте язык. Помните о мудрости, которая заключена в нем.
Кто же спорит. Предков надо чтить. Но и о заключённых в них глупостях тоже не стоит забывать, и главное не повторять их ошибки.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, sch, Вы писали:
sch>Я все больше и больше убеждаюсь в том, что: sch>1) те, кто умело программирует на C++ никогда не называют его "плюсами"; sch>2) те, кто называет C++ "плюсами" и даже вместо тега "ccode" используют тег "c#" очень часто расплачиваются за свое неуважение.
sch>Видимо, вышеописанное есть одно из важнейших свойств языка. sch>Уважайте язык. Помните о мудрости, которая заключена в нем.
всё-таки интересно, насколько сильно программирование на плюсах развивает снобизм
вероятно, это тоже одно из важнейших свойств языка
VladD2 wrote:
> C>"warning C4002: too many actual parameters for macro '_T'". > Ага. Вот только если нажать F5 в студии, то видишь только результат. Я > просто не ожидал, что компилятор так хладнокровно отнесется к такой > ошибке. Шутка ли? В макрос с одинм параметром засунили 2, а компилятор > только придупредил о чем-то.
Решается очень просто — есть ключик "treat warnings as erorrs".
Здравствуйте, VladD2, Вы писали:
VD>Ага. Вот тольк они везде. В том же MFC почему-то нет возможности просто прибавить число к строке. А я знаете ли привык к хорошему.
VD>Ну, на то они и джедаи. Мне же нужно было просто информцию о тесте вывести в клипборд. CString::Format() для этого как-то удобнее нежели возня с потоками. Как-то проще видеть всю строку целиком.
Надо просто учитывать, что Си был написан хрен знает сколько лет назад с упором на скорость и для вдумчивого программинга. А C++ предлагает совсем другие, типобезопасные тулзы.
CString s;
s.Format( " (%d MHz)", freq );
// дальше копируем строку (LPCTSTR)s в клипбоард
Сравни:
std::strstream s;
s << " (" << freq << " MHz)" << std::ends;
// дальше копируем строку s.str() в клипбоард
Те же самые две строки кода + неизменный код помещения в клипбоард. Про "они везде" — не понял. Я довольно давно уже обхожусь без них и ништяк. Ясно-понятно, что MFC'шный CString для этого не подходит, ну так и не пользуй, раз не подходит, strstream ничем не хуже.
Форматная строка наглядней, тут я полностью согласен. Увы, пока в C++ я не видел хорошей реализации форматной строки, можно писать это в минус. Кстати, почему никто не реализовал ещё? Заняться, что ли...
Шарп очень хорош — достойный конкурент C++. Вот он бы ещё .NET runtime не требовал — цены б ему не было.
Здравствуйте, IT, Вы писали:
sch>>2) те, кто называет C++ "плюсами" и даже вместо тега "ccode" используют тег "c#" очень часто расплачиваются за свое неуважение.
IT>Кстати, настоящие плюсовики, ну те которые самые настоящие, используют реальный тег для C++, а не его синоним "ccode".
Ага. И мы все знаем его имя.
А если серьезно, то думаю что и я и они(и) используют не [ccode] по вполне объяснимой и довольно банальной причине. Писать [ccode] вручную крайне утомительно. [c] значительно короче. Но я больее ленивый чем он(и)! Мне и это влом. На [c#] у меня в Янусе замаплен шорткат. И когда С/С++ код не имеет толичий от шарпа я использую [c#], так как это ровно одно ражатие клавиатуре.
Кстати, в этом абзаце все теги кроме [c#] были написаны вручную, так что это свого рода локальный подвиг.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>всё-таки интересно, насколько сильно программирование на плюсах развивает снобизм Д>вероятно, это тоже одно из важнейших свойств языка
Ты тоже заметил? Это видмо такой синдром причисление себя к высшей касте. Ну, фигня что тот с кем говоришь может знать не меньше, а то и больше тебя. Мы же избранные!
Слава богу этот синдром проявляется не у всех. И очень приятно, что как раз у более квалифицированных С++-ников он или вообще отсутствует, или выражен не так сильно.
ЗЫ
Что избранные не согласны? Тогда милости просим выражать свое несогласие.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>всё-таки интересно, насколько сильно программирование на плюсах развивает снобизм Д>вероятно, это тоже одно из важнейших свойств языка
Да , да а у тех кто работает не на C++ развивается комплекс неполноценности , сразу лезут в бочку на любую критику в сторону рабочего языка ... Но с опытом это тоже проходит.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
Ш>>Влад, если ты не видишь, что пишешь, то никакой язык программирования тебе не поможет. НЕ спеши. Тише едешь -- дальше будешь.
VD>Я вижу что пишу. А от опечаток никто не застрахован. Что до языка, думаю, ты прекрасно понимашь, что никакой язык кроме С/С++ не пропустит такую лажу.
Нда? Это какой же язык программирования может определить, что ты вместо 12345 написал 2200 (или наоборот)?
VD>В общем, тут дело не в наличии или отсуствии варнингов. Тут дело в откровенно хреновом проектировании языка.
Возможно и так > Хорошо спроектированный язык просто не допустил бы такую ситацию.
кстати _T() это не конструкция языка — это макрос, который компилятор даже и не видит.
При чём здесь язык?
ИМХО C++(а особенно его препроцессор) инструмент для того, кто знает, чего делает, а если не знает, так царствие ему...
При чём здесь язык
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, minorlogic, Вы писали:
M>>Да , да а у тех кто работает не на C++ развивается комплекс неполноценности
Д>Не льсти своему самолюбию — не развивается
M>>, сразу лезут в бочку на любую критику в сторону рабочего языка ...
Д>На критику в сторону рабочего языка реагируют все, особенно если это критика "не по делу"
Странно ты воспринимаешь , агресивно . Я например пишу на многих языках , в том числе и на яве и на C# и С и С++ . Почему ты на меня переносишь СВОИ проекции . ?
Здравствуйте, minorlogic, Вы писали:
M>Странно ты воспринимаешь , агресивно . Я например пишу на многих языках , в том числе и на яве и на C# и С и С++ . Почему ты на меня переносишь СВОИ проекции . ?
О боже, только психоаналитика мне не хватало для полного счастья
Я тоже на многих языках пишу, и все из них критикую, когда есть за что. А когда вижу необоснованную критику или нападки на обоснованную критику — считаю себя вправе вмешаться в спор. Разве это запрещено?
Здравствуйте, VladD2, Вы писали:
VD>В общем, тут дело не в наличии или отсуствии варнингов. Тут дело в откровенно хреновом проектировании языка. Хорошо спроектированный язык просто не допустил бы такую ситацию.
А может он просто не допустил бы таких макросов?
Здравствуйте, VladD2, Вы писали:
VD>Ты тоже заметил? Это видмо такой синдром причисление себя к высшей касте. Ну, фигня что тот с кем говоришь может знать не меньше, а то и больше тебя. Мы же избранные!
У небольших, находящихся на грани исчезновения, этнических групп/народностей наблюдается резкий всплеск т.н. "национального самосознания". На первое место выпячивается принадлежность к этой группе. Наиболее важными становятся цели по сохранению языка, обычаев, национальности. Что может принимать весьма причудливые и даже экстремальные формы. Например, негативное отношение к смешанным бракам, большое количество детей в "чистых" браках. Демонстративное общение между собой (а иногда и не только) исключительно на своем языке. Нежелание принимать чужие обычаи/правила для сохранения собственного, исторического уклада жизни. Со стороны может казаться, что такая этническая группа считает себя "пупом земли и центром мира". Хотя, на самом деле, эта концентрация на национальной самобытности всего лишь способ выживания.
Может быть то, что принимают за синдром высшей кастовости или снобизм на самом деле попытка сохранить себя как класс "С++ программистов"?
VD>ЗЫ
VD>Что избранные не согласны? Тогда милости просим выражать свое несогласие.
Ну вот, выразил несогласие. Почувствовал себя избранным. Приятно.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, tarkil, Вы писали:
T>Форматная строка наглядней, тут я полностью согласен. Увы, пока в C++ я не видел хорошей реализации форматной строки, можно писать это в минус. Кстати, почему никто не реализовал ещё? Заняться, что ли...
boost::format?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, sch, Вы писали:
Д>всё-таки интересно, насколько сильно программирование на плюсах развивает снобизм Д>вероятно, это тоже одно из важнейших свойств языка
Согласен, сам на С++ программирую давненько, но сказал бы — не снобизм — а педантизм.
Ибо если не думаю писать, можно написать оччень интересные вещи, и концов не соберешь.
И видимо, национально-лингвистическое самосознание программистов С++ основано именно на том, что нельзя просто так "топтать баттоны" как на шарпе, поскольку, даже если компилятор и скажет что есть ошибка, иногда очень сложно понять, что именно его неустраивает.
Как пример трактовка диграфов в шаблонах, проблемы с точками следования.
Люди понимающие такие вещи уже, невольно, повышают свою самооценку — и это есьт хорошо.
Это мое мнение, я не претендую на кровавую вендетту со стороны аппологетов СШарп.
Здравствуйте, eao197, Вы писали:
E>Может быть то, что принимают за синдром высшей кастовости или снобизм на самом деле попытка сохранить себя как класс "С++ программистов"?
А не торопишься ли ты C++ хоронить? Вроде рано. Снижение популярности имеется, но до критического порога ещё ой как далеко.
Ладно, фигня это всё. Лучше скажите (вопрос ко всем), видел кто-нибудь реализацию на плюсах удобных типобезопасных форматных строк в стиле .NET'овского String.Format? А то есть мысль сваять аналог самому. Удобнейшая штука ведь.
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, Дарней, Вы писали:
Д>>Здравствуйте, sch, Вы писали:
Д>>всё-таки интересно, насколько сильно программирование на плюсах развивает снобизм Д>>вероятно, это тоже одно из важнейших свойств языка
S>Согласен, сам на С++ программирую давненько, но сказал бы — не снобизм — а педантизм.
В чём то согласен.
C++ такой чудной язык, он в каждом человеке развивает что-то своё!
например у меня он развил жадность, снобизм, очень завышенную самооценку, лицемерие, цинизм и тд.
Я раньше думал почему я вот такой, а вот теперь понял что это всё C++!
Здравствуйте, GlebZ, Вы писали:
GZ>С уважением, Gleb.
Мои 5копеек:
ВНИМАНИЕ вопрос:
Какое кол-во из участников форума бреется опасной бритвой ?
Какое безопасной ?
Рискну предположить чот первые в меньшинстве.
Почему бы вторым не брится опасной бритвой ? Скажите — больше времени занимает бритьё ? Нет, не больше, просто ей надо уметь бриться, причем чтобы научиться — прийдется пройти через порезы ( иногда болезненные ). Следовательно понимая ( сознательно/подсознательно ), что Вы не совладаете с опасной бритвой — Вы выбираете безпасную ( осознанно или нет — другое дело ).
Так и с макросами, если не умеешь, можешь порезаться, почему бы тогда апологетам других языков, которые не в состоянии справиться с макросами просто не выбрать для себя безопасную бритву ?
Нет же, сначала надо допустить глупую ошибку, потом завести тему, и сношать сообщество С++ программистов очередными претензиями, которые кратко можно выразить так:
Неужели компилятор С\С++ такой тупой, что — не понимает что я тупой ?
PS
Извините, если обидел кого... GlebZ — лично к Вам это не относится = это так обощение по аналогии
Просто решил в Ваш тред запостить
Здравствуйте, WolfHound, Вы писали:
T>>Кстати, почему никто не реализовал ещё? Заняться, что ли... WH>boost::format?
Эк! А ведь слон-то прямо в кустах сидел...
Впрочем, удобной их форматную строку я не могу назвать при всём желании (если учесть необходимость форматирования). Так что наверное займусь на досуге генерацией велосипеда.
Здравствуйте, korzhik, Вы писали:
K>В чём то согласен. K>C++ такой чудной язык, он в каждом человеке развивает что-то своё! K>например у меня он развил жадность, снобизм, очень завышенную самооценку, лицемерие, цинизм и тд. K>Я раньше думал почему я вот такой, а вот теперь понял что это всё C++!
А я стал более внимателен к деталям
И читая форум по языку переодически узнаю что-то новое, т.е. понимаю, что никто не в силах объять необъятное.
Внимание вопрос:
Сколько вы знаете языков, в которых сообщество находило новые возможности использования яхыка, о которых авторы языка не задумывались и более того не подозревали ?
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, srggal, Вы писали:
S>>Люди понимающие такие вещи уже, невольно, повышают свою самооценку — и это есьт хорошо.
Д>хорошо — это когда думают о том, как правильно решить задачу. А не о том, где поставить скобку, чтобы прога не рухнула
Язык есть Язык, если нет понимания, что С++ это язык в котором не стоит игнорировать предупреждения, то тогда нестоит пенять на зеркало ( Русская народная поговорка ).
Кстати, понятие корректного написания программы — уже не входит в помножество правильного решения задачи ?
ИМХОИ ещё: Многое что грится в вину С/С++ можно отнести к свободе языка. Т.е. язык позволяет сделать очень многие вещи он дает свободу программирования хочешь пищи так — не хочешь пищи как хочешь. И вот за эту свободу и надо платить уменьшением дурабилити.
Здравствуйте, VladD2, Вы писали:
VD>Я вижу что пишу. А от опечаток никто не застрахован. Что до языка, думаю, ты прекрасно понимашь, что никакой язык кроме С/С++ не пропустит такую лажу.
Вы просто не умеете его готовить. А я вот например наслаждаюсь возможностями С++, которые позволяют мне писать мощные интрузивные контейнеры, в частности списки.
Наиудобнейшая вещь я вам скажу! Must Have!
Из указателя я всегда имею итератор, нет тупых переборов контейнера ради поиска элементов, и память выделяется только один раз когда CurveVertex создается, а узлы списка у него уже на борту.
void demo(Apex &apx, Curve &crv)
{
CurveVertex
*va = apx.vertices.first(),
*vb = new CurveVertex();
// замена вершины в нужном месте без гемороя и оверхеда:
// здесь порядок не имеет значения, пихаем в конец
apx.vertices.push_back(vb); // нулевой геморой, нулевой оверхед
// а здесь надо вставить куда надо:
crv.vertices.insert_after(vb, va); // нулевой геморой, нулевой оверхед
// лишнее удаляем
crv.vertices.cut(va); // нулевой геморой, нулевой оверхед
apx.vertices.cut(va); // нулевой геморой, нулевой оверхедdelete va;
}
Вот так вот. Крайне удобно, т.к. работаем только с указателями, которые всегда под рукой. И крайне эффективно.
Но вернемся к теме, для чего вообще я это пишу? Да просто С++ единственный язык котороый позволяет писать такие вещи без боли в области головы и заднего прохода .
А еще меня очень сильно прет partal specialization для геометрических примитивов:
template <int D, class T>
struct Point;
template <class T>
struct Point<2,T>
{
T x;
T y;
};
template <class T>
struct Point<3,T>
{
T x;
T y;
T z;
};
На халяву имеем кучу производных примитивов и алгоритмов которые становятся двумерными илли трехмерными простым тайпдефом.
А cтрашилки про printf — это просто развод для лохов. Всю жизнь юзаю sprintf т.к. iostream не люблю и ничего, ни одной ошибки еще не было. Вот попробуй на С# повтори те упражнения что я здесь привел, тогда и поговорим.
Здравствуйте, srggal, Вы писали:
S>Кстати, понятие корректного написания программы — уже не входит в помножество правильного решения задачи ?
ты совершенно правильно сказал — подмножество. Для решения задачи одного корректного написания соврешенно недостаточно.
А чем больше ты думаешь о корректном написании программы, тем меньше у тебя остается возможностей думать о правильном решении задачи.
Здравствуйте, Дарней, Вы писали:
Д>ты совершенно правильно сказал — подмножество. Для решения задачи одного корректного написания соврешенно недостаточно.
Я с Вашим выссказыванием полностью согласен, но на VBScript писать не буду
Здравствуйте, Дарней, Вы писали:
Д>О боже, только психоаналитика мне не хватало для полного счастья Д>Я тоже на многих языках пишу, и все из них критикую, когда есть за что. А когда вижу необоснованную критику или нападки на обоснованную критику — считаю себя вправе вмешаться в спор. Разве это запрещено?
Я к тому и веду , что у меня не возникает желания защищать нападки на язык , тем более если таковой в защите не нуждается .
Здравствуйте, srggal, Вы писали:
S>Внимание вопрос: S> Сколько вы знаете языков, в которых сообщество находило новые возможности использования яхыка, о которых авторы языка не задумывались и более того не подозревали ?
Вопросом на вопрос , а ты считаешь что это преимущество ???
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, srggal, Вы писали:
S>>Внимание вопрос: S>> Сколько вы знаете языков, в которых сообщество находило новые возможности использования яхыка, о которых авторы языка не задумывались и более того не подозревали ?
M>Вопросом на вопрос , а ты считаешь что это преимущество ???
Я считаю, что это хороший пример свободы предоставляемой языком, о которой я говорил здесь
Здравствуйте, srggal, Вы писали:
S> Какое кол-во из участников форума бреется опасной бритвой ? S> Какое безопасной ?
S>Рискну предположить чот первые в меньшинстве.
Я бы сказал, количество таких людей равняется числу программистов на Коболе. О них слышали, но их не видели. S>Почему бы вторым не брится опасной бритвой ? Скажите — больше времени занимает бритьё ? Нет, не больше, просто ей надо уметь бриться, причем чтобы научиться — прийдется пройти через порезы ( иногда болезненные ). Следовательно понимая ( сознательно/подсознательно ), что Вы не совладаете с опасной бритвой — Вы выбираете безпасную ( осознанно или нет — другое дело ).
Чего-то я не понял. Ты хочешь отказаться от C++? Тебя многие не поймут.
S>Так и с макросами, если не умеешь, можешь порезаться, почему бы тогда апологетам других языков, которые не в состоянии справиться с макросами просто не выбрать для себя безопасную бритву ?
А, это о макросах. Вообще-то в С++ можно многим порезаться. Только вот макросы настолько мощная штука, что я думаю, отказаться от них практически невозможно. (шаблоны как замену макросам, а такое здесь проходило, не признаю ).
S>Нет же, сначала надо допустить глупую ошибку, потом завести тему, и сношать сообщество С++ программистов очередными претензиями, которые кратко можно выразить так: S> Неужели компилятор С\С++ такой тупой, что — не понимает что я тупой ?
Нет. Почему компилятор не помогает моим великим мыслям. Есть задачи, для которых важно как я делаю. И в этом случае С++ неоценим. Но есть задачи где важнее что я делаю. И тут С# значительно продуктивнее чем С++. Потому как о многих вещах и не надо задумываться.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, srggal, Вы писали:
S>> Какое кол-во из участников форума бреется опасной бритвой ? S>> Какое безопасной ?
S>>Рискну предположить чот первые в меньшинстве. GZ>Я бы сказал, количество таких людей равняется числу программистов на Коболе. О них слышали, но их не видели.
Рискну сказать, что я пытался научиться, и ремень есть у меня для правки и бритва жилетт.., но колво порезов перерасло в стойкое нежпалание преодолевать трудности
S>>Почему бы вторым не брится опасной бритвой ? Скажите — больше времени занимает бритьё ? Нет, не больше, просто ей надо уметь бриться, причем чтобы научиться — прийдется пройти через порезы ( иногда болезненные ). Следовательно понимая ( сознательно/подсознательно ), что Вы не совладаете с опасной бритвой — Вы выбираете безпасную ( осознанно или нет — другое дело ).
GZ>Чего-то я не понял. Ты хочешь отказаться от C++? Тебя многие не поймут.
Речь идет об инструментах языка С++, и тем более не о моих предпочтениях.
GZ>А, это о макросах. Вообще-то в С++ можно многим порезаться. Только вот макросы настолько мощная штука, что я думаю, отказаться от них практически невозможно. (шаблоны как замену макросам, а такое здесь проходило, не признаю ).
Макросы зачастую хорошо использовать в связке с шаблонами, так сказать для упращения инстанцирования, и не только.
S>> Неужели компилятор С\С++ такой тупой, что — не понимает что я тупой ? GZ>Нет. Почему компилятор не помогает моим великим мыслям.
Для помощи свои великим мыслям — пишите свой препроцессор Темв поднимаtncz с завидной переодичностью.
GZ>Есть задачи, для которых важно как я делаю. И в этом случае С++ неоценим. Но есть задачи где важнее что я делаю. И тут С# значительно продуктивнее чем С++. Потому как о многих вещах и не надо задумываться.
В ЯБЛОЧКО, т.е. одни решаем на одном языке вторые на втором, причем эти предпочтения субъективны. Ибо в силу того, что С++ я знаю лучше СШарп, то многие вещи мне проще сделать на С++, но могут быть люди у которых все наоборот.
От себя еще добалю, что при выборе предпочтительного языка реализации следует учитывать собственный уровень знания языка, а при самой реализации на выбраном языке писаьт надо острожно, если не чуствуешь себя НэтивСпикером
Здравствуйте, srggal, Вы писали:
S>Рискну сказать, что я пытался научиться, и ремень есть у меня для правки и бритва жилетт.., но колво порезов перерасло в стойкое нежпалание преодолевать трудности
У некоторых это возникло и в языках.
Если в жизни любишь риск,
Сформатируй жесткий диск
S>Для помощи свои великим мыслям — пишите свой препроцессор Темв поднимаtncz с завидной переодичностью.
В большинстве случаев это изничтожение воробьев на крыше конкретного дома №16 с помощью запуска баллистической ракеты с подводной лодки. Да и к тому же, кто даст гарантию, что я сам не допущу ошибок.
Вобщем, я не понимаю общего фанатизма в метапрограммировании.
GZ>>Есть задачи, для которых важно как я делаю. И в этом случае С++ неоценим. Но есть задачи где важнее что я делаю. И тут С# значительно продуктивнее чем С++. Потому как о многих вещах и не надо задумываться.
S>В ЯБЛОЧКО, т.е. одни решаем на одном языке вторые на втором, причем эти предпочтения субъективны. Ибо в силу того, что С++ я знаю лучше СШарп, то многие вещи мне проще сделать на С++, но могут быть люди у которых все наоборот.
Эээ, нет. Тут проблема такая. В семантике каждый может ошибиться. Но ошибки синтаксические компилятор должен находить. И в С# большинство находит. За счет этого можно больше времени уделять семантике чем синтаксису. Поверь мне, после того как попишешь в обоих языка, твое мнение станет объективным и доказуемым.
S>От себя еще добалю, что при выборе предпочтительного языка реализации следует учитывать собственный уровень знания языка, а при самой реализации на выбраном языке писаьт надо острожно, если не чуствуешь себя НэтивСпикером
Скажу от себя, лучше знать больше языков разных и хороших. Тогда новый язык не станет для тебя каким-то непонятным, и сможешь сходу пользоваться всеми его фичами. А в результате сможешь выбирать оптимальный путь для решения конкретной задачи.
Здравствуйте, GlebZ, Вы писали:
GZ>>>Есть задачи, для которых важно как я делаю. И в этом случае С++ неоценим. Но есть задачи где важнее что я делаю. И тут С# значительно продуктивнее чем С++. Потому как о многих вещах и не надо задумываться.
S>>В ЯБЛОЧКО, т.е. одни решаем на одном языке вторые на втором, причем эти предпочтения субъективны. Ибо в силу того, что С++ я знаю лучше СШарп, то многие вещи мне проще сделать на С++, но могут быть люди у которых все наоборот. GZ>Эээ, нет. Тут проблема такая. В семантике каждый может ошибиться. Но ошибки синтаксические компилятор должен находить. И в С# большинство находит.
Должен заметить, что синтаксические ошибки компиляторы С\С++ тоже нахоодят крайне надежно.
Если речь идет о конкретной ошибке в макросе с которой начался тред, то приплетать сюда СШарп в части компиляции и поиска синтаксических ошибок — вообще некорректно, ввиду отсутсвия препроцессора в СШарп
Ибо сказано: Хочешь сделать что-нить хорошо — сделай все сам, хочешь сделать еще лучше — не делай ничего.
GZ>За счет этого можно больше времени уделять семантике чем синтаксису. Поверь мне, после того как попишешь в обоих языка, твое мнение станет объективным и доказуемым.
Что до семантики это завсегда да, это согласен, в чистом С\С++ семантика прикладной программы выглядет ужасающей, но есть библиотеки ГИ/ГУИ ДатаАкссес и все такое, если их использовать, колво реализованной семантики на строку кода ( хороший термин получился ) увеличивается. Если бы Вы писали на чистом СШарп а не дотНетФреймворк, то уверяю вас, кол-во семантики В ваших программах на строку кода, примерно соответсвовало С\С++. Но как нет в Шарпе препроцессора, так нет и Шарпа без дотНетФреймворк ( во всяком случае я не слышал ).
Так что, обсуждая простоту реализации семантики Вы невольно вынуждены передергивать, причем не по своей вине, следовательно в жтом отношении СШарп и С\С++ сложно сравнивать.
ИМХО: Предвижу, Вы скажете о мэнаджед С++, и его "дикой" наглядности. Сразу скажу, Реализация мэнэджэд С++ была притянута за уши К дотНэт Фрэймворк, отсюда и ноги.
Итого имеем: что как ни крути сравнение возможностей реализации семантики чистого языка С++ и СШарп не корректно
GZ>Скажу от себя, лучше знать больше языков разных и хороших. Тогда новый язык не станет для тебя каким-то непонятным, и сможешь сходу пользоваться всеми его фичами. А в результате сможешь выбирать оптимальный путь для решения конкретной задачи.
Ок, конкретный пример, я неплохо разобрался с шаблонами на С++, насколько это поможет мне в разборках с дженерикаим с СШарп? Очень мало поможет , больше бы помогло знание дженериков на джаве.
Соответсвенно, при освоении нового языка существенно может помочь знание языка похожего на изучаемый.
Или, философский вопрос как знание ассемблер поможет освоить бэктреккинг в ПРОЛОГ ?
Здравствуйте, srggal, Вы писали:
S>Должен заметить, что синтаксические ошибки компиляторы С\С++ тоже нахоодят крайне надежно.
А чем препроцессор не часть языка? S>Если речь идет о конкретной ошибке в макросе с которой начался тред, то приплетать сюда СШарп в части компиляции и поиска синтаксических ошибок — вообще некорректно, ввиду отсутсвия препроцессора в СШарп
Вообще-то он есть. Но маааааленький S>Ибо сказано: Хочешь сделать что-нить хорошо — сделай все сам, хочешь сделать еще лучше — не делай ничего.
Логично
GZ>>За счет этого можно больше времени уделять семантике чем синтаксису. Поверь мне, после того как попишешь в обоих языка, твое мнение станет объективным и доказуемым. S>Что до семантики это завсегда да, это согласен, в чистом С\С++ семантика прикладной программы выглядет ужасающей, но есть библиотеки ГИ/ГУИ ДатаАкссес и все такое, если их использовать, колво реализованной семантики на строку кода ( хороший термин получился ) увеличивается. Если бы Вы писали на чистом СШарп а не дотНетФреймворк, то уверяю вас, кол-во семантики В ваших программах на строку кода, примерно соответсвовало С\С++. Но как нет в Шарпе препроцессора, так нет и Шарпа без дотНетФреймворк ( во всяком случае я не слышал ). S>Так что, обсуждая простоту реализации семантики Вы невольно вынуждены передергивать, причем не по своей вине, следовательно в жтом отношении СШарп и С\С++ сложно сравнивать.
Обшибочка вышла. Я не имел ввиду библиотеки(хотя библиотеки тоже немаловажно). Я имел ввиду именно язык. Одно то, что у меня нет проблемы зацикливания ссылок уже многого стоит, и много времени экономит. Много времени экономят, те же делегаты. Много времени экономит, то что я вообще не думаю о указателях. И т.д. и т.п. Безусловно, за это есть плата в том смысле, что нельзя управлять ручками ресурсами компьютера. Но то что функциональность пишется значительно быстрее, и он значительно проще выглядит — это факт.
S>ИМХО: Предвижу, Вы скажете о мэнаджед С++, и его "дикой" наглядности. Сразу скажу, Реализация мэнэджэд С++ была притянута за уши К дотНэт Фрэймворк, отсюда и ноги.
Нет, не буду. Я абсолютно согласен.
S>Итого имеем: что как ни крути сравнение возможностей реализации семантики чистого языка С++ и СШарп не корректно
Если говорить о том, когда решаются аналогичные задачи, то вполне уместна. И тут у каждого есть свои плюсы.
GZ>>Скажу от себя, лучше знать больше языков разных и хороших. Тогда новый язык не станет для тебя каким-то непонятным, и сможешь сходу пользоваться всеми его фичами. А в результате сможешь выбирать оптимальный путь для решения конкретной задачи. S>Ок, конкретный пример, я неплохо разобрался с шаблонами на С++, насколько это поможет мне в разборках с дженерикаим с СШарп? Очень мало поможет
Достаточно поможет. Большинству же помогло. Отличаются лишь частности. Но поскольку и там, и сям пишешь одновременно, то переваривать такие частности очень сложно. Цель то одна, реализации только разные. S>Соответсвенно, при освоении нового языка существенно может помочь знание языка похожего на изучаемый.
Почти. Языки — это сборки разных фичей придуманных в программировании. И если знать эти фичи, то язык который их поддерживает будет удивлять только синтаксисом.
S>>Что до семантики это завсегда да, это согласен, в чистом С\С++ семантика прикладной программы выглядет ужасающей, но есть библиотеки ГИ/ГУИ ДатаАкссес и все такое, если их использовать, колво реализованной семантики на строку кода ( хороший термин получился ) увеличивается. Если бы Вы писали на чистом СШарп а не дотНетФреймворк, то уверяю вас, кол-во семантики В ваших программах на строку кода, примерно соответсвовало С\С++. Но как нет в Шарпе препроцессора, так нет и Шарпа без дотНетФреймворк ( во всяком случае я не слышал ). S>>Так что, обсуждая простоту реализации семантики Вы невольно вынуждены передергивать, причем не по своей вине, следовательно в жтом отношении СШарп и С\С++ сложно сравнивать. GZ>Обшибочка вышла. Я не имел ввиду библиотеки(хотя библиотеки тоже немаловажно). Я имел ввиду именно язык. Одно то, что у меня нет проблемы зацикливания ссылок уже многого стоит, и много времени экономит. Много времени экономят, те же делегаты. Много времени экономит, то что я вообще не думаю о указателях. И т.д. и т.п. Безусловно, за это есть плата в том смысле, что нельзя управлять ручками ресурсами компьютера. Но то что функциональность пишется значительно быстрее, и он значительно проще выглядит — это факт.
ИМХО: давно набив руку — я не задумываюсь об указателях, это я в том смысле что субъективно процитированное выше , кому-то много времени экономит суппер boost и ФастДелегаты на С++
S>>Итого имеем: что как ни крути сравнение возможностей реализации семантики чистого языка С++ и СШарп не корректно GZ>Если говорить о том, когда решаются аналогичные задачи, то вполне уместна. И тут у каждого есть свои плюсы.
Ок, в силу предыдуших моих ответов, грить можно, убедили, но есть одна попровочка — разговор субъективный.
GZ>>>Скажу от себя, лучше знать больше языков разных и хороших. Тогда новый язык не станет для тебя каким-то непонятным, и сможешь сходу пользоваться всеми его фичами. А в результате сможешь выбирать оптимальный путь для решения конкретной задачи. S>>Ок, конкретный пример, я неплохо разобрался с шаблонами на С++, насколько это поможет мне в разборках с дженерикаим с СШарп? Очень мало поможет GZ>Достаточно поможет. Большинству же помогло. Отличаются лишь частности. Но поскольку и там, и сям пишешь одновременно, то переваривать такие частности очень сложно. Цель то одна, реализации только разные.
Мало общего, Рантайм и Компайл тайм, и куча нюансов. ИМХО помощь только в том, что уже знакомо понятие обобщенный и все
S>>Соответсвенно, при освоении нового языка существенно может помочь знание языка похожего на изучаемый. GZ>Почти. Языки — это сборки разных фичей придуманных в программировании. И если знать эти фичи, то язык который их поддерживает будет удивлять только синтаксисом.
Я не имел в виду циклы и все подобные фичи, я имел в виду более продвинутые фичи, а они обычно отличают один я зык от другого, и именно из-за них делается выбор в пользу того или иного языка реализации.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Cyberax, Вы писали: C>>Решается очень просто — есть ключик "treat warnings as erorrs".
VD>Есть лучшее решение. Ну, вы знаете какое.
Да знаем мы, знаем... Только сдаётся мне, что лет через 20 мы будем наблюдать шоу "Последний самурай", в котором мерзопакостный молодняк будет лезть со своим Oberoid##, а кое-кто от них будет отмахиваться Generic'ами и приводить в качестве примера статистику с миллионами приложений, написаных на C#
Здравствуйте, AndreyFedotov, Вы писали:
AF> Да знаем мы, знаем... Только сдаётся мне, что лет через 20 мы будем наблюдать шоу "Последний самурай", в котором мерзопакостный молодняк будет лезть со своим Oberoid##, а кое-кто от них будет отмахиваться Generic'ами и приводить в качестве примера статистику с миллионами приложений, написаных на C#
Ну, главно шоб оборзеший молоднык не вставлял палки в колесЫ ретроградамъ.
И вообще, я так понимаю, что массы не понимают ранимую душу поэта... готового продать душу любому дьяволу который прдожит на сольд больше чем педыдущий.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, tarkil, Вы писали:
T>Ладно, фигня это всё. Лучше скажите (вопрос ко всем), видел кто-нибудь реализацию на плюсах удобных типобезопасных форматных строк в стиле .NET'овского String.Format? А то есть мысль сваять аналог самому. Удобнейшая штука ведь.
А то?
System::Format()
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, tarkil, Вы писали:
T>Ладно, фигня это всё. Лучше скажите (вопрос ко всем), видел кто-нибудь реализацию на плюсах удобных типобезопасных форматных строк в стиле .NET'овского String.Format? А то есть мысль сваять аналог самому. Удобнейшая штука ведь.
Boost.Format, baby!
Кстати, String.Format не является статически типизированным в отличии от Boost.Format.
Здравствуйте, VladD2, Вы писали:
VD>Тут вынужден был писать тест на С++. В общем, то объем плевый. Но тем неменее давно я не получал столько внеполового секса на ровном месте. Большая часть этого секса была связана с общением с WinAPI, но один случай свяазанный именно с плюсами мне очень понравился. Собственно им я и хочу поделитсья. Написал я вот такой код:
VD>Думаю, самый зоркие уже догадались в чем проблема. Я тоже довольно быстро догадался, но впечатлиение осталось. Собственно им и делюсь.
Я довольно малоопытный программист, но мысли свои выскажу.
Не стоит ожидать от С++ черезчур высокой заботливости и подстраховывания, этот язык рассчитан не на это. Конечно, я знаю все эти разговоры про то что рынку абсолютно пофик на "программистские причуды" главное чтобы продукт был написан во время и без ошибок. Но! Всё-же, ведь мы проводим долгие вечера в некотором роде "беседуя" с компилятором, — Попробуй скомпилировать вот это, а? Что не получаеться? Это? А так? Вероятно что это всё-таки откладывает какой-то отпечаток в мозгу (кстати, психологи: хорошая тема для диплома — Несознательная замена человеческого общения).
И вот С++ компилятор возлагает очень большую ответственность на программиста но кроме этого он в некотором "льстит" программисту, считая его гениальным, даже компилируя
for(char a = 255;a<=256;a++); он думает, — Я конечно это слабо понимаю но вероятно какой-то хитроумный замысел за этим стоит, так что лучше не буду ничего говорить.
Так что С++ даёт громадную свободу в сочетании с удобством программисту и рассчитан на то что человек знает что он делает, никто-же не даёт скальпель начинающему или когда нужно отрезать кусок колбасы (тут можно C# или Java)? Я просто не видел ещё языка с такой свободой, представьте, можно ведь опуститься даже до того чтобы изменить синтаксис языка, не говоря уже о таких фичах как свободное управление памятью и т.д..! По-моему, именно свобода и сделала С++ таким популярным.
Короче. Если принять аналогию что программирование на ассемблере сродни строительству из кирпичей а программирование на VB -- составлению домов из готовых блоков, то программирование на C++ это лепка из пластилина.
Всё, кому не нравиться, собери себя garbage collector'ом
Жду минусов
... << А писал я этот бред на RSDN@Home 1.1.4 stable rev. 510, под звуки ДДТ — Tы будешь вечно>>
Здравствуйте, Чипсет, Вы писали:
Ч>Короче. Если принять аналогию что программирование на ассемблере сродни строительству из кирпичей а программирование на VB -- составлению домов из готовых блоков, то программирование на C++ это лепка из пластилина.
программирование на C++ — это сборка из разноразмерных железобетонных модулей от множества производителей, с последующей подгонкой несовпадающих частей при помощи напильника и ловлей множества представителей царства насекомых, которые пробрались внутрь мимо увлеченно работающих напильниками строителей
Здравствуйте, GlebZ, Вы писали:
GZ>Эээ, нет. Тут проблема такая. В семантике каждый может ошибиться. Но ошибки синтаксические компилятор должен находить. И в С# большинство находит. За счет этого можно больше времени уделять семантике чем синтаксису. Поверь мне, после того как попишешь в обоих языка, твое мнение станет объективным и доказуемым.
Позволю себе вмешаться. Синтаксическую ошибку в программе VladD2 компилятор нашел, но посчитал ее предупреждением. Не обращать внимание на предупреждения не стоит ни в С++, ни в С#. Как минимум, надо на них посмотреть и решить, стоит ли игнорировать, а лучше вообще убрать.
А что касается вывода, то ошибка в спецификации строки вывода ловится только в рантайме. Вот такое
float f = 9;
Console.WriteLine("{0,8:d}", f);
компилируется на ура
А вот такое
Console.WriteLine("{0,8:d}");
и вообще работает, только выводит не то, что автор хотел , а то, что здесь есть.
Здравствуйте, Чипсет, Вы писали:
Ч>Не стоит ожидать от С++ черезчур высокой заботливости и подстраховывания, этот язык рассчитан не на это.
+1
>>И вот С++ компилятор возлагает очень большую ответственность на программиста но кроме этого он в некотором "льстит" программисту, считая его гениальным, даже компилируя Ч>for(char a = 255;a<=256;a++); он думает, — Я конечно это слабо понимаю но вероятно какой-то хитроумный замысел за этим стоит, так что лучше не буду ничего говорить.
Я бы так выразился. Он не ограничивает мою свободу написать ерунду, но при этом и не ограничивает свободу написать вполне хороший код. C# во многом предостерегает от того, чтобы написать ерунду, но при этом лишает меня свободы делать то, что я хочу и брать при этом ответственность за последствия на себя.
Позволю себе вольную аналогию.
C++ — язык свободного (иначе западного) общества. Можете делать все, что не запрещено законом, но ответственность за свои действия сами и несете. Вляпаетесь в неприятную историю, (прогорите, например. как бизнесмен) — сами и выпутывайтесь.
А .Net мне незабвенной памяти развитой социализм напоминает — партия позаботится о том, чтобы Вы влево-вправо не ходили, вели себя как положено, что явно не разрешено — не делали, и если будете все эти правила соблюдать — ваша пайка Вам гарантирована.
Ко всем участникам боевых действий в этом треде (и к себе тоже, конечно !
Предлагаю военные действия прекратить и заключить мирный договор на следующих принципах
1. Адепты C++ признают, что есть задачи, для которых C# и .Net лучше подходят, чем unmanaged C++ код.
2. Адепты C# и .Net признают, что есть задачи, для которых C++ и unmanaged C++ код подходят лучше , чем C# и .Net.
3. И те, и другие признают, что есть задачи, для которых ни то, ни другое не очень подходит, а лучше всего подходит
нечто третье.
Всем, кто с этим согласен — прошу, поставьте плюс.
Всем, кто с этим несогласен — прошу, поставьте минус.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Позволю себе вмешаться. Синтаксическую ошибку в программе VladD2 компилятор нашел, но посчитал ее предупреждением. Не обращать внимание на предупреждения не стоит ни в С++, ни в С#. Как минимум, надо на них посмотреть и решить, стоит ли игнорировать, а лучше вообще убрать.
+1. Только есть некоторая разница. Это компилятор посчитал ее предупреждением. Хотя и ясно, что подобная ошибка предупреждением быть не может. Непонятно о чем думали разработчики компилятора.
PD>А что касается вывода, то ошибка в спецификации строки вывода ловится только в рантайме. Вот такое PD> float f = 9; PD> Console.WriteLine("{0,8:d}", f); PD>компилируется на ура
Абсолютно правильно компилируется. Это ошибка семантики программиста. Но есть достаточно много ситуаций когда среда может говорить об ошибке постфактум. Типа:
//такое даст ошибку компиляцииbool b=true;
int i=(int)fl;
//такое даст ошибку при исполненииbool b=true;
object obj=b;
int i=(int)b;
Но по крайней мере я знаю, что компилятор старается помочь мне.
PD>А вот такое PD> Console.WriteLine("{0,8:d}"); PD>и вообще работает, только выводит не то, что автор хотел , а то, что здесь есть.
Это семантическая ошибка программиста. Среда всего-лишь выполнила то, что программист ей сказал. А что программист хотел, ни один язык не предугадает.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Всем, кто с этим согласен — прошу, поставьте плюс. PD>Всем, кто с этим несогласен — прошу, поставьте минус.
Ну соглашусь, а дальше? Будем делать мультиязыковые проекты? Из скольких языков? Каких языков? Как между ними роли распределять?
Ну например, есть C++ проект и C++ программисты. Совсем не сложно обучить их Python-у или Ruby чтобы соединить код на Python/Ruby в одном проекте (там вообще все просто -- либо C++ код становится расширением Ruby/Python, либо в C++ приложение интегрируется Python/Ruby интерпритатор).
Если взять уже C++ и C#, то C# на так прост, как Python или Ruby. Нужно потратить гораздо больше времени на его изучение. Более того, мышление менять -- это ж надо привыкнуть, что вместо шаблонов в compile-time рефлекшен в run-time использовать. Или делегаты вместо функторов. А что делать после изучения? Как объединять код на C++ и код на C#? Через COM? А если в C++ проекте COM-а вообще не было никогда, его что насильно в C++ тащить, чтобы с C# проинтегрироваться?
А если C++ и Java? Через JNI? Так ведь еще умудриться нужно сложную C++ структуру через JNI в Java передать. Или наоборот. А если не JNI, тогда что? CORBA? Почти что COM, но другое
Все нижесказанное является моим крайне субъективным ИМХО.
Как мне кажется, не так уж много программистов смогут одинаково эффективно работать на нескольких (больше трех) языках и использовать разные платформы. Даже в достаточно близких языках, таких как C++, Java, C# есть свои идиомы. Поэтому многое, что мы привыкли делать в C++ (шаблоны, RAII), в Java уже бесполезно. То, что в Java или C# элементарно выполняется с помощью рефлекшена, в C++ достигается долгими экспериментами со сторонними библиотеками или самописным велосипедом. Переключение между этими языками уже требует переключения сознания на другой способ оценки задачи и способов ее решения.
А если взять более далекие друг от друга языки? Например, C++ и Ruby, или C# и Python, или Java и Erlang? Сколько потребуется времени и сил, чтобы подготовить специалиста, способного одинаково хорошо пользоваться такими связками? А если количество языков увеличится, скажем, C++ + Java + Erlang + Python?
Но программировать это одно дело, здесь опыт нажить можно со временем. А вот проектировать кто будет? Какой опыт нужен проектировщику, чтобы сказать -- вот это на Python, вот это на Erlang, вот это в виде C++ расширения для Python, вот это только на C++, вот это на Java... И существует вероятность того, что написав какой-то фрагмент на Python можно убедиться, что он нифига не подходит. Даже после рефакторингов, оптимизаций и C++ных вставок. Большой кусок работы будет выброшен в мусор?
Другой фактор здесь, который следует учитывать -- это нравится ли конкретный язык конкретному разработчику или нет. В теории понятно, что можно взять С++ и Python, и на их основе делать проект. Но если мне, как заядлому C++нику, не нравится Python из-за своего структурирования пробелами и необходимостью передавать в каждый метод класса параметр self, то я буду откровенно филонить в использовании Python и пытаться больше кода сделать на C++. И если мне язык не нравится, то нет никакой гарантии, что я буду его хорошо знать и применять эффективные способы программирования на Python -- более вероятно, что буду делать "абы работало".
Да и человеческий фактор в мультиязыковых проектах становится гораздо более важным, чем в моноязыковых. Взаимозаменяемость может стремительно уйти в ноль. Просто потому, что бывает мало знать основы языка, нужно знать еще и кучу специализированных фреймворков для конкретного языка. Например, я смогу разобрать простые программы на Java, но в EJB я полный ноль. Поэтому с ходу заменить любого из наших Java-программистов я не смогу. Так же, как и EJB Java программист не сможет заменить C++ Qt программиста. Только после длительного переобучения.
Так что признать, что какой-то язык где-то лучше, где-то хуже -- этого мало. Гораздо более важный вопрос -- как с этим жить дальше?
Может оказаться, что выбор в качестве языка разработки всего одного языка приведет к менее эффективному или более дорогому решению. Но это окупится низкими рисками и большей предсказуемостью разработки.
Все сказанное базируется на моем собственном опыте. Некоторое время назад у нас в компании часть проектов стартовали на Java вместо C++. А сейчас я обдумываю как лучше подружить Ruby и C++. При этом наибольшее количество вопросов вызывают не технические детали, а перечисленные выше политические, психологические и социальные проблемы.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, minorlogic, Вы писали:
M>Странно ты воспринимаешь , агресивно . Я например пишу на многих языках , в том числе и на яве и на C# и С и С++ . Почему ты на меня переносишь СВОИ проекции . ?
У люди которые одинаково много пишут на разных языках синдром кастовости обычно почти не проявляется. Более того они обычно более адекватно воспринимают разные мнения о языках. Так что ты видимо не тот случай. Но тех случаев тут хватает.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>хорошо — это когда думают о том, как правильно решить задачу. А не о том, где поставить скобку, чтобы прога не рухнула
Вот именно. И очень смешно смотреть как кто-то гордится тем, что хорошо умеет подстилать соломку и совершенно не замечает того, что на этот процесс его сили и уходят.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndreyFedotov, Вы писали: AF> Да знаем мы, знаем... Только сдаётся мне, что лет через 20 мы будем наблюдать шоу "Последний самурай", в котором мерзопакостный молодняк будет лезть со своим Oberoid##, а кое-кто от них будет отмахиваться Generic'ами и приводить в качестве примера статистику с миллионами приложений, написаных на C#
А чего долго ждать? Если к дженерикам второго шарпа народ был более-менее психологически готов, то обычная первая реакция шарпдевелопера на LINQ из тройки совершенно нецензурна. Хейльсберг еще молод, так что в ближайшие десять лет я ожидаю наблюдать развернутую борьбу девелоперов с собственными предрассудками. Когда те, кто уже постиг очередной уровень, бегают с выпученными глазами и орут, как все круто, а те, кто еще нет, в упор не понимают нахрена оно вообще, при этом с остервенением отбиваясь от тех, кто еще не понял даже скрытого смысла автоматической сборки мусора
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А что касается вывода, то ошибка в спецификации строки вывода ловится только в рантайме. Вот такое PD> float f = 9; PD> Console.WriteLine("{0,8:d}", f); PD>компилируется на ура PD>А вот такое PD> Console.WriteLine("{0,8:d}"); PD>и вообще работает, только выводит не то, что автор хотел , а то, что здесь есть.
Ты будешь смеяться, но есть такой тул, как ReSharper. Он прекрасно отлавливает вот эту ситуацию. И, в принципе, не исключено, что в следующей версии отловит и первую ошибку.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали:
E>Как мне кажется, не так уж много программистов смогут одинаково эффективно работать на нескольких (больше трех) языках и использовать разные платформы. Даже в достаточно близких языках, таких как C++, Java, C# есть свои идиомы. Поэтому многое, что мы привыкли делать в C++ (шаблоны, RAII), в Java уже бесполезно. То, что в Java или C# элементарно выполняется с помощью рефлекшена, в C++ достигается долгими экспериментами со сторонними библиотеками или самописным велосипедом. Переключение между этими языками уже требует переключения сознания на другой способ оценки задачи и способов ее решения.
E>А если взять более далекие друг от друга языки?
Давай возьмем.
Вот Типичное Современное Приложение. Это маахонький веб сайт.
Он написан с использованием: SQL для бэкенда VB.NET для миддл-тайер JScript для клиент презентейшн.
Достаточно далекие языки? А тем не менее, пишется все командой в полтора человека, а при необходимости и в одного. Что, мало такого народу?
Конечно, больше тех, кто владеет только двумя смежными технологиями. Ну скажем SQL+C#, или HTML/CSS/JScript+VBScript... Теи не менее, нет никакой проблемы работать одновременно на двух языках, один из которых декларативный, а другой — императивный. Поначалу трудно работать на синтаксически близких языках. Но это проходит с тренировкой.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Ввиду того, что я выступил с мирной инициативой, в дискуссии по языкам не участвую. замечание только по одному моменту.
GZ>+1. Только есть некоторая разница. Это компилятор посчитал ее предупреждением. Хотя и ясно, что подобная ошибка предупреждением быть не может. Непонятно о чем думали разработчики компилятора.
Правильно они думали. Если Вас это не устраивает — поставьте
/WX Treats all warnings as errors. For a new project, it may be best to use /WX in all compilations; resolving all warnings will ensure the fewest possible hard-to-find code defects.
и наслаждайтесь. А вот наоборот, увы, не получится — error не обойдешь. Поэтому если что-то хоть в 1% случаев может быть верным (хитрость программиста), то не надо это запрещать. Пусть сам запрещает, если хочет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Правильно они думали. Если Вас это не устраивает — поставьте
PD>/WX Treats all warnings as errors. For a new project, it may be best to use /WX in all compilations; resolving all warnings will ensure the fewest possible hard-to-find code defects.
Warning все таки нужны. Их цель ты правильно определил. Обман компилятора. И чтобы об этом не забывали. Хочешь забыть — пиши прагму.
PD>и наслаждайтесь. А вот наоборот, увы, не получится — error не обойдешь. Поэтому если что-то хоть в 1% случаев может быть верным (хитрость программиста), то не надо это запрещать. Пусть сам запрещает, если хочет.
Вот мне хотелось бы узнать, в чем может состоять хитрость программиста. Если бы я знал хотя бы об одном потенциальном способе использования такого кода, то я не против. Но этого способа я не знаю.
Здравствуйте, Sinclair, Вы писали:
S>Ты будешь смеяться, но есть такой тул, как ReSharper. Он прекрасно отлавливает вот эту ситуацию. И, в принципе, не исключено, что в следующей версии отловит и первую ошибку.
Я не буду смеяться, но вроде бы в Unix был когда-то tool , который отлавливал несоответсвия всякие в С программах еще когда С++ не было. В частности, несоответствия между описанием функции и ее вызовом (если помнишь, в версии С Кернигана-Ритчи прототипов не было, а вызывать неописанную функцию в С даже сейчас компилятор позволит, предупреждение, правда, будет. Не исключаю, что и для C++ такие тулзы либо есть, либо их можно написать. Но мне они не нужны.
Здравствуйте, Sinclair, Вы писали:
E>>А если взять более далекие друг от друга языки?
S>Давай возьмем. S>Вот Типичное Современное Приложение. Это маахонький веб сайт.
Может быть веб-сайт и является Типичным Современным Приложением (хотя, имхо, нужно было бы сказать, что только в одной области), то вот "маахонький" -- это совершенно не пример. Команды в 1.5-2-3-3.25 человек -- они по своему живут, многие вещи там гораздо проще. А вот если объем проекта за 250 тысяч строк переваливает, и команда от десятка человек, тут уже другие законы. Имхо, опять же.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Позволю себе вмешаться. Синтаксическую ошибку в программе VladD2 компилятор нашел, но посчитал ее предупреждением. Не обращать внимание на предупреждения не стоит ни в С++, ни в С#. Как минимум, надо на них посмотреть и решить, стоит ли игнорировать, а лучше вообще убрать.
Несомненно. Но вот если уж компилятор считает сообщение не важным, то ошибка ну, никак не должна приводить к разным AV/GPF. А именно такой случай мы имеем.
PD>А что касается вывода, то ошибка в спецификации строки вывода ловится только в рантайме. Вот такое
> float f = 9; PD> Console.WriteLine("{0,8:d}", f);
PD>компилируется на ура
PD>А вот такое
PD> Console.WriteLine("{0,8:d}");
PD>и вообще работает, только выводит не то, что автор хотел , а то, что здесь есть.
Понимаш ли, есть огромная разница между логическими ошибками и ошбками вроде описаной в теме. В Шарпе без ансэйва ты просто не сможешь повредить память, а в данном случае неверно поставленная скобка привела именно к повреждению памяти. И слава богу, что все было относительно безопасно. Как-то я видел намного более забавную ошибку. Человек в следствии сложных манипуляций возвратил их функции указатель на стековую переменную. Какое-то время код даже работал, а потом... потом были 2 недели поиска ошибки.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Понимаш ли, есть огромная разница между логическими ошибками и ошбками вроде описаной в теме. В Шарпе без ансэйва ты просто не сможешь повредить память, а в данном случае неверно поставленная скобка привела именно к повреждению памяти. И слава богу, что все было относительно безопасно. Как-то я видел намного более забавную ошибку. Человек в следствии сложных манипуляций возвратил их функции указатель на стековую переменную. Какое-то время код даже работал, а потом... потом были 2 недели поиска ошибки.
Как-то пришлось подключать библиотеку, которая в своей функции удаляло строку, а потом создавала свою вместо нее. Долго разбирался. Сначала долго разбирался с ошибкой поскольку строку по незнанию я создавал в стеке. Потом долго выбивал из них, хотя бы скомпиленную библиотеку с msvcrt.dll, поскольку ихнюю строку должен был удалять уже я. Пробивать нормальный интерфейс от них по некоторым причинам было нельзя.
Здравствуйте, Kluev, Вы писали:
K>Но вернемся к теме, для чего вообще я это пишу? Да просто С++ единственный язык котороый позволяет писать такие вещи без боли в области головы и заднего прохода .
А что-нибудь ещё кроме списков он умеет?
K>А еще меня очень сильно прет partal specialization для геометрических примитивов:
Watch this:
public abstract class Person : ObjectBase
{
[Required, MaxValue(50)] public abstract string FirstName { get; set; }
[Required, MaxValue(50)] public abstract string LastName { get; set; }
public abstract Gender Gender { get; set; }
[MaxValue(100)] public abstract string Address { get; set; }
}
В результате имеем:
1. EditableObject с возможностью принятия/отката изменений и проверки флага IsDirty.
2. Маппинг во что угодно и из чего угодно (БД, XML и т.п.).
3. Визуальный баиндинг на контролы, включая гриды.
4. Автоматическую валидацию с подсветкой контролов и/или исключениями.
5. Базовый DataAccessor с готовыми основными CRUDL операциями.
6. Возможность тонкой настройки всего вышеперечисленного декларативными средствами.
Всё это без потери производительности, наглядности и тухлых указателей.
Сможешь такое на C++?
K>А cтрашилки про printf — это просто развод для лохов. Всю жизнь юзаю sprintf т.к. iostream не люблю и ничего, ни одной ошибки еще не было. Вот попробуй на С# повтори те упражнения что я здесь привел, тогда и поговорим.
Повторить что, твой код или решение конечной задачи?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, eao197, Вы писали:
E>Может быть веб-сайт и является Типичным Современным Приложением (хотя, имхо, нужно было бы сказать, что только в одной области),
Просто в этой области выпускаются сотни приложений в день. E>то вот "маахонький" -- это совершенно не пример. Команды в 1.5-2-3-3.25 человек -- они по своему живут, многие вещи там гораздо проще.
Какие вещи? Мы все еще говорим о лингвистических способностях или уже о чем? E>А вот если объем проекта за 250 тысяч строк переваливает, и команда от десятка человек, тут уже другие законы. Имхо, опять же.
Я правильно понимаю, что ты считаешь такие проекты прибежищем для людей, неспособных программировать на трех языках?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Я не буду смеяться, но вроде бы в Unix был когда-то tool , который отлавливал несоответсвия всякие в С программах еще когда С++ не было. В частности, несоответствия между описанием функции и ее вызовом (если помнишь, в версии С Кернигана-Ритчи прототипов не было, а вызывать неописанную функцию в С даже сейчас компилятор позволит, предупреждение, правда, будет. Не исключаю, что и для C++ такие тулзы либо есть, либо их можно написать. Но мне они не нужны.
Я тоже не исключаю возможности таких средств для C++. Хотя, конечно, писать их значительно труднее.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Как-то я видел намного более забавную ошибку.
А как тебе вариант, когда перед очередным запуском программы для поисках ошибки нужно было переустанавливать по новой всю систему? Дело было под DOS, непроинициализированный указатель, по которому всякий раз аккуратно затиралась FAT в памяти. Программа отлично работала, затем первая же запись на диск кем угодно, синхронизация FAT с диском и сушите вёсла. Причём, почему-то на других машинах всё было нормально, всего лишь затиралась область с системными сообщениями
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Чипсет, Вы писали:
Ч>И вот С++ компилятор возлагает очень большую ответственность на программиста но кроме этого он в некотором "льстит" программисту, считая его гениальным, даже компилируя
Я 12 лет был гениальным... я устал.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Чипсет, Вы писали:
Ч>>И вот С++ компилятор возлагает очень большую ответственность на программиста но кроме этого он в некотором "льстит" программисту, считая его гениальным, даже компилируя
IT>Я 12 лет был гениальным... я устал.
Дело не в гениальности конкретного человека а в том как компилятор оценивает программиста
... << А писал я этот бред на RSDN@Home 1.1.4 stable rev. 510, под звуки тишины>>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А .Net мне незабвенной памяти развитой социализм напоминает — партия позаботится о том, чтобы Вы влево-вправо не ходили, вели себя как положено, что явно не разрешено — не делали, и если будете все эти правила соблюдать — ваша пайка Вам гарантирована.
Ерунда. В умелых руках .NET может "такое же" как и C++. Винду я ещё не убивал, но студия у меня склеивала ласты неоднократно Вот только не занимаясь этим умышленно сделать такое практически невозможно. Так что аналогия не верна.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Чипсет, Вы писали:
IT>>Я 12 лет был гениальным... я устал.
Ч>Дело не в гениальности конкретного человека а в том как компилятор оценивает программиста
Компилятор программиста? Мощно задвинул
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Чипсет, Вы писали:
IT>>>Я 12 лет был гениальным... я устал.
Ч>>Дело не в гениальности конкретного человека а в том как компилятор оценивает программиста
IT>Компилятор программиста? Мощно задвинул
Траву новую подвезли
Я же приводил пример, что компилятор С++ оценивает программиста как опытного и потому допускает гораздо больше чем компиляторы других языков, считая что программист четко знает что он делает и его не надо доставать ошибками и подстраховками.
... << А писал я этот бред на RSDN@Home 1.1.4 stable rev. 510, под звуки тишины>>
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Позволю себе вмешаться. Синтаксическую ошибку в программе VladD2 компилятор нашел, но посчитал ее предупреждением. Не обращать внимание на предупреждения не стоит ни в С++, ни в С#. Как минимум, надо на них посмотреть и решить, стоит ли игнорировать, а лучше вообще убрать.
VD>Несомненно. Но вот если уж компилятор считает сообщение не важным, то ошибка ну, никак не должна приводить к разным AV/GPF. А именно такой случай мы имеем.
Компилятор ничего не считает. Он предоставляет это на мое усмотрение. Извини за обширное цитирование
/Wn, /WX, /Wall, /wnn, /wdn, /wen, /won (Warning Level)
/Wn
/WX
/Wall
/wnn
/wdn
/wen
/won
These options specify how the compiler generates warnings for a given compilation.
Option
/Wn Specifies the highest level of warning generated by the compiler. Valid warning levels for n range from 0 to 4:
Level 0 disables all warnings.
Level 1 displays severe warnings.
Level 2 displays all level 1 warnings and warnings less severe than level 1. Level 2 is the default warning level at the command line.
Level 3 displays all level 2 warnings and all other warnings recommended for production purposes.
Level 4 displays all level 3 warnings plus informational warnings, which in most cases can be safely ignored. This option should be used only to provide "lint" level warnings and is not recommended as your usual warning level setting.
For a new project, it may be best to use /W4 in all compilations. This will ensure the fewest possible hard-to-find code defects.
/Wall Enables all warnings, including those disabled by default. See Compiler Warnings That Are Off By Default.
/WX Treats all warnings as errors. For a new project, it may be best to use /WX in all compilations; resolving all warnings will ensure the fewest possible hard-to-find code defects.
/wnn Specifies the level for a particular warning. The first parameter sets the warning level (same as /Wn) and the second parameter is the actual warning number.
Так что если я хочу, я могу считать серьезным любое предупреждение и блокировать в этом случае создание .obj и .exe (/WX). Или, наоборот, игнорировать все предупреждения и брать полностью ответственность на себя (/W0). Или промежуточно. Или конкретно по тому или иному предупреждению.
Кстати, когда я в своем пректе поставил Level4, на меня высыпали штук 20 предупреждений, абсолютно несущественных. Так что я немедленно вернулся к дефолтному Level 3.
Между прочим, аналогичное было всегда. По крайней мере, в BC 3.1 нечто подобное тоже было.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ко всем, кто принял участие в обсуждении этого вопроса.
PD>А не кажется ли Вам, господа, что сие есть глубокая философия на мелком месте? Как известно, можно сделать весьма глубокие философские выводы даже из наблюдения скорлупы разбитого яйца. А уж из программерской ошибки... ух!
PD>P.S. Убедительно прошу тему скорлупы и яйца (а равно и курицы) далее не развивать.
Действительно, не "Философия", а обмен колкостями.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>Я не буду смеяться, но вроде бы в Unix был когда-то tool , который отлавливал несоответсвия всякие в С программах еще когда С++ не было. В частности, несоответствия между описанием функции и ее вызовом (если помнишь, в версии С Кернигана-Ритчи прототипов не было, а вызывать неописанную функцию в С даже сейчас компилятор позволит, предупреждение, правда, будет. Не исключаю, что и для C++ такие тулзы либо есть, либо их можно написать. Но мне они не нужны. S>Я тоже не исключаю возможности таких средств для C++. Хотя, конечно, писать их значительно труднее
int main()
{
printf("%d", 1.2345);
return 0;
}
Compiling: main.cpp
main.cpp: In function `int main()':
main.cpp:5: warning: int format, double arg (arg 2)
Здравствуйте, Sinclair, Вы писали:
E>>Может быть веб-сайт и является Типичным Современным Приложением (хотя, имхо, нужно было бы сказать, что только в одной области), S>Просто в этой области выпускаются сотни приложений в день.
И?
Это будет Типичным Современным Приложением в области махоньких веб сайтов. Потому что крупные веб-порталы или Web-сайты крупных корпораций или торговых компаний будут разрабатываться совсем на других технологиях и совсем другими командами (хотя SQL и JavaScript, с большой вероятностью там будут присутствовать ).
А ведь есть еще и другие направления. Системный и околосистемный софт, офисные пакеты, корпоративные информационные системы, встраиваемые системы, игры для различных платформ, телекоммуникации, оборонка, научные расчеты, и пр. и пр.
E>>то вот "маахонький" -- это совершенно не пример. Команды в 1.5-2-3-3.25 человек -- они по своему живут, многие вещи там гораздо проще. S>Какие вещи? Мы все еще говорим о лингвистических способностях или уже о чем?
Обо всем. Во-первых, маленькие команды, как мне кажется, чаще всего состоят из разработчиков одного уровня знаний и способностей. И если они успешно справляются со своими проектами то, вероятно, эти способности повыше среднестатистических. Поэтому в маленьких командах нет проблем с применением большого количества разных языков просто потому, что сами разработчики в состоянии легко освоить эти языки.
Во-вторых, в маленьких командах все на виду. Очень легко получить помощь, совет, а иногда и по рукам за откровенные ляпы. Поэтому и процесс обучения новым языкам/технологиям в маленьких командах проходит быстрее и легче.
В-третьих, маленькой команде проще согласованно выбрать новый язык для конкретной задачи. Можно обсудить достоинства Python по отношению к Ruby, или Smalltalk по отношению к Python. Можно даже сесть за один компьютер и вместе поиграться в каком-нибудь Dolphin Smalltalk или RDE. И проще учесть мнение одного из членов команды. Например, если мне не нравится способ структурирования программ пробелами в Python, то это легко принять во внимание и сделать выбор в пользу Ruby. Если же в команде таких категорических мнений не одно-два, а пять-десять-пятнадцать, то выбор языка можно делать только волевым решением. Как результат -- наличие разработчиков, не довольных выбранным языком разработки.
В-четвертых, сама разработка в небольшой команде проще, чем в большой. Просто из-за отсутствия политики и лишних накладных расходов на общение.
E>>А вот если объем проекта за 250 тысяч строк переваливает, и команда от десятка человек, тут уже другие законы. Имхо, опять же. S>Я правильно понимаю, что ты считаешь такие проекты прибежищем для людей, неспособных программировать на трех языках?
Нет, не правильно.
Я считаю, что есть некоторый диапазон, в котором для проекта очень важно иметь минимальное количество использованных языков. Скажем, объем проекта от 200 до 500 тысяч строк и команда от 7 до 20 человек. Как раз по перечисленным мной ранее факторам (взаимозаменяемость членов команды, проблемы в интеграции разноязыковых компонент, сложность в одновременной работе на более чем 3-х языках). А уже как следствие этого -- данные проекты успешно могут решаться людьми, которые знают не более 2-х или 3-х языков. Вроде как собрать команду из 5-ти корифеев сложно, но возможно. Собрать команду из 15-ти корифеев, имхо, вообще не реально. А еще менее реально -- заставить их работать сообща
Если проект больше то, имхо, он состоит из почти самостоятельных частей и команд, попадающих в указанный диапазон. И для каждого из таких продпроектов действуют те же самые правила.
PS. Цифры по объемам команд/проектов взяты мной исходя из своего личного впечатления, никакой объективной статистикой не подкреплены.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>И? E>Это будет Типичным Современным Приложением в области махоньких веб сайтов. Потому что крупные веб-порталы или Web-сайты крупных корпораций или торговых компаний будут разрабатываться совсем на других технологиях и совсем другими командами (хотя SQL и JavaScript, с большой вероятностью там будут присутствовать )
А теперь давай сравним количество маленьких сайтов и крупных порталов.
E>А ведь есть еще и другие направления. Системный и околосистемный софт, офисные пакеты,
Системного и околосистемного софта пишется бесконечно мало. E>корпоративные информационные системы,
КИС тоже пишутся как минимум на двух языках; чаще — больше. E>встраиваемые системы, игры для различных платформ,
Даже игры применяют не менее двух языков — язык платформы (С/С++) и язык игровых скриптов. Плюс еще и местами ассемблер. E>телекоммуникации, оборонка, научные расчеты, и пр. и пр.
Телекоммуникаций, оборонки и научных расчетов пишется бесконечно мало. E>Обо всем. Во-первых, маленькие команды, как мне кажется, чаще всего состоят из разработчиков одного уровня знаний и способностей.
Конечно. E>И если они успешно справляются со своими проектами то, вероятно, эти способности повыше среднестатистических.
То есть ты хочешь сказать, что редкие, как золото, крупные команды по разработке масштабного софта дают основной вклад в эту среднюю статистику? Очень она у тебя странная, эта средняя статистика. E>Поэтому в маленьких командах нет проблем с применением большого количества разных языков просто потому, что сами разработчики в состоянии легко освоить эти языки.
Ну да. А разработчики в больших командах, надо полагать, не в состоянии. E>Во-вторых, в маленьких командах все на виду. Очень легко получить помощь, совет, а иногда и по рукам за откровенные ляпы. Поэтому и процесс обучения новым языкам/технологиям в маленьких командах проходит быстрее и легче.
E>В-третьих, маленькой команде проще согласованно выбрать новый язык для конкретной задачи.
Это уже никак не относится к способностям самих программистов. E>В-четвертых, сама разработка в небольшой команде проще, чем в большой. Просто из-за отсутствия политики и лишних накладных расходов на общение.
Как и это. E>Я считаю, что есть некоторый диапазон, в котором для проекта очень важно иметь минимальное количество использованных языков. Скажем, объем проекта от 200 до 500 тысяч строк и команда от 7 до 20 человек. Как раз по перечисленным мной ранее факторам (взаимозаменяемость членов команды, проблемы в интеграции разноязыковых компонент, сложность в одновременной работе на более чем 3-х языках).
Нет, погоди. Ты аргументируешь сложность работы на более чем трех языках наличием команд, сформированных под воздействием сложности работы на более чем трех языках. E>А уже как следствие этого -- данные проекты успешно могут решаться людьми, которые знают не более 2-х или 3-х языков. Вроде как собрать команду из 5-ти корифеев сложно, но возможно. Собрать команду из 15-ти корифеев, имхо, вообще не реально. А еще менее реально -- заставить их работать сообща
Итак, мы имеем тысячи команд из двух-трех корифеев, и десятки команд из десятков, скажем так, не-корифеев.
E>Если проект больше то, имхо, он состоит из почти самостоятельных частей и команд, попадающих в указанный диапазон. И для каждого из таких продпроектов действуют те же самые правила.
А, ну то есть на самом деле у нас большой проект (в котором программеры патологически неспособны думать на трех языках) делится на маленькие команды, в которых программеры вполне способны думать на трех языках. Забавно.
E>PS. Цифры по объемам команд/проектов взяты мной исходя из своего личного впечатления, никакой объективной статистикой не подкреплены.
Ты вообще много знаешь команд с численностью в 20 человек? Да их во всем мире не так уж много. Практика показывает, что 2 языка осваивают чуть не 90% современных программеров. И не осваивают третий только потому, что не успевают. К тридцати годам избежать освоения трех языков можно только при помощи строгого поста, воздержания, и ежедневной молитвы. Такая уж у нас отрасль.
Оценить масштабы катастрофы можно исходя из здравого смысла. Найди мне хоть одного SQL девелопера, который не владеет еще одним языком. А всего SQL девелоперов — миллионы.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
E>>И? E>>Это будет Типичным Современным Приложением в области махоньких веб сайтов. Потому что крупные веб-порталы или Web-сайты крупных корпораций или торговых компаний будут разрабатываться совсем на других технологиях и совсем другими командами (хотя SQL и JavaScript, с большой вероятностью там будут присутствовать ) S>А теперь давай сравним количество маленьких сайтов и крупных порталов.
По количеству? Качеству? Стоимости? Прибыльности?
E>>А ведь есть еще и другие направления. Системный и околосистемный софт, офисные пакеты, S>Системного и околосистемного софта пишется бесконечно мало.
Миллионы строк ядер операционных систем, серверов приложений, СУБД, веб-серверов, компиляторов и пр. тебе кажется бесконечно малой величиной?
E>>корпоративные информационные системы, S>КИС тоже пишутся как минимум на двух языках; чаще — больше. E>>встраиваемые системы, игры для различных платформ, S>Даже игры применяют не менее двух языков — язык платформы (С/С++) и язык игровых скриптов. Плюс еще и местами ассемблер. E>>телекоммуникации, оборонка, научные расчеты, и пр. и пр. S>Телекоммуникаций, оборонки и научных расчетов пишется бесконечно мало.
Мне кажется, ты слишком увлечен веб-разработкой.
E>>И если они успешно справляются со своими проектами то, вероятно, эти способности повыше среднестатистических. S>То есть ты хочешь сказать, что редкие, как золото, крупные команды по разработке масштабного софта дают основной вклад в эту среднюю статистику? Очень она у тебя странная, эта средняя статистика.
Под крупными командами ты что понимаешь? Команда в 10 разработчиков -- это редкость? А в 20-ть?
Извини меня, но над какими проектами ты работаешь?
Между тем команда из 10-ти человек уже в 5-ть раз больше команды из 2-х человек.
E>>Поэтому в маленьких командах нет проблем с применением большого количества разных языков просто потому, что сами разработчики в состоянии легко освоить эти языки. S>Ну да. А разработчики в больших командах, надо полагать, не в состоянии.
Не скажу за всех, но многие не в состоянии. Чем больше команда, тем более "винтичным" становится отдельный ее представитель. А винтичность предполагает усреднение, как в амбициях, так и в способностях.
E>>Во-вторых, в маленьких командах все на виду. Очень легко получить помощь, совет, а иногда и по рукам за откровенные ляпы. Поэтому и процесс обучения новым языкам/технологиям в маленьких командах проходит быстрее и легче.
E>>В-третьих, маленькой команде проще согласованно выбрать новый язык для конкретной задачи. S>Это уже никак не относится к способностям самих программистов. E>>В-четвертых, сама разработка в небольшой команде проще, чем в большой. Просто из-за отсутствия политики и лишних накладных расходов на общение. S>Как и это.
Тем не менее, это серьезно влияет на выбор языков для разработки ПО.
E>>Я считаю, что есть некоторый диапазон, в котором для проекта очень важно иметь минимальное количество использованных языков. Скажем, объем проекта от 200 до 500 тысяч строк и команда от 7 до 20 человек. Как раз по перечисленным мной ранее факторам (взаимозаменяемость членов команды, проблемы в интеграции разноязыковых компонент, сложность в одновременной работе на более чем 3-х языках). S>Нет, погоди. Ты аргументируешь сложность работы на более чем трех языках наличием команд, сформированных под воздействием сложности работы на более чем трех языках.
Интересная точка зрения. Может ты меня слишком буквально понимаешь?
Моя точка зрения в том, что объективно есть условия, когда более 3-х или 4-х языков применять сложно и опасно. С этими условиями приходится считаться. И команды формируются так же под влиянием этих условий.
E>>А уже как следствие этого -- данные проекты успешно могут решаться людьми, которые знают не более 2-х или 3-х языков. Вроде как собрать команду из 5-ти корифеев сложно, но возможно. Собрать команду из 15-ти корифеев, имхо, вообще не реально. А еще менее реально -- заставить их работать сообща
S>Итак, мы имеем тысячи команд из двух-трех корифеев, и десятки команд из десятков, скажем так, не-корифеев.
На счет тысяч команда из двух-трех корифеев -- это, наверное, есть только в мировом масштабе считать.
А то, что существуют сотни и тысячи команд, в которых большинство разработчиков обладают хорошим средним уровнем, но не Линусы, Столманы, не Грослинги, не Хайсельберги -- это факт. Даже в рамках СНГ.
E>>Если проект больше то, имхо, он состоит из почти самостоятельных частей и команд, попадающих в указанный диапазон. И для каждого из таких продпроектов действуют те же самые правила. S>А, ну то есть на самом деле у нас большой проект (в котором программеры патологически неспособны думать на трех языках) делится на маленькие команды, в которых программеры вполне способны думать на трех языках. Забавно.
Ты не язви. Скажи с чем ты не согласен.
E>>PS. Цифры по объемам команд/проектов взяты мной исходя из своего личного впечатления, никакой объективной статистикой не подкреплены.
S>Ты вообще много знаешь команд с численностью в 20 человек?
У нас сейчас ~20 человек. Разбитые на подпроекты, но все подпроекты очень тесно переплетаются.
В нашем городе есть представительства крупных офшорных контор. Там гораздо больше народу работает.
Есть наши партнеры (друзья-соперники ), в Питере и в Магнитогорске, там вообще разработчиков сотни, а работают над линейками однотипных продуктов (банковский процессинг).
S> Да их во всем мире не так уж много. Практика показывает, что 2 языка осваивают чуть не 90% современных программеров. И не осваивают третий только потому, что не успевают. К тридцати годам избежать освоения трех языков можно только при помощи строгого поста, воздержания, и ежедневной молитвы. Такая уж у нас отрасль.
Я говорил не про возможность освоить, а возможность одновременно и эффективно программировать на более чем двух-трех языках (давай SQL сюда не включать, это не универсальный язык). Я вот и на Паскале когда-то программировал, и на С, и на Java программировал, а уж изучал много чего, только программировать не довелось. А реально сейчас я могу написать программу или на C++, или на Ruby. Вот так, с ходу, без остановок. А для всего остального нужно паузу брать, восстанавливать знания, или вообще заново учиться. Вот возьму, вспомню еще и Java. Но писать одновременно фрагменты на C++, на Ruby и на Java, имхо, будет не просто. И по крайней мере от одного языка я постараюсь поскорее избавиться.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Под крупными командами ты что понимаешь? Команда в 10 разработчиков -- это редкость? А в 20-ть?
Конечно редкость. Особенно если не считать туда же тестеров/дизайнеров/админов. Потому как им ЯП не нужны. E>Извини меня, но над какими проектами ты работаешь?
Не имеет значения. E>Интересная точка зрения. Может ты меня слишком буквально понимаешь? E>Моя точка зрения в том, что объективно есть условия, когда более 3-х или 4-х языков применять сложно и опасно.
Разве? А несколько постов назад ты написал буквально следующее:
Как мне кажется, не так уж много программистов смогут одинаково эффективно работать на нескольких (больше трех) языках и использовать разные платформы.
Вот я и не могу понять, откуда взялось такое убеждение. Это противоречит моему опыту. Я, напротив, утверждаю, что:
Большинство программистов могут эффективно работать на нескольких языках/платформах одновременно.
E>На счет тысяч команда из двух-трех корифеев -- это, наверное, есть только в мировом масштабе считать. E>А то, что существуют сотни и тысячи команд, в которых большинство разработчиков обладают хорошим средним уровнем, но не Линусы, Столманы, не Грослинги, не Хайсельберги -- это факт. Даже в рамках СНГ.
Ага. И этого среднего уровня почему-то хватает с избытком на освоение двух-трех языков.
E>Ты не язви. Скажи с чем ты не согласен.
Я тебе уже пять постингов объясняю: я не согласен с тем, что эффективно писать на двух-трех языках — что-то сверхъестественное. Ничего в этом такого нет.
S>>Ты вообще много знаешь команд с численностью в 20 человек? E>У нас сейчас ~20 человек. Разбитые на подпроекты, но все подпроекты очень тесно переплетаются. E>В нашем городе есть представительства крупных офшорных контор. Там гораздо больше народу работает.
Не надо путать численность конторы и размер команды. В Новософте работало около 500 человек; при этом они были разбиты на команды типичной численностью около пяти человек. И состоящие из более-менее универсалов типа Java+SQL+HTML. E>Есть наши партнеры (друзья-соперники ), в Питере и в Магнитогорске, там вообще разработчиков сотни, а работают над линейками однотипных продуктов (банковский процессинг).
Ок. Сколько этих партнеров? (Поверим на минуту, что у них действительно работают команды в несколько сот девелоперов, и все узкоспециализированные). А микрокоманд, где народу меньше 5, только у нас в районе под сотню наберется.
E>Я говорил не про возможность освоить, а возможность одновременно и эффективно программировать на более чем двух-трех языках (давай SQL сюда не включать, это не универсальный язык).
А какие языки ты собрался включать тогда? Нет, если вот так произвольно из рассмотрения выкидывать — то да, конечно. Там и одного языка на разработчика не наберется. E>Я вот и на Паскале когда-то программировал, и на С, и на Java программировал, а уж изучал много чего, только программировать не довелось. А реально сейчас я могу написать программу или на C++, или на Ruby. Вот так, с ходу, без остановок.
Это от того, что тренировки мало. E>А для всего остального нужно паузу брать, восстанавливать знания, или вообще заново учиться. Вот возьму, вспомню еще и Java. Но писать одновременно фрагменты на C++, на Ruby и на Java, имхо, будет не просто.
Это тебе кажется. Мне вот в свое время тяжко было печатать латиницей/кириллицей. Паузу надо было брать, переучиваться.
А в девятом/десятом классе я свободно тайпал и s QWERTY, и в ЙЦУКЕН, и в ужасной транскрипционной раскладке ямахи. Чуть-чуть ежедневной практики — и voila! E>И по крайней мере от одного языка я постараюсь поскорее избавиться.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
E>>Моя точка зрения в том, что объективно есть условия, когда более 3-х или 4-х языков применять сложно и опасно. S>Разве? А несколько постов назад ты написал буквально следующее: S>
Как мне кажется, не так уж много программистов смогут одинаково эффективно работать на нескольких (больше трех) языках и использовать разные платформы.
S>Вот я и не могу понять, откуда взялось такое убеждение. Это противоречит моему опыту. Я, напротив, утверждаю, что: S>Большинство программистов могут эффективно работать на нескольких языках/платформах одновременно.
Ok. Эта твоя вера. Не буду тебя разубеждать. Мне это не к чему, тебе, видимо, так же.
E>>Ты не язви. Скажи с чем ты не согласен. S>Я тебе уже пять постингов объясняю: я не согласен с тем, что эффективно писать на двух-трех языках — что-то сверхъестественное. Ничего в этом такого нет.
Ok. Пусть у тебя будет так. Мне же не просто с C++ на Ruby переключаться, старею, наверное.
S>Не надо путать численность конторы и размер команды. В Новософте работало около 500 человек; при этом они были разбиты на команды типичной численностью около пяти человек. И состоящие из более-менее универсалов типа Java+SQL+HTML.
Java+SQL+HTML -- это универсализм? По мне, как это специализация.
E>>Я говорил не про возможность освоить, а возможность одновременно и эффективно программировать на более чем двух-трех языках (давай SQL сюда не включать, это не универсальный язык). S>А какие языки ты собрался включать тогда?
С++
C#
Delphi
Java
Perl
Python
Ruby
VB
Универсальные языки программирования, на которых можно создавать standalone приложения. Хоть текстовые редакторы. Хоть САПР. Хоть архиваторы. Хоть компиляторы.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, IT, Вы писали:
IT>>Я 12 лет был гениальным... я устал.
VD>Та же фгиня, но я сдался на 10-ом году.
Везука, а я за 13 лет так и не поумнел. Пишу на том, за что платят.
С уважением, Gleb.
ЗЫ. единственное исключение VB4. Двух дней жесткого мазохизма хватило.
А теперь представьте себе. что эта pszFormat в рантайме вычисляется. Какую, к богу, Вы тут диагностику компилятора хотите ? Если он иногда проверяет — спасибо ему. А в общем случае нельзя здесь ничего проверить в compile-time. Ни на С++, ни на C#.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да Вы что, господа, совсем уже до ручки дошли, что ли ?
А чё "Вы" то с большой буквы?
PD> Или трудно понять, что форматная строка не обязательно константная!
PD> char* pszFormat = "%d\n"; PD> CString str; PD> str.Format(pszFormat, 123);
PD>А теперь представьте себе. что эта pszFormat в рантайме вычисляется.
Веорятность этого 0.00000001 процента. Если бы такой контроль был, было бы конечно приятнее. Вот только делать его нужно было на базе расширения языка, чтобы в нем самом моно было бы описать правила котроля. А так это всего лишь соломка на конкретный случай.
PD> Какую, к богу, Вы тут диагностику компилятора хотите ? Если он иногда проверяет — спасибо ему. А в общем случае нельзя здесь ничего проверить в compile-time. Ни на С++, ни на C#.
Хочется, чтобы "иногд" было больше/чаще. Например, printf меня мало колышит. Не часто его вызвашь. А вот CString было бы приятно если бы контролировался.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А что за программирование не на С++ уже не платят? Или платят меньше?
Нее. Мне платят и за С++, и за С#, и за HTML, и за javascript, и за Object Pascal, и за UML. Могут заплатить просто за добрые слова. А самый прибыльные из них языки — русский + UML.
Здравствуйте, VladD2, Вы писали:
>>"Пописал на С++... долго думал "
Я вот прикола плюснутых не понимаю, зачем перед каждым словом писать знак а то и два знака подчёркивания? ("_")
И зачем облачать строки в эту сугубо ублюдскую конструкцию _T("")?
Почему до сих пор хитропопые изобретатели языка не переопределили кавычки для восприятия строк в нужно кодировке?
Может ещё и для чисел с плавающей точкой сделать оператор сложения какой-нить _+("")?
Ну не изврат ли?
int i = 2;
float f = 2.0;
float z = ("i") _+("f");
Зачем вообще плодить кучу сущностей типа CString, std::string, lpzstr и прочей швали?
DJ KARIES wrote:
>>>"Пописал на С++... долго думал " > Я вот прикола плюснутых не понимаю
Естественно, ведь Дельфи до сих пор нормально Юникод не держит.
> зачем перед каждым словом писать знак а то и два знака подчёркивания? > ("_") > И зачем облачать строки в эту сугубо ублюдскую конструкцию _T("")?
В версии для ANSI (то есть для Win9x/ME) макрос _T(x) разворачивается
просто в x. То есть не происходит никаких изменений.
Но в версиях для UNICODEных систем (NT/XP/2K/CE) этот макрос
разворачивается в Lx. То есть _T("aaa") будет L"aaa" (так в С++
обозначается широкая строка).
Соответственно, почти все API в Винде имеют две версии A и W
(CreateWindowA и CreateWindowW) — они отличаются форматом применяемых строк.
> Почему до сих пор хитропопые изобретатели языка не переопределили > кавычки для восприятия строк в нужно кодировке?
Не в кодировке дело.
> Зачем вообще плодить кучу сущностей типа CString, std::string, lpzstr > и прочей швали?
Ну да, ведь нет Бога кроме Аллаха и его пророка в Дельфи....
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Дарней, Вы писали:
Д>>хорошо — это когда думают о том, как правильно решить задачу. А не о том, где поставить скобку, чтобы прога не рухнула
VD>Вот именно. И очень смешно смотреть как кто-то гордится тем, что хорошо умеет подстилать соломку и совершенно не замечает того, что на этот процесс его сили и уходят.
А как ВФЫ дышите уважаемый ?
Подумайте — какие у Вас мышцы работают ?
Если разберетесь — подумайте, а как дышать эффективней ?
Так и с указателями и с макросами в С++, кроме того, рискну предположить, что через 10 лет также будет и с шаблонами, они просто будут восприниматься/не восприниматься мозжечком
Везде есть свои + и -, например у С — аж целых 2 плюса.
А если серьезно, от опять же каждому своё — например написать драйвер на СШарп — не получиться
Точно также как и на Джаве, некоторые горячие головы ытались реалтизовать аппаратную поддержку Джава — спец- Джава процессоры и все такое, — ан не сильно получилось.
ИМХО: если язык появляется и активно используется в течении 4х лет — значит он нашел свою нишу среди других языков.
ЗЫ как уже писали умные люди все зависит от задачи.
PD>Я не буду смеяться, но вроде бы в Unix был когда-то tool , который отлавливал несоответсвия всякие в С программах еще когда С++ не было. В частности, несоответствия между описанием функции и ее вызовом (если помнишь, в версии С Кернигана-Ритчи прототипов не было, а вызывать неописанную функцию в С даже сейчас компилятор позволит, предупреждение, правда, будет. Не исключаю, что и для C++ такие тулзы либо есть, либо их можно написать. Но мне они не нужны.
Lint -- A C program verifier
You will soon discover (if you have not already) that the C compiler is pretty vague in many aspects of checking program correctness, particularly in type checking. Careful use of prototyping of functions can assist modern C compilers in this task. However, There is still no guarantee that once you have successfully compiled your program that it will run correctly.
The UNIX utility lint can assist in checking for a multitude of programming errors. Check out the online manual pages (man lint) for complete details of lint. It is well worth the effort as it can help save many hours debugging your C code.
To run lint simply enter the command:
lint myprog.c.
Lint is particularly good at checking type checking of variable and function assignments, efficiency, unused variables and function identifiers, unreachable code and possibly memory leaks. There are many useful options to help control lint (see man lint).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ко всем участникам боевых действий в этом треде (и к себе тоже, конечно !
PD>Предлагаю военные действия прекратить и заключить мирный договор
+1
Видим тендецию С++ программисты не любят СШарп — программистов, обратно, тоже верно. Есть программисты которые любят/умеют и то и другое, они осторожны в своих суждениях, есть Вы Павел, судя по Вашему нейтралитету — Вы почти кореец — очень много собак съели
Резюме:
Мира не будет
ЗЫ
время покажет, но С++ комюнити есть на что расчитывать — С++ вышел в финал ( не ы первый раз ), уже и Джава готова была похоронить С++, но не получилось
ЗЫЗЫ
По-поводу, особо горячих споров такой довод — СШарп таки работает на ОС, писанных на старом добром С
Здравствуйте, minorlogic, Вы писали:
M>Мне например бывает неловко , когда какаянить девушка слышит что я программист радосно спрашивает " о , так ты сможешь поправить мою веб страничку"
M>P.S. с HTML сталкиваюсь очень редко ... хоть и бывает
ИМХО: Программист — ВкбДизайнер — Верстальщик ШТМЛ — ??
Слишком долго классифицировать
ИМХО: программист у нас — это синоним IT-специалист, и все, даже люди настраивающие 1с- называются программисты
Огромное сорри за оффтоп, но сколько уже периодически читаю ответы в эту ветку, каждый раз механически читаю ее название как "попИсал на С++... долго думал ".
Здравствуйте, CreatorCray, Вы писали:
CC>Огромное сорри за оффтоп, но сколько уже периодически читаю ответы в эту ветку, каждый раз механически читаю ее название как "попИсал на С++... долго думал ".
А казалось бы причем тут фрэйд?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Похоже, кто-то там на верху упорно даказывает разработчикам компилятора, что большенство людей используют его как С .
Cделали бы cwindows в дополнение к windows.h, как поступили другие люди с остальными include.
В таком случае, подобной темы никогда бы не возникло.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, GlebZ, Вы писали:
GZ>Вот мне хотелось бы узнать, в чем может состоять хитрость программиста. Если бы я знал хотя бы об одном потенциальном способе использования такого кода, то я не против. Но этого способа я не знаю.
MSVC (и стандарт С++) не поддерживает макросы с переменным числом аргументов. warning вместо error в таком случае может помочь реализовать какую-нибудь заморочку. Осмысленный пример придумывать не берусь, плохо макросы С знаю.
Совсем другой пример:
LINK : fatal error LNK1561: entry point must be defined
Иногда мне нужно посмотреть асм код именно в бинарнике, а не листинге. Догадаться, что это давится ключиком /LD у меня ушло некоторое время (точнее, я это понял только сейчас !)
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, minorlogic, Вы писали:
M>>Мне например бывает неловко , когда какаянить девушка слышит что я программист радосно спрашивает " о , так ты сможешь поправить мою веб страничку"
M>>P.S. с HTML сталкиваюсь очень редко ... хоть и бывает
S>ИМХО: Программист — ВкбДизайнер — Верстальщик ШТМЛ — ?? S>Слишком долго классифицировать S>)
S>ИМХО: программист у нас — это синоним IT-специалист, и все, даже люди настраивающие 1с- называются программисты
Ну дык и я об этом , слово "программист" потеряло какое либо значение и стало сшишком расплывчато.
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, IT, Вы писали:
IT>>Сможешь такое на C++?
S>Везде есть свои + и -, например у С — аж целых 2 плюса.
S>А если серьезно, от опять же каждому своё — например написать драйвер на СШарп — не получиться
Ну почему же? Если сильно постараться то получится: Singularity: A research OS written in C#
Здравствуйте, Cyberax, Вы писали:
C>Естественно, ведь Дельфи до сих пор нормально Юникод не держит.
А причём здесь вообще дельфи?
Я могу также заявить, что Кобол и Кларион не держат нормально Юникод.
Но речь то идёт о C++.
C>В версии для ANSI (то есть для Win9x/ME) макрос _T(x) разворачивается C>просто в x. То есть не происходит никаких изменений.
C>Но в версиях для UNICODEных систем (NT/XP/2K/CE) этот макрос C>разворачивается в Lx. То есть _T("aaa") будет L"aaa" (так в С++ C>обозначается широкая строка).
Я в курсе этого.
Может удобнее один раз в настройках проекта указать платформу, а компилер пусть сам выбирает Юникодность строки.
Причём в том же MSVC эта галочка есть — Ansi/Unicode/MBCS. Почему программеры юзают в каждой строке _T("")?
Потому, что часть библиотек юникодные, а часть — нет.
Однако в других языках почему-то обходятся без данного макроса.
И не только потому, что в большинстве языков нет макросов.
C>Соответственно, почти все API в Винде имеют две версии A и W C>(CreateWindowA и CreateWindowW) — они отличаются форматом применяемых строк.
Ээ-эхххх.
И придумали ж извратни такой геморрой.
Причём в Win9x есть и CreateWindowA и CreateWindowW.
Однако CreateWindowW в Win9x не работает, т.е. это функция-пустышка!
Так на кой хер спрашивается так сделано?
Почему в одновременно с Win9x вышедшей WinNT юникодные функции работают, а в 9x — нет?
Чтоб прогеры на C++ писали _T("")?
C>Ну да, ведь нет Бога кроме Аллаха и его пророка в Дельфи....
Ещё и Васика приплетите сюда
Были б в дельфях макросы, я б ТАКОГО наворотил
Интересно, зачем эти яйцеголовые изобретатели стандартов понаделали КУЧУ ЮНИКОДОВ?
Зачем MBCS/LowEndian/HiEndian/16bit/32bit разновидности юникода?
Идиотизм!
Нельзя было обойтись одним стандартным?
Здравствуйте, IT, Вы писали:
S>>А если серьезно, от опять же каждому своё — например написать драйвер на СШарп — не получиться
IT>Сколько ты в своей жизни написал драйверов на C++?
И сколько из них предназначалось для реакторов АЭС?
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Чипсет, Вы писали:
Ч>>И вот С++ компилятор возлагает очень большую ответственность на программиста но кроме этого он в некотором "льстит" программисту, считая его гениальным, даже компилируя
IT>Я 12 лет был гениальным... я устал.
От гениальности нельзя устать. Она либо есть, либо её нет.
Здравствуйте, Шахтер, Вы писали:
Ч>>>И вот С++ компилятор возлагает очень большую ответственность на программиста но кроме этого он в некотором "льстит" программисту, считая его гениальным, даже компилируя
IT>>Я 12 лет был гениальным... я устал.
Ш>От гениальности нельзя устать. Она либо есть, либо её нет.
Судя по постам предыдущих товарищей каждая написанная на C++ строчка делает человека гениальней и увеличивает размер головного мозга в два раза. Представляешь до каких размеров разрослись мои полушария за 12 лет? Особенно левое. А если сюда добавить ещё 3 года до этого на чистом C? Там вообще был год за два. В общем, тяжело быть таким умным и гениальным.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Судя по постам предыдущих товарищей каждая написанная на C++ строчка делает человека гениальней и увеличивает размер головного мозга в два раза.
Сразу вспоминаются сорванные башни:
— Ты такой умный? Тебе череп не жмёт?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, supersceev, Вы писали:
S>>кстати _T() это не конструкция языка — это макрос, который компилятор даже и не видит. S>>При чём здесь язык?
VD>А не подскажешь — это макрос какого языка?
Никакого. То, что получается полсе подстановки макроса — это код на каком-то языке (необязательно C++ или С)
Макрос к языку не имеет отношения, да и перечитывая в очередной раз Великого И Ужасного (я про Страуструппа),
всё чаще ловлю себя на мысли, что он, пытается дать понять, что препроцесср для C++(за исключением #include)
достаточно вредная вешь. При невнимательности от него больше вреда, чем пользы.
Всё вышесказанное — ИМХО
.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, CreatorCray, Вы писали:
CC>>Огромное сорри за оффтоп, но сколько уже периодически читаю ответы в эту ветку, каждый раз механически читаю ее название как "попИсал на С++... долго думал ".
VD>А казалось бы причем тут фрэйд?
Вот и я думаю — к чему это в названии C# — решётка? Если по фрейду?
Здравствуйте, Hydrogen, Вы писали:
H>Вообще говоря, в теории безомапсности компьютерных систем, H>AFAIK есть утверждение — "Более безопасная система менее удобна".
Можно ссылку на этот бред?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Шахтер, Вы писали:
Ч>>>>И вот С++ компилятор возлагает очень большую ответственность на программиста но кроме этого он в некотором "льстит" программисту, считая его гениальным, даже компилируя
IT>>>Я 12 лет был гениальным... я устал.
Ш>>От гениальности нельзя устать. Она либо есть, либо её нет.
IT>Судя по постам предыдущих товарищей каждая написанная на C++ строчка делает человека гениальней и увеличивает размер головного мозга в два раза. Представляешь до каких размеров разрослись мои полушария за 12 лет? Особенно левое. А если сюда добавить ещё 3 года до этого на чистом C? Там вообще был год за два. В общем, тяжело быть таким умным и гениальным.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Hydrogen, Вы писали:
H>>Вообще говоря, в теории безомапсности компьютерных систем, H>>AFAIK есть утверждение — "Более безопасная система менее удобна".
VD>Можно ссылку на этот бред?
Если Вы считаете это бредом, то ссылку не дам.
В таком тоне говорите с вахтершами и кондукторами.
DK>Может удобнее один раз в настройках проекта указать платформу, а компилер пусть сам выбирает Юникодность строки.
... DK>Интересно, зачем эти яйцеголовые изобретатели стандартов понаделали КУЧУ ЮНИКОДОВ? DK>Зачем MBCS/LowEndian/HiEndian/16bit/32bit разновидности юникода?
Слова не мальчика но мужа
Здравствуйте, Alexey Axyonov, Вы писали:
AA>Здравствуйте, srggal, Вы писали:
S>>Здравствуйте, IT, Вы писали:
IT>>>Сможешь такое на C++?
S>>Везде есть свои + и -, например у С — аж целых 2 плюса.
S>>А если серьезно, от опять же каждому своё — например написать драйвер на СШарп — не получиться AA>Ну почему же? Если сильно постараться то получится: AA>Singularity: A research OS written in C#
Спасибо за интересную ссылку, но все таки, оттуда:
Again, this is a prototype research OS, not a full fledged OS that can run the typical applications you've come to expect of an OS (or even provide a user interface beyond, say, that of DOS).
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, srggal, Вы писали:
S>>А если серьезно, от опять же каждому своё — например написать драйвер на СШарп — не получиться
IT>Сколько ты в своей жизни написал драйверов на C++?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, IT, Вы писали:
S>>>А если серьезно, от опять же каждому своё — например написать драйвер на СШарп — не получиться
IT>>Сколько ты в своей жизни написал драйверов на C++?
AVK>И сколько из них предназначалось для реакторов АЭС?
Для АЭС не довелось, писали соседние фирмы.
А вот для МО Укоаины, — писал один, в стрю до сих пор, ни одного сбоя с момента ввода в экспдуатацию
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, srggal, Вы писали:
S>>А если серьезно, от опять же каждому своё — например написать драйвер на СШарп — не получиться
IT>Сколько ты в своей жизни написал драйверов на C++?
ИМХО меряться размерами не мобильного телефона смысла не вижу, в дальнейшем подобные выпады оставляю без ответа.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, VladD2, Вы писали:
VD>>Понимаш ли, есть огромная разница между логическими ошибками и ошбками вроде описаной в теме. В Шарпе без ансэйва ты просто не сможешь повредить память, а в данном случае неверно поставленная скобка привела именно к повреждению памяти. И слава богу, что все было относительно безопасно. Как-то я видел намного более забавную ошибку. Человек в следствии сложных манипуляций возвратил их функции указатель на стековую переменную. Какое-то время код даже работал, а потом... потом были 2 недели поиска ошибки. GZ>Как-то пришлось подключать библиотеку, которая в своей функции удаляло строку, а потом создавала свою вместо нее. Долго разбирался. Сначала долго разбирался с ошибкой поскольку строку по незнанию я создавал в стеке. Потом долго выбивал из них, хотя бы скомпиленную библиотеку с msvcrt.dll, поскольку ихнюю строку должен был удалять уже я. Пробивать нормальный интерфейс от них по некоторым причинам было нельзя.
GZ>С уважением, Gleb.
Здравствуйте, srggal, Вы писали:
S>>>А если серьезно, от опять же каждому своё — например написать драйвер на СШарп — не получиться AA>>Ну почему же? Если сильно постараться то получится: AA>>Singularity: A research OS written in C#
S>Спасибо за интересную ссылку, но все таки, оттуда:
Да я не спорю. Просто ты утверждал что написать драйвер на C# не получится (выделено). Я привел обратный пример. Пускай это и Research Project, но попытка предпринята была. Кто знает, какие выводи сделали из результатов этого проекта в MS.
Здравствуйте, Alexey Axyonov, Вы писали:
AA>Здравствуйте, srggal, Вы писали:
S>>>>А если серьезно, от опять же каждому своё — например написать драйвер на СШарп — не получиться AA>>>Ну почему же? Если сильно постараться то получится: AA>>>Singularity: A research OS written in C#
S>>Спасибо за интересную ссылку, но все таки, оттуда:
AA>Да я не спорю. Просто ты утверждал что написать драйвер на C# не получится (выделено). Я привел обратный пример. Пускай это и Research Project, но попытка предпринята была. Кто знает, какие выводи сделали из результатов этого проекта в MS.
Также я писал:
Точно также как и на Джаве, некоторые горячие головы ытались реалтизовать аппаратную поддержку Джава — спец- Джава процессоры и все такое, — ан не сильно получилось
И так я писал:
ИМХО: если язык появляется и активно используется в течении 4х лет — значит он нашел свою нишу среди других языков.
Причем первое процитированное — стало ясно не счерез 4е года спустя появления Лжава, позже.
Вывод: ИМХО пока говорить о C# OS — перждевременно.
И еще цитата с указанного Вами урла:
Beer28
beercosoftware.com custom linux solutions&software
galenh wrote:
This isn't the CLR. In our world, we compile entire MSIL for the kernel into x86 instructions
at installation time. There is no libc at the bottom.
However, we do have around some assembly code. Like a kernel written in C, our C# kernel needs
assembly code to handle the lowest part of the interrupt dispatch on the x86. But once the
assembly code has finished, it dispatches directly into compiled C# (no C). BTW, there is some C
code in the system, primarily for the debugger stub.
What are you using to compile the MSIL into x86?
how are you handling hardware interupts, and the interupt vector table and interupt service routines from C# code?
C# code has no way to interact with the bios. You can't drop into __asm { }; in C#.
I feel there is part of the story that is missing here.
Я разделю его мнение.
ЗЫ
Надеюсь, что мы не перейдем в спор о яйце и куритце, типа что на чем написано, это так, просто констатация факта
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, supersceev, Вы писали:
S>>кстати _T() это не конструкция языка — это макрос, который компилятор даже и не видит. S>>При чём здесь язык?
GN>Совершенно верно — ни при чём. GN>Каков смысл этого кода: GN>
в С++ ?
GN>Похоже, кто-то там на верху упорно даказывает разработчикам компилятора, что большенство людей используют его как С .
GN>Cделали бы cwindows в дополнение к windows.h, как поступили другие люди с остальными include. GN>В таком случае, подобной темы никогда бы не возникло.
Здравствуйте, VladD2, Вы писали:
Ш>>Влад, если ты не видишь, что пишешь, то никакой язык программирования тебе не поможет. НЕ спеши. Тише едешь -- дальше будешь.
VD>Я вижу что пишу. А от опечаток никто не застрахован. Что до языка, думаю, ты прекрасно понимашь, что никакой язык кроме С/С++ не пропустит такую лажу.
На самом деле, что-то в этом есть. В С++ полно "унаследованных" мест, которые ему вовсе не нужны. Ситуация с неверным числом аргументов макроса в т.ч.
Я бы перевел этот момент в разряд ошибок.
Далее, есть еще несколько уже давно устоявшихся мыслей по поводу введений в некий "safe С++":
— избавиться от const_cast, static_cast, reinterpret_cast, оставить лишь приведение в стиле С: (type_name)expression, но его семантику сделать эквивалентной нынешнему static_cast
— продолжая пред. пункт, запретить преобразование указателей и ссылок вниз по иерархии наследования новым оператором преобразования типа, т.е. от void* в т.ч. Разруливать подобные моменты впредь либо через dynamic_cast, либо через явные определения методов. Размеется, это создаст небольшие накладные расходы при работе с шаблонными базовыми классами, написанными в стиле ATL/WTL (пара лишних строк в исходниках), и тем не менее...
— в предыдущем пункте мы потеряли возможность произволдьной реинтерпретации памяти, однако иногда эта возможность все-таки нужна, например для тех же распределителей памяти... для сохранения возможности управления и явной реинтерпретации памяти достаточно оставить сигнатуры оператора void* operator new(size_t); и пр. с inplace new в т.ч., этого будет достаточно для реализаций STL и прочих boost.
------
Собственно, мне нравится в С++ сильная статическая типизация. По сравнению с тем же C# мне крайне редко приходлось отлаживать программы в пошаговом редакторе, используя С++. Еще немного более строгая типизация не повредила бы.
Понимаю, что тонны, просто тонны кода используют фичи, которые предлагается выкинуть или переписать... я думаю, всем от этого станет только лучше
------
проработать стандартную С-либу (не STL, а C RTL), всякие memmove, memcpy и прочие — убрать из С++. Ср-вами самого С++ их реализация станет невозможной. Останется только юзать STL. В результате избавимся сразу от нескольких классов UB, которые допускают программисты.
------
printf, va_list и пр. из этой оперы... жалко, согласен, однако "в топку". Переменное число аргументов сделать типизированным, наподобие реализации в С#.
IT>public abstract class Person : ObjectBase
IT>{
IT> [Required, MaxValue(50)] public abstract string FirstName { get; set; }
IT> [Required, MaxValue(50)] public abstract string LastName { get; set; }
IT> public abstract Gender Gender { get; set; }
IT> [MaxValue(100)] public abstract string Address { get; set; }
IT>}
IT>
В нашей системе мы выделенное в коде не описываем. В момент инициализации сопоставляем все подобные сущности с их описанием в БД, и эти ограничения выхватываем из схемы БД. Т.е. избавляемся от повторного описания ограничений.
Там же еще есть такие аттрибуты как:
— DefaultValue
— Format
и т.д.
Здравствуйте, Hydrogen, Вы писали:
H>>>AFAIK есть утверждение — "Более безопасная система менее удобна".
VD>>Можно ссылку на этот бред? H>Если Вы считаете это бредом, то ссылку не дам.
А чем еще можно считать постановку в один ряд несовместимых понятий?
Да и на примерах это бредовое утверждение рассыпается сразу. Возмем ДОС и Windows XP и сравним их с точки зрения удобства использования и безопасности. По обоим критериях ХРюша явно выигрывает. Другй пример, новая качественная иномарка и Жигули. Таких примеров можно привести бесчисленное множество.
H>В таком тоне говорите с вахтершами и кондукторами.
Ясно. Ну, ссылки на вахтерш меня действительно не интересуют.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Далее, есть еще несколько уже давно устоявшихся мыслей по поводу введений в некий "safe С++":
Думаю, что выражу мысль большинства С++ программистов, которые в этом треде участвовали в обсуждении проблемы высосанной из пальца, но на всякий случай ИМХО:
Здравствуйте, srggal, Вы писали:
IT>>Сколько ты в своей жизни написал драйверов на C++?
S>ИМХО меряться размерами не мобильного телефона смысла не вижу, в дальнейшем подобные выпады оставляю без ответа.
А никто ничем и не меряется. Я тебе задал вопрос, ты на него ответил. Будем беседовать дальше
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>А никто ничем и не меряется. Я тебе задал вопрос, ты на него ответил. Будем беседовать дальше
Ок, просто это было как-то грубовато что-ли
Может Маня Величко о которой твердят большивики
Переставай дружить с Маней Величко. Это плохая подруга.
Вместо этого лучше представляй себе что разговаривашь с людми опыт которых как минимум не меньше твоего.
ЗЫ Приношу извинения за неправильную трактовку. И вот еще чот — писал отлько под Linux ядро 2.4
Здравствуйте, DJ KARIES, Вы писали:
DK>Интересно, зачем эти яйцеголовые изобретатели стандартов понаделали КУЧУ ЮНИКОДОВ? DK>Зачем MBCS/LowEndian/HiEndian/16bit/32bit разновидности юникода?
Ты не перечислил и 10-й части юникодных стандартов, их море.
DK>Идиотизм! DK>Нельзя было обойтись одним стандартным?
Эти стандарты разрабатывались и использовались независимо. Да, в те далекие времена на всем экономили, поэтому юникода не было. А потом он понадобился, но не сразу, и не всем, и не везде. И вот в разных странах/фирмах разрабатывались свои подпорки. Причем количество бит в этих подпорках поначалу было ну очень разное
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>Далее, есть еще несколько уже давно устоявшихся мыслей по поводу введений в некий "safe С++":
S>Думаю, что выражу мысль большинства С++ программистов, которые в этом треде участвовали в обсуждении проблемы высосанной из пальца, но на всякий случай ИМХО:
S>
S>safe С++
S>Это и есть СШарп
Дудки. Добавьте в шарп зависимые типы, статические шаблоны, возможность иметь параметр шаблона базой, явное управление памятью (мне далеко не всегда нужен GC), указатели на члены (и на методы в т.ч.) и тогда это и будет "оно"
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, srggal, Вы писали:
IT>>>Сколько ты в своей жизни написал драйверов на C++?
S>>На С я написал 3 драйвера.
IT>Очень хорошо. А сколько ты написал не драйверов? Меня интересует соотношение, в строчках, в мегобайтах, в программах, в разах, всё равно.
Мысль понял, красивый ход.
Но строчки написанного системного ПО дорогого стоят
К ним предъявляются другие требование и, если верить клаччикам годои 70-80, то ППО 400 строк СПО 1 строка в день
В любом случае, понимая к чему Вы ведете, и имею Вам что сказать:
GZ>Есть задачи, для которых важно как я делаю. И в этом случае С++ неоценим. Но есть задачи где важнее что я делаю. И тут С# значительно продуктивнее чем С++. Потому как о многих вещах и не надо задумываться.
В ЯБЛОЧКО, т.е. одни решаем на одном языке вторые на втором, причем эти предпочтения субъективны. Ибо в силу того, что С++ я знаю лучше СШарп, то многие вещи мне проще сделать на С++, но могут быть люди у которых все наоборот.
От себя еще добалю, что при выборе предпочтительного языка реализации следует учитывать собственный уровень знания языка, а при самой реализации на выбраном языке писаьт надо острожно, если не чуствуешь себя НэтивСпикером
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, srggal, Вы писали:
S>>Здравствуйте, vdimas, Вы писали:
V>>>Далее, есть еще несколько уже давно устоявшихся мыслей по поводу введений в некий "safe С++":
S>>Думаю, что выражу мысль большинства С++ программистов, которые в этом треде участвовали в обсуждении проблемы высосанной из пальца, но на всякий случай ИМХО:
S>>
S>>safe С++
S>>Это и есть СШарп
V>Дудки. Добавьте в шарп зависимые типы, статические шаблоны, возможность иметь параметр шаблона базой, явное управление памятью (мне далеко не всегда нужен GC), указатели на члены (и на методы в т.ч.) и тогда это и будет "оно"
Ок, я понял Вашу точку зрения, теперб моё ИМХО
Аналогия:
Есть дикие собаки Динго, они независимы, довольно жестоки, и привыкли жить сами-по-себе.
И есть домашние пудели, они красивые, их надо стричь, кормить деликатесами и все такое.
Есть Люди которым импонируют собаки динго ( Я,например. ), есть люди, которым нравяться пудели ( к ним я равнодушен ).
Ещё есть зоопарки, в которых бывают собаки Динго в тесненьких вольерах. Это уже совсем не те собаки, которых показывают в программах про животных, они и внешне выглядят по-другому.
Кроме того, я подозреваю, что если бы ко мне попал в руки щенок динго, и я бы решил его вырастить, он бы не смог стать такой же собакой, как и прирученная взрослая особь.
Да к черту Динго, на даче у меня жил Пес Шарик ( точней он жил сам по себе, но рядом с моей дачей ), его кормило большинство дачников, когда я ночевал на даче, он ВСЕГДА спал исключительно под дверью моего дачного дома, я с ним игрался, он меня покусывал. Но когда я нечаянно наступил ему на лапу он меня сильно укусил, остались шрамы, после этого он скулил, просил прощения, было видно что ему непосебе, но я его и не наказывал ОН — дворовая собака, и должен был именно так поступить, — он такой как есть, и его не перделать.
Выводы:
Спросите к чему это, скажу — С/С++ это такая же дворовая собака которая такая уж есть, с ней можно играть, она может Вас покусывать, но если Вы ошибетесь, то могут остаться шрамы.
То что мы сейчас имеем — эот то, что было нужнно для выживания этой собаки в мире где уже до нее было много таких же собак. Чуть больше когтей чем у Бэйсик, чуть мягче шерсть чем у Ассемблер, за это я и люблю эту собаку.
Я люблю этот язык таким каким его делает комитет стандартизации И рад, что этот я зык есть.
Если он начнет идти в сторону Safe то это уже будет "дрессированный" язык, и совсем не тот, который мне нравится.
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я не буду смеяться, но вроде бы в Unix был когда-то tool , который отлавливал несоответсвия всякие в С программах еще когда С++ не было. В частности, несоответствия между описанием функции и ее вызовом (если помнишь, в версии С Кернигана-Ритчи прототипов не было, а вызывать неописанную функцию в С даже сейчас компилятор позволит, предупреждение, правда, будет. Не исключаю, что и для C++ такие тулзы либо есть, либо их можно написать. Но мне они не нужны.
S>[q] S>Lint -- A C program verifier
Точно, мне и припоминалось это название. Но не был уверен, а K&R лежит дома где-то очень далеко.
Здравствуйте, IT, Вы писали:
IT>Судя по постам предыдущих товарищей каждая написанная на C++ строчка делает человека гениальней и увеличивает размер головного мозга в два раза. Представляешь до каких размеров разрослись мои полушария за 12 лет? Особенно левое. А если сюда добавить ещё 3 года до этого на чистом C? Там вообще был год за два. В общем, тяжело быть таким умным и гениальным.
Эхе-хе-хе. Что же мне тогда говорить с моим опытом программирования на Фортране ? Не иначе как мне просто должны за гениальность платить — даже если я вообще ничего делать не буду...
Не-а. Глубина падения и одновременно мощности С++ значительно больше.
Возьми к примеру наложение структуры на адрес в памяти. Чрезвычайно полезная фича в некоторых случаях, как и опасная. Или взять к примеру инициализацию структуры нулевыми значениями через memset. Ты уже ее уничтожил, а фича также очень полезная.
Можно запретить указатели, но это уже не будет С++.
Здравствуйте, GlebZ, Вы писали:
GZ>Если вы не знаете что такое C# не стоит обзывать им все что можно. GZ>И заранее предупреждаю, это даже не safe C++/CLI.
Здравствуйте, srggal, Вы писали:
S> Спросите к чему это, скажу — С/С++ это такая же дворовая собака которая такая уж есть, с ней можно играть, она может Вас покусывать, но если Вы ошибетесь, то могут остаться шрамы.
Тебе не кажется, что шрамы были иначально. Дворовая собака — это конечно хорошо чтобы играться. Но тут нам нужно именно приручить. А учитывая, что у этой собаки остались длинные ноги от С, то есть вероятность что она может просто упрыгать быстрее тебя. Прыгать быстро конечно прикольно, но не каждому дано. S> Я люблю этот язык таким каким его делает комитет стандартизации И рад, что этот я зык есть.
В язык было очень многое заложено. Было, по-моему даже заложено, то о чем и не предполагали. С++ был действительно мощный язык, такой, что заложенного в него хватило на 15-20 лет существования. Но существует одна проблема. Дальнейшее улучшение языка возможно только с помощью таких уродцев типа boost. И невозможно построить эффективный GC не теряя совместимости. Он начинает терять позиции на рынке бизнес-приложений. Но есть рынки где его позиции останутся такими же еще лет 10 точно. S> Если он начнет идти в сторону Safe то это уже будет "дрессированный" язык, и совсем не тот, который мне нравится.
Это точно. Меня пугает вообще политика улучшения языка. Полезнее придумать новый. Если красивой девушке навесить ну очень большие уши, она лучше слышать. Но вот в остальном, она потеряет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, IT, Вы писали:
IT>>Судя по постам предыдущих товарищей каждая написанная на C++ строчка делает человека гениальней и увеличивает размер головного мозга в два раза. Представляешь до каких размеров разрослись мои полушария за 12 лет? Особенно левое. А если сюда добавить ещё 3 года до этого на чистом C? Там вообще был год за два. В общем, тяжело быть таким умным и гениальным.
PD>Эхе-хе-хе. Что же мне тогда говорить с моим опытом программирования на Фортране ? Не иначе как мне просто должны за гениальность платить — даже если я вообще ничего делать не буду...
Согласен с Вами,
Я хоть и моложе Вас ( Фортран знаю только понаслышке, да и переводил алгоритмы из старых простых-исходников ),
но имею немного Пролог-опыта, а рамках нескольких курсовых в бытность студентом. Конечно мой маленький опыт-пролог-программирования не может претендовать на тотального освобождения меня от Уголовной Ответсвенности, но быь может, стоит принять закон, чтобы ГАИ меня оставило в покое, надеюсь, моего опыта в ПРОЛОГ'е на это хватит
S>Видим тендецию С++ программисты не любят СШарп — программистов, обратно, тоже верно. Есть программисты которые любят/умеют и то и другое, они осторожны в своих суждениях, есть Вы Павел, судя по Вашему нейтралитету — Вы почти кореец — очень много собак съели
Нет. Я собак не люблю, но и есть их тоже не буду . Просто мне по моему характеру всякая нетерпимость чужда. Я ведь не покушаюсь ни на один язык. Прочти мои постинги — я хоть где-нибудь заявлял "ZZ must die" ? Не найдешь. А то, что я их те или иные свойства и ИМХО недостатки критиковал — так это в порядке вещей. И я не понимаю людей, которые заявляют, что что-то надо уничтожить, кого-то к чему-то не подпускать, и вообще которые так уверены в своей правоте, что не дай бог им когда-либо начальниками стать
Я ничего против C# и .Net не имею. Как и против Питона с Обероном, Визуал Бэйсика и Фохпро и др.. Одни языки я люблю, другие — нет, но запрещать ничего не призываю. Мне только не нравится, когда нечто новое немедленно находит адептов, которые тут же его объявляют панацеей от всех проблем. Я достаточно много таких проектов видел, которые вначале претендовали на то, чтобы все прежнее заменить, а потом в лучшем случае тихо занимали свою нишу, а в худшем — тихо помирали. ПЛ/1, Алгол-68, Ада...
S>время покажет, но С++ комюнити есть на что расчитывать — С++ вышел в финал ( не ы первый раз ), уже и Джава готова была похоронить С++, но не получилось
С++ обязательно похоронят, так же, как в свое время похоронили Фортран, царство которого тоже казалось в то время вечным. Но это произойдет очень-очень нескоро. Похоронят только тогда, задачи, решаемые сейчас на С++, уйдут в тень, как ушли вычислительные задачи — их процент в годы моей молодости был уж точно за 50%, а сейчас — в лучшем случае проценты. Но это будет очень нескоро Потому как можно, конечно, заявлять, что эффективность не самое главное, но когда все же появится конкурентная система, то от таких заявлений толку мало будет. А в плане эффективности ему конкурентов нет.
S>ЗЫЗЫ S>По-поводу, особо горячих споров такой довод — СШарп таки работает на ОС, писанных на старом добром С
А кстати, на чем написан JIT Net Framework ?
Лично мой прогноз — C++ останется базой лет на 5 как минимум для настольных приложений. Может быть, будет модифицирован, или на его базе будет создан новый язык, так же как он — на базе С. Для ОС — убежден, изменений не будет, для гигантов настольных приложений (PhotoShop, AutoCad etc.) — тоже. Макимум. что возможно — переписывание юзеровского интерфейса на .Net, а все остальное — на C++.
Ну а что касается программирования для www — так там С++ никогда всерьез и не использовался. CGI на C++ написать, конечно, можно, но этого уже давно практически никто не делает. Кстати, и там ИМХО PHP с ASP.NET вполне успешно конкурирует.
В общем, мое мнение — революции серьезной здесь не будет, если только MS нам ее силой не навяжет. Она, к сожалению, может.
Здравствуйте, Hydrogen, Вы писали:
H>В таком тоне говорите с вахтершами и кондукторами.
С вахтершами и кондукторами надо разговаривать вежливо, они отнюдь не заслуживают априорно подобного обращения. А в подобном стиле разговаривают только дурно воспитанные люди — и неважно с кем.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, srggal, Вы писали:
GZ>Тебе не кажется, что шрамы были иначально.
Собаки не рождаются со шрамами.
GZ>Дворовая собака — это конечно хорошо чтобы играться. Но тут нам нужно именно приручить.
Об этом и толкую, но как обычно, издалека...
Ьема началась с того, что человек наступил на больную лапу дворовому псу.
GZ>А учитывая, что у этой собаки остались длинные ноги от С, то есть вероятность что она может просто упрыгать быстрее тебя. Прыгать быстро конечно прикольно, но не каждому дано.
Правда уже не с Вами.
GZ>С++ был действительно мощный язык, такой, что заложенного в него хватило на 15-20 лет существования. Но существует одна проблема. Дальнейшее улучшение языка возможно только с помощью таких уродцев типа boost.
Много Вы уважемый ( без иронии ) знаете языков, пускай даже модных, новых, которые так можно тюнинговать, пусть при промощи уродцев типа буста ?
GZ>И невозможно построить эффективный GC не теряя совместимости.
А зачем козе баян ? (Народная мулрость)
GZ>Он начинает терять позиции на рынке бизнес-приложений. Но есть рынки где его позиции останутся такими же еще лет 10 точно.
Спорно, ну лучше мне с Вами согласиться, за неимением желания расскладывать Бизнесс Приложения на винтики и показывать в них нишу С/С++.
S>> Если он начнет идти в сторону Safe то это уже будет "дрессированный" язык, и совсем не тот, который мне нравится.
GZ>Это точно. Меня пугает вообще политика улучшения языка.
GZ>Полезнее придумать новый. Если красивой девушке навесить ну очень большие уши, она лучше слышать. Но вот в остальном, она потеряет.
Вы таки заговорили аналогиями
Хорошая аналогия, согласен, кстати есть еще дуализм:
я бы не хотел иметь красивую девушку с Большими ушами.
Вы меня правильно поняли, я тоже за то, чтобы GC не было в С++, я против радикального изменения языка, но я только один, ртдельно взятый программист
GZ>С уважением, Gleb.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет. Я собак не люблю, но и есть их тоже не буду . Просто мне по моему характеру всякая нетерпимость чужда. Я ведь не покушаюсь ни на один язык. Прочти мои постинги — я хоть где-нибудь заявлял "ZZ must die" ? Не найдешь. А то, что я их те или иные свойства и ИМХО недостатки критиковал — так это в порядке вещей. И я не понимаю людей, которые заявляют, что что-то надо уничтожить, кого-то к чему-то не подпускать, и вообще которые так уверены в своей правоте, что не дай бог им когда-либо начальниками стать
PD>Я ничего против C# и .Net не имею. Как и против Питона с Обероном, Визуал Бэйсика и Фохпро и др.. Одни языки я люблю, другие — нет, но запрещать ничего не призываю. Мне только не нравится, когда нечто новое немедленно находит адептов, которые тут же его объявляют панацеей от всех проблем. Я достаточно много таких проектов видел, которые вначале претендовали на то, чтобы все прежнее заменить, а потом в лучшем случае тихо занимали свою нишу, а в худшем — тихо помирали. ПЛ/1, Алгол-68, Ада...
Именно такую позицию я подразумевал под "съесть много собак" Вот ВлаДД — тоже съел собак, но мало, и это мы видим из его постов.
S>>время покажет, но С++ комюнити есть на что расчитывать — С++ вышел в финал ( не ы первый раз ), уже и Джава готова была похоронить С++, но не получилось
PD>С++ обязательно похоронят, так же, как в свое время похоронили Фортран, царство которого тоже казалось в то время вечным. Но это произойдет очень-очень нескоро. Похоронят только тогда, задачи, решаемые сейчас на С++, уйдут в тень, как ушли вычислительные задачи — их процент в годы моей молодости был уж точно за 50%, а сейчас — в лучшем случае проценты. Но это будет очень нескоро Потому как можно, конечно, заявлять, что эффективность не самое главное, но когда все же появится конкурентная система, то от таких заявлений толку мало будет. А в плане эффективности ему конкурентов нет.
Я имел виду старую притчу: .... или ишак сдохнет или падишах
PD>Лично мой прогноз — C++ останется базой лет на 5 как минимум для настольных приложений. Может быть, будет модифицирован, или на его базе будет создан новый язык, так же как он — на базе С. Для ОС — убежден, изменений не будет, для гигантов настольных приложений (PhotoShop, AutoCad etc.) — тоже. Макимум. что возможно — переписывание юзеровского интерфейса на .Net, а все остальное — на C++.
PD>Ну а что касается программирования для www — так там С++ никогда всерьез и не использовался. CGI на C++ написать, конечно, можно, но этого уже давно практически никто не делает. Кстати, и там ИМХО PHP с ASP.NET вполне успешно конкурирует.
PD>В общем, мое мнение — революции серьезной здесь не будет, если только MS нам ее силой не навяжет. Она, к сожалению, может.
Не навяжет, есть еще Linux и OpenSource — сил клнечно у М$ много, но эти ветрянные мельницы для нее все-таки более желательны для силовых решений ИМХО
Здравствуйте, Andrei N.Sobchuck, Вы писали:
>>> Везука, а я за 13 лет так и не поумнел. Пишу на том, за что платят.
C>>Хехе... А мне платят за то, что я пишу
ANS>А мне за то, что думаю
ANS>На том и живём.
Везука. Вот бы мне так. Я бы только и делал бы что только думал. Все думал бы, думал и думал и еще думал. А эти зверюги требуют чтобы я еще что-то делал. Поубивал бы.
Здравствуйте, VladD2, Вы писали:
H>>Вообще говоря, в теории безомапсности компьютерных систем, H>>AFAIK есть утверждение — "Более безопасная система менее удобна".
VD>Можно ссылку на этот бред?
Не на этот, но похоже
Согласно легенде, ранние конструкции торпед имели устройства безопасности, предохраняющие подводную лодку от повреждения, когда торпеда была запущена. Торпеда была сконструирована так, чтобы самоуничтожение запускалось, если торпеда поворачивалась на 180? . Идея была в том, что повернувшаяся на 180? торпеда может повредить выпустившую ее лодку. Однажды, капитан подводной лодки решил выпустить торпеду. Однако торпеда застряла в пусковой камере, и ее не смогли удалить. Капитан решил вернуться в порт для ремонта. Когда субмарина развернулась на 180 градусов, торпеда взорвалась и потопила лодку.
Здравствуйте, srggal, Вы писали:
S>Много Вы уважемый ( без иронии ) знаете языков, пускай даже модных, новых, которые так можно тюнинговать, пусть при промощи уродцев типа буста ?
Во-первых, как раз о том, что есть вещи о которых разработчики языка и не догадывались. А во вторых, я знаю много языков в которых эти вещи присутсвуют и без тюнинга. Их они там классно вписываются.
GZ>>И невозможно построить эффективный GC не теряя совместимости. S>А зачем козе баян ? (Народная мулрость)
Тута и я кинусь ссылкой.Re[17]: Лекция Вирта в политехническом — впечатления
GZ>>Полезнее придумать новый. Если красивой девушке навесить ну очень большие уши, она лучше слышать. Но вот в остальном, она потеряет. S>Вы таки заговорили аналогиями S>Хорошая аналогия, согласен, кстати есть еще дуализм: S>я бы не хотел иметь красивую девушку с Большими ушами.
Нет. С Большими ушами это уже не будет красивая. Хорошо хоть девушкой останется.
S>Вы меня правильно поняли, я тоже за то, чтобы GC не было в С++, я против радикального изменения языка, но я только один, ртдельно взятый программист
Ты не один.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, srggal, Вы писали:
S>>Много Вы уважемый ( без иронии ) знаете языков, пускай даже модных, новых, которые так можно тюнинговать, пусть при промощи уродцев типа буста ?
GZ>Во-первых, как раз о том, что есть вещи о которых разработчики языка и не догадывались. А во вторых, я знаю много языков в которых эти вещи присутсвуют и без тюнинга. Их они там классно вписываются.
ИМЕННО, я и говорю, о том, что С/С++ настолько гибкий язык, что можно прикрутить новые фокусы, а много таких языков на которые можно также прикручивать новые фокусы ?
Например к С/С++ можно прикрутить GC, а в Шарпе он уже есть.
ВОПРОС:
А можно ли от шарпа открутить GC?
GZ>>>И невозможно построить эффективный GC не теряя совместимости. S>>А зачем козе баян ? (Народная мулрость) GZ>Тута и я кинусь ссылкой.Re[17]: Лекция Вирта в политехническом — впечатления
Ссылку смотрел, зачем в С++ делегаты ?
Есть ФастДелегаты, описанные на РСДН, их использование не противоречит духу С++. Либо я чего-то не понял, либо мой довод ИМХО перекрывает Ваш.
GZ>>>Полезнее придумать новый. Если красивой девушке навесить ну очень большие уши, она лучше слышать. Но вот в остальном, она потеряет. S>>Вы таки заговорили аналогиями S>>Хорошая аналогия, согласен, кстати есть еще дуализм: S>>я бы не хотел иметь красивую девушку с Большими ушами. GZ>Нет. С Большими ушами это уже не будет красивая. Хорошо хоть девушкой останется.
Здравствуйте, Hydrogen, Вы писали:
H>Вообще говоря, в теории безомапсности компьютерных систем, H>AFAIK есть утверждение — "Более безопасная система менее удобна".
Ну да, карандашом, оно конечно, в носу ковырять удобнее, чем как все, пальцем
Ибо палец безопаснее, к тому же, не у всех пальцы умещаются в предметной области.
Здравствуйте, srggal, Вы писали:
S>>>Много Вы уважемый ( без иронии ) знаете языков, пускай даже модных, новых, которые так можно тюнинговать, пусть при промощи уродцев типа буста ?
GZ>>Во-первых, как раз о том, что есть вещи о которых разработчики языка и не догадывались. А во вторых, я знаю много языков в которых эти вещи присутсвуют и без тюнинга. Их они там классно вписываются.
S>ИМЕННО, я и говорю, о том, что С/С++ настолько гибкий язык, что можно прикрутить новые фокусы, а много таких языков на которые можно также прикручивать новые фокусы ?
Ну, про Лисп не забываем. Многие функциональные языки это умеют. Или тот-же рекламируемый eao197 ruby. Прикручивать фокусы — это не пререгатива С++.
S>Например к С/С++ можно прикрутить GC, а в Шарпе он уже есть.
Прикрутить то можно. Но те GC которые я видел(не использовал а читал документацию), не позволяют прикрутить многие фичи. Ц как был так и остался, как его крестами не добавляй.
S>ВОПРОС: S> А можно ли от шарпа открутить GC?
Можно, только отвалятся многие полезные фичи, и это уже не будет C#.
GZ>>>>И невозможно построить эффективный GC не теряя совместимости. S>>>А зачем козе баян ? (Народная мулрость) GZ>>Тута и я кинусь ссылкой.Re[17]: Лекция Вирта в политехническом — впечатления
S>Повторюсь про баян. S>Ссылку смотрел, зачем в С++ делегаты ?
Нет. S>Есть ФастДелегаты, описанные на РСДН, их использование не противоречит духу С++. Либо я чего-то не понял, либо мой довод ИМХО перекрывает Ваш.
Я помню эту статью(сейчас доступа нет). Большая часть посвящена тому, что компиляторы С++ очень разные. Что касается делегатов(независимо от того, fastdelegate или boost.function), то я при своем мнении и забаяню. Тяжело контролировать в вызове функции, жив ли объект или мы вызываем ссылку на убитый объект. Лучше не станет.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, srggal, Вы писали:
S>>ИМЕННО, я и говорю, о том, что С/С++ настолько гибкий язык, что можно прикрутить новые фокусы, а много таких языков на которые можно также прикручивать новые фокусы ? GZ>Ну, про Лисп не забываем. Многие функциональные языки это умеют. Или тот-же рекламируемый eao197 ruby. Прикручивать фокусы — это не пререгатива С++.
Соглашусь, тем не менее СШарп Вы не назвали
S>>Например к С/С++ можно прикрутить GC, а в Шарпе он уже есть. GZ>Прикрутить то можно. Но те GC которые я видел(не использовал а читал документацию), не позволяют прикрутить многие фичи. Ц как был так и остался, как его крестами не добавляй.
S>>ВОПРОС: S>> А можно ли от шарпа открутить GC? GZ>Можно, только отвалятся многие полезные фичи, и это уже не будет C#.
Если можно ссылок, интересно мне очень.
GZ>Я помню эту статью(сейчас доступа нет). Большая часть посвящена тому, что компиляторы С++ очень разные. Что касается делегатов(независимо от того, fastdelegate или boost.function), то я при своем мнении и забаяню. Тяжело контролировать в вызове функции, жив ли объект или мы вызываем ссылку на убитый объект. Лучше не станет.
Тем не менее — жесткий контроль идет в разрез духу С++ и мы с Вами согласились, что С++ трогать не стоит в этом плане.
Собственно, мне нравится в С++ сильная статическая типизация. По сравнению с тем же C# мне крайне редко приходлось отлаживать программы в пошаговом редакторе, используя С++. Еще немного более строгая типизация не повредила бы.
Это явно выдумка. Сила типизации в С++ несравнимо ниже. Статическая типизация анлогична. Джененирики устраняют последние потуги к динмическим приведениям типов.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
V>Дудки. Добавьте в шарп зависимые типы, статические шаблоны, возможность иметь параметр шаблона базой, явное управление памятью (мне далеко не всегда нужен GC), указатели на члены (и на методы в т.ч.) и тогда это и будет "оно"
Не будет. Из шарпа прийдется выкинуть половину языка и его компонентный дух. Однако утверждение srggal так же не верно.
В общем, Шарп и С++ очень разные языки. Они филосовски разные.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, srggal, Вы писали:
S>Соглашусь, тем не менее СШарп Вы не назвали
Потому что там этого нет В C# достаточно своих фич чтобы не нуждаться в таком расширении.
S>Если можно ссылок, интересно мне очень.
Не, ссылок типа в вот что было бы если бы этого не было — не дам. Не потому что жалко, а просто нет и не видел. Но могу сразу сказать — делегаты сразу отвалятся. mutable string возможно отвалятся. Ну наверно еще много что можно намешать, просто над такой идиотской мыслью не задумывался. Как я сказал — шарпом это назвать нельзя.
GZ>>Я помню эту статью(сейчас доступа нет). Большая часть посвящена тому, что компиляторы С++ очень разные. Что касается делегатов(независимо от того, fastdelegate или boost.function), то я при своем мнении и забаяню. Тяжело контролировать в вызове функции, жив ли объект или мы вызываем ссылку на убитый объект. Лучше не станет. S>Тем не менее — жесткий контроль идет в разрез духу С++ и мы с Вами согласились, что С++ трогать не стоит в этом плане.
Unexpected error — это дух C++?
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, srggal, Вы писали:
S>>Соглашусь, тем не менее СШарп Вы не назвали GZ>Потому что там этого нет В C# достаточно своих фич чтобы не нуждаться в таком расширении.
S>>Если можно ссылок, интересно мне очень. GZ>Не, ссылок типа в вот что было бы если бы этого не было — не дам. Не потому что жалко, а просто нет и не видел. Но могу сразу сказать — делегаты сразу отвалятся. mutable string возможно отвалятся. Ну наверно еще много что можно намешать, просто над такой идиотской мыслью не задумывался. Как я сказал — шарпом это назвать нельзя.
Я надеюсь, мы друг-друга понялию, и что я имел в виду когда писал про СШарп, думаю Вы тоже поняли.
GZ>>>Я помню эту статью(сейчас доступа нет). Большая часть посвящена тому, что компиляторы С++ очень разные. Что касается делегатов(независимо от того, fastdelegate или boost.function), то я при своем мнении и забаяню. Тяжело контролировать в вызове функции, жив ли объект или мы вызываем ссылку на убитый объект. Лучше не станет. S>>Тем не менее — жесткий контроль идет в разрез духу С++ и мы с Вами согласились, что С++ трогать не стоит в этом плане. GZ>Unexpected error — это дух C++?
Да, это дух С++ и UB — дух С++ и кроме того UnspecB — тоже дух С++
Это ВСЁ дух С++. Как грится, — не зная брода — ... С++ не программируй.
Здравствуйте, eao197, Вы писали:
E>Не на этот, но похоже E>
E>Согласно легенде, ранние конструкции торпед имели устройства безопасности, предохраняющие подводную лодку от повреждения, когда торпеда была запущена. Торпеда была сконструирована так, чтобы самоуничтожение запускалось, если торпеда поворачивалась на 180? . Идея была в том, что повернувшаяся на 180? торпеда может повредить выпустившую ее лодку. Однажды, капитан подводной лодки решил выпустить торпеду. Однако торпеда застряла в пусковой камере, и ее не смогли удалить. Капитан решил вернуться в порт для ремонта. Когда субмарина развернулась на 180 градусов, торпеда взорвалась и потопила лодку.
Singularity does the same as well, it only use BIOS during the 16-bit real-mode boot strap. Once jump to 32-bit mode, we never use BIOS again, but use device drivers written in C# instead. Yes, we had to replace a lot of CLR libraries with different code. However, unlike the CLR, the Singularity runtime is written in C#.
Singularity executables represent executable code in
an abstract instruction set, called MSIL. MSIL is Microsoft’s
implementation of the ECMA Common Intermediate
Language [25]. All third-party executables,
including applications and device drivers, are delivered
to Singularity as type-safe MSIL binaries.
S>Точно также как и на Джаве, некоторые горячие головы ытались реалтизовать аппаратную поддержку Джава — спец- Джава процессоры и все такое, — ан не сильно получилось.
Вообще-то получается. Тут ты снова пальцем в небо. Другое дело, что практика показывает, что спец.процессоры явно уступают идее JIT-компиляции.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, srggal, Вы писали:
S>Спасибо за интересную ссылку, но все таки, оттуда:
S>
S>Again, this is a prototype research OS, not a full fledged OS that can run the typical applications you've come to expect of an OS (or even provide a user interface beyond, say, that of DOS).
И? Ты утверждал что на C# нельзя писать драйверы. В этой ОС все драйверы написаны на этом языке. Может лучше признать, что ты поспешил с выводами?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DJ KARIES, Вы писали:
DK>Здравствуйте, Hydrogen, Вы писали:
H>>Вообще говоря, в теории безомапсности компьютерных систем, H>>AFAIK есть утверждение — "Более безопасная система менее удобна". DK>Ну да, карандашом, оно конечно, в носу ковырять удобнее, чем как все, пальцем
Ну и зачем сравнивать заведомо неэффективную систему с эффективной? DK>Ибо палец безопаснее, к тому же, не у всех пальцы умещаются в предметной области.
Неправильно надо так:
1. Собираем типовой блок питания для усилителя. Для этого мы выясняем пробойное напряжение
провода, бумаги для прослойки между обмотками, провод выбираем с военной приемкой, все проверяем по тысячу раз.
Удобно — нет. Безопасно — да.
2. Собираем типовой блок питания для усилителя. Для этого мы берем обычный провод из кладовки, кладем два слоя промаслянной бумаги, и не мороча голову мотаем.
Удобно — да. Безопасно — много меньше чем в п.1.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Hydrogen, Вы писали:
H>>>>AFAIK есть утверждение — "Более безопасная система менее удобна".
VD>>>Можно ссылку на этот бред? H>>Если Вы считаете это бредом, то ссылку не дам.
VD>А чем еще можно считать постановку в один ряд несовместимых понятий? VD>Да и на примерах это бредовое утверждение рассыпается сразу. Возмем ДОС и Windows XP и сравним их с точки зрения удобства использования и безопасности.
Во-первых безопасности чего? VD> По обоим критериях ХРюша явно выигрывает. Другй пример, новая качественная иномарка и Жигули. Таких примеров можно привести бесчисленное множество.
Во-первых, это совершенно справедливо для систем разграничения доступа и безопасности компьютеров и сетей.
Для остальных случаев согласен, это спорный вопрос, можно привести как доводы за так и против.
Во-вторых, нужно сравнивать системы одного класса, даже лучше два варианта одной и той же системы.
E>>Согласно легенде, ранние конструкции торпед имели устройства безопасности, предохраняющие подводную лодку от повреждения, когда торпеда была запущена. Торпеда была сконструирована так, чтобы самоуничтожение запускалось, если торпеда поворачивалась на 180? . Идея была в том, что повернувшаяся на 180? торпеда может повредить выпустившую ее лодку. Однажды, капитан подводной лодки решил выпустить торпеду. Однако торпеда застряла в пусковой камере, и ее не смогли удалить. Капитан решил вернуться в порт для ремонта. Когда субмарина развернулась на 180 градусов, торпеда взорвалась и потопила лодку.
Имхо, самое прямое. Так же, как и афоризм: "Можно сделать систему, которой сможет пользоваться даже дурак. И только дурак станет ей пользоваться".
Безопасность не дается просто так. Иногда за нее приходится расплачиваться удобством. Вспомни, хотя бы, контейнеры из Java до появления Generic-ов. Безопасно? Да. Удобно. Вряд ли, т.к. после извлечения объекта из контейнера всегда приходилось делать приведение типа. Между тем, так приходилось писать практически 8 лет.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
H>Во-первых, это совершенно справедливо для систем разграничения доступа и безопасности компьютеров и сетей.
С какой стати?
H>Для остальных случаев согласен, это спорный вопрос, можно привести как доводы за так и против. H>Во-вторых, нужно сравнивать системы одного класса, даже лучше два варианта одной и той же системы.
C чего бы это? Заявление делалось без каких либло поправок на классы слжности.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Безопасность не дается просто так. Иногда за нее приходится расплачиваться удобством.
Вот именно, что иногда. А иногда наоборот.
E> Вспомни, хотя бы, контейнеры из Java до появления Generic-ов. Безопасно? Да. Удобно. Вряд ли, т.к. после извлечения объекта из контейнера всегда приходилось делать приведение типа. Между тем, так приходилось писать практически 8 лет.
Офигительная аргументация. Сам то не понимашь, что этот пример ни коим боком не противопоставляет удобство безопастности? Ты с тем же успехом можешь делать такие же неудобные контейнеры на С++, но при этом они еще к тому же будут небезопастными.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>В нашей системе мы выделенное в коде не описываем. В момент инициализации сопоставляем все подобные сущности с их описанием в БД, и эти ограничения выхватываем из схемы БД. Т.е. избавляемся от повторного описания ограничений.
Тоже вариант.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, srggal, Вы писали:
S>Мысль понял, красивый ход.
Шахматист, блин На вопрос так и не ответил.
S>Но строчки написанного системного ПО дорогого стоят
На сколько дороже?
S>В любом случае, понимая к чему Вы ведете, и имею Вам что сказать:
Я это всё знаю. Но так же знаю, что количество софта типа отчётов и формочек для тёти Маши, веб сайтов, ентерпрайзов и прочей базаданново-формочной шелупни разрабатывается на несколько порядков, в сотни, в тысячи раз больше, чем драйверов. Это ты тут такой уникальный попался. А для подавляюшего числа C++ программистов написание драйверов — это такая же экзотика как и для всех остальных. Поэтому, твое утверждение
А если серьезно, от опять же каждому своё — например написать драйвер на СШарп — не получиться
может и является отчасти справедливым, но, тем не менее, если и даёт C++ какое-то преимушество, то на столько мизерное, что его не видно даже в микроскоп при максимальном увеличении. А в сравнении с его недостатками — это просто смешно. ХА-ХА-ХА!
S>Так что, я не против других языков, я против ходьбы в чужой монастырь со своим уставом.
Люди тебя спасти хотят, образумить, направить на путь истинный, а ты их за ворота
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Тут надо не о собаках, а о динозаврах аналогии приводить. Они долго доминировали на Земле, но вот точно так же не захотели куда-то переходить и все вымерли
S> Я люблю этот язык таким каким его делает комитет стандартизации И рад, что этот я зык есть.
Как антиквар антиквара я бы тебя мог понять
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
согласен с большинством тезисов в том виде, как я их понял (в команде писать одновременно на многих универсальных языках одинаково эффективно -- сложно, во всяком случае, если предъявлять к оценке эффективности высокие требования; в маленьких командах это делать подчас проще, чем в больших и т.п.)
Единственное, где хотелось бы уточнить -- пожалуй, не стоит отождествлять маленькие команды с маленькими проектами, т.к. из уравнения выпадает временная составляющая
> Я считаю, что есть некоторый диапазон, в котором для проекта очень важно иметь минимальное количество использованных языков. Скажем, объем проекта от 200 до 500 тысяч строк и команда от 7 до 20 человек.
Для иллюстрации. Ради любопытства прикинул объем кода в одной из наших веток. Получилось, пожалуй, не меньше полу-миллиона строк. Наверное, что-то там дублируется и т.п., но вряд ли это даст принципиальную разницу. Сторонний код (которого, естественно, в несколько раз больше) не учитывал. Количество программистов только недавно добралось до заявленного нижнего порога (наверное, года 2-3 из примерно 12).
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали: VD>Можно ссылку на этот бред?
На самом деле все не так плохо. Безопасность-удобство-стоимость образуют треугольник компромисса.
Безопасность здесь понимается не та, которая спасает от переполнения буфера или от коре дампа при делении на ноль.
Имеется в виду безопасность данных от несанкционированного доступа.
И одно дело уязвимость, а другое дело — когда тебе каждые три минуты надо вбивать пароль не короче тридцати символов в разном регистре.
В большинстве случаев "завинчивание гаек" безопасности сразу снижает удобство.
Хотя неотъемлемого неудобства в безопасности вроде бы нет, внедрение удобных безопасных решений как правило стоит больше денег, чем неудобных. Куда дешевле заставить всех на входе в офис раздеваться, чем поставить металлодетектор.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, srggal, Вы писали:
PD>>В общем, мое мнение — революции серьезной здесь не будет, если только MS нам ее силой не навяжет. Она, к сожалению, может.
S>Не навяжет, есть еще Linux и OpenSource — сил клнечно у М$ много, но эти ветрянные мельницы для нее все-таки более желательны для силовых решений ИМХО
Бог знает. Дело в том, что все же реально MS монополист. Другие ОС ей в мире массового пользователя не конкуренты. И это, похоже, очень надолго. Такого никогда в истории западного общества не было. Если вдруг "Рено" сделает какую-нибудь глупость в автомобилестроении, то ее рынок с радостью поделят другие фирмы, а в мире будет одной автомобильной фирмой меньше — эка беда, их десятки. А вот MS — монополист.
Я иногда жалею, что IBM не смогла составить конкуренции Windows с OS/2. В общем, эта ОС была совсем неплохо задумана. Если бы она реально конкурировала с Windows, у MS было бы намного меньше возможностей делать то, что ей в голову придет и заставлять нас следовать ее шараханьям из стороны в сторону.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>согласен с большинством тезисов в том виде, как я их понял (в команде писать одновременно на многих универсальных языках одинаково эффективно -- сложно, во всяком случае, если предъявлять к оценке эффективности высокие требования; в маленьких командах это делать подчас проще, чем в больших и т.п.)
+1
ПК>Единственное, где хотелось бы уточнить -- пожалуй, не стоит отождествлять маленькие команды с маленькими проектами, т.к. из уравнения выпадает временная составляющая
А я и не отождествлял
Я говорил:
объем проекта от 200 до 500 тысяч строк и команда от 7 до 20 человек
В этих случаях начинают действовать другие законы, чем в ситуации, когда объем проекта 200-500 тысяч строк и команда в 2-3 человека.
>> Я считаю, что есть некоторый диапазон, в котором для проекта очень важно иметь минимальное количество использованных языков. Скажем, объем проекта от 200 до 500 тысяч строк и команда от 7 до 20 человек.
ПК>Для иллюстрации. Ради любопытства прикинул объем кода в одной из наших веток. Получилось, пожалуй, не меньше полу-миллиона строк. Наверное, что-то там дублируется и т.п., но вряд ли это даст принципиальную разницу. Сторонний код (которого, естественно, в несколько раз больше) не учитывал. Количество программистов только недавно добралось до заявленного нижнего порога (наверное, года 2-3 из примерно 12).
Я сейчас тоже прикинул объем моего текущего проекта ~210. В основном (%75) это мой код, но время от времени ко мне 2-3 человека подключались.
Так что с твом замечанием про маленькие команды != маленькие проекты я полностью согласен. У меня даже есть впечатление, что маленькими командами большие проекты делать проще
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
VD>Согласен со всем кроме: VD>
Собственно, мне нравится в С++ сильная статическая типизация. По сравнению с тем же C# мне крайне редко приходлось отлаживать программы в пошаговом редакторе, используя С++. Еще немного более строгая типизация не повредила бы.
VD>Это явно выдумка. Сила типизации в С++ несравнимо ниже. Статическая типизация анлогична. Джененирики устраняют последние потуги к динмическим приведениям типов.
Однако! Возьмём, например, String.Format. Что-то я там не заметил особенной статической типизации. Аналог на C++ может быть либо ostringstream, либо Boost.Format. Оба полностью статически типизированны.
Здравствуйте, Andrei Gorlov, Вы писали:
>>>а у С# их пять пригляделся?
AG>пригляделся. те же два, только кривые и наложенные друг на друга (с) кто-то в одном из форумов rsdn...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я иногда жалею, что IBM не смогла составить конкуренции Windows с OS/2.
Во-первых, подозреваю, что межделмаш-у это банально не было нужно. Они мыслят категориями прибыли, а МС им винду продавали по спеццене (за копейки). Вероятно это было дешевле чем самим разрабатывать ОС, возиться с драйверами, поддержкой, и пр. Плюс, против бимеров раньше велись антимонопольные дела, и получить еще одно им нафиг не нужно было .
Во-вторых, у них есть один продукт — майнфреймы, а всё остальное это "наносное". Типа, сегодня мода на один продукт — делаем этот продукт, завтра на другой — делаем другой, а про первый быстро забываем.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, srggal, Вы писали:
S>>А если серьезно, от опять же каждому своё — например написать драйвер на СШарп — не получиться
VD>Как всегда пальцем в небо. VD>Знакомься с исследовательской ОС Singularity 99% кода которой написано на C#.
Лично для меня — это уже не новость, я писал об этом здесь
Здравствуйте, VladD2, Вы писали:
VD>И? Ты утверждал что на C# нельзя писать драйверы. В этой ОС все драйверы написаны на этом языке. Может лучше признать, что ты поспешил с выводами?
Для тех кто в бронепоезде:
В силу своей ограниченности я не знал, что существует такая эксперементальная ОС целиком написанная на СШарп, и в которой можно писать свои драйвера на СШарп
Точно также как и на Джаве, некоторые горячие головы ытались реалтизовать аппаратную поддержку Джава — спец- Джава процессоры и все такое, — ан не сильно получилось
Так что поглядим какие выводы сделает из эксперимента M$ ( кстати это уже звучало )
IBM R400 + ПМО от IBM — позволяют делать такие вещи, которые M$ и не снились
Причем есть спрос на такие продукты, хоть и цены на них несравнимы с ценами на продукты M$.
Причем M$ не пытается свою ОС написать для R400 ж)
Здравствуйте, IT, Вы писали:
Драйверов я написал всего 3, но есть форум где тусуются люди, которые гораздо больше меня знают в этом вопросе, и исходя из их кол-ва, — не так уж мало задач по разработкае драйверов.
Но, в принципе — я согласен что СПО нужно гораздо меньше чем ППО, ибо конечные пользователи, таки используют ППО и именно для них все и затевается с СПО.
Я против СШарп ничего не имею, кроме того, 2.0 мне понравился, к сожалению мне платят деньги только за С/С++.
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, Andrei N.Sobchuck, Вы писали:
S>Причем M$ не пытается свою ОС написать для R400 ж)
А на кой MS это сдалось? Эти системы продаются единицами и о последующем апгрейде за деньги там речь по сути не идет, так как работает принцип — работает не трожь. У Windows ситуация противоположная: сколько там миллионов копий Windows XP продано? По стоимости получается приблизительно несколько сот проданных R400. Но пройдет время и хочешь не хочешь, а OEM поставщики ПК будут впаривать тебе Vista, да и сам народ начнет потихонечку перебираться на нее, а это опять деньги в пользу Microsoft.
Всем, кто поддержал — спасибо. Увы, войну остановить не удалось. Хотя и несогласие никто не выразил, но это не то молчание, которое знак согласия.
Что меня огорчает — фанатическая нетерпимость некоторых к другому мнению. В общем, увы, советское воспитание легко не исчезает.
"По этому вопросу есть два мнения — одно мое, другое неправильное"
И редко у кого из этих людей возникает хоть тень сомнения в своей правоте. В общем, лозунг "Сомневайтесь" — явно не для них. Они знают истину в последней инстанции. Признать свою неправоту хоть в чем-то — выше их сил.
Здравствуйте, GlebZ, Вы писали:
S>>Соглашусь, тем не менее СШарп Вы не назвали GZ>Потому что там этого нет В C# достаточно своих фич чтобы не нуждаться в таком расширении.
GZ>>>Я помню эту статью(сейчас доступа нет). Большая часть посвящена тому, что компиляторы С++ очень разные. Что касается делегатов(независимо от того, fastdelegate или boost.function), то я при своем мнении и забаяню. Тяжело контролировать в вызове функции, жив ли объект или мы вызываем ссылку на убитый объект. Лучше не станет. S>>Тем не менее — жесткий контроль идет в разрез духу С++ и мы с Вами согласились, что С++ трогать не стоит в этом плане. GZ>Unexpected error — это дух C++?
Вот еще подумалось у духах ( ударение н2ом слоге )
Преамбула:
Была такая задача DataAccessor, он должен вычитывать данные из БД и предоставлять Бизнесс-интерфейс для доступа к данным, БД может работать на удаленной машине, причем акссессор должен работать на той же машине что и БД. Использовали корбу, чтобы не изобретать велосипед.
Проблема появилась неожиданно: ValueType использовались ОРБОМ повсеместно, и как результат — датааксессор отрабатывал запрос клиента — корба маршалила данные.... и в памяти оставалось ~500 метров большей частью ValueType'ов, которые уже были не нужны и кроме того клиент уже обработал данные и ему тоже они были не нужны. Попытки инициации процесса GC не привели ни к чему хорошему — проседало время реакции на запросы клиентов.
Такая грустная песня об автоматической сборке мысора и ValueType для большого кол-ва кратко живущих экземпляров...
Здравствуйте, srggal, Вы писали:
PD>>А они есть. MFC называется
S>Я думал Мы грим о <winows.h> и иже с ними
А windows.h в базовой части в основном С, а не С++. Естественно, если не говорить об OLE.
С врапперами вокруг хендлов не так все просто. Дело в том, что многие хендлы имеют ассоциированный с ними счетчик. Например, LoadLibrary-FreeLibrary, Create/OpenXX — CloseHandle. И если кто-то в этом случае будет вызывать исходные функции Win API напрямую, то без проблем не обойдется.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А windows.h в базовой части в основном С, а не С++. Естественно, если не говорить об OLE.
Cделали бы cwindows в дополнение к windows.h, как поступили другие люди с остальными include.
В таком случае, подобной темы никогда бы не возникло.
Оттуда и хэндлы
PD>С врапперами вокруг хендлов не так все просто. Дело в том, что многие хендлы имеют ассоциированный с ними счетчик. Например, LoadLibrary-FreeLibrary, Create/OpenXX — CloseHandle. И если кто-то в этом случае будет вызывать исходные функции Win API напрямую, то без проблем не обойдется.
Да, проблемы могут возникнуть, но в кривых — не умелых или неопытных, а может и просто в невнимательных руках
Но ведь можно использовать подобную функциональность правильно ?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Hydrogen, Вы писали:
H>>Во-первых, это совершенно справедливо для систем разграничения доступа и безопасности компьютеров и сетей. VD>С какой стати?
Легко проверить. Никогда не пробовали Secure Linux, насколько он удобен?
Или включить файрвол, антивирус, Ad-Aware Monitor и видеть сколько страниц не не грузится и будет работать медленее, и для каждого аппликейшена создавать свой профайл в файерволле и.т.д.
H>>Для остальных случаев согласен, это спорный вопрос, можно привести как доводы за так и против. H>>Во-вторых, нужно сравнивать системы одного класса, даже лучше два варианта одной и той же системы.
VD>C чего бы это? Заявление делалось без каких либло поправок на классы слжности.
Потому что в простой системе просто напросто нет того функционала который Вам нужен.
-------
Говоря иначе, перефразировав свою мысль:
Безопасность превышающая необходимый (для конкретной цели) уровень, является неудобством.
Здравствуйте, Hydrogen, Вы писали:
H>>>Во-первых, это совершенно справедливо для систем разграничения доступа и безопасности компьютеров и сетей. VD>>С какой стати? H>Легко проверить. Никогда не пробовали Secure Linux, насколько он удобен? H>Или включить файрвол, антивирус, Ad-Aware Monitor и видеть сколько страниц не не грузится и будет работать медленее, и для каждого аппликейшена создавать свой профайл в файерволле и.т.д.
Более жизненный Владу пример: повышаеш уровень безопасности в эксплорере — отваливается локальный МСДН.
Здравствуйте, srggal, Вы писали:
S>Для тех кто в бронепоезде:
S>В силу своей ограниченности я не знал, что существует такая эксперементальная ОС целиком написанная на СШарп, и в которой можно писать свои драйвера на СШарп
Это ты похоже в бронепоезде. Понял, что не прав, так скажи извините, мол был не прав.
Ты думашь тут единственный с такими заявлениями? И ведь никому в голову не прийдет поиском воспользоваться.
S>Думал это и так ясно.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexeiz, Вы писали:
A>Однако! Возьмём, например, String.Format. Что-то я там не заметил особенной статической типизации. Аналог на C++ может быть либо ostringstream, либо Boost.Format. Оба полностью статически типизированны.
И? Это говорит о чем-то? Динамическая типизация в дотнете несомненно есть. Использовать ее несомноно не обязательно. Так что можно сказать, что в дотнете статическая типизация не хуже С++-ной, но динамическая гараздо лучше.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Имеется в виду безопасность данных от несанкционированного доступа. S>И одно дело уязвимость, а другое дело — когда тебе каждые три минуты надо вбивать пароль не короче тридцати символов в разном регистре.
Ну, вот в ДОС-е с безопасностью было явно хуже чем в NT. Пароли приходилось вбивать куда чаще чем в NT. Какие мне делать выводы? По твоей логике вывод должен быть — "безопасные системы удобнее небезопасных". Чущь? Несомненно. А все потому, что удобство зависит исключительно от того насклько разработчики системы его добивались. Например, API дотнета явно удобнее Windows API, но при этом дотнетные API явно более безопасны чем виндузные.
S>В большинстве случаев "завинчивание гаек" безопасности сразу снижает удобство.
Возможно это усложняет создание удобных интерфейсов, но это снижение не идет ни в какое сравнение с усилиями прикладываемыми для получения удобных интерфейсов. Просто приводит к более грамотному проектированию аспектов безопасности. Собственно я еже устал приводить примеры этого.
S>Хотя неотъемлемого неудобства в безопасности вроде бы нет, внедрение удобных безопасных решений как правило стоит больше денег, чем неудобных. Куда дешевле заставить всех на входе в офис раздеваться, чем поставить металлодетектор.
Безопасность — это аспект разработки. Удобство — это тоже аспект разработки. Было бы странно если сведение двух аспектов в одном продукте не приводило к усложнению его разработки. Вот только это справидливо для любых аспктов и из этого никак не вытикает, что безопасные системы менее удобны. Так что процетированное заявление является полным бредом, как я об этом и говорил.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
он говорит, что эта библиотека 4fun). E>Интересно, многие бы повеселились, если бы увидели такой код в реальном проекте?
Самое забавное, что сами то идеи интересные. Вот только вылевается это все на шаблонах в ужас кромешный. Так что согласен. Я бы предпочел нечто по проще.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, srggal, Вы писали:
S>>Для тех кто в бронепоезде:
S>>В силу своей ограниченности я не знал, что существует такая эксперементальная ОС целиком написанная на СШарп, и в которой можно писать свои драйвера на СШарп
VD>Это ты похоже в бронепоезде. Понял, что не прав, так скажи извините, мол был не прав. VD>Ты думашь тут единственный с такими заявлениями? И ведь никому в голову не прийдет поиском воспользоваться.
S>>Думал это и так ясно.
Это Всё ? комментировать приведенные ссылки не будете
Здравствуйте, Hydrogen, Вы писали:
H>Легко проверить. Никогда не пробовали Secure Linux, насколько он удобен? H>Или включить файрвол, антивирус, Ad-Aware Monitor и видеть сколько страниц не не грузится и будет работать медленее, и для каждого аппликейшена создавать свой профайл в файерволле и.т.д.
Ну, то есть идет подмена понятия удобство на скорость?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Более жизненный Владу пример: повышаеш уровень безопасности в эксплорере — отваливается локальный МСДН.
Ну, при установку на 95-ые он тоже глючит. Делаем обратный вывод?
Записывать глюки в неудобство несколько странно.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, srggal, Вы писали:
S>Была такая задача DataAccessor, он должен вычитывать данные из БД и предоставлять Бизнесс-интерфейс для доступа к данным, БД может работать на удаленной машине, причем акссессор должен работать на той же машине что и БД. Использовали корбу, чтобы не изобретать велосипед.
S>Проблема появилась неожиданно: ValueType использовались ОРБОМ повсеместно, и как результат — датааксессор отрабатывал запрос клиента — корба маршалила данные.... и в памяти оставалось ~500 метров большей частью ValueType'ов, которые уже были не нужны и кроме того клиент уже обработал данные и ему тоже они были не нужны. Попытки инициации процесса GC не привели ни к чему хорошему — проседало время реакции на запросы клиентов.
S>Такая грустная песня об автоматической сборке мысора и ValueType для большого кол-ва кратко живущих экземпляров...
Какое отношение КОРБА имеет к GC? И какое отношение имеют ValueType-ы к GC? Что-то я ничего не понял.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ANS>>Более жизненный Владу пример: повышаеш уровень безопасности в эксплорере — отваливается локальный МСДН.
VD>Ну, при установку на 95-ые он тоже глючит. Делаем обратный вывод? VD>Записывать глюки в неудобство несколько странно.
имхо, это не глюки. там блокируется какойто ActiveX. При том, как его "разрешить" не трогая уровень безопасности я не понял.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, srggal, Вы писали:
S>>Была такая задача DataAccessor, он должен вычитывать данные из БД и предоставлять Бизнесс-интерфейс для доступа к данным, БД может работать на удаленной машине, причем акссессор должен работать на той же машине что и БД. Использовали корбу, чтобы не изобретать велосипед.
S>>Проблема появилась неожиданно: ValueType использовались ОРБОМ повсеместно, и как результат — датааксессор отрабатывал запрос клиента — корба маршалила данные.... и в памяти оставалось ~500 метров большей частью ValueType'ов, которые уже были не нужны и кроме того клиент уже обработал данные и ему тоже они были не нужны. Попытки инициации процесса GC не привели ни к чему хорошему — проседало время реакции на запросы клиентов.
S>>Такая грустная песня об автоматической сборке мысора и ValueType для большого кол-ва кратко живущих экземпляров...
VD>Какое отношение КОРБА имеет к GC?
ОРБОМ генерил стабы на СШарп
VD>И какое отношение имеют ValueType-ы к GC? Что-то я ничего не понял.
в процессе работы использовалось большое кол-во ValueType ( это вкратце ) В Шарпе, насколько я знаю, даже для управления памятью, отведенной под ValueType, используется GC.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что меня огорчает — фанатическая нетерпимость некоторых к другому мнению. В общем, увы, советское воспитание легко не исчезает.
PD>"По этому вопросу есть два мнения — одно мое, другое неправильное"
PD>И редко у кого из этих людей возникает хоть тень сомнения в своей правоте. В общем, лозунг "Сомневайтесь" — явно не для них. Они знают истину в последней инстанции. Признать свою неправоту хоть в чем-то — выше их сил.
PD>Печально.
Печально другое. Печально что есть люди тыкающие в других пальцем и наклеивающие ярлыки. Но при этом эти люди мами как нельзя лучше подходят к своим ярлыкам. Они даже слушать не хотят этого другого мнения, но при этом обвиняют в том же оппонента. Причем доказать что-либо им невозможно. Они просто нацлены на определенный план. Их задача любыми способами нейти фатальный недостато. В ход идут подтасовки (вроде сравнения создания новых объектов с копированием данных в статический буфер) и другие приемы нечесной дискусси. Ну, и чтобы быть по убедительнее применяют последний прием — обвинение оппонентов в отсуствии сомнений в своей правоте.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DJ KARIES, Вы писали:
DK>Причём в том же MSVC эта галочка есть — Ansi/Unicode/MBCS. DK>[b]Почему программеры юзают в каждой строке _T("")?
Потому-что "галочки" переключают макросы препроцесора. Сами строки при том не изменяются. А уже в зависимости от значений макросвов макрос _T принимает то или иное значение.
Согласен, что это лажа. Лажа языковая. Но тут уже похоже ничего не поделаешь.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, srggal, Вы писали:
S>>Это Всё ? комментировать приведенные ссылки не будете
VD>А что коментировать то?
Ну например:
What are you using to compile the MSIL into x86?
how are you handling hardware interupts, and the interupt vector table and interupt service routines from C# code?
C# code has no way to interact with the bios. You can't drop into __asm { }; in C#.
X86 аппаратно поддерживает IL поддерживает
ЗЫ впрочем не нужно комментариев устал от дискуссии, буду работать.
Здравствуйте, VladD2, Вы писали:
VD>Ну, вот в ДОС-е с безопасностью было явно хуже чем в NT. Пароли приходилось вбивать куда чаще чем в NT. Какие мне делать выводы?
Влад, не парь мозг. Вот лично мне в досе вообще паролей вбивать не приходилось. И это было значительно удобнее, чем с паролями. VD>По твоей логике вывод должен быть — "безопасные системы удобнее небезопасных".
Нет. Вывод — "можно сделать небезопасную неудобную систему". Более того, Влад, можно сделать еще и офигенно дорогую, небезопасную и неудобную систему. Не имеет смысла обсуждать развитие в этом направлении.
S>>В большинстве случаев "завинчивание гаек" безопасности сразу снижает удобство. VD>Возможно это усложняет создание удобных интерфейсов,
А я что говорю? Усиление безопасности требует дополнительных вложений для сохранения удобства. VD> но это снижение не идет ни в какое сравнение с усилиями прикладываемыми для получения удобных интерфейсов. Просто приводит к более грамотному проектированию аспектов безопасности. Собственно я еже устал приводить примеры этого.
Да ты еще и не начинал. Вот только не надо про дос больше рассказывать. 0S>>Хотя неотъемлемого неудобства в безопасности вроде бы нет, внедрение удобных VD>Безопасность — это аспект разработки. Удобство — это тоже аспект разработки. Было бы странно если сведение двух аспектов в одном продукте не приводило к усложнению его разработки. Вот только это справидливо для любых аспктов и из этого никак не вытикает, что безопасные системы менее удобны. Так что процетированное заявление является полным бредом, как я об этом и говорил.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>What are you using to compile the MSIL into x86?
S>how are you handling hardware interupts, and the interupt vector table and interupt service routines from C# code?
S>C# code has no way to interact with the bios. You can't drop into __asm { }; in C#.
И что тут коментировать? Это два вопроса и одно утверждение.
Если тебе интересно как рабоает эта ОС, то почитай обсуждение по внимательнее. Там все описано. Просто глубже. Если на пальцах... Есть HAL и загрузчик которые написаны на не C#. Это очень маленький по объему код. Его задачи работа с кокретным железом и абстрагирование всего остального от него. Примерно так же была написана первая версия NT. Драйверы и т.п. уже работают через этот HAL. Часть C#-кода (очень малая) использует небезопасное расширение. В частности ансэйф используется для реализации GC. Кстати, тут до тебя были товарищи утверждавшие, что на C# нельзя делать ни GC, ни компиляторы. Как видишь это тоже не верно.
S>X86 аппаратно поддерживает IL поддерживает
К чему бы это ты сказал?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, srggal, Вы писали:
VD>>Какое отношение КОРБА имеет к GC?
S>ОРБОМ генерил стабы на СШарп
Стабы наверно все же генерируеются генераторами кода idl2xxx. Но причем тут ОРБ? Он то скорее всего на плюсах написан.
При передаче данныех ОРБ-у может быть два сценария.
1. Создание объектной ссылки. Тогда ОРБ управляет жизнью объекта.
2. Сериализация состояния объектоа. Так вот вэлью-типа принципиально невозможно передаватьп по ссылке. Так что они должны обязательно сериализоваться. Альтернативной является боксинг, но при этом вэлью-тип превращается в ссылочный со всеми вытекающими последствиями.
VD>>И какое отношение имеют ValueType-ы к GC? Что-то я ничего не понял.
S>в процессе работы использовалось большое кол-во ValueType ( это вкратце ) В Шарпе, насколько я знаю, даже для управления памятью, отведенной под ValueType, используется GC.
Фигово ты знашь. Так что не повторяй больше эти глупости. Вэлью-типы они на то и "вэлью", чтобы передаваться по значению и не требовать тем самым GC. GC управляет исключительно объектами. Вэлью-типы конечно могут входить в состав объектов, но напрямую GC ими не управляет. Если ты создашь переменную вэлью-типа, то она размещается в стэке или в другом объекте. Так что потерять память от этого невозможно.
Ручные вызовы сборки мусора тоже смысла не имеют.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>имхо, это не глюки. там блокируется какойто ActiveX. При том, как его "разрешить" не трогая уровень безопасности я не понял.
Разрешить использование подписанных ActiveX-ов.
Вот только это не с удобством связано. Просто при некотором уровне безопасности продукт вообще не может рабатать. Это общая проблема анменеджед-кода. У менеджед-кода такой проблемы нет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, srggal, Вы писали:
S>Вот еще подумалось у духах ( ударение н2ом слоге )
S>Преамбула:
S>Была такая задача DataAccessor, он должен вычитывать данные из БД и предоставлять Бизнесс-интерфейс для доступа к данным, БД может работать на удаленной машине, причем акссессор должен работать на той же машине что и БД. Использовали корбу, чтобы не изобретать велосипед.
S>Проблема появилась неожиданно: ValueType использовались ОРБОМ повсеместно, и как результат — датааксессор отрабатывал запрос клиента — корба маршалила данные.... и в памяти оставалось ~500 метров большей частью ValueType'ов, которые уже были не нужны и кроме того клиент уже обработал данные и ему тоже они были не нужны. Попытки инициации процесса GC не привели ни к чему хорошему — проседало время реакции на запросы клиентов.
S>Такая грустная песня об автоматической сборке мысора и ValueType для большого кол-ва кратко живущих экземпляров...
Ты о каком сборщике говоришь? О корбовском?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>имхо, это не глюки. там блокируется какойто ActiveX. При том, как его "разрешить" не трогая уровень безопасности я не понял.
VD>Разрешить использование подписанных ActiveX-ов.
Здравствуйте, GlebZ, Вы писали:
S>>Такая грустная песня об автоматической сборке мысора и ValueType для большого кол-ва кратко живущих экземпляров...
Виноват, не забыл в чем была проблема.
Были 2х мерные массивы ValueType, и вот из-за них-то и была проблема с памятью.
Т.е. навыделяли массивов ValueType'ов отдали клентам, а память осталась неосвобожденной Т.е. GC не отработал, потом новый запрос данных и сборка мусора, как результат — большле время реакции на запросы клиента.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, srggal, Вы писали:
S>>
S>>What are you using to compile the MSIL into x86?
S>>how are you handling hardware interupts, and the interupt vector table and interupt service routines from C# code?
S>>C# code has no way to interact with the bios. You can't drop into __asm { }; in C#.
VD>И что тут коментировать? Это два вопроса и одно утверждение. VD>Если тебе интересно как рабоает эта ОС, то почитай обсуждение по внимательнее. Там все описано. Просто глубже. Если на пальцах... Есть HAL и загрузчик которые написаны на не C#. Это очень маленький по объему код. Его задачи работа с кокретным железом и абстрагирование всего остального от него. Примерно так же была написана первая версия NT. Драйверы и т.п. уже работают через этот HAL. Часть C#-кода (очень малая) использует небезопасное расширение. В частности ансэйф используется для реализации GC. Кстати, тут до тебя были товарищи утверждавшие, что на C# нельзя делать ни GC, ни компиляторы. Как видишь это тоже не верно.
S>>X86 аппаратно поддерживает IL поддерживает
VD>К чему бы это ты сказал?
Именно к тому, что есть ХАЛ — и именно в нем настоящие драйаеры
А то, что пишется на шарпе — это уже псевдо-драйверы ИМХО
Т.е. на СШарп для этой ОС не напишешь драйвер, устройства неподдерживаемого ХАЛ, а чтобы оно поддерживалось надо в ХАЛ добавить его поддержку, при этом ХАЛ не на Шарпе...
ГМ, и это называется Драйвер ?
Согласен, что в принципе, все равно с натяжкой можно назвать драйвером, но в большинстве определений понятия драйвер присутсвует магическое hardware, т.е. таки совсем с натяжкой можно это назвать драйвером
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
S>>>Такая грустная песня об автоматической сборке мысора и ValueType для большого кол-ва кратко живущих экземпляров...
S>Виноват, не забыл в чем была проблема. S>Были 2х мерные массивы ValueType, и вот из-за них-то и была проблема с памятью. S>Т.е. навыделяли массивов ValueType'ов отдали клентам, а память осталась неосвобожденной Т.е. GC не отработал, потом новый запрос данных и сборка мусора, как результат — большле время реакции на запросы клиента.
И естественно массивы были больше 20 килобайт в одном блоке памяти?
Здравствуйте, srggal, Вы писали:
GZ>>И естественно массивы были больше 20 килобайт в одном блоке памяти?
S>Как показал пост немного Выше, я не дока в части СШарпа и связать СШарп Массивы с блоками памяти не могу, что Вы имели в виду ?
int a[10,10] — просто двухмерный массив. Лежит одним большим куском.
int a[10][10] — jagged массив. Массив строчек.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, VladD2, Вы писали: VD>>Можно ссылку на этот бред? S>На самом деле все не так плохо. Безопасность-удобство-стоимость образуют треугольник компромисса.
Именно так.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Hydrogen, Вы писали:
H>>Легко проверить. Никогда не пробовали Secure Linux, насколько он удобен? H>>Или включить файрвол, антивирус, Ad-Aware Monitor и видеть сколько страниц не не грузится и будет работать медленее, и для каждого аппликейшена создавать свой профайл в файерволле и.т.д.
VD>Ну, то есть идет подмена понятия удобство на скорость?
Нет. Ибо скорость — это тоже удобство.
Вернее так- одной из составляющей удобства есть скорость.
Здравствуйте, DJ KARIES, Вы писали:
DK>Но речь то идёт о C++.
Ну так вот: С++ поддерживает Юникод.
DK>Я в курсе этого. DK>Может удобнее один раз в настройках проекта указать платформу, а компилер пусть сам выбирает Юникодность строки.
А если я хочу ANSI-строку? Как компилятор догадается ЧТО мне нужно? Все равно нужно как-то помечать строки — и макрос оказался самым простым решением.
DK>Причём в том же MSVC эта галочка есть — Ansi/Unicode/MBCS. DK>Почему программеры юзают в каждой строке _T("")?
Так как эта галочка всего лишь управляет определениями макросов.
DK>Однако в других языках почему-то обходятся без данного макроса.
И без Юникода. Или наоборот, все делают в Юникоде.
DK>Однако CreateWindowW в Win9x не работает, т.е. это функция-пустышка! DK>Так на кой хер спрашивается так сделано?
Так как ядро Win9x — это дописаное ядро Win3.11, в котором Юникодом и близко не пахло.
DK>Почему в одновременно с Win9x вышедшей WinNT юникодные функции работают, а в 9x — нет?
Потому, что ядро WinNT изначально проектировалось под Юникод.
DK>Интересно, зачем эти яйцеголовые изобретатели стандартов понаделали КУЧУ ЮНИКОДОВ? DK>Зачем MBCS/LowEndian/HiEndian/16bit/32bit разновидности юникода?
Не везде удобен Единственный Верный Формат. Скажем, на BigEndian-машинах использовать LittleEndian будет "слегка" неудобно. В юниксовых утилитах удобнее использовать UTF-8 и т.п.
DK>Нельзя было обойтись одним стандартным?
Нет.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alexeiz, Вы писали:
A>>Однако! Возьмём, например, String.Format. Что-то я там не заметил особенной статической типизации. Аналог на C++ может быть либо ostringstream, либо Boost.Format. Оба полностью статически типизированны.
VD>И? Это говорит о чем-то?
Это говорит о том, что статически типизированной библиотеки форматирования в C# нет. Т.е. сделать её одновременно удобной и статически типизированной нельзя. Иначе бы было. А ещё кто-то там говорит, что в C# статическая типизиция не хуже.
Здравствуйте, alexeiz, Вы писали:
A>Это говорит о том, что статически типизированной библиотеки форматирования в C# нет. Т.е. сделать её одновременно удобной и статически типизированной нельзя. Иначе бы было. А ещё кто-то там говорит, что в C# статическая типизиция не хуже.
А зачем библиотека в языке который и сам кое что может?
string s = "Тест " + 123.9.ToString("###0.00") + " второй тест " + 123;
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Влад, не парь мозг. Вот лично мне в досе вообще паролей вбивать не приходилось. И это было значительно удобнее, чем с паролями.
А мне приходилось. К новелу, к ланменеджеру и т.п. Каждая программа отдельный пароль запрашивала. А уж как ДОС был удобен — это отдельная песня. Так что не парь мозги сам.
S>Нет. Вывод — "можно сделать небезопасную неудобную систему". Более того, Влад, можно сделать еще и офигенно дорогую, небезопасную и неудобную систему. Не имеет смысла обсуждать развитие в этом направлении.
Вот и не обсуждай. Просто согласись, что исходное утвердение полный бред.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alexeiz, Вы писали:
A>>Это говорит о том, что статически типизированной библиотеки форматирования в C# нет. Т.е. сделать её одновременно удобной и статически типизированной нельзя. Иначе бы было. А ещё кто-то там говорит, что в C# статическая типизиция не хуже.
VD>А зачем библиотека в языке который и сам кое что может? VD>
VD>string s = "Тест " + 123.9.ToString("###0.00") + " второй тест " + 123;
VD>
Не вижу, как это меняет ситуацию. Данная возможность опирается на виртуальный метод Object.ToString(). Т.е. это прямо эквивалентно тому, как работает String.Format.
Чтобы продемонстрировать различие статической и динамической типизации можно рассмотреть простейший пример:
class MyClass {} //empty
MyClass c = new MyClass;
string s = "Test " + c;
Будь конкатенация строк (или тот же String.Format) статически типизируем, данный пример вызвал бы ошибку компиляции. При динамической типизации компилятор просто ограничивается рассмотрением объекта "c" как Object и вызывает у него метод ToString().
PS: Я даже не буду сосредотачиваться на том, что данная конкатенация просто превращается в вызов String.Concat(Object[]). Те статической типизацией и не пахнет.
Здравствуйте, VladD2, Вы писали:
H>>Вообще говоря, в теории безомапсности компьютерных систем, H>>AFAIK есть утверждение — "Более безопасная система менее удобна".
VD>Можно ссылку на этот бред?
Security measures usually reduce convenience, especially for sophisticated users. Security can delay work and can create expensive administrative and educational overhead. Security can use significant computing resources and require dedicated hardware.
"
S>Именно к тому, что есть ХАЛ — и именно в нем настоящие драйаеры
S>А то, что пишется на шарпе — это уже псевдо-драйверы ИМХО
S>Т.е. на СШарп для этой ОС не напишешь драйвер, устройства неподдерживаемого ХАЛ, а чтобы оно поддерживалось надо в ХАЛ добавить его поддержку, при этом ХАЛ не на Шарпе...
S>ГМ, и это называется Драйвер ?
S>Согласен, что в принципе, все равно с натяжкой можно назвать драйвером, но в большинстве определений понятия драйвер присутсвует магическое hardware, т.е. таки совсем с натяжкой можно это назвать драйвером
Весьма странные слова для человека писавшего драйверы.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, srggal, Вы писали:
GZ>>С++ был действительно мощный язык, такой, что заложенного в него хватило на 15-20 лет существования. Но существует одна проблема. Дальнейшее улучшение языка возможно только с помощью таких уродцев типа boost.
S>Много Вы уважемый ( без иронии ) знаете языков, пускай даже модных, новых, которые так можно тюнинговать, пусть при промощи уродцев типа буста ?
Никто не возражает против буста, более того, я не считаю его уродцем. Буст — это вполне такой нормальный почин разработки прикладных библиотек в рамках единого переносимого фреймворка.
И если посмотреть на конкретные меры по safe-изации C++, которые я предложил, то они никак не повлияют ни на буст, ни на сам менталитет С++.
Основная проблема С++ — это возможность "безнаказанной" реинтерпретации памяти в произвольной строчке программы. Эта возможность идет вразрез с понятием Язык Высокого Уровня. Большинство UB, падений и вообще сниженная надежность программ на С++ имеют корни как раз из-за этой спорной вещи. Я вижу необходимость реинтерпретации памяти только в собственных аллокаторах памяти. Поэтому и предложил оставить НЕЯВНУЮ ту самую реинтерпретацию только в операторах new и в его inplace варианте в т.ч.
Грамотные С++ программисты стараются избегать приемов С++, связанных с реинтерпретацией памяти, так же как с ее разновидностью — побайтным копированием.
Все остальное, перечисленное мною выше (да, я забыл еще об детерминированном вызове деструкторов) позволяет писать точно такие же эффективные и надежные приложения.
GZ>>И невозможно построить эффективный GC не теряя совместимости. S>А зачем козе баян ? (Народная мулрость)
Правильно, не надо его встраивать в язык. Вполне можно обойтись чем-то вроде GC Handle и смарт-поинтером на его основе.
GZ>>Он начинает терять позиции на рынке бизнес-приложений. Но есть рынки где его позиции останутся такими же еще лет 10 точно.
S>Спорно, ну лучше мне с Вами согласиться, за неимением желания расскладывать Бизнесс Приложения на винтики и показывать в них нишу С/С++.
И все же, ниша языка формируется именно из-за качеств самого языка. Повышение надежности никак не сократит нишу С++, однако способно сильно эту нишу расширить. (Покажи мне любой "эффективный" код на С++, требующий реинтерпретации памяти, и я покажу тебе, как обойтись без нее без какой-либо потери эффективности).
Так же, на фомирование ниш в современном раскладе инструментов для разработки ПО немалое влияние оказывает и весь тот фреймворк, что окружает рассматриваемый инструмент. Для С++ мы имеет ну просто тонны готовых библиотек, начиная от GUI, и заканчивая сетевыми и даже прочими низкоуровневыми. Однако, все эти билиотеки совершенно не совместимы м/у собой. Пусть бросит в меня камень тот, кто ни разу не совмещал всякие роперы над тредами или мютексами от разных библиотек.
ACE — неплохая была попытка, но она элементарно морально устарела и требовала рефакторинга еще 5 лет назад, т.к. выполнена ммм... не совсем в духе С++.
Boost — очень неплохой почин, и я ожидаю от него многого. Жаль, что его разработка и стандартизация идут не так быстро как хотелось бы. Утопическое желание — чтобы какой-нить гигант вложил в него денег, типа как Sun и IBM в Java-направление.
S>>> Если он начнет идти в сторону Safe то это уже будет "дрессированный" язык, и совсем не тот, который мне нравится.
Я повторяю предложение дать ЛЮБОЙ код, требующий хаков с памятью или приведением указателей/ссылок вниз по иерархии наследования, и переделаю его без этих хаков. Нравится/не нравится — это слишком субъективный фактор, в то время как обеспечиваемая языком надежность — конкретный.
GZ>>Это точно. Меня пугает вообще политика улучшения языка.
S>
Возьмите глыбу мрамора и отсекие лишнее. Красота — она в простоте. ( (С) Пикассо из 9-й роты )
Я предлагаю именно отсечь лишнее.
GZ>>Полезнее придумать новый. Если красивой девушке навесить ну очень большие уши, она лучше слышать. Но вот в остальном, она потеряет.
Чур нас всех от очередного "нового". Тем более, что направления приложения современных языков более-менее устаканились.
S>Вы меня правильно поняли, я тоже за то, чтобы GC не было в С++, я против радикального изменения языка, но я только один, ртдельно взятый программист
Ну да, удаление потенциально опасных инструкций можно назвать "радикальным" изменениям языка. Тебя это смущает? Например STL и Boost их практичеки не используют (или не используют вообще), так что мы немного потеряем.
Практически со всем согласен.
V>Ну да, удаление потенциально опасных инструкций можно назвать "радикальным" изменениям языка. Тебя это смущает? Например STL и Boost их практичеки не используют (или не используют вообще), так что мы немного потеряем.
Смущает, если STL и BOOST их не использует, то и использовать их будет меньтшинство, соответсвенно маштабы проблемы — малы. использующмй ещё сорок раз подумает что он делает, есди делает что-то нетривиальное. Для улучшения и были введены xxx_cast
Здравствуйте, srggal, Вы писали:
S>Объясню свою позицию: S> ОС написана на одном языке СШарп, ХАЛ — на другом С/Асм, при этом считается что на СШарп — я пишу драйвера ?
S> В моём случае ядро ОС было написано на том-же языке что и драйвера
Ты явно не понимашь задач ХАЛ-а и того как он может быть организован. Почитай на досуге что-нить про архитекуру микроядра.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты явно не понимашь задач ХАЛ-а и того как он может быть организован. Почитай на досуге что-нить про архитекуру микроядра.
Andrei N.Sobchuck wrote: > > PD>Я иногда жалею, что IBM не смогла составить конкуренции Windows с OS/2. > > Во-первых, подозреваю, что межделмаш-у это банально не было нужно. Они > мыслят категориями прибыли, а МС им винду продавали по спеццене (за > копейки). Вероятно это было дешевле чем самим разрабатывать ОС, возиться > с драйверами, поддержкой, и пр. Плюс, против бимеров раньше велись > антимонопольные дела, и получить еще одно им нафиг не нужно было .
Однако OS/2 совсем недавно снята с производства. И до того они ее
зачем-то исправно поддерживали, и даже имели небольшой круг вполне
лояльных пользователей...
Здравствуйте, 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, пусть юзает нормальный.
Здравствуйте, 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).
Здравствуйте, Pzz, Вы писали:
Pzz>Однако OS/2 совсем недавно снята с производства. И до того они ее Pzz>зачем-то исправно поддерживали, и даже имели небольшой круг вполне Pzz>лояльных пользователей...
Крупным клиентам впарили 15 лет назад. Приходится поддерживать.
Здравствуйте, srggal, Вы писали:
S>Смущает, если STL и BOOST их не использует, то и использовать их будет меньтшинство, соответсвенно маштабы проблемы — малы. использующмй ещё сорок раз подумает что он делает, есди делает что-то нетривиальное. Для улучшения и были введены xxx_cast
S>
Струструп в "Дизайн и эволюция С++" говорил примерно следующее (за дословность не ручаюсь, но смысл передам):
"Такие введения как xxx_cast были специально введены именно в таком ужасном и бросающемся глаза виде, чтобы явно выделять опасные места прогаммы. В идеале хотелось бы, чтобы программисты избегали использования этих конструкций".
Из всех xxx_cast с моей т.з. имеют право на жизнь только dynamic_cast и static_cast. Использование остальных кастов явно сигнализирует об ошибке проектирования, или попытке совместить несовместимое.
Здравствуйте, 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;
}
Здравствуйте, VladD2, Вы писали:
VD>Согласен со всем кроме: VD>
Собственно, мне нравится в С++ сильная статическая типизация. По сравнению с тем же C# мне крайне редко приходлось отлаживать программы в пошаговом редакторе, используя С++. Еще немного более строгая типизация не повредила бы.
VD>Это явно выдумка. Сила типизации в С++ несравнимо ниже. Статическая типизация анлогична. Джененирики устраняют последние потуги к динмическим приведениям типов.
Я не говорю, что дженерики чего-то там не устраняют. Сказать честно, я уже прилично устал от 1.1, но пока не вышел релиз 2.0 вынуждены работать и выпускать продукты на нем.
Я лишь сказал, что мне с довольно завидной регулярностью приходится пользоваться брейкпоинтами и пошаговой отладкой на C#, и это факт. На С++ у меня такая потребность возникала куда как реже.
Кстати, когда писал на VB/VBA, тоже без пошаговой отладки не обходилось.
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.
Нового ничего не прочитал
Судя по поставленным минусам и отсутсвию плюсов здесь
Здравствуйте, 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 вручную, от будет орсвобождаться не только эта память, которую надо освободить, но вся память будет анализироваться.
ЗЫ
прошу простить мне мой "французский" с терминами СШарп знаком не сильно, возможно такую работу с массивами можно назвать каким нить ёмким словом чтобы сразу стало понятно, но я его не знаю.
Здравствуйте, GlebZ, Вы писали:
GZ>int a[10,10] — просто двухмерный массив. Лежит одним большим куском. GZ>int a[10][10] — jagged массив. Массив строчек.
Здравствуйте, vdimas, Вы писали:
V>И все же, ниша языка формируется именно из-за качеств самого языка. Повышение надежности никак не сократит нишу С++, однако способно сильно эту нишу расширить. (Покажи мне любой "эффективный" код на С++, требующий реинтерпретации памяти, и я покажу тебе, как обойтись без нее без какой-либо потери эффективности).
V>Я повторяю предложение дать ЛЮБОЙ код, требующий хаков с памятью или приведением указателей/ссылок вниз по иерархии наследования, и переделаю его без этих хаков. Нравится/не нравится — это слишком субъективный фактор, в то время как обеспечиваемая языком надежность — конкретный.
Распечатай float. Не забудь про Q-NAN, S-NAN, +iINF, +0, -0, денормализованные числа.
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, 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 часов заниматься изменением архитектуры, и потом выходить на полный цикл тестировани?
ЗЫЗЫЗЫ
Видимо убедился я в Вашей правоте еще не полностью. Страуструп — прав этого надо избегать, но ИНОГДА от ЭТОГО НИКУДА НЕ ДЕТЬСЯ
Здравствуйте, _Winnie, Вы писали:
_W>Здравствуйте, vdimas, Вы писали:
V>>И все же, ниша языка формируется именно из-за качеств самого языка. Повышение надежности никак не сократит нишу С++, однако способно сильно эту нишу расширить. (Покажи мне любой "эффективный" код на С++, требующий реинтерпретации памяти, и я покажу тебе, как обойтись без нее без какой-либо потери эффективности).
V>>Я повторяю предложение дать ЛЮБОЙ код, требующий хаков с памятью или приведением указателей/ссылок вниз по иерархии наследования, и переделаю его без этих хаков. Нравится/не нравится — это слишком субъективный фактор, в то время как обеспечиваемая языком надежность — конкретный.
Имеется массив четвёрок struct vec3f_t { float x, y, z, _; }; в массив матриц 4x4 для API вроде OpenGL/Direc3D
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, _Winnie, Вы писали:
_W>Здравствуйте, _Winnie, Вы писали:
_W>>Здравствуйте, vdimas, Вы писали:
V>>>И все же, ниша языка формируется именно из-за качеств самого языка. Повышение надежности никак не сократит нишу С++, однако способно сильно эту нишу расширить. (Покажи мне любой "эффективный" код на С++, требующий реинтерпретации памяти, и я покажу тебе, как обойтись без нее без какой-либо потери эффективности).
V>>>Я повторяю предложение дать ЛЮБОЙ код, требующий хаков с памятью или приведением указателей/ссылок вниз по иерархии наследования, и переделаю его без этих хаков. Нравится/не нравится — это слишком субъективный фактор, в то время как обеспечиваемая языком надежность — конкретный.
Имеется embedded устройство, 32 мегабайта оперативки. 1 мегабайт для кода и данных, 1 мегабайт для стека. Нужно загрузить образ с DVD размером в 30 мегабайт.
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, _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 }, то я буду смеятся и плакать.
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, _Winnie, Вы писали: _W>Здравствуйте, _Winnie, Вы писали: _W>>Здравствуйте, _Winnie, Вы писали: _W>>>Здравствуйте, vdimas, Вы писали:
_W>Имеется embedded устройство, 32 мегабайта оперативки. 1 мегабайт для кода и данных, 1 мегабайт для стека. Нужно загрузить образ с DVD размером в 30 мегабайт.
Ну или аналогичная задача — загрузить DOM-дерево за один malloc + 1 fread. Никакого парсинга.
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, _Winnie, Вы писали: _W>Здравствуйте, _Winnie, Вы писали: _W>>Здравствуйте, _Winnie, Вы писали: _W>>>Здравствуйте, _Winnie, Вы писали: _W>>>>Здравствуйте, vdimas, Вы писали:
Тупая такая задача. Распечатать указатель в двоичной системе счисления.
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, _Winnie, Вы писали: _W>Здравствуйте, _Winnie, Вы писали: _W>>Здравствуйте, _Winnie, Вы писали: _W>>>Здравствуйте, _Winnie, Вы писали: _W>>>>Здравствуйте, _Winnie, Вы писали: _W>>>>>Здравствуйте, vdimas, Вы писали:
Имется сишная библиотека. Она в callback передает void *. Как ты будешь без down-castа конвертировать void * в указатель на свои данные?
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, _Winnie, Вы писали: _W>Здравствуйте, _Winnie, Вы писали: _W>>Здравствуйте, _Winnie, Вы писали: _W>>>Здравствуйте, _Winnie, Вы писали: _W>>>>Здравствуйте, _Winnie, Вы писали: _W>>>>>Здравствуйте, _Winnie, Вы писали: _W>>>>>>Здравствуйте, vdimas, Вы писали:
Напиши аналог boost::optional или boost::variant.
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, srggal, Вы писали:
S>>Мысль понял, красивый ход.
IT>Шахматист, блин На вопрос так и не ответил.
S>>Но строчки написанного системного ПО дорогого стоят
IT>На сколько дороже?
CASE-средства можно отнести к системному ПО ? К примеру, наш продукт стоит порядка $20 000(за лицензию) в полной комплектации и $9 000 в минимальной.
Дорого это или нет, судить вам
Здравствуйте, _Obelisk_, Вы писали:
IT>>На сколько дороже?
_O_>CASE-средства можно отнести к системному ПО ?
Нельзя. Мы говорим о драйверах к железкам.
_O_>К примеру, наш продукт стоит порядка $20 000(за лицензию) в полной комплектации и $9 000 в минимальной. _O_>Дорого это или нет, судить вам
Сколько стоит драйвер я могу судить только по вторичным половым признакам. Например, в штатах проекты по написанию драйверов контрактниками обычно на 3 месяца. Если взять рейт в 80-100 в час, то это будет 40 — 50 тысяч.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
V>Так что, смысл в специально "заточенном" аппаратном процессоре есть.
Ну, не знаю. Пока что все же джиты дают больше. Вот чего бы точно не помешало, так это внедрение в процессоры некоторых аппоратных ускорителей отдельных аспектов управляемых сред.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
E>Есть наши партнеры (друзья-соперники ), в Питере и в Магнитогорске, там вообще разработчиков сотни, а работают над линейками однотипных продуктов (банковский процессинг).
Здравствуйте, ZayatsZ, Вы писали:
E>>Есть наши партнеры (друзья-соперники ), в Питере и в Магнитогорске, там вообще разработчиков сотни, а работают над линейками однотипных продуктов (банковский процессинг).
ZZ>Это вы про Компасс-Плюс?
Да.
Хотя не знаю, имеет ли смысл раскрывать реальные имена персонажей
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
S>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.
S>Нового ничего не прочитал
Значит не судьба.
S>Судя по поставленным минусам и отсутсвию плюсов здесь
S>Мое мнение никто больше не разделяет, тем не менее я останусь при нем
Значит такова судьба.
S>В Дальнейшем продолжении беседы — смысла не виижу, за отсутсвием с моей стороны каких-либо аргументов в пользу своей точки зрения.
Тогда рассмотри такое предположение... ХАЛ содержит функции позволяющие читать (и писать) в порты процессора I/O interface), использовать DMA и обрабатывать прерывания. Ддрайверы же используют этот примитивный, но высокоуровневый интерфейс для общения с конкретным железом. В итоге им не нежно применять ассембленых инструкций, но нем не менее они легко могут взаимодействовать с железом.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Стабы наверно все же генерируеются генераторами кода idl2xxx. Но причем тут ОРБ? Он то скорее всего на плюсах написан.
V>Нет, написанны они на дотнете, и выполнены как форматтеры каналов или же в виде самих каналов (у кого как), т.е. используют инфраструктуру .Net Remoting,
Какой Ремоутинг? Речь о КОРБА.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
V>>Нет, написанны они на дотнете, и выполнены как форматтеры каналов или же в виде самих каналов (у кого как), т.е. используют инфраструктуру .Net Remoting,
VD>Какой Ремоутинг? Речь о КОРБА.
Он наверное имел ввиду Transparent/RealProxy
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, _Winnie, Вы писали:
_W>Здравствуйте, _Winnie, Вы писали:
_W>>Здравствуйте, _Winnie, Вы писали:
_W>>>Здравствуйте, vdimas, Вы писали:
V>>>>И все же, ниша языка формируется именно из-за качеств самого языка. Повышение надежности никак не сократит нишу С++, однако способно сильно эту нишу расширить. (Покажи мне любой "эффективный" код на С++, требующий реинтерпретации памяти, и я покажу тебе, как обойтись без нее без какой-либо потери эффективности).
V>>>>Я повторяю предложение дать ЛЮБОЙ код, требующий хаков с памятью или приведением указателей/ссылок вниз по иерархии наследования, и переделаю его без этих хаков. Нравится/не нравится — это слишком субъективный фактор, в то время как обеспечиваемая языком надежность — конкретный.
_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 }, то я буду смеятся и плакать.
И напрасно. При таком высокоуровневом подходе происходит естественный unroll цикла.
Кроме того, компилятор имеет возможность переупорядочить обращение к памяти c RWRWRW к RRRWWW, что улучшает производительность.
Здравствуйте, AndrewVK, Вы писали: VD>>Какой Ремоутинг? Речь о КОРБА.
AVK>Он наверное имел ввиду Transparent/RealProxy
А зачем все это для КОРБА? КОРБА и на С/С++ работает там где этих вещей в принципе быть не может. Там все просто как неучить уроки. Компиляторы idl2xxx генерируют факбрики классов и скелитоны (прокси) со стабами которые и реализуют все что нужно.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, srggal, Вы писали:
S>ЗЫЗЫ S> Возникло подозрение, что на этапе поддержки ПО, все остальные касты, которые Вы хотите выбросить, используются на право и налево в большинестве проектов. Поскольку обычно ведут уже другие люди, которым вдаватьася в подробности архитектуры неохота, либо исправление ошибки ( или не дай бог ипрувмент ) — требуют слишком много времени, и проще наплевать на всё и использовать эти конструкциии и работу с памятью. S> Предвижу — Вы скажете, что если бы была заложена правильная Архитектура — то все -бы прохолдило на ура. Но ведь много проектов с неправильной, в этом плане архитектурой, которые продаются/используются/сопровождаются. Кроме того, я участвовал в проекте с Правильной Архитектурой, где только о ней и думали ( как сделать так чтобы потом ихменять было легко ), ничего хорошего из этого не вышло. В данный момент — одна из моих задач — соправождение продукта, он кривой, написан через задницу, исправлять ошибки в нем — мучение, не говоря уже об импрувментах, НО он хорошо продается и много копий уже стоит у заказчиков. Так что — язык должен мне отказать в возможности эффективно решать поставленную задачу? Т.е. вместо того, чтобы прсле 2х часовых поисков взять и интерпретировать буффер памяти по-своему, я должен 40 часов заниматься изменением архитектуры, и потом выходить на полный цикл тестировани?
S>ЗЫЗЫЗЫ S> Видимо убедился я в Вашей правоте еще не полностью. Страуструп — прав этого надо избегать, но ИНОГДА от ЭТОГО НИКУДА НЕ ДЕТЬСЯ
Действительно, деться трудно. У меня на одном из мест работы года 4 назад были регулярные конфликты с тим-лидером, из-за того, что я вместо того, чтобы "заниматься делом", т.е. замазывать соплями очередной баг и бежать к следующему, занимался "всякой ерундой", т.е. выискивал первопричины возникновения ошибочных ситуаций (правильнее сказать — допущения программистами этих ситуаций) и довольно много кода перелопачивал вручную... Положительный эфект сказался не сразу, но суть его была в том, что баги стали уходить не по одному, а целыми классами или семействами, и большинство из них уже не возвращались на вновь разрабатываемые модули.
Да, о чем это я... Последние пару лет плотно сижу на C#, и овладел такой штукой как Resharper на уровне "слепого десятипальцевого метода". В общем, постоянное поддержание кода в состоянии up to date — это вполне себе нормальное состояние кода. В противном случае код загнивает и обесценивается. Если бы для С++ существовали в настоящий момент ср-ва рефакторинга, типа тех, что мы имеем для Java и C#, то БЫЛО БЫ КУДА ОТ ЭТОГО ДЕТЬСЯ.
И еще обнаружил интересный момент. Помимо того, что этот рефакторинг или даже более "глубокий", чем рефакторинг, ремонт кода не требует видимых постоянных усилий ныне, приводить код в порядок инструментом типа Решарпера — это само по себе приятное занятие. Испытываешь прямо-таки эстетическое наслаждение от процесса. А, помятуя усилия, которые порой приходилось затрачивать на рефакторинг чужого кода на С++, так все еще не могу отделаться от удивления: "вот же ж блин же ж!!! ай да Пушкин, ай да бычий глаз"... (оффтопная лирика).
---------
Ну, а раз подобных по мощности инструментов для С++ пока нет (и все опасные конструкции тоже на месте), то — внимание и еще раз внимание при разработке. Такой уж он у нас требовательный...
Обычные нападки Влада2Д поскипаны ....
VD>Тогда рассмотри такое предположение... ХАЛ содержит функции позволяющие читать (и писать) в порты процессора I/O interface), использовать DMA и обрабатывать прерывания. Ддрайверы же используют этот примитивный, но высокоуровневый интерфейс для общения с конкретным железом. В итоге им не нежно применять ассембленых инструкций, но нем не менее они легко могут взаимодействовать с железом.
Ок, расмотрел, "они легко могут" — не совсем согласен, да, я могу замапить память конкретного устройства используя какого-нить, СШарпХаловского ИОремапХХХ, но память мне надо трактовать по своему как какой-нить фркейм, Номер, размер, пэйлоад, и эта трактовка уже не в духе СШарп, а скорей противоречит духу СШарп
Именно это я и имел в виду.
Кроме того, я писал:
Согласен, что в принципе, все равно с натяжкой можно назвать драйвером, но в большинстве определений понятия драйвер присутсвует магическое hardware, т.е. таки совсем с натяжкой можно это назвать драйвером
ИМХО поэтому эта ОС пока экспериментальная...
Again, this is a prototype research OS, not a full fledged OS that can run the typical applications you've come to expect of an OS (or even provide a user interface beyond, say, that of DOS).
Возможно что нить придумают воопще за рамки всего известного выходящее, возможно эта ОС умретЮ, а возможно так и останутся в ней места, которые будут противоречить концепции языка на котором ОС написана.
Здравствуйте, vdimas, Вы писали:
V>--------- V>Ну, а раз подобных по мощности инструментов для С++ пока нет (и все опасные конструкции тоже на месте), то — внимание и еще раз внимание при разработке. Такой уж он у нас требовательный...
Согласен еще раз на все 100
V>
Жду с нетерменииме реСплюплюссера , уже не первый год
Здравствуйте, _Winnie, Вы писали:
_W>Я тоже. _W>Пример 1: _W>
_W>#define X(x,y) m ## x ## y
_W>struct
_W>{
_W> int X(em, ber1);
_W> int X(em, ber2);
_W> void f() { member1 = 10; member2 = 20; }
_W>};
_W>
_W>Задача: заменить member1 на xxx, не трогая member2.
_W>А еще этот реСплюплюссер должен уметь инстанцировать шаблоны, делать поиск имен, уметь делать sizeof(sic!), осуществлять поиск перегруженной функции.
_W>
_W>//нужно ли в этом выражении поменять member1 на xxx ?
_W>some_template<sizeof(f(x))>::type variable;
_W>variable.member1 = 10;
_W>
Потому и долго ждем и ждать будет, имхо грамматика не простая
_Winnie wrote:
> Пример 1: > >#define X(x,y) m ## x ## y > >struct >{ > int X(em, ber1); > int X(em, ber2); > void f() { member1 = 10; member2 = 20; } >}; > > Задача: заменить member1 на xxx, не трогая member2.
Никак. XRef в таких случаях выводит предупреждение о конфликте в макросах.
> А еще этот реСплюплюссер должен уметь инстанцировать шаблоны, делать > поиск имен, уметь делать sizeof(sic!), осуществлять поиск > перегруженной функции.
А это умеет xref — он внутри использует EDG со всеми вытекающими.
Здравствуйте, srggal, Вы писали:
S>Ок, расмотрел, "они легко могут" — не совсем согласен, да, я могу замапить память конкретного устройства используя какого-нить, СШарпХаловского ИОремапХХХ, но память мне надо трактовать по своему как какой-нить фркейм, Номер, размер, пэйлоад, и эта трактовка уже не в духе СШарп, а скорей противоречит духу СШарп
Почитай обсуждение на ченэл9. Там как раз сказано, что возможности Шарпа по реинтерпретации памяти (по простому ансэйф) потребовались только при написании GC (который тоже на Шарпе написан). Драйверы по их словам чистый сэйф-код. Значит ХАЛ это позволяет. Так что вопрос только в эффективности решений. Собственно ОС пока что исследовательская и авторы честно говорят, что производительность для них не приоритет. Однако не думаю, что они про нее не думают.
S>Кроме того, я писал: S>
S>Согласен, что в принципе, все равно с натяжкой можно назвать драйвером, но в большинстве определений понятия драйвер присутсвует магическое hardware, т.е. таки совсем с натяжкой можно это назвать драйвером
А на недо соглашаься с фактами "в принципе". Факт есть факт. Все драйверы написаны на Шарпе. Без них работать с устройствами вроде клавиатуры и монитора было бы невозможно. Так же четко сказано, что объем вообще небезопасного кода очень мал. А уж С/С++/асм вообще мизерный.
S>ИМХО поэтому эта ОС пока экспериментальная... S>
S>Again, this is a prototype research OS, not a full fledged OS that can run the typical applications you've come to expect of an OS (or even provide a user interface beyond, say, that of DOS).
Цитата твоя говорит о том, что сделана тольк поддрежка консоли. Тоже самое было во всех ОС кроме Виндовс. Тот же Линукс получил ГУИ далеко не сразу и очень долгое время вообще являлся эксперементальной ОС (в начале вообще дипломным проектом).
S>Возможно что нить придумают воопще за рамки всего известного выходящее, возможно эта ОС умретЮ, а возможно так и останутся в ней места, которые будут противоречить концепции языка на котором ОС написана.
ХАЛ и микроядерная архитектура известны очень давно. Идеи проверенные и не ясно с какго рожна их уничтожать.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, srggal, Вы писали:
VD>Почитай обсуждение на ченэл9. Там как раз сказано, что возможности Шарпа по реинтерпретации памяти (по простому ансэйф) потребовались только при написании GC (который тоже на Шарпе написан). Драйверы по их словам чистый сэйф-код. Значит ХАЛ это позволяет. Так что вопрос только в эффективности решений. Собственно ОС пока что исследовательская и авторы честно говорят, что производительность для них не приоритет. Однако не думаю, что они про нее не думают.
Ок, я не указал, чот ркчь идет о моём стороннем устройстве, например PCI-платы с ПЛИСС, на которой прошита моя математика и с которой мне надо работать, причем со 99% вероятностью, памяьт мне прийдется интерпретировать.
VD>А на недо соглашаься с фактами "в принципе". Факт есть факт. Все драйверы написаны на Шарпе. Без них работать с устройствами вроде клавиатуры и монитора было бы невозможно. Так же четко сказано, что объем вообще небезопасного кода очень мал. А уж С/С++/асм вообще мизерный.
Я не увидел Факта, гдк написано, что ВСЕ ДРАЙВЕРЫ написаны на СШарп. Если не затруднит, дайте ссылку из котрой Вы почерпнули этот факт.
Здравствуйте, srggal, Вы писали:
S>Я не увидел Факта, гдк написано, что ВСЕ ДРАЙВЕРЫ написаны на СШарп. Если не затруднит, дайте ссылку из котрой Вы почерпнули этот факт.
The MSIL to x86 compiler we use is Bartok, developed by Microsoft Research's Advanced Compiler Technology Group (http://research.microsoft.com/act/). David Tarditi and his team have created this fantastic whole-program optimizing compiler that reads in a collection of MSIL Assemblies and outputs an x86 binary. At the end of the day, its just code.
Beer28, remember that libc is just x86 code. So, we replace whatever one might need from libc, with C# code. Instead of calling a C version of libc, Singularity uses safe code written in C# to directly access the screen hardware (for example).
This probably makes more sense when you realizes the most OSes don't use BIOS except during the very earliest stage of boot. Singularity does the same as well, it only use BIOS during the 16-bit real-mode boot strap. Once jump to 32-bit mode, we never use BIOS again, but use device drivers written in C# instead. Yes, we had to replace a lot of CLR libraries with different code. However, unlike the CLR, the Singularity runtime is written in C#.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
S>>Я не увидел Факта, гдк написано, что ВСЕ ДРАЙВЕРЫ написаны на СШарп. Если не затруднит, дайте ссылку из котрой Вы почерпнули этот факт.
VD>
The MSIL to x86 compiler we use is Bartok, developed by Microsoft Research's Advanced Compiler Technology Group (http://research.microsoft.com/act/). David Tarditi and his team have created this fantastic whole-program optimizing compiler that reads in a collection of MSIL Assemblies and outputs an x86 binary. At the end of the day, its just code.
VD>Beer28, remember that libc is just x86 code. So, we replace whatever one might need from libc, with C# code. Instead of calling a C version of libc, Singularity uses safe code written in C# to directly access the screen hardware (for example).
VD>This probably makes more sense when you realizes the most OSes don't use BIOS except during the very earliest stage of boot. Singularity does the same as well, it only use BIOS during the 16-bit real-mode boot strap. Once jump to 32-bit mode, we never use BIOS again, but use device drivers written in C# instead. Yes, we had to replace a lot of CLR libraries with different code. However, unlike the CLR, the Singularity runtime is written in C#.
Не увидел, Где написано, что ВСЕ драйверы на СШарп, только то, что драйверы написаны на СЩарп, а все или только часть — нет информации , кроме того написано, что рантайм переписан на СШарп.
Здравствуйте, srggal, Вы писали:
S>Не увидел, Где написано, что ВСЕ драйверы на СШарп, только то, что драйверы написаны на СЩарп, а все или только часть — нет информации , кроме того написано, что рантайм переписан на СШарп.
А какая тебе разница? Ты же отриыал сам факт подобного. Ну, и строчку "uses safe code written in C# to directly access the screen hardware" я тебе выделил не просто так. Как ты понимашь, прямой доступ к видеоадаптеру — это прямая работа с железом.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, srggal, Вы писали:
S>>Не увидел, Где написано, что ВСЕ драйверы на СШарп, только то, что драйверы написаны на СЩарп, а все или только часть — нет информации , кроме того написано, что рантайм переписан на СШарп.
VD>А какая тебе разница? Ты же отриыал сам факт подобного. Ну, и строчку "uses safe code written in C# to directly access the screen hardware" я тебе выделил не просто так. Как ты понимашь, прямой доступ к видеоадаптеру — это прямая работа с железом.
Блин сколько можно топтаться как розовый слоник, на месте.
Я уже дано запостил, что был не прав, но остался при своем мнении.
Нет косрруктива ни с Вашей ни с моей стороны, предлагаю не плодить безконструктивные сообщения.
Ты абсолютно прав, инструмент для рефакторинга должен содержать полноценный компилятор (по крайней мере пол-компилятора, без той половины, что оптимизирует и генерит бинарны образ).
Разумеется, необходимо иметь полную модель кода перед модификацией.
Здравствуйте, srggal, Вы писали:
S>Ок, я не указал, чот ркчь идет о моём стороннем устройстве, например PCI-платы с ПЛИСС, на которой прошита моя математика и с которой мне надо работать, причем со 99% вероятностью, памяьт мне прийдется интерпретировать.
Для общения с PCI-устройствами достаточно иметь API дляработы с IRQ, DMA и портами. А то что ты называшь интерпретацией памяти можно сдалеть, например, с помощью BinaryReader. При этом код будет 100%-но типобзопасным.
S>Я не увидел Факта, гдк написано, что ВСЕ ДРАЙВЕРЫ написаны на СШарп. Если не затруднит, дайте ссылку из котрой Вы почерпнули этот факт.
Там слишком много текста чтобы перечитывать. Но я встречал это утверждение раза два.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, srggal, Вы писали:
S>>Ок, я не указал, чот ркчь идет о моём стороннем устройстве, например PCI-платы с ПЛИСС, на которой прошита моя математика и с которой мне надо работать, причем со 99% вероятностью, памяьт мне прийдется интерпретировать.
VD>Для общения с PCI-устройствами достаточно иметь API дляработы с IRQ, DMA и портами. А то что ты называшь интерпретацией памяти можно сдалеть, например, с помощью BinaryReader. При этом код будет 100%-но типобзопасным.
Это я уже почти выяснил.
Единственное я не понял о каком СШарп идет речь 2.0?
Вроде в более раннем реинтерпретацией памяти была usafe ?
Или я что-то путаю ?
Здравствуйте, _Winnie, Вы писали:
_W>Здравствуйте, _Winnie, Вы писали:
_W>>Здравствуйте, vdimas, Вы писали:
V>>>И все же, ниша языка формируется именно из-за качеств самого языка. Повышение надежности никак не сократит нишу С++, однако способно сильно эту нишу расширить. (Покажи мне любой "эффективный" код на С++, требующий реинтерпретации памяти, и я покажу тебе, как обойтись без нее без какой-либо потери эффективности).
V>>>Я повторяю предложение дать ЛЮБОЙ код, требующий хаков с памятью или приведением указателей/ссылок вниз по иерархии наследования, и переделаю его без этих хаков. Нравится/не нравится — это слишком субъективный фактор, в то время как обеспечиваемая языком надежность — конкретный.
_W>Имеется массив четвёрок struct vec3f_t { float x, y, z, _; }; в массив матриц 4x4 для API вроде OpenGL/Direc3D
обещал переделать — буду переделывать:
(подробности опущены, показана идея, как сохранить похожий внешний синтаксис, кстати, можно добавить конструкторы и еще всякие методы)
Здравствуйте, _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 — это суть одно и тоже. В общем, хватает там косяков. Видно, что делали не "выразительную и удобную" систему команд, а просто экономили байты, захломляя саму систему команд всяким мусором.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, _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] — тогда всю эту операцию можно делать именно так как ты имел ввиду, а для цветовых составляющих сделать акцессоры, типа так:
учитывая инлайность и способности компиляторов, я уверен, что порожденный код не уступит твоей структуре RGB, зато будет более надежным и переносимым, т.к. не будет зависеть от опций компилятора в плане упаковки структур, т.е. не будет вероятности "промазать".
>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"?
Правильно работающая программа — просто частный случай Undefined Behavior
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.
Здравствуйте, IT, Вы писали:
IT>Экономия места мне там не понравилась. Систему команд можно было сделать в два раза проще выкинув короткие версии команд и все эти ldarg.0, .1, .2, .3.
Ну типа размеры сборок уменьшали. по байту на команду — можно много съэкономить.
IT> С примитивными типами тоже намудрили. ldc команд почему-то 4, а conv и ldind по полной схеме. Можно было иметь вообще по одной команде, если сопроводить её целевым типом или брать его со стека.
Они там что то говорили на тему того, что это дает возможность JIT делать более мощные оптимизации с учетом всяких SSE и разной разрядности целевых процессоров.
IT>Загрузка самого типа делается через задницу — ldtoken с последующим вызовом Type.RuntimeTypeHandle. Нельзя для этого было команду отдельную сделать?
А это уже не совсем система команд.
IT> ldarg и ldloc — это суть одно и тоже.
Не факт. Вполне возможен JIT, который может их интерпретировать по разному. Опять же дополнительный контроль.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, 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 там у себя и разобрался бы. Ему то всё равно, он же машина.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, srggal, Вы писали:
S>Вроде в более раннем реинтерпретацией памяти была usafe ?
А кто тебе сказал, что где-то используется реинтерпретация памяти? Там же явно сказано, что в насэйфе написан менеджер памяти и несколько мелких никоуровневых вещей. Задача этой ОС как раз минимизировать наличие ансэйфа.
BinaryReader же позоляет читать память как душе угодно, но при этом не заниматься реинтерпретацией типов и не допуская порчи памяти к которой может привести реинтерпетация. Погляди BinaryReader Рефлектором или в Роторе.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
VD>>Менялся, но это не важно. Ввели инлайн-массивы (для ускорения работы с интеропом).
AVK>Интероп это не ансейф.
Ага. А бутылка не ложка. И?
Я говорю о то для на что было расчитано расширение языка. Хотя конечно кроме интеропа это дело кое-где еще может пригодиться.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Менялся, но это не важно. Ввели инлайн-массивы (для ускорения работы с интеропом).
AVK>>Интероп это не ансейф.
VD>Ага. А бутылка не ложка. И? VD>Я говорю о то для на что было расчитано расширение языка. Хотя конечно кроме интеропа это дело кое-где еще может пригодиться.
Только это не имеет никакого отношения к тому что я написал, а именно в плане unsafe никакого изменения в 2.0 не было. А inline массивы вполне можно использовать и в safe-коде.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Только это не имеет никакого отношения к тому что я написал, а именно в плане unsafe никакого изменения в 2.0 не было. А inline массивы вполне можно использовать и в safe-коде.
Нет. Ты ошибашся. Почитай спецификацию.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали: AVK>Ну типа размеры сборок уменьшали. по байту на команду — можно много съэкономить.
Совершенно верно. Причем, что характерно, всего команд в первом FW — 224. Т.е. выкинув "лишние" опкоды ничего сэкономить бы не получилось — вряд ли опкоды размером меньше байта завоевали бы популярность.
Мне лично мсил показался как раз очень продуманным в том смысле, что самые частые команды типа ldarg.0 и ldc.0 занимают по одному байту вместе со всеми аргументами.
Это как раз показывает, что авторы думали не только в стиле "бывает 0, 1, и много". А сравнивали частоты различных значений аргументов. С учетом отсутствия в дотнете встроенной поддержки компрессии байт-кода это — достаточно нормальное решение. Полная версия команды загрузки целой константы жрет пять байт — в пять раз больше ldc.0. А этих ldc.0 больше, чем любых других (for int i=0...).
Опять же, ведь никто не принуждает тебя использовать шорткаты. Можешь всегда пользоваться полной формой, если тебе это проще.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Только это не имеет никакого отношения к тому что я написал, а именно в плане unsafe никакого изменения в 2.0 не было. А inline массивы вполне можно использовать и в safe-коде.
В спецификации направленной в ECMA я этот понкт не нашел. Или плохо искал, или просто пока не добавили. Но в языке фича есть и поддерживается еще с бэты 1.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Это как раз показывает, что авторы думали не только в стиле "бывает 0, 1, и много". А сравнивали частоты различных значений аргументов. С учетом отсутствия в дотнете встроенной поддержки компрессии байт-кода это — достаточно нормальное решение. Полная версия команды загрузки целой константы жрет пять байт — в пять раз больше ldc.0. А этих ldc.0 больше, чем любых других (for int i=0...).
А по моему это изврат. Если они хотели экономить то пусть бы они делали это при записи в фаил.
ИМХО лучше считать что бывает только 1, 0 и много (а то и просто бывает только много) чем плодить опкоды.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Sinclair, Вы писали:
S>>Это как раз показывает, что авторы думали не только в стиле "бывает 0, 1, и много". А сравнивали частоты различных значений аргументов. С учетом отсутствия в дотнете встроенной поддержки компрессии байт-кода это — достаточно нормальное решение. Полная версия команды загрузки целой константы жрет пять байт — в пять раз больше ldc.0. А этих ldc.0 больше, чем любых других (for int i=0...). WH>А по моему это изврат. Если они хотели экономить то пусть бы они делали это при записи в фаил. WH>ИМХО лучше считать что бывает только 1, 0 и много (а то и просто бывает только много) чем плодить опкоды.
Не понимаю тех, кто говорит про нелогичность. Можно подумать, что вы программируете в шестнадцеричном редакторе, а не на C#/Visual Basic. Меня абсолютно не колышет логичность/не логичность MSIL кода, я его и не вижу.
А то, что он получается чуть поменьше — это здорово, это объективный профит, в отличие от "логичности".
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, _Winnie, Вы писали:
_W>Не понимаю тех, кто говорит про нелогичность. Можно подумать, что вы программируете в шестнадцеричном редакторе, а не на C#/Visual Basic. Меня абсолютно не колышет логичность/не логичность MSIL кода, я его и не вижу.
Хотя конечно можно просто мысленно забыть о существовании сокращенных команд и пользоваться только полными.
_W>А то, что он получается чуть поменьше — это здорово, это объективный профит, в отличие от "логичности".
Дык, речь и идет о том, что расширенный набор команд могли бы порождать райтеры пишушие код в поток.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
CC>Огромное сорри за оффтоп, но сколько уже периодически читаю ответы в эту ветку, каждый раз механически читаю ее название как "попИсал на С++... долго думал ".
Я только хотел написать про это...
... << А писал я этот бред на RSDN@Home 1.1.4 stable rev. 510, под звуки Алиса — Все в наших руках>>
Здравствуйте, srggal, Вы писали:
PD>>С врапперами вокруг хендлов не так все просто. Дело в том, что многие хендлы имеют ассоциированный с ними счетчик. Например, LoadLibrary-FreeLibrary, Create/OpenXX — CloseHandle. И если кто-то в этом случае будет вызывать исходные функции Win API напрямую, то без проблем не обойдется.
S>Да, проблемы могут возникнуть, но в кривых — не умелых или неопытных, а может и просто в невнимательных руках
S>Но ведь можно использовать подобную функциональность правильно ?
Мы-то можем, но где гарантия. что эту Library кто-то не загрузит еще раз из ненашего кода ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, srggal, Вы писали:
PD>>>С врапперами вокруг хендлов не так все просто. Дело в том, что многие хендлы имеют ассоциированный с ними счетчик. Например, LoadLibrary-FreeLibrary, Create/OpenXX — CloseHandle. И если кто-то в этом случае будет вызывать исходные функции Win API напрямую, то без проблем не обойдется.
S>>Да, проблемы могут возникнуть, но в кривых — не умелых или неопытных, а может и просто в невнимательных руках
S>>Но ведь можно использовать подобную функциональность правильно ?
PD>Мы-то можем, но где гарантия. что эту Library кто-то не загрузит еще раз из ненашего кода ?
Нет гарантий. Нелюблю праноидальность , где гарантии, что Предоставленный Вами класс не разрушат дважды ?
class Foo{};
int main()
{
Foo pFoo = new Foo;
delete pFoo;
delete pFoo;
return 0;
}
Здравствуйте, Павел Кузнецов, Вы писали:
>> Если бы для С++ существовали в настоящий момент ср-ва рефакторинга, типа тех, что мы имеем для Java и C# <...>
ПК>Xrefactory пробовал?
(Вернее, пробовал последний раз 4 года назад всевозможные плагины макросы и настройки, но это все было, мягко говоря, не совсем с человеческим лицом, поэтому отказывался и всерьез не использовал... Сделаю еще один заход...)
Здравствуйте, Sinclair, Вы писали:
S>Мне лично мсил показался как раз очень продуманным в том смысле, что самые частые команды типа ldarg.0 и ldc.0 занимают по одному байту вместе со всеми аргументами.
Сегодня вчерне как раз дописал миникомпилятор. Вобщем, кое где эти ldc_i4_0 и ldnull довольно удобны, например при работе с bool. Единственное, наличие ldc_i4_2 — ldc_i4_8 меня несколько удивляет.
А IT понятно почему ругается, он на br/br.s словил в RFD презабавнейшую багу в крайне неудачный момент (ИМХО потому что документацию невнимательно читал ).
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Павел Кузнецов, Вы писали:
>>> Если бы для С++ существовали в настоящий момент ср-ва рефакторинга, типа тех, что мы имеем для Java и C# <...>
ПК>>Xrefactory пробовал?
V>EMacs для С++ всерьез не пробовал, но обязательно попробую после этих обсуждений http://www.rsdn.ru/Forum/Message.aspx?mid=1428475&only=1
.
V>(Вернее, пробовал последний раз 4 года назад всевозможные плагины макросы и настройки, но это все было, мягко говоря, не совсем с человеческим лицом, поэтому отказывался и всерьез не использовал... Сделаю еще один заход...)
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AndrewVK, Вы писали:
IT>>>Ну разве что только "в отличии от x86".
AVK>>А что тебе там не понравилось?
IT>Экономия места мне там не понравилась. Систему команд можно было сделать в два раза проще выкинув короткие версии команд и все эти ldarg.0, .1, .2, .3. С примитивными типами тоже намудрили. ldc команд почему-то 4, а conv и ldind по полной схеме. Можно было иметь вообще по одной команде, если сопроводить её целевым типом или брать его со стека. Загрузка самого типа делается через задницу — ldtoken с последующим вызовом Type.RuntimeTypeHandle. Нельзя для этого было команду отдельную сделать? ldarg и ldloc — это суть одно и тоже. В общем, хватает там косяков. Видно, что делали не "выразительную и удобную" систему команд, а просто экономили байты, захломляя саму систему команд всяким мусором.
Обычное дело в системе команд — наиболее частоиспользуемые вещи должны иметь наиболее короткую кодировку.
Мне понравилась сама стековая направленность системы команд, т.е. общий принцип. Т.е. уходим от специфичных регистров АЛУ, ибо их наличие уже просто необоснованно, и служит скорее, ограничением. В реальных процах все-равно этих регистров давно нет (имеется ввиду одноименных и с тем же функционалом), а есть конвееры и планировщики ОПЕРАЦИЙ.
Здравствуйте, AndrewVK, Вы писали:
VD>>Какой Ремоутинг? Речь о КОРБА.
AVK>Он наверное имел ввиду Transparent/RealProxy
Нет, я имел ввиду ChannelServices и RemotingServices, использующих эти прокси и IMessage заодно.
Речь ведь шла о реализации CORBA на дотнете, и Влад спрашивал, при чем тут структуры и сериализация. Я показал, как они связаны.
CORBA-channel должен сделать то же самое как и любой channel — всего навсего передать IMessage (MethodCallMessage и пр. шушеру), и восстановить этот IMessage на другой стороне для вызова инфраструктурой .Net.
По сути, CORBA-channel можно назвать всего-навсего форматтером канала. На обоих сторонах канала полностью используется .Net Remoting фреймворк. По проводу "текут" данные в формате GIOP/IIOP.
В случае "обычного" .Net Remoting по проводу текут данные в формате .Net Binary Serialization, например.
GIOP/IIOP не содержит метаинформации, при вызове методов всегда точно должна быть известна сигнатура. Поэтому не поддерживаются перезагрузки сигнатур.
----------
Что касается самой сериализации, то разные поставщики CORBA под дотнет делают ее по-разному. Например — генерить из IDL сразу двоичную сборку, содержащую интерфейсы и типы данных, размеченных аттрибутами, управляющими маппингом сложных .Net типов на CORBA типы (простые мапятся легко, ибо обе платформы имеют фиксированное представление простых чисел).
Некоторые генерят исходники Transparent/RealProxy, которые выполняют эту сериализацию/маппинг.
Есть правда и такие решения CORBA под .Net, которые полностью все делают сами и несут в себе собственный фреймворк. Такая архитектура мне кажется самой неудачной.
Выполнен в виде форматтера канала. IDL-компилятор генерит интерфейсные .Net-сборки, которые можно будет потом использовать и для обычного Remoting. Т.е. сервак может выставить одни и те же интерфейсы на разных портах для разных подсистем , например, для дотнета — слушать по родному TCP Remoting, а для Java/C++ открыть понятный им IIOP.
Есть так же утилита, которая берет дотнетную сборку и генерит IDL на ее основе. Именно так можно открывать интерфейс для С++/Java к имеющимся .Net приложениям.
Здравствуйте, Cyberax, Вы писали:
C>vdimas wrote:
>> _W>Напиши аналог boost::optional или boost::variant. >> Хм.. для variant необходимо что-то типа union.
C>Нет. Внутри boost::optional/variant просто используется буффер, который C>по разному интерпретируется.
Да ну? Память ЭВМ — это буфер, который по разному интерпретируется. Мы ведем речь о безопасности и удобстве. Двигаемся далее.
>> В общем, сделать размеченный union частью языка, примерно как в >> спецификациях CORBA.
C>Кхм. Вы доку на boost::variant смотрели?
variant — Safe, generic, stack-based discriminated union container, from Eric Friedman and Itay Maman.
Прошу заметить, что память в variant не то, чтобы реинтерпретируется как угодно, она там инициализируется, т.е. для сохраняемых значений вызывается new(address) Type(); Таким образом, не существует возможности значению попасть туда кроме как через конструктор (копирования в т.ч.), что и требуется для безопасной работы.
И нет вообще никакой возможности прочитать значение не того типа, которое хранится в данный момент. А какой тип хранится — узнать нельзя, потому как типы нумеруются в CompileTime и variant хранит порядковый номер типа текущего значения из листа типов (т.е. variant<int, long> не одно и то же что variant<long, int>, что правильно с т.з. С++, но не совсем правильно семантически). Не зря рекомендуют использовать визитор для извлечения данных.
А вот отрывок из раздела Motivation по разработке variant, читаем внимательно:
Clearly another approach is required. Typical solutions feature the dynamic-allocation of objects, which are subsequently manipulated through a common base type (often a virtual base class [Hen01] or, more dangerously, a void*). Objects of concrete type may be then retrieved by way of a polymorphic downcast construct (e.g., dynamic_cast, boost::any_cast, etc.).
However, solutions of this sort are highly error-prone, due to the following:
— Downcast errors cannot be detected at compile-time. Thus, incorrect usage of downcast constructs will lead to bugs detectable only at run-time.
— Addition of new concrete types may be ignored. If a new concrete type is added to the hierarchy, existing downcast code will continue to work as-is, wholly ignoring the new type. Consequently, the programmer must manually locate and modify code at numerous locations, which often results in run-time errors that are difficult to find.
К сожалению, текущая версия variant прямо-таки провоцирует на вот это:
variant<int, long, std::string> v;
v = "Hello World!";
switch(*(char*)&v) {
case 0: // int
case 1: // long
case 2; // string
};
Но исходный посыл это не меняет. Безопасный union мог бы быть частью языка. В том виде, что мы имеем сейчас, С++ унаследовал от C очередную опасную конструкцию.
В общем, продолжаю рекомендовать посмотреть синтаксис и семантику описания union в CORBA. Мне гораздо более нравится явный диспечеризатор, чем неявный compile-time перечислитель типов, который к тому же недоступен для опроса. Бустовским вариантом в итоге неудобно пользоваться, потому как необходимо диспечеризатор писать самому, за счет побочного эффекта:
------------
одно продолжает радовать в С++ — это самодостаточность. Если чего-то в языке нет, то это "что-то" можно дописать самому. Пока что это уникальная фича, примера которой я еще не видел.
Здравствуйте, VladD2, Вы писали:
VD>>>Стабы наверно все же генерируеются генераторами кода idl2xxx. Но причем тут ОРБ? Он то скорее всего на плюсах написан.
V>>Нет, написанны они на дотнете, и выполнены как форматтеры каналов или же в виде самих каналов (у кого как), т.е. используют инфраструктуру .Net Remoting,
VD>Какой Ремоутинг? Речь о КОРБА.
Блин, я уже который раз пропагандирую это интересное сочетание, только проснулись...
Здравствуйте, WolfHound, Вы писали:
WH>А по моему это изврат. Если они хотели экономить то пусть бы они делали это при записи в фаил. WH>ИМХО лучше считать что бывает только 1, 0 и много (а то и просто бывает только много) чем плодить опкоды.
понятно, да, sequence<sequence<ValueType> > отображается на ValueType[][], а хотелось бы на ValueType[,], ибо первый случай — это массив объектов-массивов, каждый из которых требует отдельного управления GC.
Но для такого отображения нужно указать фиксированный размер внутреннего sequence<> (количество колонок фиксированное?) и то не факт, что все КОРБы переведут его в [,] вместо [][].
Здравствуйте, _Winnie, Вы писали:
>>long mantis(float); // некая нормализованная мантисса, умноженная на десятичный коэф, достаточной ширины >>extern const float Q_NAN; //и т.д.
_W>Ну да. Только библиотеку надо писать. Сама она ниоткуда не появится.
конечно, если что-то урезать, то кое-что придется добавить
>>struct vec3f_t { >>std::cout << a[0][2] << a[0][0]; _W>Передавать в консоль — это круто, но от меня ждут float *, а не символы. _W>см. DxSDK/MSDN SetVertexShaderConstant
Я же сказал, что переделаю пример — и переделал.
Эти SDK от С++ далеки. Могли бы выпустить нечто вроде враппера для плюсов, где производитель платформы взял бы на себя гарантию бинарной совместимости (а не программист, забывший прописать #pragma pack 4).
Типа как в GDI+, есть API, а есть C++ библиотека-ропер.
>>__W>Имеется embedded устройство, 32 мегабайта оперативки. 1 мегабайт для кода и данных, 1 мегабайт для стека. Нужно загрузить образ с DVD размером в 30 мегабайт. >>и? в чем прикол? _W>1+1+30 == 32. _W>В том, что нет места, что бы загрузить нечто в одно место, а потом распарсить его и записать его в другое место. Единственный выход — загрузка inplace всех структур данных. _W>И нет времени, что бы парсить — время загрузки игры по TCR Sony/Microsoft составляет 30 секунд. Подгружать приходится по ходу игры, на ходу.
>>Не разделяю восторга. На машине с другой архитектурой этот файл не прочитается. Могу загрузить за 1 malloc, + 1 fread, + парсинг (мне бы хватило 4-х байт на объект, если множество типов узлов конечное, т.е. не подлежит расширению). _W>И не надо. Это файл собирается под определенную архитектуру. Так же, как и исполняемы файл. Под PlayStation2 — по одному, под X-Box — по другому(ух, объединённая оперативная и видепамять — это здорово!), под PC- по третьему , под Game Cube — по четвёртому. _W>Тебя же не смущает, что исполняемый файл с одной системы не запускается на другой, хотя она собирается из C++ и под ту, и под другую? Вот данные собираются точно так же. _W>Да, по сети его не передашь, но кому придёт в голову пересылать .exe с Win32 на Linux?
Это понятно, не понятно, при чем тут ООП и С++, если речь идет о загрузке? Напиши загрузку-выгрузку на С.
>>+ парсинг _W>Memory Mapping, и используем кусок памяти как готовый объект! Никакого парсинга! _W>Возможно, делаем fixup таблицы указателей на виртуальные функции, их то в файле не сохранишь.
fixup чего? самой таблицы или указателей на эту таблицу у подгружаемых объектов? Кстати, у тебя, насколько я понял, фиксированный адрес, куда ты подгружаешь свои данные? (иначе, твои связи объектов нарушатся) Тебе не кажется, что в подавляющем большинстве других обычных платформ у нас принципиально не может вопрос так стоять (насчет заведомой области памяти)?
Есть такое дело EC++, не смотрел? Должен знать или даже использовать, если у тебя такая область деятельности. Это слегка урезанный С++. Очень живучая ветвь языка С++, кстати. К чему это я? Может текущую версию С++ ответвить как UC++? (Unsafe C++)
Дело в том, что конкретный EC++ конкретно специфицирован производителем под определенную платформу. Т.е. существует некая детерминированность в терминах битов. Как раз, что вам требуется.
>>Конкретный адрес указателя не имеет смысла, кроме значения NULL, и то ты не знаешь, чему оно равно на всевозможных платформах. Сорри. _W>Для отладки очень даже имеет значение. Если я там вижу что-то вроде BaadFooD... Или DeadBeef... или хочу понять, где оно лежит, на стеке, в куче или в код.
Ну так я же сказал, указатель в число — не опасно, в отличие от наоборот.
>>Хотя... ничего страшного нет, если мы приведем указатель к size_t. _W>Ага! Я же говорил, ничего страшного в реинтерпретации нет!
Ну знаешь, может быть запретить char переводить в int?
Распространенная потенциальная опасность — в неверной интерпретации структур данных или пользование непроинициализированными структурами.
Я плохо представляю себе неверное использование целочисленного представления адреса указателя. Зато хорошо представляю себе использователя именно указателя в его основном качестве (операции косвенной записи и чтения), который ведет "в космос".
>>Опасность нас ждет при обратном приведении произвольного числа к указателю произвольного типа. Т.е. запретить именно эту операцию. _W>А как дать в отладчике пользователю ввести этот указатель с клавиатуры? _W>Отладчики что, уже святым духом пишутся, не на С?
Отладчик пускай пишется на чем угодно, хоть на С те места, где требуется биты путать с байтами. Меня удивляет другое — тебе приходится в отладчике присваивать вручную указателям значения? Можно подробней?
>>Да никак. _W>А обещал, что сможешь переписать любой код...
И продолжаю утверждать это.
Я обещал переделать С++ код, с его ООП-задачами (а иначе — welcome to C, я ему тоже 6 лет отдал). Т.е. я расчитывал выделить прикладную функциональность и повторить. А тут мне как раз предлагают следующее: "функциональность примера состоит в реинтерпретации памяти, сможете ли повторить этот трюк без реинтерпретации?". Не может функциональность в этом состоять, понимаешь?
>>Хм.. для variant необходимо что-то типа union.
_W>Да нет.. скорее, struct variant { byte store[max(sizeof(T1), sizeof(T2), sizeof(T3)]. }; (очень грубо).
Меня пугает твое уже второе НЕТ, когда речь заходит об union. Ты вообще в курсе, что это за штуковина?
Потому как твое "очень грубо" — это и есть смысл унаследованного С-union, который я предлагаю заменить. В той ветке про variant я ответил подробнее.
>>byte image[3*N] _W>Ну, мне удобно рассматривать картинку как массив байтов для одних операций, и как набор структур RGB для других. А кастовать так память все равно придется, например в аксессоре, который возврщает RGB &(ссылку), когда я не хочу работать с байтами.
Нет, кастовать память не придется, пиши так:
int MakeRGB(byte r, byte g, byte b) { return b<<16 + g<<8 + r; }
И поверь на слово, что компилятор сам прекрасно разберется, как ему наиболее оптимально собрать 3 байта в целое.
_W>Я хочу одновременно и скорость, и удобство. А прагмы/аттрибуты упаковки есть у всех компиляторов.
Помимо упаковки есть еще align, и ты не можешь им управлять.
А теперь объясни мне, в чем удобство работы со структурой RGB как с массивом байт, если все равно твои R, G, B байты соседних точек не будут располагаться друг за другом в памяти, кроме как в 8-ми битной или 24-битной архитектуре?
Т.е. в 32-битной это будет примерно так:
R G B _ R G B _ ...
V>>учитывая инлайность и способности компиляторов, я уверен, что порожденный код не уступит твоей структуре RGB, зато будет более надежным и переносимым, т.к. не будет зависеть от опций компилятора в плане упаковки структур, т.е. не будет вероятности "промазать".
_W>Я _очень_ много времени провожу с asm, который генерит компилятор.
_W>Что бы заставить IntelC++ Compiler сгенерировать код под MMX надо много колдовать с его #pragmaми и циклами for. И получившийся код будет не намного более переносимым, чем assembler, а другие компиляторы по нему будут генерить неэффективный код. Всё равно его придется брать в #ifdef __INTEL_COMPILER.
Пиши этот код в *.С — файлах, зачем тебе С++. Если у тебя такие задачи, то тебе будет еще проще писать их на С, там меньшая строгость по использованию указателей, и все enum совместимы м/у собой, что позволяет неплохо создавать свои удобные подмножества чужих API, так как и объединять различные API без кучи типизированных оболочек, как в С++.
_W>Писать под абстрактную плаформу невозможно. Пишут всегда под конкретную, даже если их много( Mozilla/Boost/STLPort другие кросс-платфоменные проекты). _W>Ты видел, сколько в них #ifdef для WorkAroundов? И стоит #error "unknown compiler"?
Звучит как приговор.
К счастью, большинство work-around в boost обыгрывают VC 6.0 или старый gcc. А зря, ИМХО. Надо тупо ориентироваться на стандарт. Буст только-только разрабатывается, по сути. Время его активного использования наступит не завтра (а сразу после принятия boost как стандарта, гы-гы). К тому времени о VC 6.0 уже никто не вспомнит.
Здравствуйте, vdimas, Вы писали:
V>Обычное дело в системе команд — наиболее частоиспользуемые вещи должны иметь наиболее короткую кодировку.
Я вовсе не против того, чтобы частоиспользуемые вещи были более короткими. Я против того, чтобы в данном случае называть их "выразительными и удобными". MSIL невыразителен и неудобен. Он делался для компиляторов, а не для человеков.
ЗЫ. Выразительным и удобным для своего времени был дековский ассемблер.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
AVK>А IT понятно почему ругается, он на br/br.s словил в RFD презабавнейшую багу в крайне неудачный момент (ИМХО потому что документацию невнимательно читал ).
Да причём тут документация. Наверняка MSIL'овский компилятор выдал бы мне диагностику и послал. А вот имит скушал гад и не подавился. А орать матом потом начал jit, причем объясняя это в свойственной ему форме — типа "не шмогла"
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
V>Пиши этот код в *.С — файлах, зачем тебе С++. Если у тебя такие задачи, то тебе будет еще проще писать их на С, там меньшая строгость по использованию указателей, и все enum совместимы м/у собой, что позволяет неплохо создавать свои удобные подмножества чужих API, так как и объединять различные API без кучи типизированных оболочек, как в С++.
А си просто хуже подходит для этих задач. Например я подобные вещи пишу на C++ используя вовсю шаблоны и практически не используя классы (в смысле ООП, как АТД используются), получается и более высокоуровнево и быстрее чем си за счет агресивного инлайнинга и специализаций. Так что думаю не стоит загонять C++ только в свои рамки.
vdimas wrote:
> C>Кхм. Вы доку на boost::variant смотрели? > А ты исходники смотрел?
Я до появления Boost 1.33 написал свою реализацию сериализации для
вариантов.
> variant — Safe, generic, stack-based discriminated *union container*, > from Eric Friedman and Itay Maman. > Прошу заметить, что память в variant не то, чтобы реинтерпретируется > как угодно, она там инициализируется, т.е. для сохраняемых значений > вызывается new(address) Type(); Таким образом, не существует > возможности значению попасть туда кроме как через конструктор > (копирования в т.ч.), что и требуется для безопасной работы.
Да, однако это обеспечивается с помощью аккуратного ручного контроля
преобразований. В функции get все равно будет происходить реинтерпретация.
> И нет вообще никакой возможности прочитать значение не того типа, > которое хранится в данный момент. А какой тип хранится — узнать > нельзя, потому как типы нумеруются в CompileTime и variant хранит > порядковый номер типа текущего значения из листа типов (т.е. > variant<int, long> не одно и то же что variant<long, int>, что > правильно с т.з. С++, но не совсем правильно семантически).
Ну, вообще говоря, можно. Там есть функция what(), возвращающая номер
активного типа.
> К сожалению, текущая версия variant прямо-таки провоцирует на вот это: > variant<int, long, std::string> v; > v = "Hello World!"; > switch(*(char*)&v) { > case 0: // int > case 1: // long > case 2; // string > };
Ээээ? Я не понял смысла этой конструкции. Можно писать так:
variant<int, long, std::string> v;
v="Hello, world!";
switch(v.what())
{
case 0:
case 1:
case 2:
}
Это вполне безопасно и легально. В моей сериализации варианта
использовался подобный прием.
> Но исходный посыл это не меняет. Безопасный *union *мог бы быть частью > языка. В том виде, что мы имеем сейчас, С++ унаследовал от C очередную > опасную конструкцию.
А зачем? Вариантный тип из Буста — вполне безопасен, даже если и сделан
поверх небезопасных компонентов.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, srggal, Вы писали:
V>[skip]
V>понятно, да, sequence<sequence<ValueType> > отображается на ValueType[][], а хотелось бы на ValueType[,], ибо первый случай — это массив объектов-массивов, каждый из которых требует отдельного управления GC.
V>Но для такого отображения нужно указать фиксированный размер внутреннего sequence<> (количество колонок фиксированное?) и то не факт, что все КОРБы переведут его в [,] вместо [][].
Здравствуйте, vdimas, Вы писали:
WH>>А по моему это изврат. Если они хотели экономить то пусть бы они делали это при записи в фаил. WH>>ИМХО лучше считать что бывает только 1, 0 и много (а то и просто бывает только много) чем плодить опкоды. V>Должны же быть короткая команда обнуления.
Обнуления чего? Да и зачем? Пусть размером комманд занимается тот код который пишет сборку.
А сейчас приходится делать таких монстриков
...
#region PushLocal
public ILGeneratorHelper PushLocal(UInt16 n)
{
switch (n)
{
case 0: _il.Emit(OpCodes.Ldloc_0); return this;
case 1: _il.Emit(OpCodes.Ldloc_1); return this;
case 2: _il.Emit(OpCodes.Ldloc_2); return this;
case 3: _il.Emit(OpCodes.Ldloc_3); return this;
}
if (n <= Byte.MaxValue)
_il.Emit(OpCodes.Ldloc_S, n);
else
_il.Emit(OpCodes.Ldloc, n);
return this;
}
#endregion
#region Push const
public ILGeneratorHelper PushBool(bool b)
{
if (b)
_il.Emit(OpCodes.Ldc_I4_1);
else
_il.Emit(OpCodes.Ldc_I4_0);
return this;
}
public ILGeneratorHelper PushInt(int i)
{
switch (i)
{
case -1: _il.Emit(OpCodes.Ldc_I4_M1); return this;
case 0: _il.Emit(OpCodes.Ldc_I4_0); return this;
case 1: _il.Emit(OpCodes.Ldc_I4_1); return this;
case 2: _il.Emit(OpCodes.Ldc_I4_2); return this;
case 3: _il.Emit(OpCodes.Ldc_I4_3); return this;
case 4: _il.Emit(OpCodes.Ldc_I4_4); return this;
case 5: _il.Emit(OpCodes.Ldc_I4_5); return this;
case 6: _il.Emit(OpCodes.Ldc_I4_6); return this;
case 7: _il.Emit(OpCodes.Ldc_I4_7); return this;
case 8: _il.Emit(OpCodes.Ldc_I4_8); return this;
}
if (i >= sbyte.MinValue && i <= sbyte.MaxValue)
_il.Emit(OpCodes.Ldc_I4_S, i);
else
_il.Emit(OpCodes.Ldc_I4, i);
return this;
}
#endregion
...
И так для всех комманд IL.
Иначе генерировать IL ручками становится не просто.
Хотя даже такие монстрики не решают проблему условных и безусловных переходов.
Для того чтобы это решить видимо нужно городить свою систему комманд по которой потом строить IL.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, IT, Вы писали:
IT>Да причём тут документация. Наверняка MSIL'овский компилятор выдал бы мне диагностику и послал. А вот имит скушал гад и не подавился.
А чем ты, прости за откровенность, думал, когда использовал инструкцию перехода с аргументом размера 1 байт на неизвестную заранее дистанцию? Эти инструкции может применить компилятор, когда он абсолютно уверен (потому что код уже нагенерен), либо в случаях вроде выполнения операции && над аргументами в стеке, когда ничего непредвиденного внутри перехода быть не может в принципе.
IT> А орать матом потом начал jit, причем объясняя это в свойственной ему форме — типа "не шмогла"
А мог и не орать, если при переполнении циферка удачно попала.
S>Нет гарантий. Нелюблю праноидальность , где гарантии, что Предоставленный Вами класс не разрушат дважды ?
Нет, не пойдет в качестве аргумента. Этот экземпляр класса я сам создал в моей программе, если я дважды его экземпляр удалять буду — я и виноват. А вот хендлами оперирую, увы, не только я, и это мне совсем неподконтрольно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, не пойдет в качестве аргумента. Этот экземпляр класса я сам создал в моей программе, если я дважды его экземпляр удалять буду — я и виноват. А вот хендлами оперирую, увы, не только я, и это мне совсем неподконтрольно.
Здравствуйте, srggal, Вы писали:
S>Точно также как и на Джаве, некоторые горячие головы ытались реалтизовать аппаратную поддержку Джава — спец- Джава процессоры и все такое, — ан не сильно получилось.
Получилось, получилось. Просто на серверах это нафиг не упёрлось, проще софтовую JVM вылизать. А вот в мобильном секторе расклад принципиально иной.
S>ЗЫ как уже писали умные люди, все зависит от задачи.
Именно.
Здравствуйте, SilverCloud, Вы писали:
SC>Здравствуйте, srggal, Вы писали:
S>>Точно также как и на Джаве, некоторые горячие головы ытались реалтизовать аппаратную поддержку Джава — спец- Джава процессоры и все такое, — ан не сильно получилось. SC>Получилось, получилось. Просто на серверах это нафиг не упёрлось, проще софтовую JVM вылизать. А вот в мобильном секторе расклад принципиально иной.
Дык в целях расширения кругозора, моего естественно, дайте линк на железку реализующую аппаратную JVM ( если так можно выразаиться )
Здравствуйте, Pzz, Вы писали:
Pzz>Раньше пополаму очень любили вставлять в банкоматы. Причем не Pzz>какую-нибудь, а самую древнюю 16-битную версию. Pzz>Теперь вот в банкоматы стали вправлять NT. Я недавно видел банкомат, у Pzz>которого сверху стандартной банкомантной фигни висит message box, в Pzz>котором написано, что один из системных сервисов не запустился. Pzz>Как подумаешь, а что, если сервис, который деньги со счета списывает, Pzz>запустится, а тот, который купюры выдает — нет, карточку вставлять Pzz>становится страшно...
Я задал этот вопрос специалисту, обслуживающему в нашем городе Золотую Корону после того, как увидел перегружающийся от скачка напряжения банкомат, а перед этим за минуту снял в нем деньги с карточки. Его ответ приблизительно следующий. Списывание денег и их выдача по сути транзакция. Банкомат отсчитывает деньги кладет их за шторку, деньги списываются, деньги выезжают из за шторки. Единственное узкое место — деньги остались за шторкой. Выход — звонок в банк и все исправят и восстановят без потерь с обеих сторон (разве что только время).
В общем-то, за все время работы банкоматов он не мог вспомнить реальных проблем с этим — все продумано достаточно точно. Но мог вспомнить множество проблем, которых пользователи не видят. Будь то установка firewall на банкоматы или систем их мониторинга. Чтоже касается ОС. То и полуось и вин вызывают у него нарекания. Каждая свои.
Но это лирика и к предмету обсуждения не относится
Здравствуйте, tarkil, Вы писали:
T>Здравствуйте, eao197, Вы писали:
E>>Может быть то, что принимают за синдром высшей кастовости или снобизм на самом деле попытка сохранить себя как класс "С++ программистов"?
T>А не торопишься ли ты C++ хоронить? Вроде рано. Снижение популярности имеется, но до критического порога ещё ой как далеко.
T>Ладно, фигня это всё. Лучше скажите (вопрос ко всем), видел кто-нибудь реализацию на плюсах удобных типобезопасных форматных строк в стиле .NET'овского String.Format? А то есть мысль сваять аналог самому. Удобнейшая штука ведь.
Отпиши в приват. Есть кое-что по этому поводу.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>А не подскажешь — это макрос какого языка?
C
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Hydrogen, Вы писали:
H>Вообще говоря, в теории безомапсности компьютерных систем, H>AFAIK есть утверждение — "Более безопасная система менее удобна".
А ты ничего не путаешь? AFAIK как раз наоборот: более безопасный путь использования системы должен быть более удобным.
Хотя здесь можно навернуть ещё философию типа "смотря с чего начинать". Специально для форума, тыксыть.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, tarkil, Вы писали:
T>Здравствуйте, eao197, Вы писали:
E>>Может быть то, что принимают за синдром высшей кастовости или снобизм на самом деле попытка сохранить себя как класс "С++ программистов"?
T>А не торопишься ли ты C++ хоронить? Вроде рано. Снижение популярности имеется, но до критического порога ещё ой как далеко.
T>Ладно, фигня это всё. Лучше скажите (вопрос ко всем), видел кто-нибудь реализацию на плюсах удобных типобезопасных форматных строк в стиле .NET'овского String.Format? А то есть мысль сваять аналог самому. Удобнейшая штука ведь.
Ну, есть boost::format. Тормоз дикий, отстаёт от даже .NET String.Format.
Ждите Winnie Format Library!
Скоро-скоро!
Только разберусь с ошибками округления в scientific формате
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Hydrogen, Вы писали:
H>>Вообще говоря, в теории безомапсности компьютерных систем, H>>AFAIK есть утверждение — "Более безопасная система менее удобна".
ГВ>А ты ничего не путаешь? AFAIK как раз наоборот: более безопасный путь использования системы должен быть более удобным.
Security measures usually reduce convenience, especially for sophisticated users. Security can delay work and can create expensive administrative and educational overhead. Security can use significant computing resources and require dedicated hardware.
"
Здравствуйте, tarkil, Вы писали:
T>Ладно, фигня это всё. Лучше скажите (вопрос ко всем), видел кто-нибудь реализацию на плюсах удобных типобезопасных форматных строк в стиле .NET'овского String.Format? А то есть мысль сваять аналог самому. Удобнейшая штука ведь.
Спасибо за линки, однако!
H> http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/security.htm H>" H>Count the Cost
H>Security measures usually reduce convenience, especially for sophisticated users. Security can delay work and can create expensive administrative and educational overhead. Security can use significant computing resources and require dedicated hardware. H>"
+1 Как раз иллюстрация к тезису "с чего начинать": если начинать с незащищённой системы — то да, действительно, разграничение доступа принесёт дополнительные неудобства.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[24]: offtopic: расставим все точки в слове "Linux"
Обратим внимание, когда исходники linux стали публичными:
Эту дату я хорошо помню: 17 сентября 1991 года.
Не думаю, чтобы ту версию проверяло больше одного-двух человек. Для
этого нужно было возиться с установкой специального компилятора, выделить
пустой раздел, чтобы использовать его для загрузки, откомпилировать мое ядро
и запустить оболочку. А кроме запуска оболочки, делать было особенно нечего.
Можно было распечатать исходники -- всего 10 000 строк, т.е. меньше ста
страниц, если печатать мелким шрифтом.
далее:
Дело приняло новый оборот, когда я понял, что
Linux не просто игрушечная операционная система -- на нее всерьез стало
полагаться множество людей. Вначале многие ставили себе Linux, просто чтобы
поковыряться в ней, а вот когда ее стали использовать как настоящую
операционную систему, я понял, что несу ответственность, если что-то
случится. Или по крайней мере начал это понимать. (Я и сейчас чувствую такую
ответственность.) За 1992 год Linux превратилась из увлекательной игры в
важную составляющую жизни людей, стала источником их доходов, средством
ведения коммерции.
Скачок произошел весной 1992-го -- примерно через год после того, как я
занялся программой эмуляции терминала, -- когда под Linux заработала первая
версия оконной системы X Window. Это значило, что операционка может
поддерживать графический интерфейс пользователя и что пользователи могут
работать в нескольких окнах одновременно благодаря проекту X Window,
зародившемуся в Массачусетском технологическом институте. Это было
существенное новшество. Помню, за год до его внедрения я шутил на эту тему с
Ларсом: говорил, мол, когда-нибудь мы сможем запустить X Window, и все
заработает. Я совершенно не ожидал, что это произойдет так быстро. Хакер по
имени Орест Збровски сумел перенести X Window под Linux.
VD> и очень долгое время вообще являлся эксперементальной ОС (в начале вообще дипломным проектом).
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Re: LINUX устарела
Date: 29 Jan 92 23:14:26 GMT
Organization: University of Helsinki
...
В сообщении <12595@star.cs.vu.nl> ast@cs.vu.nl (Энди Таненбаум)
пишет: ...
>Как большинство из вас знает, для меня MINIX --
>хобби, которым я занимаюсь по вечерам, когда мне
>надоедает писать книжки, а по CNN не показывают
>никаких войн, революций или парламентских
>слушаний. Моя основная работа -- преподавание и
>исследования в области операционных систем.
Re 1: Для вас minix хобби -- но ведь minix приносит доход, a linux
раздается бесплатно. Теперь по поводу хобби. Поместите minix в свободный
доступ, и одна из моих главных претензий к ней отпадет. Linux для меня в
большой степени хобби (серьезное хобби, самого высшего сорта). Я не беру за
нее денег, и она даже не является частью моей учебной работы. Я сделал ее в
свободное время на собственной машине.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, vdimas, Вы писали:
V>>Пиши этот код в *.С — файлах, зачем тебе С++. Если у тебя такие задачи, то тебе будет еще проще писать их на С, там меньшая строгость по использованию указателей, и все enum совместимы м/у собой, что позволяет неплохо создавать свои удобные подмножества чужих API, так как и объединять различные API без кучи типизированных оболочек, как в С++.
FR>А си просто хуже подходит для этих задач. Например я подобные вещи пишу на C++ используя вовсю шаблоны и практически не используя классы (в смысле ООП, как АТД используются), получается и более высокоуровнево и быстрее чем си за счет агресивного инлайнинга и специализаций. Так что думаю не стоит загонять C++ только в свои рамки.
Забыл ответить
PD>>Нет, не пойдет в качестве аргумента. Этот экземпляр класса я сам создал в моей программе, если я дважды его экземпляр удалять буду — я и виноват. А вот хендлами оперирую, увы, не только я, и это мне совсем неподконтрольно.
S>А CreateFile — не Вы делаете в своей программе ?
CreateFile — я. Но тут вот такой нюанс
Если дважды сделать CreateFile с одним и тем же файлом — получишь 2 разных хендла. Здесь проблем нет.
А вот если дважды вызвать LoadLibrary для одной и той же библиотеки, то получишь один и тот же HMODULE, только счетчик использований увеличится до 2 и потребуется сделать 2 вызова FreeLibrary. Это же относится к ивентам, семафорам и т.д.
А теперь представь себе class CModule. Конструктор делает LoadLibrary, деструктор — FreeLibrary, все в порядке. А тут вдруг из какого-то другого места (из прилинкованного кода статической библиотеки третьей фирмы) кто-то возьмет да и сделает LoadLibrary минуя, естественно, твой CModule. Потом ты вызовешь деструктор CModule и будешь думать, что библиотека выгружена, а она сидит себе в памяти...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А теперь представь себе class CModule. Конструктор делает LoadLibrary, деструктор — FreeLibrary, все в порядке. А тут вдруг из какого-то другого места (из прилинкованного кода статической библиотеки третьей фирмы) кто-то возьмет да и сделает LoadLibrary минуя, естественно, твой CModule. Потом ты вызовешь деструктор CModule и будешь думать, что библиотека выгружена, а она сидит себе в памяти...
А в чем проблема? Если библиотека нужна другому модулю то пусть себе сидит. Ведь не просто так же она сидит.
Гораздо хуже если она будет выгружена пока она еще комуто нужна.
А если тебе нужен полный контроль над кодом то нефиг библиотеки третьих фирм использовать.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Обнуления чего? Да и зачем? Пусть размером комманд занимается тот код который пишет сборку. WH>А сейчас приходится делать таких монстриков
WH>И так для всех комманд IL.
Да сколько там этих команд-то
WH>Иначе генерировать IL ручками становится не просто. WH>Хотя даже такие монстрики не решают проблему условных и безусловных переходов. WH>Для того чтобы это решить видимо нужно городить свою систему комманд по которой потом строить IL.
+1
И это справедливо не только для .Net VM
Посмотри на аналогичное у IT в RFD, не совсем явно выражено, но близко. Еще тут http://iiop-net.sourceforge.net/ так же не совсем явно выраженные намерения (при организации кодогенерации), но сути не меняет.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, vdimas, Вы писали:
V>>Обычное дело в системе команд — наиболее частоиспользуемые вещи должны иметь наиболее короткую кодировку.
IT>Я вовсе не против того, чтобы частоиспользуемые вещи были более короткими. Я против того, чтобы в данном случае называть их "выразительными и удобными". MSIL невыразителен и неудобен. Он делался для компиляторов, а не для человеков.
Если абстрагироваться от Ldloc_0 (_1, _2, _S) и прочей аналогичной разновидности чуть более высокоуровневым генератором — то вполне.
IT>ЗЫ. Выразительным и удобным для своего времени был дековский ассемблер.
Здравствуйте, vdimas, Вы писали:
FR>>А си просто хуже подходит для этих задач. Например я подобные вещи пишу на C++ используя вовсю шаблоны и практически не используя классы (в смысле ООП, как АТД используются), получается и более высокоуровнево и быстрее чем си за счет агресивного инлайнинга и специализаций. Так что думаю не стоит загонять C++ только в свои рамки.
V>опять повторю про EC++, очень рекомендую.
Не вижу смысла использовать урезанный вариант, когда могу нормально работать с полноценным.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, vdimas, Вы писали:
V>>Да сколько там этих команд-то WH>216. WH>Если несчитать короткие версии то 185.
если так же объединить разновидности по ширине операнда (смысл операции тот же), то там чуть больше 90 получается.
Здравствуйте, WolfHound, Вы писали:
WH>А в чем проблема? Если библиотека нужна другому модулю то пусть себе сидит. Ведь не просто так же она сидит. WH>Гораздо хуже если она будет выгружена пока она еще комуто нужна.
Да никакой проблемы нет. Просто я хочу отметить, что мы получим класс, который реально своим внутренним состоянием не управляет
WH>А если тебе нужен полный контроль над кодом то нефиг библиотеки третьих фирм использовать.
Хороший совет . Например, я динамически подгружу некоторую библиотеку от Микрософт, а она что-то еще вздумает загрузить. Или, скажем, библиотека третьей фирмы, не будучи уверен, что я загрузил comctl32.dll (мог ведь и не загрузить!), на всякий случай ее загрузит (вызовет InitCommonControls), да еще и неявно. Как тут быть ?
Pavel Dvorkin,
> Просто я хочу отметить, что мы получим класс, который реально своим внутренним состоянием не управляет
Не согласен. "Внутренним состоянием" данного класса является гарантия, что на каждый вызов LoadLibrary, сделанный через этот класс, последует FreeLibrary. "Общих" гарантий относительно использования LoadLibrary/FreeLibrary во всей программе класс не дает.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eugals, Вы писали:
E>Здравствуйте, tarkil, Вы писали:
T>>Ладно, фигня это всё. Лучше скажите (вопрос ко всем), видел кто-нибудь реализацию на плюсах удобных типобезопасных форматных строк в стиле .NET'овского String.Format? А то есть мысль сваять аналог самому. Удобнейшая штука ведь.
E>ICU
Мощная штука, кстати уже к регекспу из буста прикрутили, а к ксерксу уже давно. Вот только что меня раздражает в С++ что в каждой библиотеке свои порядки(именование, сообщение об ошыбках) в результате чтобы свести всё это в одну работающую програму нужно нетривиальное мастерство и иногда большая куча кода для всяких враперов, фасадов чем сама включеная библиотека.
Здравствуйте, SilverCloud, Вы писали:
S>>Дык в целях расширения кругозора, моего естественно, дайте линк на железку реализующую аппаратную JVM ( если так можно выразаиться )
SC>сабж
Это конечно хорошо, но ещё б рыночную долю этого продукта бы узнать?
Здравствуйте, VladD2, Вы писали:
Ш>>Нда? Это какой же язык программирования может определить, что ты вместо 12345 написал 2200 (или наоборот)?
VD>Как видишь, есть языки которые умадряются привести альтернативное решение.
Вот для этого придумали Python, чтобы вещи можно было сделать только одним способом
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что меня огорчает — фанатическая нетерпимость некоторых к другому мнению. В общем, увы, советское воспитание легко не исчезает.
Я бы попросил Вас воздерживаться от подобных высказываний. Ибо оскорбительно/некультурно...
Здравствуйте, SilverCloud, Вы писали:
S>>Дык в целях расширения кругозора, моего естественно, дайте линк на железку реализующую аппаратную JVM ( если так можно выразаиться )
SC>сабж
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Pavel Dvorkin,
>> Просто я хочу отметить, что мы получим класс, который реально своим внутренним состоянием не управляет
ПК>Не согласен. "Внутренним состоянием" данного класса является гарантия, что на каждый вызов LoadLibrary, сделанный через этот класс, последует FreeLibrary. "Общих" гарантий относительно использования LoadLibrary/FreeLibrary во всей программе класс не дает.
"Внутренним состоянием" данного класса — согласен. Но вот то, что он общих гарантий не дает — и плохо. Иными словами, он своей задачи, которую я хотел бы решить (полностью управлять загрузкой/выгрузкой) — не решает. И этим меня не устраивает, почему я его писать и не буду. А то, что он внутренне непротиворечив — не спорю.
Как было написано в одном приказе по некоторому учреждении — "Гвозди в стенку забивать только через меня или зама". Вот это он и не позволит, увы.
Pavel Dvorkin,
> "Внутренним состоянием" данного класса — согласен. Но вот то, что он общих гарантий не дает — и плохо. Иными словами, он своей задачи, которую я хотел бы решить (полностью управлять загрузкой/выгрузкой) — не решает. И этим меня не устраивает, почему я его писать и не буду. А то, что он внутренне непротиворечив — не спорю. > > Как было написано в одном приказе по некоторому учреждении — "Гвозди в стенку забивать только через меня или зама". Вот это он и не позволит, увы.
Отчего же? Можно поставить триггер на VCS, запрещающий "случайно" submit (прошу прощения, никак не могу вспомнить подходящее русское слово) код, содержащий LoadLibrary/FreeLibrary где-либо, кроме файла с определением соответствующего класса.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Препроцессор C++ ругали все и всегда, если бы ты поизучал литературу, то знал бы от этом. А так, в любом языке есть куча возможностей как прострелить себе ногу.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Отчего же? Можно поставить триггер на VCS, запрещающий "случайно" submit (прошу прощения, никак не могу вспомнить подходящее русское слово) код, содержащий LoadLibrary/FreeLibrary где-либо, кроме файла с определением соответствующего класса.
Придерусь к техническ4им моментам — ИМХО запрещать коммит на основании каких то правил не есть верная мысль. Мы это в свое время уже проходили — создает массу проблем разработчикам. VCS должна решать только свою задачу, а именно контроль версий. Все остальное должно работать параллельно. Т.е. в данном случае правильным было бы запускать проверку после коммита, а по ее результатам присваивать статус проверенной ревизии.
AndrewVK,
> ПК>Отчего же? Можно поставить триггер на VCS, запрещающий "случайно" submit (прошу прощения, никак не могу вспомнить подходящее русское слово) код, содержащий LoadLibrary/FreeLibrary где-либо, кроме файла с определением соответствующего класса.
> Придерусь к техническ4им моментам — ИМХО запрещать коммит на основании каких то правил не есть верная мысль.
Не запрещать, а напоминать о правилах (см. выделенное выше и ниже). Т.е. запрещать делать подобное неявно. В случае, если разработчик настаивает (включил соответствующую опцию при submit), то разрешается, но, как ты написал ниже, ревизии присваивается соответствующий статус. Точно такой же подход принят в Team System.
> Мы это в свое время уже проходили — создает массу проблем разработчикам. VCS должна решать только свою задачу, а именно контроль версий. Все остальное должно работать параллельно. Т.е. в данном случае правильным было бы запускать проверку после коммита, а по ее результатам присваивать статус проверенной ревизии.
ОК. Давай называть SCM system, а не VCS. Так легче? Должна/не должна, правильно/неправильно -- это вопросы открытые, и в такой постановке мне мало интересные, а вот если в Perforce включены некоторые триггеры, хоть как-то проверяющие корректность файлов being submitted, жить становится заметно легче всем, кто потом эти файлы оттуда получает.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Joker6413, Вы писали:
J>Препроцессор C++ ругали все и всегда, если бы ты поизучал литературу, то знал бы от этом.
Воспринимаю фразу "если бы ты поизучал литературу, то знал бы от этом" как хмаство и дешовые понты.
J>А так, в любом языке есть куча возможностей как прострелить себе ногу.
Ага. И качество языка оределеяется их количеством. Надо отсылать к литературе по вопросу количества граблей в С++?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Не запрещать, а напоминать о правилах (см. выделенное выше и ниже).Т.е. запрещать делать подобное неявно.
Все равно нельзя. Явно, не явно — процесс коммита и так штука непростая, чтобы перегружать ее дополнительными сложностями.
ПК> В случае, если разработчик настаивает (включил соответствующую опцию при submit), то разрешается,
Разработчик почти наверняка включит такую опцию.
ПК> но, как ты написал ниже, ревизии присваивается соответствующий статус. Точно такой же подход принят в Team System.
В TS именно что есть несколько разновидностей статуса ревизии.
ПК>ОК. Давай называть SCM system, а не VCS. Так легче?
Дело не в названии, дело в том чтобы одно не ешало другому.
ПК> Должна/не должна, правильно/неправильно -- это вопросы открытые, и в такой постановке мне мало интересные, а вот если в Perforce включены некоторые триггеры, хоть как-то проверяющие корректность файлов being submitted, жить становится заметно легче всем, кто потом эти файлы оттуда получает.
Не знаю — у нас была ситуация обратная. Когда на коммит были завязаны всякие танцы с бубнами, процедура превращалась в долгий и нудный процесс. В результате коммитили чуть ли не раз в неделю, когда был полностью завершен очередной этап.
... << RSDN@Home 1.2.0 alpha rev. 619 on Windows XP 5.1.2600.131072>>
Здравствуйте, VladD2, Вы писали:
VD>BinaryReader же позоляет читать память как душе угодно, но при этом не заниматься реинтерпретацией типов и не допуская порчи памяти к которой может привести реинтерпетация. Погляди BinaryReader Рефлектором или в Роторе.
Откровенно говоря, выглядит грустно:
public virtual int ReadInt32()
{
if (this.m_isMemoryStream)
{
MemoryStream stream1 = this.m_stream as MemoryStream;
return stream1.InternalReadInt32();
}
this.FillBuffer(4);
return (((this.m_buffer[0] | (this.m_buffer[1] << 8)) | (this.m_buffer[2] << 0x10)) | (this.m_buffer[3] << 0x18));
}
Для чтения больших объемов, пожалуй, непригодно.
Разве только JIT способен понять, о чем речь и превратить это все в ту же реинтерпретацию памяти, что вызывает сомнения.
Здравствуйте, Schade, Вы писали:
S>Для чтения больших объемов, пожалуй, непригодно.
А ты попробуй.
S>Разве только JIT способен понять, о чем речь и превратить это все в ту же реинтерпретацию памяти, что вызывает сомнения.
То, что делает (или может деть) JIT и рантейм — это оптимизации которые никак не могут повлиять на устойчивость программы, так как делаются они после всех необходимых проверок корректности и безопасности.
Правда, я думаю, что на данном этапе развития упрвляемых рантаймов такие мощьные оптимизации еще не доступны. Однако они несомненно станут доступны в будущем. Да и на сегодня скорость очень и очень приличная.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Отчего же? Можно поставить триггер на VCS, запрещающий "случайно" submit (прошу прощения, никак не могу вспомнить подходящее русское слово) код, содержащий LoadLibrary/FreeLibrary где-либо, кроме файла с определением соответствующего класса.
Ничего из этого путного не выйдет. Потому как LoadLibrary может вызываться из какой-нибудь другой DLL, третьей фирмы или же даже от MS. Представь себе, что она уже вызвана, а я еще в классе загрузку ни разу не делал. Я считаю, что ее нет, реально она есть...
Здравствуйте, pvgoran, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Что меня огорчает — фанатическая нетерпимость некоторых к другому мнению. В общем, увы, советское воспитание легко не исчезает.
P>Я бы попросил Вас воздерживаться от подобных высказываний. Ибо оскорбительно/некультурно...
OK, готов воздержаться. Насчет некультурнсти, правда, не согласен, а если это ты считаешь оскорбительным — извини.
Pavel Dvorkin,
> ПК> Отчего же? Можно поставить триггер на VCS, запрещающий "случайно" submit (прошу прощения, никак не могу вспомнить подходящее русское слово) код, содержащий LoadLibrary/FreeLibrary где-либо, кроме файла с определением соответствующего класса.
> Ничего из этого путного не выйдет. Потому как LoadLibrary может вызываться из какой-нибудь другой DLL, третьей фирмы или же даже от MS. Представь себе, что она уже вызвана, а я еще в классе загрузку ни разу не делал. Я считаю, что ее нет, реально она есть...
Я не понимаю, в чем, собственно, проблема? Классы-обертки предназначены для того, чтобы было легче писать корректный код. Как и прочие средства, они не гарантируют корректность вашего кода, и уж подавно не могут обеспечить правильность кода чужого.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Я не понимаю, в чем, собственно, проблема? Классы-обертки предназначены для того, чтобы было легче писать корректный код. Как и прочие средства, они не гарантируют корректность вашего кода, и уж подавно не могут обеспечить правильность кода чужого.
Да никакой проблемы и нет вовсе. Просто ИМХО класс-обертка должна управлять тем объектом, который она оборачивает. Например, класс string полностью управляет своим ASCIIZ буфером — изменить его состояние помимо интерфейса класса нельзя. здесь же объект может изменять свое состояние помимо этого класса. Вот и все, что я хотел сказать.
IsLoaded может лишь ответить на вопрос — было ли количество Load для данного модуля больше, чем Unload. На вопрос : есть ли модуль в моем адресном простанстве или нет — IsLoaded корректно ответить не может.
Pavel Dvorkin,
> ПК> Я не понимаю, в чем, собственно, проблема? Классы-обертки предназначены для того, чтобы было легче писать корректный код. Как и прочие средства, они не гарантируют корректность вашего кода, и уж подавно не могут обеспечить правильность кода чужого.
> Да никакой проблемы и нет вовсе. Просто ИМХО класс-обертка должна управлять тем объектом, который она оборачивает.
Смотря, что понимать под "управлять". Если речь идет о гарантиях неизменности объекта мимо интерфейса класса-обертки, то я не вижу, откуда это следует, почему это должно быть так. Более того, обычно для объектов, "управляющих" внешними по отношению к программе сущностями, это не так: файлы, сокеты, соединения с базами данных и т.п.
> Например, класс string полностью управляет своим ASCIIZ буфером — изменить его состояние помимо интерфейса класса нельзя. здесь же объект может изменять свое состояние помимо этого класса. Вот и все, что я хотел сказать.
Почему состояние "управляемого" объекта отождествляется с состоянием объекта класса-обертки? А содержимое файла является состоянием объекта, представляющего файл с точки зрения программы? Имхо, ответ отрицательный в обоих случаях.
> class CModule{ > public: > BOOL Load(...) {...} > BOOL Unload(...) {...} > BOOL IsLoaded(...) {...} > }; > > IsLoaded может лишь ответить на вопрос — было ли количество Load для данного модуля больше, чем Unload. На вопрос : есть ли модуль в моем адресном простанстве или нет — IsLoaded корректно ответить не может.
А почему он должен отвечать на этот вопрос? Может, это означает, что функция с подобной семантикой лишняя в интерфейсе данного класса?
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Смотря, что понимать под "управлять". Если речь идет о гарантиях неизменности объекта мимо интерфейса класса-обертки, то я не вижу, откуда это следует, почему это должно быть так. Более того, обычно для объектов, "управляющих" внешними по отношению к программе сущностями, это не так: файлы, сокеты, соединения с базами данных и т.п.
ПК>А почему он должен отвечать на этот вопрос? Может, это означает, что функция с подобной семантикой лишняя в интерфейсе данного класса?
Я думаю, дискууссию стоит прекратить. Я вполне согласен с твоей точкой зрения — в рамках твоей парадигмы ты совершенно прав. В рамках иной парадигмы (полный контроль) — ИМХО прав я. Вопрос, таким образом, сводится к тому, какая парадигма правильная . А это от задачи зависит.
, список героев, принимающих активнейщее участие в ристалище столь общирен, что я не упомянул весьма многих из достойнейших, ограничившись лишь теми, с кем вёл благочестивые беседы совсем недавно... 
Если нам не помогут, то мы тоже никого не пощадим.
).
"Всё что не убивает нас, делает нас сильнее..."
1.1.4 stable rev. 510
.
