Здравствуйте, _NN_, Вы писали:
_>>Всё правильно. Если сравнивать C# и C. А вот при сравнение C# и C++ уже ничего подобного не наблюдается. _NN>К сожалению, чтобы этого добиться в С++ нужно гораздо больше понимать чем в C#. _NN>И научить людей всем нюансам гораздо сложнее, ведь многое в понимании приходит только с опытом.
Согласен, это один из основных недостатков C++ в данный момент) Ну так полного идеала нет нигде. ) Лично для нас этот недостаток не особо напрягающий. А скажем для большинства не IT компаний думаю это весьма существенно...
Для нас более критично отсутствие интроспекции (времени компиляции) и работы со строками в шаблонах. Надеюсь когда-нибудь поправят — тогда для нас будет совсем позитивно.
Хотя кто его знает, какое направление развитие будет в дальнейшем. К примеру мы особо не ждали полиморфные лямбды, но когда увидели их, то изменили своё мнение — крайне мощный инструмент. Настолько мощный, что варианты его использования ещё не целиком проглядываются (потому и не особо ждали наверное)...
Re[45]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
_>>Всё правильно. Если сравнивать C# и C. А вот при сравнение C# и C++ уже ничего подобного не наблюдается. VD>Ты тут рядом типа мифы развенчивал, а тут сам мифы придумываешь.
Можешь продемонстрировать большую надёжность C# кода по сравнению с C++ (а не C!) кодом? )
VD>Как бы мы с Вольфхаундом старые С/С++-ники. И с радостью выкинули эти языки на свалку истории. Догадайся почему?
Пока не особо представляю. Потому как сам пока что не могу выкинуть C++ даже в варианте перехода C++ -> D...
Re[47]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, alex_public, Вы писали:
_>Можешь продемонстрировать большую надёжность C# кода по сравнению с C++ (а не C!) кодом? )
Что там демонстрировать? Язык с ручным управлением памятью и легко доступными небезопасными приведениями типов, отсутствием контроля границ массивов и адресной арифметикой надежным не может быть по определению. Программирование на нем сравни хождению по минному полю. Если ты большой профессионал, то тебе удастся пройти между заботливо разложенными граблямиминами. Но если ты оступился, то может оторвать важные части тела.
Обвешивание разными смартпоинтерами и прочими приблудами упрощающими жизнь стремительно приводит производительность к тому что ты мог бы получить на Шарпе без малейшего напряжения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_>>Можешь продемонстрировать большую надёжность C# кода по сравнению с C++ (а не C!) кодом? ) VD>Что там демонстрировать? Язык с ручным управлением памятью и легко доступными небезопасными приведениями типов и адресной арифметикой надежным не может быть по определению. Программирование на нем сравни хождению по минному полю. Если ты большой профессионал, то тебе удастся пройти между заботливо разложенными граблямиминами. Но если ты оступился, то может оторвать важные части тела.
Эээ, я же вроде бы чётко указал, что у нас речь идёт о C++, а не о C.
VD>Обвешивание разными смартпоинтерами и прочими приблудами упрощающими жизнь стремительно приводит производительность к тому что ты мог бы получить на Шарпе без малейшего напряжения.
Ха, человек хорошо знающий C++ никогда такого не напишет. Там же краеугольный камень всей идеологии языка в нулевом оверхеде всех абстракций и он соблюдается неукоснительно.
Re[48]: Nemerle через 5 лет - выстрелит или скончается?
А вообще, я смотрю что ты игнорируешь множество интересных (но видимо неудобных тебе?) вопросов в данной темке, хотя при этом комментируешь всякие мелкие оффтопики... Ну и какой смысл тогда нормально общаться? )
Re[49]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, alex_public, Вы писали:
_>А вообще, я смотрю что ты игнорируешь множество интересных (но видимо неудобных тебе?) вопросов в данной темке, хотя при этом комментируешь всякие мелкие оффтопики... Ну и какой смысл тогда нормально общаться? )
У меня времен нет развернуто отвечать. Будет время отвечу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[46]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>ЗЫ VD>Как бы мы с Вольфхаундом старые С/С++-ники. И с радостью выкинули эти языки на свалку истории. Догадайся почему?
Извини, конечно, но в том-то и дело, что вы слишком старые С++ники. Современным С++никам нет нужды знать WinAPI и все нюансы реализации COM, им нужны другие знания и умения. Даже в MSDN заглядывать практически никогда не приходится.
Re[49]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, alex_public, Вы писали:
VD>>Что там демонстрировать? Язык с ручным управлением памятью и легко доступными небезопасными приведениями типов и адресной арифметикой надежным не может быть по определению. Программирование на нем сравни хождению по минному полю. Если ты большой профессионал, то тебе удастся пройти между заботливо разложенными граблямиминами. Но если ты оступился, то может оторвать важные части тела. _>Эээ, я же вроде бы чётко указал, что у нас речь идёт о C++, а не о C.
Что из этого не относится к С++?
_>Ха, человек хорошо знающий C++ никогда такого не напишет. Там же краеугольный камень всей идеологии языка в нулевом оверхеде всех абстракций и он соблюдается неукоснительно.
Расскажи ка мне про производительность InterlockedIncrement/InterlockedDecrement которые необходимы для подсчёта ссылок в многопоточной программе.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[50]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, WolfHound, Вы писали:
_>>Ха, человек хорошо знающий C++ никогда такого не напишет. Там же краеугольный камень всей идеологии языка в нулевом оверхеде всех абстракций и он соблюдается неукоснительно. WH>Расскажи ка мне про производительность InterlockedIncrement/InterlockedDecrement которые необходимы для подсчёта ссылок в многопоточной программе.
Структуру данных JudyArray в пару тысяч строк писало целое подразделение отличных алгоритмистов из IBM несколько лет.
Смешно читать при таких проектах не только про "ошибки в коде на Си", но даже про дебаг.
Высокопроизводительный код, пишется годами и вылизывается до блеска без какого либо оверхеда.
И самое интересное — что альтернативы коду на Си просто нет, если речь идет о производительности
Шарп да Джава точились на 80% для ынтырпрайза. Это когда в одном опенспейсе сажают с два десятка хомячков которые усиленно скриптуют какую-нибудь склад-бухгалтерию.
Re[50]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, WolfHound, Вы писали:
WH>Расскажи ка мне про производительность InterlockedIncrement/InterlockedDecrement которые необходимы для подсчёта ссылок в многопоточной программе.
1. Для ref-counted smart pointers лишние передёргивания ссылок требуются только когда время жизни объекта реально "раздваивается", в большинстве же случаев достаточно move. Эти редкие атомарные ++ -- конечно же прям наисерьезнейшая проблема по сравнению с stop-the-world и прочими GC радостями.
2. Это всего лишь один из вариантов smart-pointer'ов. Есть другие — например есть ref-counted без синхронизации, а есть и вовсе без всяких counter'ов.
3. Значимость smart pointers сильно преувеличенна теми, кто полагает что для каждого new в управляемых языках, единственная альтернатива на C++ это smart pointer. На практике же, для большинства случаев достаточно scoped-based lifetime.
Здравствуйте, WolfHound, Вы писали:
VD>>>Что там демонстрировать? Язык с ручным управлением памятью и легко доступными небезопасными приведениями типов и адресной арифметикой надежным не может быть по определению. Программирование на нем сравни хождению по минному полю. Если ты большой профессионал, то тебе удастся пройти между заботливо разложенными граблямиминами. Но если ты оступился, то может оторвать важные части тела. _>>Эээ, я же вроде бы чётко указал, что у нас речь идёт о C++, а не о C. WH>Что из этого не относится к С++?
Собственно ничего. Ну или с другой стороны всё, но в таком случае оно и к C# относится (у нас же там имеется unsafe, не так ли?).
_>>Ха, человек хорошо знающий C++ никогда такого не напишет. Там же краеугольный камень всей идеологии языка в нулевом оверхеде всех абстракций и он соблюдается неукоснительно. WH>Расскажи ка мне про производительность InterlockedIncrement/InterlockedDecrement которые необходимы для подсчёта ссылок в многопоточной программе.
Для начала тогда уж std::atomic, а не эта хрень из win api. Ну а потом собственно причём тут это? Мы говори о нулевом оверхеде неких абстракций. А здесь у нас совсем не абстракция, а прямая функциональность — синхронизация. Так что само понятие оверхед тут не применимо, т.к. ресурсы тратятся не на реализацию абстракции, а на "дело". Ну или ты хочешь сказать, что можешь привести случаи, когда в C++ синхронизация нужна, а в том же случае в C# не нужна? )
Re[51]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>1. Для ref-counted smart pointers лишние передёргивания ссылок требуются только когда время жизни объекта реально "раздваивается", в большинстве же случаев достаточно move.
Вот только компилятор не в состоянии определить большинство таких ситуаций.
Так что тебе придется писать что-то типа ptr1.moveFrom(ptr2). И не дай байт написать это лишний раз.
EP>Эти редкие атомарные ++ -- конечно же прям наисерьезнейшая проблема по сравнению с stop-the-world и прочими GC радостями. http://www.azulsystems.com/technology/c4-garbage-collector
EP>2. Это всего лишь один из вариантов smart-pointer'ов. Есть другие — например есть ref-counted без синхронизации, а есть и вовсе без всяких counter'ов.
И если он не дай байт залетит в другой поток, случится феерверк.
EP>3. Значимость smart pointers сильно преувеличенна теми, кто полагает что для каждого new в управляемых языках, единственная альтернатива на C++ это smart pointer. На практике же, для большинства случаев достаточно scoped-based lifetime.
Ну, это ты сильно погорячился.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[51]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, alex_public, Вы писали:
_>Собственно ничего. Ну или с другой стороны всё, но в таком случае оно и к C# относится (у нас же там имеется unsafe, не так ли?).
Его отдельно включать надо.
_>Для начала тогда уж std::atomic, а не эта хрень из win api.
Не важно. Уверен, что std::atomic на винде через эту хрень и работает.
Ну, или эту хрень туда тупо скопипастили.
_>Ну а потом собственно причём тут это? Мы говори о нулевом оверхеде неких абстракций. А здесь у нас совсем не абстракция, а прямая функциональность — синхронизация. Так что само понятие оверхед тут не применимо, т.к. ресурсы тратятся не на реализацию абстракции, а на "дело". Ну или ты хочешь сказать, что можешь привести случаи, когда в C++ синхронизация нужна, а в том же случае в C# не нужна? )
class Foo
{
Baz baz;
void Bar()
{
var localBaz = new Baz();//раз
baz = localBaz;//два
//три
}
//удаление Foo четыре
}
В C# не нужно ни разу.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[52]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>1. Для ref-counted smart pointers лишние передёргивания ссылок требуются только когда время жизни объекта реально "раздваивается", в большинстве же случаев достаточно move. WH>Вот только компилятор не в состоянии определить большинство таких ситуаций.
Ссылку на "большинство" не затруднит привести? Компилятор как раз отлично знает, где у него что, гуглить rvalue references.
WH>Так что тебе придется писать что-то типа ptr1.moveFrom(ptr2). И не дай байт написать это лишний раз.
Крайне редко это придется писать, уж поверь. Судя по тому, что ты пишешь moveFrom() вместо std::move и rvalue references, о С++11 ты имеешь довольно смутное представление.
EP>>2. Это всего лишь один из вариантов smart-pointer'ов. Есть другие — например есть ref-counted без синхронизации, а есть и вовсе без всяких counter'ов. WH>И если он не дай байт залетит в другой поток, случится феерверк.
А если единорог придет, то вообще труба.
EP>>3. Значимость smart pointers сильно преувеличенна теми, кто полагает что для каждого new в управляемых языках, единственная альтернатива на C++ это smart pointer. На практике же, для большинства случаев достаточно scoped-based lifetime. WH>Ну, это ты сильно погорячился.
То есть в твоих программах на С++ сплошные сплошные динамические полиморфные объекты с неопределенным временем жизни? Ну тогда конечно.
Здравствуйте, WolfHound, Вы писали:
EP>>1. Для ref-counted smart pointers лишние передёргивания ссылок требуются только когда время жизни объекта реально "раздваивается", в большинстве же случаев достаточно move. WH>Вот только компилятор не в состоянии определить большинство таких ситуаций. Так что тебе придется писать что-то типа ptr1.moveFrom(ptr2).
Если прям стоит задача минимизировать лишние передёргивания, то можно запретить неявные копии и оставить только явные move или copy — в любой непонятной ситуации компилятор будет задавать вопрос.
WH>И не дай байт написать это лишний раз.
Это уже вопрос к корректности, надёжности, тестированию, а не к производительности.
EP>>Эти редкие атомарные ++ -- конечно же прям наисерьезнейшая проблема по сравнению с stop-the-world и прочими GC радостями. WH>http://www.azulsystems.com/technology/c4-garbage-collector
Как-будто конкуренция куда-то делась
Continuously Concurrent Compacting Collector
EP>>2. Это всего лишь один из вариантов smart-pointer'ов. Есть другие — например есть ref-counted без синхронизации, а есть и вовсе без всяких counter'ов. WH>И если он не дай байт залетит в другой поток, случится феерверк.
Baby-sitting'а нет, откуда вытекает мощность с одной стороны, и возможность делать плохие вещи с другой.
EP>>3. Значимость smart pointers сильно преувеличенна теми, кто полагает что для каждого new в управляемых языках, единственная альтернатива на C++ это smart pointer. На практике же, для большинства случаев достаточно scoped-based lifetime. WH>Ну, это ты сильно погорячился.
Это опыт реальных проектов. Как ты говорил "уж поверь практикам".
При этом не отрицаю что есть некоторые задачи где время жизни определяется внешними факторами. А иногда даже таким способом, что возможны жёсткие циклы в графе зависимостей.
P.S. Кстати, а есть ли готовая возможность в Nemerle для освобождения ресурса, как только все ссылки на него выйдут из scope? using'и или их аналоги тут не особо помогают:
using System;
using System.IO;
public class Test
{
public delegate void fireworks();
public static fireworks make_closure(FileStream fs)
{
return () => fs.Read(new byte[10], 0, 10);
}
public static fireworks fire()
{
using (var fs = File.Open("file", FileMode.Open))
{
return make_closure(fs);
}
}
public static void Main()
{
fire()();
}
}
Re[53]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, jazzer, Вы писали:
J>Ссылку на "большинство" не затруднит привести? Компилятор как раз отлично знает, где у него что, гуглить rvalue references. http://rsdn.ru/forum/nemerle/5811981.1
Объясни, как компилятор поймет, что нужно щелкать счётчиком ссылок 2, а не 4 раза?
J>Крайне редко это придется писать, уж поверь. Судя по тому, что ты пишешь moveFrom() вместо std::move и rvalue references, о С++11 ты имеешь довольно смутное представление.
Пальцы спрячь. С++ я знаю не хуже всех вас вместе взятых.
WH>>И если он не дай байт залетит в другой поток, случится феерверк. J>А если единорог придет, то вообще труба.
Знакомая песня. А потом софт в продакшене падает.
J>То есть в твоих программах на С++ сплошные сплошные динамические полиморфные объекты с неопределенным временем жизни? Ну тогда конечно.
Это весьма частый сценарий. Особенно если логика сложная.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[54]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, jazzer, Вы писали:
J>>Ссылку на "большинство" не затруднит привести? Компилятор как раз отлично знает, где у него что, гуглить rvalue references. WH>http://rsdn.ru/forum/nemerle/5811981.1
WH>Объясни, как компилятор поймет, что нужно щелкать счётчиком ссылок 2, а не 4 раза?
Почитай что-нибудь про move-конструкторы, знаток вместе взятых.
J>>Крайне редко это придется писать, уж поверь. Судя по тому, что ты пишешь moveFrom() вместо std::move и rvalue references, о С++11 ты имеешь довольно смутное представление. WH>Пальцы спрячь. С++ я знаю не хуже всех вас вместе взятых.
Ты "11" не заметил или специально пропустил? То, что ты знал С++98/03 не хуже всех — не сомневаюсь. Но С++11/14 — то, что ты тут пишешь, говорит само за себя, уж извини.
WH>Знакомая песня. А потом софт в продакшене падает.
Вот-вот, знакомая песня про мифический софт, который у кого-то (у тебя?) в продакшене падает.
У нас вот ничего не падает уже который год, и мы смотрим на тебя с недоумением.
Что-то мы явно делаем не так.
J>>То есть в твоих программах на С++ сплошные сплошные динамические полиморфные объекты с неопределенным временем жизни? Ну тогда конечно. WH>Это весьма частый сценарий. Особенно если логика сложная.
Ну куда уж нам с нашей простецкой логикой, в которой 99.999% объектов имеют автоматическое время жизни.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Если прям стоит задача минимизировать лишние передёргивания, то можно запретить неявные копии и оставить только явные move или copy — в любой непонятной ситуации компилятор будет задавать вопрос.
Ну, так я и говорю, что тебе придётся всё это руками выписывать.
EP>Это уже вопрос к корректности, надёжности, тестированию, а не к производительности.
Если на асме каждую инструкцию отполировать будет ещё быстрее.
EP>Как-будто конкуренция куда-то делась EP>
EP>Continuously Concurrent Compacting Collector
Не стоит отвечать на одно слово.
В данном случае это слово означает, что stop-the-world не бывает вообще.
EP>Это опыт реальных проектов. Как ты говорил "уж поверь практикам".
У меня С++ного опыта тоже не мало.
EP>При этом не отрицаю что есть некоторые задачи где время жизни определяется внешними факторами. А иногда даже таким способом, что возможны жёсткие циклы в графе зависимостей.
Во-во. Распутать клубок зависимостей в нитре у меня при всём желании не получится.
Хотя конечно можно сложить каждый отдельный клубок в собственный пул.
Но это куча работы на ровном месте. А у меня и так есть чем заняться.
EP>P.S. Кстати, а есть ли готовая возможность в Nemerle для освобождения ресурса, как только все ссылки на него выйдут из scope? using'и или их аналоги тут не особо помогают:
Я и на С++ так никогда не писал.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[55]: Nemerle через 5 лет - выстрелит или скончается?
WH>>Объясни, как компилятор поймет, что нужно щелкать счётчиком ссылок 2, а не 4 раза? J>Почитай что-нибудь про move-конструкторы, знаток вместе взятых.
Я знаю, что такое move-конструкторы. Я их еще до С++11 делал.
А теперь давай разбери конкретный пример.
Как тут поможет move-конструктор.
Подсказка: move-конструктор тут использовать нельзя от слова совсем.
J>Вот-вот, знакомая песня про мифический софт, который у кого-то (у тебя?) в продакшене падает. J>У нас вот ничего не падает уже который год, и мы смотрим на тебя с недоумением. J>Что-то мы явно делаем не так.
Тот софт который писал лично я тоже не падает.
Но про большинство других разработчиков я это, к сожалению, сказать не могу.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
http://rsdn.ru/forum/nemerle/5811981.1
