Здравствуйте, neFormal, Вы писали:

F>Здравствуйте, Abyx, Вы писали:

F>>>это псевдопотоки.. потоки в одном системном потоке..
A>>я не знаю, может вы говорите про какую-то одну версию питона для какой-то ОС,
A>>но у меня на винде питон нормально работает в нескольких системных потоках, и использует системные потоки для своих потоков,
A>>см. \Python\thread_nt.h

F>не, падажжи.. ты хочешь сказать, что у тебя питон без GIL-а?. и данные не разрушаются?.

c GIL'ом. только он не мешает ни разу %)

Здравствуйте, Abyx, Вы писали:

A>c GIL'ом. только он не мешает ни разу %)

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

Здравствуйте, Ziaw, Вы писали:

F>>ну если сложные типы передаются по ссылке и сигнатура метода создаётся лишь однажды при объявлении/импорте, то логично, что список создаётся на момент объявления функции и живёт там продолжительное время..
Z>Это причина, а не логика. Логика подсказывает, что следующие вызовы должны быть эквивалентны, но это не так:
Z>

Z>make_list(42)
Z>make_list(42, [])
Z>

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

Здравствуйте, neFormal, Вы писали:

F>а снаружи они эквивалентны а вот внутренняя реализация зависит..
F>вот если бы там использовалась глобальная переменная, было бы это таким же недостатком?. или если бы по-дефолту второй параметр был бы интом?.
F>просто нюанс языка.. совсем не страшный и не фатальный..

Не фатальный, но совсем нелогичный. В руби тоже списки передаются по ссылке, но пример работает вполне ожидаемо.

def make_list(element, head=[])
    head << element
end

print make_list(42)
print make_list(42)

Здравствуйте, neFormal, Вы писали:

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

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, Курилка, Вы писали:

К>>А покажи неривиальную валидаци, не вписывающуюся в JSR-303?

D>А в Spring MVC можно к параметру контроллера страницы (т.е. к GET-параметру HTTP-запроса) прикрутить этот самый JSR303-валидатор, и спринг его зацепит? Если да, тогда данная претензия снимается.

Ну вешаешь @Valid на параметр просто.
Но это опять же демонстрация заморочности построения функционала фреймворка на аннотациях, о чём ты выше писал.

Здравствуйте, Lloyd, Вы писали:

L>К чему все это? Я тебе специально вопрос выделил жирным. Выбор var/декларация типа — исключительно иллюстрация того, что изменение синтаксиса — не такая тривиальная задача. Дабы тема опять не съехала в сторону, повторюсь, что речь не о технической стороне дела, а о концептуальной.

Да нет в этом выборе ничего особенного. Здесь опять же речь идет о клинически пугливых теоретиках и практиках.
Потом тебе уже раз сто сказали, что в случае макросов это выбор конкретной группы людей работающих над конкретным проектом. Как из этого вытекают те ужасы на которые ты намекаешь я не понимаю.

L>Я вижу проблему в приведенном примере, я вижу на примерах nikov-а, что и в шарпе полно нелогичностей и неоднозначностей. Какие еще мне могуть понадобиться подтверждения того, что проблема реальна?

Ладно. Я наблюдаю очередной приступ клинического фанатазирования с твоей стороны. Мне это уже право надоело.

В примерах, Никова, кстати, очень редко появляются примеры именно синтаксических аномалий. Все они связаны с кривым дизайном C# авторы которого предпочли совместимость с С-ишными принципами прямому дизайну. Учитывая, что все эти ошибки сделаны еще в самых первых версиях я вообще не понимаю причем тут расширяемость.

Основная же часть этюдов Никова — это семантические этюды. С синтаксическими расширен они никак не связаны.

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

Здравствуйте, Философ, Вы писали:

Вот, буквально на днях пришлось писать совершенно дурацкий код для преобразования Tuple<DerivedClass, string> в Tuple<BaseClass, string>. То же самое для immutable списка (я использовал FSharpList<T> из C#).
Ну и как уже заметили, отсутствие краткого синтаксиса и pattern matching для этих типов.

Здравствуйте, VladD2, Вы писали:

VD>Это в любом языке есть. Более того, если есть более одного компилятора, то у каждого могут быть свои особенности.
VD>Я не понимаю где здесь именно непредсказуемость?

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

Здравствуйте, neFormal, Вы писали:


F>не, падажжи.. ты хочешь сказать, что у тебя питон без GIL-а?. и данные не разрушаются?.
F>дай погонять, а?.

Нет он прав, тот же модуль threading создает вполне полноценные системные потоки.
Но интерпретатор их постоянно блокирует из-за GIL, в результате особенно на SMP все работает еще медленнее чем
было бы в одном потоке. Исключение сишные библиотеки которые могут сразу отпускать GIL если не обращаются к интерпретатору,
что и было продемонстрировано на примере numpy.

На вскидку:
1. Нет поддержки двоичной системы — int a = 0110010b написать нельзя
2. Неявное приведение char* -> bool, double -> int
3. template <double> — не работает, ровно как и например template <std::string>
4. Долго компилируется и линкуется
5. Нет проверки переполнения, типа как в C#: checked { a = b * c; }
6. Нельзя расширить enum объявленный в базовом классе в производном классе

Здравствуйте, FR, Вы писали:

FR>было бы в одном потоке. Исключение сишные библиотеки которые могут сразу отпускать GIL если не обращаются к интерпретатору,
FR>что и было продемонстрировано на примере numpy.

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

Здравствуйте, Слава, Вы писали:

С>Это не ерунда, а трудно вылавливаемые баги в будующем. У нас по умолчанию W4 и работаем без варнингов.

Какой здесь может быть баг?:

class X {
    int const i_;
public:
    X(int i) : i_ (i) {}
}; // warning C4512: 'X' : assignment operator could not be generated

Здравствуйте, Abyx, Вы писали:

A>если ваш код не компилится с /W4 — правьте ваш код.

Как править следующий код, выбрасывать const?:

class X {
    int const i_;
public:
    X(int i) : i_ (i) {}
}; // warning C4512: 'X' : assignment operator could not be generated

Здравствуйте, okman, Вы писали:

O>>>Отсутствие двоичного стандарта.
J>>Посмотрел бы я на этот стандарт, который бы удовлетворил и 64-битовым билдам, и 8-битным микроконтроллерам

O>А мне бы хватило стандарта для одной определенной платформы (Windows) — схема расширения имен,
O>объектные файлы, передача объектов/исключений между модулями и тому подобное.
O>Чтобы можно было гарантировать совместимость интерфейсов C++ между теми же dll, собранными
O>разными компиляторами. Может быть, в таких громадинах как COM тогда и не было бы необходимости.

Дык для Windows есть считай стандартизированый ABI — MSVC.
Другой вопрос что следуют ему не все.

O>Куда эта дорога ведет?
К сохранению принципа "платишь только за то, что реально используешь". И это для С++ краеугольный камень

O>>>Отсутствие единого глобального соглашения о скобках, отступах и именах.
J>>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться?

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

bool AcquireCompletionToken (ThreadHandle& handle)
{
    if (handle.GetOwnerThread != PerfThreadId (s_resourcePool->GetThisThread ()))
        return false;

    return PerfThreadAcqToken (handle.GetStorage ());
}

Вот и какой стиль надо принимать за "единственно правильный" (тм)?

O>Я к тому, что некоторые существующие концепции программирования в C++ эволюционировали в нечто
O>настолько сложное и запредельное для понимания обычными людьми, что сильно потеряли, на мой взгляд,
O>в практическом отношении.
Это по мне означает что эти концепции надо пересматривать в сторону упрощения.

O>Мне нравится, когда шаблоны используются как в STL или бустовских смартпоинтерах, или как обертки для COM-интерфейсов в ATL, но когда из них делают что-то, понятное лишь гуру метапрограммирования — это перебор.
А, ты про это. Ну, ИМХО творчество укушенных Александреску нравится только таким же укушенным. И по хорошему такой код надо на помоечку, авторам скипидарную клизму и пусть переписывают заново, без извратов.

O>>>Очень много платформенных "заточек" вроде #pragma, __declspec и #ifdef _X64.
J>>Вообще-то возможность заточки под платформу — это фича языка
O>Если заточек становится слишком много, значит язык не справляется со своей задачей.
Ну как бы нельзя внести в системный язык фичи всех потенциально поддерживаемых платформ. Они ж зачастую друг другу ортогональны.

Здравствуйте, dimgel, Вы писали:

D>Позвольте представить: говно, просто говно. Я не могу придумать ничего, что бы мне в нём нравилось.
Сурово!

Здравствуйте, Ytz, Вы писали:

Ytz>1. Нет поддержки двоичной системы — int a = 0110010b написать нельзя
мгу ошибаться, но вроде как в С++0х это пофиксили.

Ytz>3. template <double> — не работает, ровно как и например template <std::string>
Можно пример, а то я что то не совсем понял что тут имеется в виду.

Ytz>5. Нет проверки переполнения, типа как в C#: checked { a = b * c; }
реализуется через перегрузку операторов.

Ytz>6. Нельзя расширить enum объявленный в базовом классе в производном классе

Не надо такого делать никогда и нигде. И уж тем более не надо приводить базовый класс к производному.

Здравствуйте, igna, Вы писали:

I>Какой здесь может быть баг?:

I>

I>class X {
I>    int const i_;
I>public:
I>    X(int i) : i_ (i) {}
I>}; // warning C4512: 'X' : assignment operator could not be generated
I>

Там ж написано: не могу сгенерить operator=
Потому как i_ константное.

Здравствуйте, igna, Вы писали:

I>Как править следующий код, выбрасывать const?:

I>

I>class X {
I>    int const i_;
I>public:
I>    X(int i) : i_ (i) {}
private:
    X& operator= (const X&);
I>}; // warning C4512: 'X' : assignment operator could not be generated
I>