S>>Ну и начиная с рослина всякие проверки типа таких пишутся на раз-два. M>Я хочу использовать дизайн языка а не ковырять очередное поделие от микрософта. Понимаете вы мне все время говорите — "а вот пара дней помучать задницу, и вы разродитесь решением". Меня такой подход не устраивает потому что для меня ЯП это не вещь в себе а инструмент для решения определенной задачи. И я не собираюсь вникать в эти индусские идеи чтобы исправить индусские баги. Это детский сад. Мне нужен approach на уровне дизайна языка, в C# его нет.
Мы точно ещё в контексте С++? А то я не уверен что язык в котором всё может быть приведено к byte* и заполнено ценнейшими данными, является взрослым решением с тем approach на уровне дизайна языка, который вам нужен.
M>Это касается не только конкретно этой фичи но и кучи других вещей. Напр. множественное наследование. В дизайне языка просто отсутствуют rules которые помогли бы формировать корректный код. Вместо это вас отправляют к каким-то паттернам, стайл копам и прочей чуши. Это просто бред
В C# может и много чего нет, и я сам любитель покритиковать, но в нём дофига всякого и есть. Последний раз когда мне реально понадобилось множественное наследование в C# — выкрутился через генерацию partial классов. Кроме этого есть ещё PostSharp, Nemerle, и другие интересные способы решить проблему множественного наследования.
M>Вы просто не работали с индусами. M>>>C# поощряет такой подход на уровне дизайна. С++ наоборот может подсказать новичку, что "вот так менять гравитацию" нельзя на уровне синтаксиса.
Ну если в контексте индусов, то честно говоря я не представляю что это за задачи такие в которых const что-то решает по сравнению с проверкой кода через контракты. В C++ нам далеко не индус организовал два delete одному указателю. Плавающий баг тихарился годами и был найден случайно когда код в связи с ростом проекта попал в цикл и memory manager взбрыкнул. А до того были странности выполнения зависящие от звёзд на небе. Как там, approach на уровне дизайна языка, говорите?
S>>Геттер без сеттера + init-метод? M>Это слишком жесткая связка. Я не хочу ограничивать себя readonly методом. Очередная недороботка C# по дизайну. Очень грустно программировать на подобных языках
Прокачивайте чувство юмора, мне вот весело И снова, вы ещё в ракете не смотрели JavaScript на сервере не писали, там в сумерках вложенных каллбэков настоящая жара начинается
Здравствуйте, mapnik, Вы писали:
M>Очень правильный механизм "защиты от дурака". M>Discuss, господа, discuss
Раз в С++ есты защита от дурака, значит предполагается что на нам будут писать дураки.
Так какой там язык для индусов? :trollface:
Здравствуйте, DreamMaker, Вы писали:
DM>и да, у меня ~18 лет на С++ и 4 на шарпе. и таких как я немало. а вот чтобы человек с шарпа перешел на плюсы и радовался — что-то о таком не слышал.
Будем знакомы. Уже три года как на плюсах после 5ти на шарпе. Причем выбор не случайный, сам к этому шел.
Здравствуйте, hi_octane, Вы писали:
_>В C++ нам далеко не индус организовал два delete одному указателю.
А кто вообще организовал delete указателю не в библиотечном коде? Оно такое нафиг не нужно.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Ops>А кто вообще организовал delete указателю не в библиотечном коде? Оно такое нафиг не нужно.
Свои пулы (memory regions) объектов под задачи. Эволюционировали с простейших кусков памяти привязанных к задаче до поддержки вложенности, сериализации и передачи вместе с задачей на другую ноду кластера. В общем-то предположение правильное — вполне библиотечный код.
Здравствуйте, hi_octane, Вы писали:
_>Свои пулы (memory regions) объектов под задачи. Эволюционировали с простейших кусков памяти привязанных к задаче до поддержки вложенности, сериализации и передачи вместе с задачей на другую ноду кластера. В общем-то предположение правильное — вполне библиотечный код.
Не, я под "библиотечным" имел в виду RAII примитивы. Использовать delete где-то кроме них сегодня довольно странно. Оно, конечно, можно, для какой-нибудь хардкорной оптимизации, но тогда надо об этом помнить и писать везде аршинными буквами.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, mapnik, Вы писали:
M>Простейший пример оператор const в С++ в применении к функциям (Constant Member Functions).
class World {
public:
World(){
//initialize world's physics and geometry with default values
setupWorld(defaultGravity, defaultSize, defaultBorderBehaviour);
}
~World();
hkpWorld* getWorld() const {
//Yellow!!!
//I'm Rajesh, I got Phd in India and now I'm going to fix one bug!
hkpWorldCinfo worldInfo = new...;
//let's change gravity from 9.8f to 10 because...
worldInfo.m_gravity = 10;
(const_cast<World*>(this))->physicsWorld = new hkpWorld(worldInfo);
return new hkpWorld(worldInfo);
};
...
private:
...
hkpWorld * physicsWorld;
...
};
ААААА, C++ говнище!!! Мало того что const нифига не помог, так еще и утечку памяти создал. Срочно бросайте все этот дерьмовый язык.
А если серьезно, то иди читай букварь прежде чем писать подобные темы.
Здравствуйте, DreamMaker, Вы писали:
DM>a задачи какие? если что-то низкоуровневое, то да, возможно оправданно. DM>иначе — мазохизм хождения по костылям.
Распределенные вычисления HPC. Использует всю память и считает по несколько дней, поэтому дотнет для задачи не подходит. Хотя все остальные части продукта, как UI, например, реализованы на дотнете.
Здравствуйте, Figaro, Вы писали:
F>Просто порог вхождения в шарпей гораздо ниже... Но как только начинаешь интересоваться даже в шарпе тонкостями, большинство сливается...
Шарп неплохой язык, но он наполнен людьми, которые не любят технологии и программирование, а используют его только для заработка. И я их понимаю, ведь платят хорошо и работу найти легче. Один мой коллега дотнетчик с пятилетним стажем, как-то, прервал мои рассуждение о BidEndian и LittleEndian. Как оказалось, он не знал сколько битов в байте и многое другое в этом направлении. Тем не менее, он успешный программист в своей нише и ему хорошо платят.
Здравствуйте, hi_octane, Вы писали:
_>В C# может и много чего нет, и я сам любитель покритиковать, но в нём дофига всякого и есть. Последний раз когда мне реально понадобилось множественное наследование в C# — выкрутился через генерацию partial классов. Кроме этого есть ещё PostSharp, Nemerle, и другие интересные способы решить проблему множественного наследования.
Делается с помощью интерфейса и extension methods на этот интерфейс. Потом класс наследует интерфейс и еще один класс и вот тебе множественное наследование в C#.
M>Господа, я не уверен было уже или нет. Думаю что да, прошу прощения за возможное повторение. M>Читаю подобные темы и неудержимо тянет на гомерический хохот M>http://rsdn.ru/forum/dotnet/6006483.flat.1
M>"С# такая няшечка, в нем столько красивых рюшечек...". Все это в целом мило, но что насчет реально нужных фич, которые имеют действительно сильные проверенные временем ОО-языки? M>Простейший пример оператор const в С++ в применении к функциям (Constant Member Functions).
M>Пример на С#:
M>
M>public sealed class World
M>{
M> ...
M> private hkpWorld physicsWorld;
M> ...
M> public World()
M> {
M> //initialize world's physics and geometry with default values
M> setupWorld(defaultGravity, defaultSize, defaultBorderBehaviour);
M> }
M> ...
M> public hkpWorld getWorld()
M> {
M> //Yellow!!!
M> //I'm Rajesh, I got Phd in India and now I'm going to fix one bug!
M> hkpWorldCinfo worldInfo = new...;
M> //let's change gravity from 9.8f to 10 because...
M> worldInfo.m_gravity = 10;
M> physicsWorld = new hkpWorld(worldInfo);
M> ...
M> //Hello, I'm mapnik and I see this code
M> //FUUUUUUCK!!!
M> return physicsWorld;
M> }
M> ...
M>}
M>
Здравствуйте, greenpci, Вы писали:
G>Распределенные вычисления HPC. Использует всю память и считает по несколько дней, поэтому дотнет для задачи не подходит.
Чем же не подходит, ну кроме масдайности? Неужели MS-й JIT таки писан Раджешом, и потому сливает сановскому JIT-у по производительности?
G> UI, например, реализованы на дотнете.
А вот за масдайность гуя надо руки отбивать.
Здравствуйте, Aртём, Вы писали:
Aё>Чем же не подходит, ну кроме масдайности? Неужели MS-й JIT таки писан Раджешом, и потому сливает сановскому JIT-у по производительности?
Если бы продукт был на дотнете с самого начала, никто бы не заметил. А так, он сейчас на сях и если его на дотнете переписать, то он будет медленнее работать и жрать больше памяти, то есть у некоторых клиентов просто перестанет работать. Клиенты расстроятся. Поэтому нельзя.
Джит прекрасно написан, я уверен. Но, до предела оптимизированное сишное приложение, все равно, делает меньше работы. Поэтому работает быстрее и жрет меньше памяти.
G>> UI, например, реализованы на дотнете. Aё>А вот за масдайность гуя надо руки отбивать.
Здравствуйте, greenpci, Вы писали:
G>Джит прекрасно написан, я уверен. Но, до предела оптимизированное сишное приложение, все равно, делает меньше работы. Поэтому работает быстрее и жрет меньше памяти.
Я бы не был уверен насчёт жита дотнета- взять хотя бы его неспособность житить лишь горячие участки. Насчёт до предела оптимизаций- Matematica написана на Java и умеет CUDA, т.е. работает быстрее, а память- не ресурс.
Здравствуйте, Aртём, Вы писали:
Aё>Я бы не был уверен насчёт жита дотнета- взять хотя бы его неспособность житить лишь горячие участки. Насчёт до предела оптимизаций- Matematica написана на Java и умеет CUDA, т.е. работает быстрее, а память- не ресурс.
Hotspot jit во многом нужен из-за отсутствия value types в яве. Без них разница с шарпом непринципиальна (что как бы очевидно, в рамках времени, отводимого на jit, ничего сильно пристойного всё равно не сделать). Для частных случаев с .net 4.5 есть profile guided optimisation, для cuda есть AleaGPU, т.е. не в этом счастье.
Тут в другом проблема: старые реализации jit не были заточены под числомолотилки. Плюс, начиная с второго дотнета и вплоть до winphone8/win8 clr не развивался от слова никак.
В свежих релизах с .NetCore и RyuJit положение потихоньку выправляется, особенно с учётом .net native и возможности трансляции в llvm. Но, очевидно, в ближайщую пару релизов ничего сильно не изменится — сначала надо переползти толком на новые платформы, ничего сильно не потеряв. Дальше — будем посмотреть.
Здравствуйте, Aртём, Вы писали:
Aё>Я бы не был уверен насчёт жита дотнета- взять хотя бы его неспособность житить лишь горячие участки. Насчёт до предела оптимизаций- Matematica написана на Java и умеет CUDA, т.е. работает быстрее, а память- не ресурс.
КУДА на подойдет, это же GPU, как я понимаю. У этого приложения распределение идет на workers и облако.
И снова, вы ещё 
