Здравствуйте, l33thaxor, Вы писали:
L> public unsafe static MatrixComplex operator *(MatrixComplex left, MatrixComplex right)
Кажется увидел слово unsafe? Здравствуй обратно ручное управление памятью?
Здравствуйте, andrey.desman, Вы писали:
AD>То, что на C# быстрее разрабатывается — тоже факт, однако.
Вовсе не факт. Проблема плюсов как правило в библиотеках, т.е. для разработки серьезных приложений нужно использовать библиотеки, которые не очень (а то и API использовать — вообще кошмар)
P.S. Данный тест на плюсах по времени разрабатывался примерно столько же, сколько и шарповый. Может чуть дольше — приходилось вспоминать что там к чему
Здравствуйте, AndreyR7, Вы писали:
AR>Здравствуйте, l33thaxor, Вы писали:
L>> public unsafe static MatrixComplex operator *(MatrixComplex left, MatrixComplex right) AR>Кажется увидел слово unsafe? Здравствуй обратно ручное управление памятью?
... и досвиданья. unsafe не имеет никакого отношения к ручному управлению памяти. Учись, пока молод.
Я видел тут у некоторых такую зелененькую подпись: "эксперт". Пора вводить новую, ярко красную мигающую: "студент".
Здравствуйте, l33thaxor, Вы писали:
AR>>Кажется увидел слово unsafe? Здравствуй обратно ручное управление памятью? L>... и досвиданья. unsafe не имеет никакого отношения к ручному управлению памяти. Учись, пока молод.
Ну здрасьте, приехали. А значит арифметика указателей — это не ручное управление памятью? Или в управление памятью входит только операции new/delete(GC)? Или ошибки в плюсовых программах типа "BlahBlah. Memory can't be read" — это наверное неправильное использование оператора new?
Я имел в виду широкое понятие, не только выделение/освобождение, но и работа с памятью. И слово unsafe как раз об этом.
L>Я видел тут у некоторых такую зелененькую подпись: "эксперт". Пора вводить новую, ярко красную мигающую: "студент".
Ага. И синюю жирную "умник". Уважаемый l33thaxor, оставьте свое мнение при себе.
Здравствуйте, AndreyR7, Вы писали:
AR>Вовсе не факт. Проблема плюсов как правило в библиотеках, т.е. для разработки серьезных приложений нужно использовать библиотеки, которые не очень (а то и API использовать — вообще кошмар)
Если брать в расчёт простое набивание кода, то действительно можно поспорить. Если же учесть возможности современных IDE (вива Решарпер!), то C# ИМХО однозначно впереди.
Здравствуйте, Delight, Вы писали:
D>Если брать в расчёт простое набивание кода, то действительно можно поспорить. Если же учесть возможности современных IDE (вива Решарпер!), то C# ИМХО однозначно впереди.
Для MS VC++ есть (по крайней мере раньше был) Visual Assist, который очень неплохо со всем справлялся, где-то и получше решарпера. И памяти столько не кушал (хватало для разработки 128 мб RAM, сейчас с решарпером 1 гига мало, если несколько студий открывать)
Здравствуйте, AndreyR7, Вы писали:
AR>Здравствуйте, l33thaxor, Вы писали:
AR>>>Кажется увидел слово unsafe? Здравствуй обратно ручное управление памятью? L>>... и досвиданья. unsafe не имеет никакого отношения к ручному управлению памяти. Учись, пока молод. AR>Ну здрасьте, приехали. А значит арифметика указателей — это не ручное управление памятью? Или в управление памятью входит только операции new/delete(GC)? Или ошибки в плюсовых программах типа "BlahBlah. Memory can't be read" — это наверное неправильное использование оператора new?
Не смешивай все в одну кучу. А то получится балаган, как с твоим бестолковым бенчмарком.
AR>Я имел в виду широкое понятие, не только выделение/освобождение, но и работа с памятью. И слово unsafe как раз об этом.
Люблю дискуссии на rsdn. Как только кто-нибудь пропирается, начинаются попытки подменить понятия. Ну, да ладно, по доброте души пошлю тебя на wikipedia:
Memory management is the act of managing computer memory. In its simpler forms, this involves providing ways to allocate portions of memory to programs at their request, and freeing it for reuse when no longer needed.
А то, что в моем коде происходит, называется pointer arithmetics. Это тебе на будущее, чтоб знал.
L>>Я видел тут у некоторых такую зелененькую подпись: "эксперт". Пора вводить новую, ярко красную мигающую: "студент". AR>Ага. И синюю жирную "умник". Уважаемый l33thaxor, оставьте свое мнение при себе.
Иногда приходится учить студентов. Ничего не поделаешь.
Здравствуйте, l33thaxor, Вы писали:
L>Я видел тут у некоторых такую зелененькую подпись: "эксперт". Пора вводить новую, ярко красную мигающую: "студент".
Ты сам себя к которым причисляешь?
Зелёненькой надписи рядом с твоим ником что-то не видно...
Здравствуйте, COFF, Вы писали:
COF>Не, все правильно, условия уравниваются так — на C++ метод at и на C# метод at. То что на C++ этот метод заинлайнится является его преимуществом. У меня, например, как раз за счет инлайнов release версия часто работает на порядок быстрее debug. Без потери читаемости кода. К тому же в исходных условиях автор явно был против написания одной большой функции.
C++ метод at — уродство. Вопервых можно руками написать асерт, правда тут еще замут с стльной беззнаковостью. Нужно иметь возможность включать ранже, а где она?
Здравствуйте, AndreyR7, Вы писали:
AR>1) Не использовать ничего стороннего. В случае C# — только managed код (никакого interop & unsafe) + .Net framework, в случае C++ — только сам язык + STL.
В STL комплех чем дальше тем чуднее, там проверки на нвалуе встречаются непонятно зачем, деление с лишней нормировкой. Ну и вообще наворочено
Здравствуйте, MatFiz, Вы писали:
MF>Здравствуйте, l33thaxor, Вы писали:
L>>Вот такой код MatrixComplex класса на C# уделывает первоначальный код на C++ на 25% (1.36s (C#) vs 1.75s (C++)):
MF>Может и уделывает, но согласись, это не C# уже в том виде, в котором его хочется видеть
А вам хочется чтобы и красиво, и быстро, и GC работал? Спуститесь на землю, такого не бывает.
Всетаки на C# можно писать отличающиеся по скорости на проценты (а не на порядки) от С++. Для C# это отличный результат
