Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Я не требую от тебя формального доказательства. Только прошу логичной аргументации чем-нибудь кроме твоих впечатлений.
Для тебя логичной аргументацией является аргументация восхволяющая С++. А остальную ты всеми силами пыташся невилировать.
Даже очевидные недостактки С++ и его спецификации ты или не видишь, или оправдываешь, или пытаешся осмеять/невилировать (в том числе и поптыками опустить мнение оппонента).
В такой ситуации любые мои слова для тебя не будут являться аргументами.
Мне вот непонятно другое. Когда оберонщики используют С++ в качестве некого эталона багоглючности ты полчишь себе в тряпочку, когда я краем задеваю С++, ты докапывашся до первого попвшегося слова (мало относящегося к делу) и развивашь эту тему во вселенский флэйм. Что является причиной этому?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ну стандарт C# от стандарта CLI зависит совершенно явным образом, поэтому тут отказываться не от чего.
Только лишь тем, что описание базовых бублиотек чтобы не дублировать вынесли в отдельную спецификацию. Они ксатит, тоже на Шарпе описаны.
>> и соглсен, что и C#, и C++ могут быть реализованы отдельно без привязыки к разным там реализациям CLI?
ПК>А вот здесь еще не знаю.
Ну, так ты решил свои затруднения?
ПК> Сначала был в этом уверен, теперь — нет.
Уже приятно.
ПК> Разбираюсь.
Ну, и как?
ПК> По крайней мере, часть библиотек, описанных в стандарте CLI, C#, в отличие от C++, требует.
И? Это непреодалимая проблема?
ПК> Это факт.
О... Таких фактов можно надыбать много. Например, C# создал МС. Тоже фак. Какя связь? А какая там связь?
ПК> Осталось разобраться, требуется ли этой части библиотек что-то собственно от платформы, или же это только спецификация относительно небольшого набора интерфейсов.
Разберись. А до тех пор не нужно делать предположений и высказывать мнений. Ты же веть так этого не любишь.
ПК>Сегодня обходит, завтра, может, не будет обходить. Поживем — увидим. Если модули появятся — просто супер, но и без них вполне жить можно.
А можно жить и без С++. По крайней мере во многих областях. И если они и дальше "будут обходить", то объходить начут С++. В прочем уже начинают обходить.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Я не вижу ни одной причины использовать С на данный момент. Крупные системы на С — это те, которые относительно давно ведут свой отчет.
Гы. Вот там и используется. А причины банальны. С — это элементарнийший язык. Транслятор для него можно написать на ассемблере за довольно короткий строк (темболее, что для этого достаточно заменить бэкэнд). И этого языка достаточно для системной части.
V>Для маленьких встраиваемых систем сейчас сущестует EC++, где убрали множественное наследование, динамик каст и т.д.
Ну, посчитай сколько ОС и драйверов написано на нем, а сколько на С.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Как в стандарте C, так и в стандарте C++ есть понятие байта. В соответствии со стандартами C и C++ байту соответствуют типы char, signed char, и unsigned char.
> Понятие не есть тип.
В C/C++ char — это и есть тип, обозначающий байт. Просто назван по-другому.
> Кстати, поискал по стандарту, но так и не нашел где определялся бы размер char/unsigned char. Что весма забавно.
5.3.3 Sizeof
The sizeof operator yields the number of bytes in the object representation of its operand. <...> sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1 <...>
> На С или ассемблере пишется микроядро <...>
Вот это и есть пример той задачи, для которой C#, в отличие от C или C++ не подходит, и о которых шла речь.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Шахтер, Вы писали:
VD>>Да не так же. И процессоры стали более стандартными.
Ш>В порядке самообразования. Зайди на сайты Texas Instruments и Motorola и скачай доки по их процам разных семейств. И почитай на досуге.
Да ты не стесняйся, приводи конкретные примеры современных микроконтроллеров, у которых байт не равен 8 битам.
Здравствуйте, VladD2, Вы писали:
V>>Я не вижу ни одной причины использовать С на данный момент. Крупные системы на С — это те, которые относительно давно ведут свой отчет.
VD>Гы. Вот там и используется. А причины банальны. С — это элементарнийший язык. Транслятор для него можно написать на ассемблере за довольно короткий строк (темболее, что для этого достаточно заменить бэкэнд). И этого языка достаточно для системной части.
Разве это причина? Причина в том, что эти системы начинались разрабатываться тогда, когда еще не было стандартов С++ и даже этого компилятора на многих аппаратных платформах.
V>>Для маленьких встраиваемых систем сейчас сущестует EC++, где убрали множественное наследование, динамик каст и т.д.
VD>Ну, посчитай сколько ОС и драйверов написано на нем, а сколько на С.
Windows уже давно пишут на С++. WinXP многие свои новые API вообще выдает как COM-объекты.
Дрова для видюх под винды, поддерживающие DirectX, тоже нереально писать без C++ (можно, но затрахаешься).
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
VD>>>Реально фиксация типов данных была сделана исходя из разных соображений. Одно из них было — упрощение восприятия программ людьми.
V>>еще пара таких высказываний и я буду собирать подписи за открытие храма Билла-Безвоздмездного в Севастополе
VD>Начинай. Типы зафиксировали еще в Яве. Не думаю, что он приложел к этому руку.
Не думаю, что причина та, которую ты озвучил.
VD>Это всего лишь демагогия.
Во-первых, порезал аргументы. Во-вторых — некрасиво аргументы игнориировать.
V>>Во-первых, моно чуствует себя немного хуже даже на Win32 платформе. Во вторых, я некорректно выразился. Я имел ввиду Intel32.
VD>Гы. Как раз Вынь32 был еще хот чем-то. А Intel32 совсем мимо кассы. Есть куча КПК на которых крутится дотнет. Ява вообще 70% мобильников захватила. Там Интелом и не пахнет. Ну, а 32... что-же похоже это самое разумное количество бит для процессора предназначенного в частное пользование.
V>>Где там ориентация на 64 бита?
VD>Ну, хотя бы она в том, что реально в бехопасном режиме без указания расположения полей ни кто не мешает разработчикам фрэймворка плевать на указанные велечины и делать int 64-битным.
ну и? какой вывод? что даже в unsafe-режиме есть возможность написать непереносимую программу.
VD>Кстати, в Вынь64 int вроде как остается 32-битным, так что с указателями прийдется повозиться. Весь Вынь-ориентированный С++-ный код прийдется серьезно проверить, так как проблем в нем может оказаться не мало.
там, где используется API так, как описано в h-заголовках — никаких проблем. В VC++ 7.x есть опция — выдавать варниги несовместимости для 64-битных платформ. Так все уже давно компилят свои программы с этой опцией и проблем пока нет. (Проблемы могут быть там, где есть явные преобразования типов в духе С (SomeType*)&someVar. Но тут компилятор просто умывает руки, мол, пишешь в духе С — значит и задача твоя соответствующая).
VD>А вот код на Шарпе гарантированно будет работать. И при наличии хорошо оптимизированной VM будет работать очень шустро.
Мне с последним утверждением спорить?
V>> все коллекции имеют индекс типа int. Да и вообще, int — наиболее употребимый тип (он же System.Int32).
VD>Ни одна коллекция не сможет вместить в себя и 2 миллиарда объектов, так как их алгоритмы просто на это не рассчитаны. Массивы же имеют 64-битную индексацию (погляди класс Array там есть как 32-х, так и 64-битные методы). Можеш даже провести эксперемент. Создай вот такой код:
Какая разница, во что он компилит, если внешний интерфейс на Int32?
Если я захочу разреженный массив сделать с 64-битным индексом (раз платформа позволяет, а у меня сложное математическое моделирование на мэйн-фрейме), то не смогу воспользоваться стандартными интерфейсами: ICollection, IList.
VD>В общем, дотнет построен по принципу ты пишешь программу, а она работает на любой платформе.
Мне и с этим спорить?
Яву именно для этого двигали, т.е. для экстенсивного расширения сфер влияния фирм-инициаторов.
VD>Ты как бы пишешь нужную тебе программу, а CLR обеспечивает оптимальное исполнение на заданной платформе. Программа не становится другой на 64-битной платформе. Она просто получает возможность создать больше объектов (если больше памяти есть) и более эффективно работать с 64-битными числами. В общем, подход заточеный на максимальную переносимость того что есть, а не на масимальную но гипотетическую возможность оптимизации. Всю оптимизацию берет на себя фрэймворк.
Ты — идеальный потребитель с т.з. финансовой позиции Microsoft. Успехов!
Здравствуйте, VladD2, Вы писали:
V>>В 1.0 и 1.1 имплементация интерфейсов — вообще полные мраки... туши свет, кидай гранату. VD>(в плане мозолей на пальцах)
VD>Вообще-то в VS2003 — это можно сделать автоматически.
автоматически он создаст заголовки этих ф-ий, от этого не легче.
Здравствуйте, vdimas, Вы писали:
VD>>Вообще-то в VS2003 — это можно сделать автоматически. V>автоматически он создаст заголовки этих ф-ий, от этого не легче.
А тебе чего надо? Если нужна реализация, то для этого есть абстрактные классы, ибо нефиг заниматься копипейстом.
Здравствуйте, Шахтер, Вы писали:
Ш>В порядке самообразования. Зайди на сайты Texas Instruments и Motorola и скачай доки по их процам разных семейств. И почитай на досуге.
Это не те ли где сейчас Ява крутится?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, vdimas, Вы писали:
VD>>>Вообще-то в VS2003 — это можно сделать автоматически. V>>автоматически он создаст заголовки этих ф-ий, от этого не легче.
AVK>А тебе чего надо? Если нужна реализация, то для этого есть абстрактные классы, ибо нефиг заниматься копипейстом.
ибо если к уже имеющемуся классу захочу подмешать интерфейс — обломаюсь.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Шахтер, Вы писали:
VD>>>Да не так же. И процессоры стали более стандартными.
Ш>>В порядке самообразования. Зайди на сайты Texas Instruments и Motorola и скачай доки по их процам разных семейств. И почитай на досуге.
AVK>Да ты не стесняйся, приводи конкретные примеры современных микроконтроллеров, у которых байт не равен 8 битам.
Здравствуйте, Шахтер, Вы писали:
AVK>>Да ты не стесняйся, приводи конкретные примеры современных микроконтроллеров, у которых байт не равен 8 битам.
Ш>Вы хочете байтов? Их есть у меня. ;)
Здравствуйте, vdimas, Вы писали:
V>Разве это причина?
Ага.
V> Причина в том, что эти системы начинались разрабатываться тогда, когда еще не было стандартов С++ и даже этого компилятора на многих аппаратных платформах.
А это нет. Темболее что NT и Линукс разрабатывались в начале 90-ых. С++ тогда уже был.
V>Windows уже давно пишут на С++.
Никгда системные части Виндов не писались на С++. Погляди примеры к DDK и т.е.
V>WinXP многие свои новые API вообще выдает как COM-объекты.
Одно другому не мешает.
V>Дрова для видюх под винды, поддерживающие DirectX, тоже нереально писать без C++ (можно, но затрахаешься).
Не вижу связи. DirectX работает поверх дров с С-ишным АПИ.
В общем, погляди тут рядом есть рассуждения как раз тех кто проффесионально пишет дрова. У них вообще вопрос "зачем нужен С++?" встает.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
VD>>Вообще-то в VS2003 — это можно сделать автоматически. V>автоматически он создаст заголовки этих ф-ий, от этого не легче.
Вообще-то от этого значительно легче (с точки зрения мазолей).
Ну, а радикальное уменьшение мазолей можно найти здесь
Здравствуйте, AndrewVK, Вы писали:
AVK>А тебе чего надо? Если нужна реализация, то для этого есть абстрактные классы, ибо нефиг заниматься копипейстом.
Известно чего. Множественного наследования или микс-инов.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Множественного наследования или микс-инов.