Здравствуйте, Павел Кузнецов, Вы писали:

ПК>VladD2,

>> Стандат Шарпа проработан куда лучше, но размер он имеет даже меньший.

ПК>А каков твой критерий качества проработки стандарта?

Ходил сейчас на сайт ANSI, прикупить новую версию стандарта. Так вот, С++ стандарт -- в числе бестселлеров.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>В самом деле, если размер машинного слова не ложится на размеры целых типов CLI, то очевидно, что работа с целыми в C# не будет прямой работой с платформой.

Можно узнать про эти платформы и эти типы?
Напомню, в Шарпе есть: byte (1 байта), short (2), int (4), long (8). Можно узнать о типах C/C++ которые не покрываются этими виличинами.

ПК> И подобный выбор очень хорошо иллюстрирует то, что C#, в отличие от C++, и близко не предназначен для замены использования C или, тем более, ассемблера.

Без обоснования первого утверждения, для меня все эти слова выглядят, как попытка притянуть "аргументы" за уши.

ПК>Я не утверждаю, что это плохо. Просто это демонстрирует разницу в целях, которые ставили перед собой разработчики C# и C++.

А я утверждаю, что введение зависимости между машинным словом и размером int-а была сделана в целях оптимизации, что никак не относится к переносимости, и на сегодня (учитывая интеллект компиляторов) не актуально.

Здравствуйте, VladD2, Вы писали:
VD>Можно узнать про эти платформы и эти типы?
VD>Напомню, в Шарпе есть: byte (1 байта), short (2), int (4), long (8). Можно узнать о типах C/C++ которые не покрываются этими виличинами.
PDP-10: 36-битное слово и 72-битное двойное слово.

VladD2,

> ПК>В самом деле, если размер машинного слова не ложится на размеры целых типов CLI, то очевидно, что работа с целыми в C# не будет прямой работой с платформой.

> Можно узнать про эти платформы и эти типы?
> Напомню, в Шарпе есть: byte (1 байта), short (2), int (4), long (8).

Важно уточнить, что при этом размер байта в C# фиксирован, и равен 8 битам. В C/C++ такого ограничения нет.

> Можно узнать о типах C/C++ которые не покрываются этими виличинами.

Сюда не впишутся платформы, имеющие машинное слово, не являющееся степенью двойки, например 36 или 30 бит. Где-то до конца восьмидесятых подобные компьютеры еще были в производстве. А использование на них C актуально и до сих пор.

> ПК> Я не утверждаю, что это плохо. Просто это демонстрирует разницу в целях, которые ставили перед собой разработчики C# и C++.

> А я утверждаю, что введение зависимости между машинным словом и размером int-а была сделана в целях оптимизации, что никак не относится к переносимости

Фактически, С "родился" среди компьютеров с разным размером машинного слова и разным размером байта; поэтому не удивительно, что в книгах "отцов-основателей" вполне можно встретить упоминание этих моментов:

C has four fundamental types of variables:
int integer (PDP-11: 16 bits; H6070: 36 bits; IBM360: 32 bits)
char one byte character (PDP-11, IBM360: 8 bits; H6070: 9 bits)
float single-precision floating point
double double-precision floating point

Для ревизии C эти моменты были актуальны и в 1999:

Other architectures have different word sizes, such as 36 and 60 bit; for these implementations, types using multiples of word sizes, such as 72-bit and 60-bit integers, are appropriate.

Также это видно и по дизайну "фиксированных целых" — новый стандарт C99 не требует от платформы их наличия.

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

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

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

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

ГВ>>>Не, дело не в этом. Дело в том, что публично высказанное ошибочное мнение, оставленное без соответствующих contra может принести кому-то вполне реальный вред. Мне например. И кстати, это одна из причин, по которой я, например, тусуюсь на этом форуме.
V>>Да, да!!! Я тоже здесь тусуюсь в ожидании получения вполне реального вреда!
V>>Пока получается с точностью до наоборот... не везет, короче...

ГВ>Дима, спасибо за поправку. Естественно, я тусуюсь тут того, чтобы не допустить такого вреда.

Спасиб за компанию!

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

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

что-то ты все ставишь с ног на голову, меняешь причину и следсвие.

для обеспечения переносимости м/у платформами пришлось зафиксировать представление базовых типов.

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

----
чуство нелепости этого спора не покидает, скорее обостряется

----
типы CLI зафиксированы так, чтобы дать наибольший выигрыш на Win32 платформе. Посмотрим сравнение быстродействия С++ и дотнета на остальных платформах. Дотнет же ради переносимости разработан, вполне корректно будет сравнивать результаты именно на разных платформах.

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

ГВ>>Дима, спасибо за поправку. Естественно, я тусуюсь тут того, чтобы не допустить такого вреда.
V>Спасиб за компанию!
Хм. Кстати, хорошая мысль. Как насчёт субботы?

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

ГВ>>>Дима, спасибо за поправку. Естественно, я тусуюсь тут того, чтобы не допустить такого вреда.
V>>Спасиб за компанию!
ГВ>Хм. Кстати, хорошая мысль. Как насчёт субботы?

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

S>PDP-10: 36-битное слово и 72-битное двойное слово.

С писался на 32-битных машинах. Но это не важно.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Важно уточнить, что при этом размер байта в C# фиксирован, и равен 8 битам. В C/C++ такого ограничения нет.

C/C вообще нет типа byte. Ну, да не в том дело.

ПК>И дело тут вовсе не в оптимизации, а в самом предназначении языка для системного программирования, каковое вряд ли можно представить без наличия типа, непосредственно соответствущего машинному слову, равно как и типа, представляющего минимально адресуемую единицу памяти.

Да, можно представить. Особенно на сегодня. Для языка уже не так вазно машинное слово. Операции с адресацией все больше и больше уводятся из самого языка ("за кулисы"), а те редкие случае которые действительно нужны можно оформить в виде платформно-зависимых библиотек.

Да и само системное программирование — это отдельный и довольно узких участок деятельности. С++ же обычно применяется для совсем не системных областей. И в этих областях его небезопасность базовых концепций служит весма плохую службу.

Ну, а там где от С есть толк этот езяк еще долго будет использоваться. Возможно даже совместно с новыми более надежными и простыми в испльзовании средствами.

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

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

V>что-то ты все ставишь с ног на голову, меняешь причину и следсвие.

V>для обеспечения переносимости м/у платформами пришлось зафиксировать представление базовых типов.

Я ничего никуда не ставлю. Можно сказать и так. Но это только одна из предпосылок к подобному решению. Реально фиксация типов данных была сделана исходя из разных соображений. Одно из них было — упрощение восприятия программ людьми.

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

Это демагогия. И не надо говорить, что она аналогична моим словам.

V>типы CLI зафиксированы так, чтобы дать наибольший выигрыш на Win32 платформе.

Ничем не обоснованное утверждение. Более того дотнет проектировался с прицелом как на 64-разнядные системы, так и на другие платформы. На том же Линуксе Моно себя чувствует ни чем не хуже.

V> Посмотрим сравнение быстродействия С++ и дотнета на остальных платформах. Дотнет же ради переносимости разработан, вполне корректно будет сравнивать результаты именно на разных платформах.

Вот когда выйдут нормальные вируальные машины на 64-битные платформы тогда и глянем. А на линуксе у Моно такой же код. Так что и производительность отличатся не должна.

VladD2,

> ПК> Важно уточнить, что при этом размер байта в C# фиксирован, и равен 8 битам. В C/C++ такого ограничения нет.

> C/C вообще нет типа byte. Ну, да не в том дело.

Как в стандарте C, так и в стандарте C++ есть понятие байта. В соответствии со стандартами C и C++ байту соответствуют типы char, signed char, и unsigned char.

> ПК> И дело тут вовсе не в оптимизации, а в самом предназначении языка для системного программирования, каковое вряд ли можно представить без наличия типа, непосредственно соответствущего машинному слову, равно как и типа, представляющего минимально адресуемую единицу памяти.

> Да, можно представить. Особенно на сегодня. Для языка уже не так вазно машинное слово.

Для системного — все так же. Именно о слабой пригодности C# для этих целей и шла речь. Например, вряд ли получится использовать даже unsafe режим C# для реализации даже тех же целочисленных типов самого C# (Int32 и т.п.) на платформе, где машинное слово не является степенью двойки, а байт не равен 8.

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

VD>Реально фиксация типов данных была сделана исходя из разных соображений. Одно из них было — упрощение восприятия программ людьми.

еще пара таких высказываний и я буду собирать подписи за открытие храма Билла-Безвоздмездного в Севастополе

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

VD>Это демагогия. И не надо говорить, что она аналогична моим словам.

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


V>>типы CLI зафиксированы так, чтобы дать наибольший выигрыш на Win32 платформе.

VD>Ничем не обоснованное утверждение. Более того дотнет проектировался с прицелом как на 64-разнядные системы, так и на другие платформы. На том же Линуксе Моно себя чувствует ни чем не хуже.

Во-первых, моно чуствует себя немного хуже даже на Win32 платформе. Во вторых, я некорректно выразился. Я имел ввиду Intel32.

Где там ориентация на 64 бита? все коллекции имеют индекс типа int. Да и вообще, int — наиболее употребимый тип (он же System.Int32)

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

V>видел и .Net 2.0, однако отсутствие конструкции типа typedef делает невозможным примерно 70% шаблонного программирования (не могу в классе указать зависимый тип, т.е. все traits и стратегии — лесом). Отсутствие возможности отнаследоваться от параметра шаблона отнимает еще примерно 20% (имеплементация аспектов интерфейсов).

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

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

Вот чего точно нет в C# 2.0, так это основанного на шаблонах метапрограммирования. Но эту проблему как раз решит R# и другие средства АОП и метапрограммирования. Я уже сейчас делаю на R# вещи недоступные или крайне сложно реализуемые на С++. Например, вот пилотный вариант реализации паттерна Visitor на R#-е

Автор: VladD2
Дата: 16.11.04

.

V>В 1.0 и 1.1 имплементация интерфейсов — вообще полные мраки... туши свет, кидай гранату.
(в плане мозолей на пальцах)

Вообще-то в VS2003 — это можно сделать автоматически. А в VS2005 вообще смарт-тэг на имени интерфейса вылезает и можно сделать как явную, так и не явную реализацию.

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

VD>Ну, а там где от С есть толк этот езяк еще долго будет использоваться. Возможно даже совместно с новыми более надежными и простыми в испльзовании средствами.

Я не вижу ни одной причины использовать С на данный момент. Крупные системы на С — это те, которые относительно давно ведут свой отчет.

Для маленьких встраиваемых систем сейчас сущестует EC++, где убрали множественное наследование, динамик каст и т.д.

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

V>Насчет синтаксиса C# 2.0 вынужден согласиться, там наворочено много чего, возможно нужна КЗ-грамматика, я имел ввиду 1.0 — 1.1

Ну, слава богу, хоть так. Хотя бы частичное признание очевидных вещей отдельными личностями...

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

V>Я смотрел в роторе компилятор C#. Там они просто вмешиваются в работу компилятора и "вручную" обрабатывают некоторые из указанных конструкций, изымая их из входной последовательности разборщика. сам же разборщик более похож на реализацию КС грамматики.

О! Вот теперь я слышу разумные слова. Так оно и есть. Граматика Шарпа — это КСГ, но с набором исключений. Все эти исключения описаны в стандарте и предложены пути разрешения.

Точно так же приходится разрешать их и в парсере R#-а. Собственно я их и приводил.

ЗЫ

Кстати, не в курсе нет ли еще Ротора 2.0? Ну, на базе второго фрэймворка?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Как в стандарте C, так и в стандарте C++ есть понятие байта. В соответствии со стандартами C и C++ байту соответствуют типы char, signed char, и unsigned char.

Понятие не есть тип. Кстати, поискал по стандарту, но так и не нашел где определялся бы размер char/unsigned char. Что весма забавно.

ПК>Для системного — все так же.

Да не так же. И процессоры стали более стандартными. И понятие системности размылось. И акценты важности сместились. На сегодня зачастую бывает важнее факторы надежности и переносимости. А размеры типов они все же относятся именно к опримизации.

ПК> Именно о слабой пригодности C# для этих целей и шла речь. Например, вряд ли получится использовать даже unsafe режим C# для реализации даже тех же целочисленных типов самого C# (Int32 и т.п.) на платформе, где машинное слово не является степенью двойки, а байт не равен 8.

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

В общем, если речь идет о возможности написания ОС на управляемых средах, то это более чем возможно. Более того Ява-ОС уже была создана. И на Обероне (который в данном случае близок к Яве и дотнету) тоже ОС имеется.

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

ЗЫ

В общем, технически тут особых проблем не будет. Тут скорее вопрос целесобразности и вопрос традиций/имеющегося кода. Думаю, пройдет лет 10 и ОС состоящие на 90-99% из менеджед-кода станут повседневной реальностью.

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

VD>>Реально фиксация типов данных была сделана исходя из разных соображений. Одно из них было — упрощение восприятия программ людьми.

V>еще пара таких высказываний и я буду собирать подписи за открытие храма Билла-Безвоздмездного в Севастополе

Начинай. Типы зафиксировали еще в Яве. Не думаю, что он приложел к этому руку.

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

VD>>Это демагогия. И не надо говорить, что она аналогична моим словам.

V>Это прямое следсвие твоих рассуждений.

Это всего лишь демагогия.

V>Во-первых, моно чуствует себя немного хуже даже на Win32 платформе. Во вторых, я некорректно выразился. Я имел ввиду Intel32.

Гы. Как раз Вынь32 был еще хот чем-то. А Intel32 совсем мимо кассы. Есть куча КПК на которых крутится дотнет. Ява вообще 70% мобильников захватила. Там Интелом и не пахнет. Ну, а 32... что-же похоже это самое разумное количество бит для процессора предназначенного в частное пользование.

V>Где там ориентация на 64 бита?

Ну, хотя бы она в том, что реально в бехопасном режиме без указания расположения полей ни кто не мешает разработчикам фрэймворка плевать на указанные велечины и делать int 64-битным. Проверели, что код не работает на уровне битов и наплевали... Указатели уже автоматичски становятся 64-битными. Так что проблем просто-таки никаких.

Кстати, в Вынь64 int вроде как остается 32-битным, так что с указателями прийдется повозиться. Весь Вынь-ориентированный С++-ный код прийдется серьезно проверить, так как проблем в нем может оказаться не мало. А вот код на Шарпе гарантированно будет работать. И при наличии хорошо оптимизированной VM будет работать очень шустро.

V> все коллекции имеют индекс типа int. Да и вообще, int — наиболее употребимый тип (он же System.Int32).

Ни одна коллекция не сможет вместить в себя и 2 миллиарда объектов, так как их алгоритмы просто на это не рассчитаны. Массивы же имеют 64-битную индексацию (погляди класс Array там есть как 32-х, так и 64-битные методы). Можеш даже провести эксперемент. Создай вот такой код:

    class Program
    {
        static void Main(string[] args)
        {
            long i = 123;
            byte[] a = new byte[i];
        }
    }

Скомпилируй его. И дезасемблируй. Получишь нечто вроде:

.method private hidebysig static void Main(string[] args) cil managed
{
      .entrypoint
      // Code Size: 13 byte(s)
      .maxstack 1
      .locals (
            int64 num1,
            unsigned int8[] buffer1)
      L_0000: ldc.i4.s 123
      L_0002: conv.i8 
      L_0003: stloc.0 
      L_0004: ldloc.0 
      L_0005: conv.ovf.i 
      L_0006: newarr unsigned int8
      L_000b: stloc.1 
      L_000c: ret 
}

Главная инструкция здесь выделена жирным. Она конвертирует лезащее на вершине стека числов в так называемый "natural int". Это нечто аралогичное int в С. Таким образом если мы будет работать на 64-битной платформе, то будет роизведена попытка конвертации к int64, а на 32-битной соотвественно в int32.

В общем, дотнет построен по принципу ты пишешь программу, а она работает на любой платформе. Ты как бы пишешь нужную тебе программу, а CLR обеспечивает оптимальное исполнение на заданной платформе. Программа не становится другой на 64-битной платформе. Она просто получает возможность создать больше объектов (если больше памяти есть) и более эффективно работать с 64-битными числами. В общем, подход заточеный на максимальную переносимость того что есть, а не на масимальную но гипотетическую возможность оптимизации. Всю оптимизацию берет на себя фрэймворк.