AndrewVK,

> ПК> Дык, я большой фанат жесткой статической типизации...
>
> А я большой фанат компонентных сред. А там один черт статикой ничего не разрулишь.

В этом и разница. Мне компонентность сама по себе нужна мало.

>>> А насчет эквивалентным встроенным я не понял.

> ПК>Ну, в C++ легко можно клепать типы, с точки зрения языка почти такие же, как int. В том числе, работающие с такой же эффективностью.

> Типы, не поддерживаемые процессором не могут работать с такой же эффективностью, как поддерживаемые. В остальном же не знаю чем в этом плане C# отличается.

Пример:

class my_int : arithmetic< my_int, totally_ordered< my_int > >
{
public:
   my_int& operator +=( my_int );
   my_int& operator -=( my_int );
   my_int& operator *=( my_int );
   my_int& operator /=( my_int );

   bool operator ==( my_int ) const;
   bool operator < ( my_int ) const;
   bool operator > ( my_int ) const;

private:
   int value;
};

Наследуясь от arithmetic и totally_ordered я получаю все остальные арифметические операторы и операторы сравнения. На C++ приведенный my_int будет работать +- с эффективностью int.

Если я правильно понимаю, в C#, для реализации value-классов, вроде того, что выше, придется заниматься copy-paste вместо повторного использования.

> ПК> Для этого все есть: и наследование "value" классов,

> Во встроенных типах где то используется наследование? Забавно было бы поглядеть как ты от int отнаследуешься.

Нет, от int не отнаследуешься. А вот от my_int, что выше — запросто.

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

> А там все есть. Свободные функции там не нужны, поскольку нет свободных типов.

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

Пример: тебе нужно записывать один библиотечный класс в поток, определенный в другой библиотеке; ни один из классов модифицировать, естественно, нельзя. Достаточно написать что-нибудь вроде:

std::ostream& operator <<( std::ostream&, OtherClass const& );

Что характерно, решения типа создания какого-нибудь класса с соответствующей статической функцией не подходят, т.к. в этом случае для твоего класса не будет работать значительное количество используемых тобой везде шаблонов, которые понятия не имеют о новом классе, зато прекрасно знают, что класс в поток выводится при помощи operator <<.

> Для чего шаблоны для встроенных типов вобще неясно.

Это ты, вероятно, математику не пытался делать. Скажем, если у тебя есть шаблон Vector3, параметризуемый типом элемента, то в разных случаях тебе достаточно просто параметризовать его типами int, float, double или my_int, my_rational, my_big_number и т.п. Иначе придется заниматься copy-paste. То же самое с многочисленными функциями, коих в математике нужно много, и далеко не все из них предоставляются языком/стандартной библиотекой.

Это просто пример, естественно есть много других use cases.

> Единственное что нужно от языка — перегрузка операторов, а это в шарпе есть.

Мне — не единственное. Если бы мне было нужно только это, я бы к C# относился заметно положительнее.

Дарней,

> A> А выдели все это барахло в отдельный подраздел, что-то вроде extern "C Compat" <...>

> Собственно, это все уже есть. Называются эти ветки C# и MC++

MC++... Ты много знаешь удачных примеров использования MC++? К тому же, он уже deprecated, не успев как следует распространиться. Если ты о C++/CLI, то это тоже не совсем так: это одноплатформенные расширения C++.

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

> за отсутствие нормального const надо просто руки дизайнерам рубить

И этого тоже.

> Но, в любом случае — начало положено.

Влияние C++ несомненно, впрочем, как и некоторых других языков, но вот утверждать, что это является развитием C++ явно неверно. Это начало совсем другому языку, со своими, другими, чем в C++, идиомами.

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

AVK>А где там проблема?

Стандартизовать протокол я не собираюсь, более того, в ближайшее время все измениться.

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

VD>>Ну, надо же с жадностью боросться?
S>А идея, надеюсь, подход не запетентован?
Есть способ кардинальнее.
При выпуске второго сервиспака для XP, помимо включения туда dotnetfx-а, мелкософту нужно было просто захардкодить в кернел ограничение, чтобы ось не стартовала на машинах c <= 1000 мегов оперативки!

Эх, жаль в свое время не догадался продать MS-овцам эту мысль...
Впрочем, вероятно ещё не всё потеряно...

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

AVK>>А где там проблема?
Т>

Стандартизовать протокол я не собираюсь, более того, в ближайшее время все измениться.

Ну так ты на дату сообщения смотри — это стадия преальфы. Говорить что то о стандартах тогда было просто рано. Де-факто протокол практически не изменился. Так что это не мешает.

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

AVK>>Интересно, что ж это за софт такой? Как называется? Если это коробка, то никаких причин скрывать его название я не вижу.
S>Софт разрабатывается, оффициального названия нет, есть кодовое "платформа". Мой работодатель не позволяет мне раскрывать больше информации.

Здорово. Софта нет, клиентов нет, но далеко идущие выводы мы уже сделали. Эдак я тоже из пальца высосать могу — мы вот платформу выкатили и ни один клиент на системные требования не пожаловался.

AVK>>МС уже выпустил достаточно софта на дотнете.
S>Второй круг. Вроде уже обсуждали? Я имел ввиду настольный софт, не бизнес. Ворд/Фотошоп/Браузер и т.д. Ничего этого нет.

Мало ли что ты имел ввиду. Самый дорогой софт — серверный. А все остальное подтянется по необходимости.

AVK>>Как же так — контора, выпускающая коробочный ERP (!!!), а ты на такой дохлой тачке работал.
S>Это было ДОМА. А ДОМА у меня ДВА компа и ОДИН ноутбук. Просто один из компов был п3 800. Который я специально не модернизировал, чтобы использовать как тест стенд в своих ЛИЧНЫХ разработках. Остальные компьютеры у меня с пнями4 и гигами оперативки, уверяю

А, ну то есть ты янус специально запускал на самом дохлом компе. Месье мазохист?

S>Я не буду спорить. У нас erp идёт с несколькими уникальными фичами, которые очень напрягают аппаратуру. Если их делать на C#, то они вообще сдохнут.

И что это за уникальные фичи ты конечно не скажешь

AVK>>А ты так и не ответил.
S>Ну хорошо, делаем платформу управление предприятием, да не простую, а золотую. Из-за ряда уникальных фич она сильно напрягает компы, так что от C++ не убежишь.

Мы вот тоже таку платформу делаем. И вот что удивительно — все упирается в БД, а не в процессор. Хотя фич уникальных у нас предостаточно.

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

AVK>>От чего?
S>Да так, от того. Не вериться, что двух лет не хватило, чтоб хоть аутлук перенести на net.

А его никто пока не переносил.

AVK>>Оно и заметно.
S>Если честно, мне C# очень даже импонирует,

Не верю .

S> на нём классно быстро писать компоненты под win, какие-то программы. Хороший язык, но в данный момент я его не могу применять. Вот JIT улучшат, вот тогда посмотрим.

Для ERP качество JIT на данный момент более чем, ты уж поверь человеку, этой самой ERP уж 10 лет занимающемся.

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

AVK>Самый дорогой софт — серверный.

Самый дорогой или самый прибыльный?

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

AVK>Здорово. Софта нет, клиентов нет, но далеко идущие выводы мы уже сделали. Эдак я тоже из пальца высосать могу — мы вот платформу выкатили и ни один клиент на системные требования не пожаловался.
Слушай, не делай сам далеко идущих выводов. У меня есть опыт.

AVK>Мало ли что ты имел ввиду. Самый дорогой софт — серверный. А все остальное подтянется по необходимости.
А чо за отмазки ей богу. Ну хорошо, где сервеная ОС на .Net, где базы данных? Что-то не видно на горизонте...

AVK>А, ну то есть ты янус специально запускал на самом дохлом компе. Месье мазохист?
Ну что за десткие придирки ей богу?

AVK>И что это за уникальные фичи ты конечно не скажешь
Конечно.

AVK>Мы вот тоже таку платформу делаем. И вот что удивительно — все упирается в БД, а не в процессор. Хотя фич уникальных у нас предостаточно.
Ну и какие? Раз выкатили, напиши, по сайту ничего отличающего ваш продукт от других на рынке я не нашел, даже последнюю версию скачал, заценить.

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

AVK>А его никто пока не переносил.
Не понял, а что так?

AVK>Не верю .
Вот класс, человеку говоришь, а в его воспаленном мозгу всё равно одна мысля бегает: "кругом враги!".

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

AVK>>Здорово. Софта нет, клиентов нет, но далеко идущие выводы мы уже сделали. Эдак я тоже из пальца высосать могу — мы вот платформу выкатили и ни один клиент на системные требования не пожаловался.
S>Слушай, не делай сам далеко идущих выводов. У меня есть опыт.

У меня тоже. Только я, в отличие от тебя, аргументами, которые невозможно проверить не пользуюсь.

AVK>>Мало ли что ты имел ввиду. Самый дорогой софт — серверный. А все остальное подтянется по необходимости.
S>А чо за отмазки ей богу. Ну хорошо, где сервеная ОС на .Net, где базы данных?

Эти вещи за 2 года не пишутся.

AVK>>А, ну то есть ты янус специально запускал на самом дохлом компе. Месье мазохист?
S>Ну что за десткие придирки ей богу?

Детские придирки это когда ты всем тут рассказываешь как тормозит янус, когда ты его запускаешь на дохлой машине.

AVK>>И что это за уникальные фичи ты конечно не скажешь
S>Конечно.

Тогда отметаем.

AVK>>Мы вот тоже таку платформу делаем. И вот что удивительно — все упирается в БД, а не в процессор. Хотя фич уникальных у нас предостаточно.
S>Ну и какие? Раз выкатили, напиши, по сайту ничего отличающего ваш продукт от других на рынке я не нашел, даже последнюю версию скачал, заценить.

Ты это о чем???

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

AVK>>А его никто пока не переносил.
S>Не понял, а что так?

А зачем?

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

AVK>У меня тоже. Только я, в отличие от тебя, аргументами, которые невозможно проверить не пользуюсь.
Ну извеняйте, расскажу, могут уволить или того хуже, у меня NDA однако.

AVK>Эти вещи за 2 года не пишутся.
Ну хорошо хорошо.

AVK>Детские придирки это когда ты всем тут рассказываешь как тормозит янус, когда ты его запускаешь на дохлой машине.
Ну тогда указывайте в системных рекомендациях pentium 4 2048 mb DDR 400 ram чес слово, если п3 800 дохлая машина...

AVK>Тогда отметаем.
Отметай, не жалко.

AVK>>>Мы вот тоже таку платформу делаем. И вот что удивительно — все упирается в БД, а не в процессор. Хотя фич уникальных у нас предостаточно.
AVK>Ты это о чем???
Что у вас за фичи уникальные? По описанию/юзанью вашего софта я их не увидел, это не издевательство, я серьёзно, конкурента, так сказать, узнать

alexeiz,

>> Скажем, если бы C++ остался бы тем же, что сейчас, но пресловутая арифметика указателей была бы вынесена в какой-нибудь "unsafe", наверное, был бы "за" (хотя, имхо, есть более удачные альтернативы).

> Какие нибудь подвИги в этом направлении есть?

Мне ничего сколько-нибудь перспективного не попадалось. И, думаю, вряд ли будет: теперь к сохранению существующей семантики обязывает не только и не столько совместимость с C, сколько совместимость с C++...

> Так-же хотелось бы узнать и про более удачные альтернативы.

Более удачными, чем регионы "unsafe", для C++-подобного языка мне кажутся варианты, вписывающие "опасные" указатели в систему типов наравне с "безопасными", и позволяющие работать значительно более гибко. В самом деле, в самой по себе концепции указателей ничего особенно опасного нет, потенциальные проблемы появляются, если указатель непосредственно представляет собой адрес, да еще и может быть объектом арифметических операций.

Допустим, можно сделать указатель по-умолчанию "безопасным", а при наличии какого-нибудь модификатора — "опасными":

Obj*     obj = new Obj;        // "безопасный" указатель
Obj raw* unsafe_pointer = obj; // "опасный" указатель

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

Для "безопасных" указателей можно было бы запретить арифметику, либо же снабдить их информацией, позволяющей верифицировать корректность арифметических операций во время исполнения.

Полагаю, более удачным вариантом был бы запрет арифметики для "безопасных" указателей, и введение в язык полноценных массивов, плюс slices, позволяющие делать все то же, что и арифметика указателей, но более четко отражающие суть происходящего, и более экономные (раза в два), чем снабжение "безопасных" указателей доп. информацией.

В таком случае "безопасные" указатели семантически отличась бы от ссылок, пожалуй, только тем, что могли бы быть нулевыми.

Кроме того, для "безопасных" указателей влет вводится опциональная сборка мусора, которую с "низкоуровневыми" указателями организовать несколько сложнее...

И т.д., и т.п.

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

> выдели все это барахло в отдельный подраздел, что-то вроде extern "C Compat", сломай совместимость один раз с возможностью с небольшими трудозатратами отпортировать существующий код, и дальше можно развивать язык в двух направлениях: "true C++" & "C Compat".

Может быть... Но, к сожалению, такой подход очень дорог на практике. Фактически, это означает наличие в одном компиляторе двух: компилятора "старого" C++, и компилятора "нового" C++. Т.е., например, любой разработчик нового компилятора будет вынужден "пахать" вдвойне, что резко снизит привлекательность языка для создателей компиляторов и инструментальных средств. C++ в теперешнем виде, и без добавления к нему второго языка, находится на этой грани, если не за ней. Плюс возникает множество тонких моментов, связанных с возможностью вызова "старого" кода из "нового", и наоборот.

Почему-то мне кажется, что единственно реальным вариантом значительного изменения C++ является создание нового языка, (максимально) совместимого с C++ на уровне объектной модели.

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

• он будет содержать какие-то значительные возможности, которых в C++ нет, и добавить сложно; фактически, речь должна идти о поддержке какого-то стиля программирования, сильно нужного программистам C++, но не поддерживаемого C++; "безопасность" и большая "чистота" языка таковым, естественно, не являются;
  
• за этим языком встанет одна из больших компаний с большими деньгами, и будет его активно продвигать на рынок, как это было с Java или C#.

При этом, без выполнения второго условия, как я понимаю, новый язык должен позволять, действительно, легко переносить на него программы с C++ и, возможно, C.

> Java, C#, D имеют в этом смысле успех, отрубая у него некоторое количество голов. Но, как ты очень правильно выразился, ни один из них не "вставляет."

Ага. И, глядя на это безобразие, собственно, и приходят мысли о том, что новый язык должен добавлять возможности, а не убирать их. Из самых востребованных в голове крутятся достойная поддержка метапрограммирования и рефлексии, функционального стиля, плюс более развитые возможности динамической типизации. Плюс, естественно, не стоит забывать массу мест, где C++ может быть улучшен, позволяя значительно лучшую оптимизацию одновременно с упрощением использования. Например, для иллюстрации, легко можно представить добавление возможности возвращения ковариантных объектов или массивов нефиксированной длины по значению, как это давным-давно можно делать в Аде.

> Не родился еще dragon slayer version next. Хотя я очень надеюсь, что C++/CLI (точнее C++/CLI + STL.NET) будет катализатором для этого рождения.

Присоединяюсь: очень хочется надеяться...

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

ГВ>Странный какой-то критерий. Если на то пошло, то и asm — суть не более, чем ветка C++.

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

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

ПК>MC++... Ты много знаешь удачных примеров использования MC++? К тому же, он уже deprecated, не успев как следует распространиться.

Собственно, он так и задумывался. Единственная его задача — это интеграция унаследованного С++ кода и .NET, и в таком качестве он проживет еще очень долго.

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

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

VD>>>Ну, надо же с жадностью боросться?
S>>А идея, надеюсь, подход не запетентован?
E>Есть способ кардинальнее.
E>При выпуске второго сервиспака для XP, помимо включения туда dotnetfx-а, мелкософту нужно было просто захардкодить в кернел ограничение, чтобы ось не стартовала на машинах c <= 1000 мегов оперативки!

E>Эх, жаль в свое время не догадался продать MS-овцам эту мысль...
E>Впрочем, вероятно ещё не всё потеряно...

Дарю addon к идее — сервиспак должен ставиться на память определённой марки: Kingston MS certified. Кстати, тогда и проблема софтверного корсарства (каперства и иже с ними) пропадёт сама собой.

Дарней,

> ПК> MC++... Ты много знаешь удачных примеров использования MC++? К тому же, он уже deprecated, не успев как следует распространиться.

> Собственно, он так и задумывался. Единственная его задача — это интеграция унаследованного С++ кода и .NET, и в таком качестве он проживет еще очень долго.

Все то же самое на C++/CLI делается намного легче и быстрее. Некоторое время назад Microsoft проводили исследование, есть ли вообще достаточное количество кода на MC++, чтобы заботиться его поддержкой. Чем закончилось — без понятия. Планировавшаяся поддержка на тот момент заключалась в написании инструмента, преобразующего код на MC++ в код на C++/CLI. Этим транслятором на тот момент занимался Стэнли Липпман. Так что MC++ можно преспокойно сказать R.I.P. Никаких "долго", насколько мне известно, не ожидается. "И это правильно, товарищи"

Или у тебя есть какая-то другая информация?

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

AVK>>У меня тоже. Только я, в отличие от тебя, аргументами, которые невозможно проверить не пользуюсь.
S>Ну извеняйте, расскажу, могут уволить или того хуже, у меня NDA однако.

Тогда не стоит вобще об этом упоминать.

AVK>>Детские придирки это когда ты всем тут рассказываешь как тормозит янус, когда ты его запускаешь на дохлой машине.
S>Ну тогда указывайте в системных рекомендациях pentium 4 2048 mb DDR 400 ram чес слово, если п3 800 дохлая машина...

Зачем?

AVK>>>>Мы вот тоже таку платформу делаем. И вот что удивительно — все упирается в БД, а не в процессор. Хотя фич уникальных у нас предостаточно.
AVK>>Ты это о чем???
S>Что у вас за фичи уникальные? По описанию/юзанью вашего софта я их не увидел, это не издевательство, я серьёзно, конкурента, так сказать, узнать

Ты о каком софте вобще речь ведешь?

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

AVK>Тогда не стоит вобще об этом упоминать.
Я вроде всё доходчиво писал, фичи тяжелые, что ты от меня хочешь? Чтобы я тебе еще и исходны коды показал?

AVK>Зачем?
У тебя же п3 800 — дохлая машина для Януса, ну вот я и посмеялся.

AVK>>>>>Мы вот тоже таку платформу делаем. И вот что удивительно — все упирается в БД, а не в процессор. Хотя фич уникальных у нас предостаточно.
AVK>>>Ты это о чем???
S>>Что у вас за фичи уникальные? По описанию/юзанью вашего софта я их не увидел, это не издевательство, я серьёзно, конкурента, так сказать, узнать

AVK>Ты о каком софте вобще речь ведешь?
О твоей платформе, или у тебя их много? Если у тебя их нема , тогда зачем пишешь:

Мы вот тоже таку платформу делаем. И вот что удивительно — все упирается в БД, а не в процессор. Хотя фич уникальных у нас предостаточно.

Как я понял, ты из Паруса, делаешь конструктор на .Net.