LINUX.ORG.RU

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


0

0

Страуструп описал вкратце улучшения, грозящие всем программёрам С++ в следующем стандарте, который должен выйти к 2009 году. Немалая толика софта под линукс пишется на С++ поэтому новость будет интересна не только разработчикам, пишущим на С++. Итак, что же нам светит:

* язык будет лучше поддерживать системное программирование
* язык будет проще в обучении и преподавании

Обещается опциональная сборка мусора и поддержка параллелизма. Внимание разработчиков стандарта фокусируется на расширениях, которые "меняют способ которым люди думают" (дословно!). Добавлено наиболее значительное расширение - "концепция" как "тип типов" (посредством where-выражения) и обобщенный список инициализации. Обещано, что вектора базовых типов будут работать не медленнее встроенных массивов тех же типов. В общем всё для того, чтобы сделать обощённое программирование таким же мейнстримом как объектно-ориентированное.
Также комитет по языку уже проголосовал за добавку в STL хешей, регекспов, смарт-поинтеров, генераторов случайных чисел и математических спец-функций. Появится новый тип итераторов - auto с автоопределением своего типа. Наконец-то стандартизаторы обещают уделять внимания простоте не меньше, чем гибкости но, тем не менее, не в ущерб последней.

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

>>> Подробности

★★

Проверено: Pi ()

Ответ на: комментарий от Begemoth

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

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

Pi ★★★★★
()
Ответ на: комментарий от Begemoth

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

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

Pi ★★★★★
()
Ответ на: комментарий от Pi

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

я видел этот

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;
};

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

YesSSS ★★★
()
Ответ на: комментарий от Begemoth

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

Zulu ★★☆☆
()
Ответ на: комментарий от anonymous

>Например:

>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

aka50
()
Ответ на: комментарий от YesSSS

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

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

Pi ★★★★★
()

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

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

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от pavel_pimenov

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

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

Pi ★★★★★
()
Ответ на: комментарий от anonymous

> SmallTalk?

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

anonymous
()
Ответ на: комментарий от anonymous

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

svu ★★★★★
()
Ответ на: комментарий от anonymous

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

(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))))


ugoday ★★★★★
()
Ответ на: комментарий от dees

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

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

darth
()
Ответ на: комментарий от ugoday

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

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

aka50
()
Ответ на: комментарий от darth

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

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

anonymous
()
Ответ на: комментарий от Zulu

1. это Haskell

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

Begemoth ★★★★★
()
Ответ на: комментарий от Sun-ch

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

anonymous
()
Ответ на: комментарий от Begemoth

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

Zulu ★★☆☆
()
Ответ на: комментарий от Zulu

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

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

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

Begemoth ★★★★★
()
Ответ на: комментарий от anonymous

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

Begemoth ★★★★★
()
Ответ на: комментарий от Begemoth

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

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

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

aka50
()
Ответ на: комментарий от aka50

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

Begemoth ★★★★★
()
Ответ на: комментарий от Begemoth

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

Begemoth ★★★★★
()
Ответ на: комментарий от Begemoth

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

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

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

aka50
()
Ответ на: комментарий от ugoday

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

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

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

Spectr ★★★
()
Ответ на: комментарий от aka50

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

Begemoth ★★★★★
()
Ответ на: комментарий от Begemoth

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

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

YesSSS ★★★
()
Ответ на: комментарий от anonymous

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

prasthita
()
Ответ на: комментарий от YesSSS

2 YesSSS

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от ugoday

>(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-ов не корректно с точки зрения стандарта, хотя работает на практически всех реализициях.

rusl
()
Ответ на: комментарий от darth

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

MOByte
()
Ответ на: комментарий от MOByte

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

Begemoth ★★★★★
()
Ответ на: комментарий от anonymous

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

Begemoth ★★★★★
()
Ответ на: комментарий от darth

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

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

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

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

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

Yilativs ★★★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

ugoday ★★★★★
()
Ответ на: комментарий от Yilativs

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

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

r ★★★★★
()
Ответ на: комментарий от anonymous

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.