быстрый взгляд на C++0x

Haskell рулит!

>Нафига чтолько строк?

хммм.... не поспоришь :)

>А каким местом он ОО язык?

общепризнаным, хотя ОО-ости это не прибавляет :(

приведите - мне оч. интересно :)

Бегемот привел.

я видел этот

template<unsigned int x>
struct fact_v1
{
  static const unsigned int res = x * fact_v1<x - 1>::res;
};

template<>
struct fact_v1<0>
{
  static const unsigned int res = 1;
};

смысл в том, что все вычисления проводит компилер, в рантайме остается только число.

не понял, какой это язык, но видимо тут 1) создается множество 2) итератор, который бегает по этому множеству. Не уверен, что это дешево.

> Ой ну до чего же ты тупой! Иди посмотри на Blender и убей себя.

Хочешь сказать, там визуализатор на Питоне?

>Например:

>MyClass mc(arg1, arg2, ..., argn);
>MyClass newmc(mc); //Для newmc будет вызван конструктор копирования

>anonymous (*) (04.01.2006 15:04:07)

Угу... а что будет если класс объявлен вот так:
class MyClass
{
...
private:
auto_ptr<MyMegaSharedClass> _sharedClass;
...
}

(про boost::scoped_ptr в курсе, тут именно о side-effect
такого неявного определения. Ну и еще есть фича, что
явный конструктор копирования - MyClass(const MyClass&),
а неявный MyClass(MyClass&). )

Вместо одного clone() в Java, в С++ нужно
написать 2-e функции.
MyClass(const MyClass& rhs);
MyClass& operator=(const MyClass& rhs);

И по поводу лени разработчиков - думаю не лень, а именно
борьба за понятность кода (если класс предназначен для
клонирования, объяви это явно). ИМХО это важнее чем
экономия нескольких строчек (хотя в них тоже закрадываются
ошибки, например забытое маленькое данное).

Простая реализация для незамысловатых классов будет довольно
проста, хотя потребует аж 4 (в моем code style) лишних строчки.

class MyClass implements Cloneable
{
...
public Object clone()
{
return new MyClass(this.arg1, this.arg2, ... );
}
...
}

Ну и вызов будет
MyClass obj = obj2.clone();

Если еще об экономии строчек, то в жабе есть семантика this/super,
для чего в c++ приходится захламлять классы всякими
initMe(arg1,... argn). :)

А вообще жава тоже развивается, например вот фичи, которые
могут появится гораздо раньше 2009+ :)
1. 4809540 - Objects in stack. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4809540
2. 4820062 - Structs in Java. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4820062

блин, да мне на хаскеле итересно!

на плюсах, изрядно помучившись, или на каком немерле мне всё достаточно ясно, а вот скажем про хаскель не очень ясно, на скока реально и как - про Template Haskell инфы мало. практического толка мне на данный момент не нужно, но интересно. :)

>Просьба языковой флейм не начинать, языки всякие важны, языки всякие нужны.

Какой он наивный, этот filin. :-)

Blender целиком иполностью написан на plain C. Python используется только как встроенный скриптовый язык.

Если в Java всё так хорошо отлажено, то подскажите пожалуйста как заставить blojsom сохранять файлы на диск с любой кодировкой имён, кроме iso8859-1 под FreeBSD?

> И что? Хочешь сделаю такую же реализацию на С/С++, только без дебильного goto?

а почему в исходниках ядра так много "goto"?

SmallTalk?

>а почему в исходниках ядра так много "goto"?

а ты не путай Гоголя с Гегелем

> SmallTalk?

Я знаю каратэ, дзюдо, тэквандо, и ещё много страшных слов ...

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

Проблемы бздунов индейцев не волнуют

А почему на C++ нельзя написать вот такое приложение: http://javamaniac.com/resource.jsp?id=26 ? Ась? Если вы такие умные?

К вопросу о функциональном и императивном стилях, а также нужности хвостовой рекурсии.

(defun fact (n m) 
  (if (eq n 1) m (fact (- n 1) (* n m))))

(defun fact1 (n)
  (do ((f 1))
      ((eq n 1) f)
      (setq f (* n f))
      (setq n (- n 1))))

> Генерики, появившиеся сперва в java 1.5 потом в .net 2.0 это все-таки не то. Да и производительность их оставляет желать лучшего (надеюсь что пока).

Это как это? Компилятор тормозит на них, что ли? ;)

>К вопросу о функциональном и императивном стилях, а также нужности >хвостовой рекурсии.

Ооо... как же без хвостовой рекурсии то при обсуждении языков :))))

> Это как это? Компилятор тормозит на них, что ли? ;)

Х-ню какую то генерит. Потому и называются "Генерики".

1. это Haskell

2. Факториал определяется как произведение чисел от 1 до n. Компилятор сгенерирует простой цикл, т.к. prod - это простая свертка списка, который создается и используется только локально.

Я не согласен. Например, системы СОИ для летательных аппаратов пишутся целиком в машинных кодах, и ни про какую Java там вообще не вспоминают (как, впрочем, и про C++). Но, черт побери! C++ - это продукт интеллекта, а Java - капитализма.

Ну это он сильно умный 8) В общем случае что-то мне подсказывает что это не сильно дешевый/применимый метод 8) Кстати а где определение prod? или в языке есть предефайнед функция для folding'а list'а при помощи умнодения?

> В общем случае что-то мне подсказывает что это не сильно дешевый/применимый метод 8)

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

prod как и fold[rl] определяются в Predule

Если не вспоминают даже про С (или какой-нибудь DSL), то это говорит о низком профессиональном уровне разработчиков

>Если не вспоминают даже про С (или какой-нибудь DSL), то это говорит о
>низком профессиональном уровне разработчиков

"про С" - это ProC? :)))

А что такого великого в С чего нет в С++? (не мелочей, которых и между
разными С++ компилерами навалом, а принципияльных отличий)?

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

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

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

ну это же можно не использовать когда не надо (например -fno-exceptions) и использовать только структуры... получится практически "С", только с большим type-safe.

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

> Для особо тупых анонимусов поясняю, что вышеприведённый код факториала был на примером хорошего кода на лиспе, а примером _императивного_ применения лиспа. Помоему это было очевидно для любого индивида с неотрицательным iq.

Нах положительный iq? Чтобы приходить на работу, и потом плакать, что пишешь не на лиспе?

Любой уровень iq стоит с толком применять, чтобы он не стал обузой :)

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

Я не писал в машинных кодах, но imho на них тоже должны писать хорошие кодеры (в данном случае скорее упертые).

На C++ полно языковых возможностей, от которых всегда можно отказаться если они мешают.

аты посмотри, на чем в blender'е написан именно шейдер и что в blender'е пишут на питоне... :) потом скажи себе свои слова и исполни свой совет :))

2 YesSSS

/* На C++ полно языковых возможностей, от которых всегда можно отказаться если они мешают. */

Kruto!!! Ne luchshe li togda voobshe otkazatsa ot C++? Tipa, Stroustrup, vali-ka ty v Bobrujsk. Pardon za translit.

>Вообщем, так. В 09 году C++ уже не будет, как сейчас Фортрана и перфокарт. Ага ) Помню мне лет 8 назад тоже про Ассемблер говорили ) А он есть - и активно юзается

>(defun fact (n m) > (if (eq n 1) m (fact (- n 1) (* n m))))

хвостовая рекурсия автоматически не включается, это не Схема.

> >(defun fact1 (n) > (do ((f 1)) > ((eq n 1) f) > (setq f (* n f)) > (setq n (- n 1))))

eq - двух fixnum-ов не корректно с точки зрения стандарта, хотя работает на практически всех реализициях.

>А почему на C++ нельзя написать вот такое приложение: http://javamaniac.com/resource.jsp?id=26 ? Ась? Если вы такие умные?

Пишут батенька. Только называется не аплетом, а вирусом :)

> Генерики, появившиеся сперва в java 1.5 потом в .net 2.0 это все-таки >не то. Да и производительность их оставляет желать лучшего (надеюсь что >пока).

>Это как это? Компилятор тормозит на них, что ли? ;)

Ну и гы-де "в java 1.5 и потом в .net 2.0" просматривается _Компилятор_ !? ( Это к ? о производительности ;-) )

>Да ладно... я пошутил, у нас еще останется Pascal... который, ничем не хуже C++, кроме разве, что неэкономного синтаксиса.

Поздравляю тебя, Шарик. Ты балбес (с)

Очень аргументативно.

А собственно разве эти языки принципиально отличаются?

Глаза протри и посмотри внимательно, и если ты не слепой, то увидишь.

>> Генерики, появившиеся сперва в java 1.5 потом в .net 2.0 это все-таки не то. Да и производительность их оставляет желать лучшего (надеюсь что пока).

>Это как это? Компилятор тормозит на них, что ли? ;)

IMHO человек имел ввиду что идет расход СPU на Class Casting (приведение типов) во время выполнения.

В этом случае расход CPU идет линейно, причем с низким к-том , так что это не проблема.

Подозреваю , что у человека тормозила программа по другой причине (в большинстве случаев это /dev/hands в тежелых случаях /proc/user/DNA).

> Подождите, страница компилируется... [ok] Запустить страницу (y/n)?

Есть интерпретаторы C++, cint, к примеру.

Сервер, оборудованный цэпэпэ интерпретатором --- мечта опенсорс вируса. ;-)

>IMHO человек имел ввиду что идет расход СPU на Class Casting (приведение типов) во время выполнения.

Расход CPU на ЧТО!?!

Ox какой бред! :)

Суровая правда. Вы уже потратили CPU?