C++ 11

GNUStep

R.I.P.

ок.

предали ObjC анафеме.

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

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

Слухи сильно преувеличены.

GNUStep

Это даже не смешно.

Слухи сильно преувеличены.

пробовал я ее - таки не преувеличены, такое не взлетит, только всплывет

узри взором внутреним C(императивный ассемблер) + рантайм для «безклассовой» обьектной модели

Объектная модель там очень даже классовая, только для сообщений используется утиная типизация.

вот такое Г вытесняет сейчас C++

где, кроме Mac OS X и iOS?

обьектная модель С++ был компромиссом

Вначале, потом просто поняли, что ООП - не единственная парадигма. Современный С++ - это не ОО язык.

Да ты просто хейтер :}

Мне не нужен. Хватает c, cl, erlang и tcl для моих задач.

http://www.catb.org/~esr/writings/world-domination/world-domination-201.html

так что если макось сменит уинду на рынке ширпотреба ибо всё вокруг 64битное (более или менее) так что достаточно.

в objС классы рантайма , а не компайлтайма(структура ,наследование и все дела)

все языки массовые - мультиНЕХальные.

со стороны энтерпрайза C++ подпёрт Java (бюрократия) и C# (уинда)
со стороны эмбеддеда С
cо стороны бытовой электроники ObjC

т.е C++ ещё будет коптить небо десятилетия - как Фортран - однако новоё на нём нет смысла начинать , ибо С++ не фронтир уже и не настолько низкий (C) чтоб быть наименьшим фактором.

cо стороны бытовой электроники ObjC

Бытовая электроника ограничивается поделями Яббла?

Бытовая электроника ограничивается поделями Яббла?

Ага, холодильники iCold, стиральные машины iClean и микроволновые печи iHot.

Пылесосы iBlow забыл :)

Но мой скромный опыт работы с этой библиотекой говорит (как-то от нечего делать тыкал spirit), что её можно использовать лишь для забавы: любая ошибка порождает многостраничный, абсолютно нечитаемый выхлоп компилятора. Единственный способ найти эту ошибку - планомерное комментирование и локализация.

о да! Компилируется долго, и имеено со спиритом я сталкивался с gcc: aborted (или что-то в этом роде)

вообще я хотел выяснить, нужно ли знание с++11 на современном рынке труда. Т.е. допустим, [забугорная]контора ищет С++ разработчика - они уже имеют в виду С++11 или старый стандарт?

В любом случае, учить надо. Да.

Нужен?

Нужен настолько же, насколько и Си++.

со спиритом я сталкивался с gcc: aborted (или что-то в этом роде)

Памяти не хватило, это со спиритом бывает :-) Грамматику надо разбивать на части, которые раздельно компилируются.

нужен, в новых проектах уже использую вместо буста

Везет тебе, а некоторым приходится msvc2008 до сих пор на работе использовать ;) Привет от коллеги бывшего (меня) :)

qrck

Везет тебе, а некоторым приходится msvc2008 до сих пор на работе использовать ;)

А 2005 не хо?

А 2003 не хо? Есть один проектик в нашем вузе, считается передовым таким и уникальным, на него ещё регулярно первокурсников тащат. Под более новыми студиями не работает.

Да хрен с ним, с ВУЗом. От них я всего ожидать могу.

З.Ы. У нас специально обученные люди уже давненько пилят переход на 2008-ую (ЕМНИП только из-за распараллеленой компиляции) и пока недопилили. Потому что кода и подпроектов дофигища.

Объектная модель там очень даже классовая

Это да

только для сообщений используется утиная типизация.

А вот тут не совсем верно. Не утиная, а динамическая ( и уже динамическая влечет утиную). Утиная типизация присутствует и в статически типизированных языках (С++, OCaml). А в ObjC - динамическая типизация.

А в ObjC - динамическая типизация.

Выражения там имеют вполне определённый при компиляции тип, так что типизация там вполне себе статическая.

Выражения там имеют вполне определённый при компиляции тип

Та часть язык что от С - да, статически, но та часть что от SmallTalk - динамически типизированная: [[otherObject getObject] doSomething] - тип [otherObject getObject] статически может быть не известен => тип всего выражения не известен, просто он потом приводится автоматически к типу переменной, куда присваивается это выражение.

В утиной статической типизации ошибки об отсутсвии метода возникают на этапе компеляции :

struct A { void a() {}; }
struct B { void a() {}; }
struct C { void m() {}; }
template<T> function dummy(T * t) {
  t.a();
}
dummy(new A()); // OK
dummy(new B());  // OK
dummy(new C()); // Compile time error

[[otherObject getObject] doSomething]

А как же методы, которые возвращают значения встроенных типов?

Максимум варнинг выдаст. Ну а питон в этом случае бросает исключения.

А итог один - программу на ObjectiveC трудно верифицировать статически, без запусков на всевозможных ручных и автоматических тестах. В C++11, кстати, появилось несколько новых фич для проверок на этапе компиляции. Жаль, что пока не могу юзать - override/final только в GCC 4.7 появился, да и static_assert может отсутствовать на некоторых компиляторах. Кстати, какие ещё фичи для статических проверок имеются?

Под более новыми студиями не работает.

В чём причина? Неужели, если писать кошерно под 2003 студию, то потом это нельзя будет скомпилять под 2010?

Я думаю, проблема лишь в том, что проект написан через одно место, используя грязные хаки, вендор-специфик фичи и прочий кал носорога. А если так, то сами себе злые буратины.

ага вполне определёный [Object]

оно конечно сужает выбор .

quiet_readonly

да и static_assert может отсутствовать на некоторых компиляторах

Дык его самому написать - минута времени.

ага. напиши свой компилятор приводит к лиспофилии.

static assert на С++ уже 1000 лет как сделан и описан у того же Александреску. От десятка строк проект не разжиреет.

Единственный способ найти эту ошибку - планомерное комментирование и локализация.

Еще есть delta :D

Это тот, в котором сообщение должно быть в виде Int_Must_Be_4_Bytes?

Что это такое?

а как дела в бусте обстоят с move semantic ? - не знаешь

http://delta.tigris.org/

anonymous

Это тот, в котором сообщение должно быть в виде Int_Must_Be_4_Bytes?

Типо того. Набыдлокодженый вариант дает:

main.cpp:20:9: error: ‘class static_assert_check<false>’ has no member named ‘is_ok’

template <bool check> class static_assert_check { };

template <> class static_assert_check<true>
{
public:
    void is_ok() {}
};

#define static_assert(x) do { static_assert_check<x>().is_ok(); } while (false)

int main()
{
        static_assert(2*2==5);
}

Не сработает, если запихать static_assert в класс. Вариант с массивом вроде бы должен работать везде, где надо. В качестве fallback вполне сойдёт макрос с двумя параметрами, который просто игнорирует второй параметр. Ну не будет красивого сообщения, но главное, что компиляция обломается.

а как дела в бусте обстоят с move semantic ?

В некоторых местах встречал костыль по аналогии со старым-добрым auto_ptr.

Я вот глянул сейчас это есть только для контейнеров и все пока

const86

Не сработает, если запихать static_assert в класс.

Что сделать? Не понял.

Если ты про возможность засунуть проверку вне функции (в т.ч. и глобально), то

template <bool check> struct static_assert_check { };

template <> struct static_assert_check<true>
{
    typedef int is_ok;
};

#define static_assert(x) static static_assert_check<x>::is_ok _check_##__FILE__##_##__LINE__

Ограничение - не более одного на строку (жить можно).

Да, можно так.

не нужен. не использую. не использую.

C++

спасибо, не надо.

Мне не нужен. Хватает c, cl, erlang и tcl для моих задач.

Ты тут самое небыдло, типа?

Если ты себя быдлом считаешь, то это только твои проблемы, мне пофиг.

А что нужно тогда? О.о

Список нужных языков есть у меня в профиле.

Люблю: Scheme, Forth, APL, Smalltalk, языки Вирта и им подобные
Не люблю: C++, Haskell

О, член тусовки его Величества VSL. Но почему тогда в списке нужных нет Common Lisp? О.о
Но от цпп никуда не отвертеться, слишком уж много на нём написано и слишком он раскручен чтобы выпилиться из индустрии.

Потому что Common Lisp не слишком-то нужен, очевидно.

слишком уж много на нём написано

Не так много, как кажется.