Здравствуйте, 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 совсем недавно снята с производства. И до того они ее
зачем-то исправно поддерживали, и даже имели небольшой круг вполне
лояльных пользователей...
