Стрижиное

[migmit]

Ну что, попробовал я таки этот Swift. Скачал бету XCode, распаковал, запустил. И доложу я вам: это штука с огроменным потенциалом. В смысле, ни фига не работает.

Я, честно сказать, думал проверить ихние дженерики своим любимым тестом, который C++ не прошёл, а, скажем, Java — вполне. Наивный.

Дело в том, что когда вы пишете код в XCode, то вам показывают места ошибок. Это очень удобно. Однако делается это путём запуска компилятора в фоне. А компилятор сей страдает падучей. И когда он сегфолтится — а это происходит довольно часто — весь XCode вылетает нафиг.

Дальше ещё веселее. Вы запускаете XCode заново, он восстанавливает тот же файл, снова прогоняет его через компилятор, тот снова сегфолтится, и XCode снова вылетает.

Я не смог запилить такой код, который проверял бы мой тест и при этом не сегфолтился.

Так что пока ихняя бета (которая beta than nothing) отправляется в корзину. Увы.

Comments

[alex-public.livejournal.com]

Ваша задачка тривиально решается на C++ (кстати, это решение я уже давно выкладывал на rsdn):

#define cint struct{const int value;}
template<typename T> class Cons{
    vector<int> data;
    Cons()=default;
    template<typename S, typename F> friend Cons<S> MakeCons(S s, F f);
    template<typename S> friend int ScalarProduct(const Cons<S>& c1, const Cons<S>& c2);
};
template<typename S, typename F> Cons<S> MakeCons(S s, F f)
{
    Cons<S> r;
    for(int i=0; i<s.value; i++) r.data.push_back(f(i));
    return r;
}
template<typename S> int ScalarProduct(const Cons<S>& c1, const Cons<S>& c2)
{return inner_product(c1.data.cbegin(), c1.data.cend(), c2.data.cbegin(), 0);}
int main()
{
    int n;
    cin>>n;
    cint size{n};
    auto cons1=MakeCons(size, [](int i){return i;});
    auto cons2=MakeCons(size, [](int i){return i+1;});
    //cint size1{n+1};
    //auto cons2=MakeCons(size1, [](int i){return i;});//а такое не будет компилироваться
    cout<<ScalarProduct(cons1, cons2)<<endl;
} 

Причём такой подход позволяет спокойно создавать компоненты для произведения не обязательно внутри одной функции, как в примерах C#/Java. Ну а про расход памяти и быстродействие думаю можно даже не упоминать — они тут получаются вообще не сравнимыми... )

Что касается Swift'a, то по набору качеств (во всяком случае судя по документации - саму среду я не ставил и не собираюсь) он больше всего напоминает обрезанный D (без метапрограммирования, без интроспекции, без исключений и поддержки многопоточности). Однако даже такой обрезанный D в любом случае выглядит лучше чем C#/Java...

А вот настолько глючной компилятор - это конечно беспредел...

[migmit.livejournal.com]

Ну, пример не смешной. В нём столько очевидно неверного, что не знаешь, с чего начать. Ну, например:

    decltype(size) size1{n+1};
    auto cons3 = MakeCons(size1, [](int i) {return i+1;});
    cout << ScalarProduct(cons1, cons3) << endl;

[alex-public.livejournal.com]

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

#define cint(x) [v=int(x)]{return v;}
...
auto size=cint(n);//теперь записываем так
decltype(size) size1=cint(n+1);//тут компилятор пошлёт )))

[migmit.livejournal.com]

Помилуйте, если бы речь шла о сознательном противодействии, то всё было бы куда проще, был бы банальный const_cast или C-style cast. Я уже уменьшил свои требования и согласен не рассматривать хотя бы то, что традиционно считается грязным хаком (хотя и всё равно все делают). Но decltype — штука совершенно безопасная, она для того и придумана.

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

#define mint(x) [v = int(x)] () mutable {return v++;}

?

Да, мне интересно, как далеко вас заведёт DTDD.

> конкретно эта ваша проблема

Извините, это ВАША проблема. Не моя.

[alex-public.livejournal.com]

Я согласен, что decltype - это нормальная вещь. Потому и показал исправление.

А вот против этого вашего mint я уже защиту показывать не буду (хотя она тут же возникла в голове), т.к. это уже просто бред. Это приблизительно тоже самое, что требовать нормальной работы функции записи в файл при передаче ей дескриптора файла, открытого на чтение.

Кстати, если рассматривать уже такой уровень претензий, то что будет, если передать null вместо одного из Cons'ов в вашем примере на C#? )

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

[migmit.livejournal.com]

> Это приблизительно тоже самое, что требовать нормальной работы функции записи в файл при передаче ей дескриптора файла, открытого на чтение.

Кстати, есть разработки, которые это учитывают. И не скомпилируют такую функцию. Светлой памяти Microsoft Vault, например.

> то что будет, если передать null вместо одного из Cons'ов в вашем примере на C#?

Ну как бэ то и будет, что происходит при использовании грязных хаков.