Re[2]: За что я не люблю С++ - Компьютерные священные войны

Здравствуйте, Игoрь, Вы писали:

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

_>>

_>>    int* p = NULL;
_>>    int a = 1;
_>>    int c = 10;
_>>    p = &a;
_>>    int b = ( p == NULL ? c : *p) / 100;
_>>

И>Можно чуть короче, явно не делать проверку на NULL:

И>

И>int* p = NULL;
И>int a = 1, c = 10;

И>int b = (p? *p : c) / 100;
И>

То есть ради такой єлементарщины надо вводить доп. переменную?
Ок.
Усложним задачу:

int? a = 1;
int c = 10;
int? b = (a == null ? a : c) / 100;

Здравствуйте, Игoрь, Вы писали:

И>

И>int* p = NULL;
И>int a = 1, c = 10;

И>int b = (p? *p : c) / 100;
И>

Ну так, <censored> нам кабанам, обобщим, и научим тупой С++ работать с nullable

template <typename T>
class nullable
{
public:
    nullable(T* p ,T val )
    { 
        res =  p ? *p : val  ;
    }
    T res;
};

int main(int argc, char* argv[])
{
    int* p = NULL;
    int a = 1;
    int c = 10;
    p = &a;
    
    b = nullable<int>(p,c).res / 100;

    return 0;
}

Здравствуйте, Игoрь, Вы писали:

И>Мы сейчас говорим о конкретных языках или "вообще"? Если говорить "вообще", то я могу согласиться, что в С++ константность — это сбоку бантик, который легко снимается конст-кастом. И это все дело можно было бы сделать намного лучше, делая сейчас и не думая об обратной совместимости. С этим я как бы и не спорю. Но только при чем здесь C++ и C#?
C# тут действительно не причем.
Тут С++ мочат

И>И с этим я не спорю, и то, что они могли сделать нормально — согласен, но сейчас есть то, что есть. А то что есть не особо лучше того, что есть в С++.
По своему опыту могу сказать что таки сильно лучше.

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

WH>Тут С++ мочат

Пытаются, сравнивая его с C#

И>>И с этим я не спорю, и то, что они могли сделать нормально — согласен, но сейчас есть то, что есть. А то что есть не особо лучше того, что есть в С++.
WH>По своему опыту могу сказать что таки сильно лучше.
Ну так может ты приведешь конкретные примеры из твоего опыта, особенно интересны связанные с mutable/immutable? Потому что я серьезных преимуществ пока не вижу, кроме как иногда хочется в С++ использовать что-то более легковесное а-ля const_string, только не как замену string. С другой стороны и в C# иногда хочется использовать какой-то аналог string с возможностью записи.

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

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

C>>То, как сделано в С# — ГОРАЗДО лучше. Строки обязаны быть immutable по той причине, что:
C>>var str = "abc";
C>>var str2 = "abc2";
C>>ссылаются на один и тот же участок памяти str == str2 true.

C>Опечатка. str2 = "abc" конечно же.

Кстати, а что мешает и варианты "abc" и "abc2" хранить в одной области(имеется ввиду сами буфферы, объекты будут разными в любом варианте)?
Длина заключена в объекте(а не определяется положением терминирующего символа), при этом строки никогда не будут изменены.
Так ли это в реале, не знаю, но ничего не мешает так устроить.

Здравствуйте, Игoрь, Вы писали:

И>Пытаются, сравнивая его с C#

Ты меня с кем-то путаешь.

И>Ну так может ты приведешь конкретные примеры из твоего опыта, особенно интересны связанные с mutable/immutable?
С immutable всегда проще.
Причем это не только строк касается.
Особенно если язык заточен на работу в этом стиле.
Тут я уже приводил пример кода работающего исключительно с неизменяемыми данными.
Даже если этот код оставить на немерле но переписать так чтобы AST изменялся по месту получится серьезное усложнение.
Со строками все не так печально но там тоже хватает головной боли особенно в многопоточной среде.

И>Потому что я серьезных преимуществ пока не вижу, кроме как иногда хочется в С++ использовать что-то более легковесное а-ля const_string, только не как замену string.
И создать еще одну строку...

И>С другой стороны и в C# иногда хочется использовать какой-то аналог string с возможностью записи.
Зачем?

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

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

C>...
C>>Специально для Вас выделил ключевое.

C>Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:

C>

C>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

C>Потом вы пишете

C>

C>А никто и не утверждал, что интерфейс является полным контрактом класса

C>Не будем углубляться в аспекты русского языка, но если к примеру колесо это неотьемлемая часть машины (давайте не разводить демагогию о том какие бывают машины), то нельзя написать:
C>Колесо — это чисто машина.
C>Надеюсь в этот раз я вас не запутал и привёл нормальные доводы.

Мне кажется, ты не прав. Например, я утверждаю что Подработка это чисто доход. При этом я не утверждаю, что подработка это полный мой доход. Это часть полного дохода.

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

C>Ок.
C>Усложним задачу:

C>

C>int? a = 1;
C>int c = 10;
C>int? b = (a == null ? a : c) / 100;
C>

Простейшее решение:

template<typename T>
struct Nullable {
  T val;
  Nullable() : null_(true){}
  Nullable(const T &rhs) : val(rhs), null_(false){}
  bool isNull() const { return true; }
  operator const T &() { if (null_) throw /* что надо, то и выкидываем */; return val; }
  const Nullable & operator = (const T &rhs) { val = rhs; null_ = false; return *this; }
private:
  bool null_;
};

// ...
Nullable<int> a(1);
int c = 10;
Nullable<int> b = a.isNull() ? a : (c / 100);

Арифметику и логические операции можно добавить по вкусу.

P.S.: Про строки, я так понимаю, ответа не будет?

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

И>>Потому что я серьезных преимуществ пока не вижу, кроме как иногда хочется в С++ использовать что-то более легковесное а-ля const_string, только не как замену string.
WH>И создать еще одну строку...

А в чём проблема? Реализаций строк можно иметь хоть мильён. Работа с таким зоопарком просто и складно унифицируется набором свободных функций типа такого:

template<typename Str1_, typename Str2_> void assign(Str1_ *, const Str2_ &);
template<typename Str_> int getLength(const Str_ &);
template<typename Str1_, typename Str2_> int getSubstring(Str1_ *, const Str2_ &, int pos, int length);

Некоторое исключение составляют ASCIIZ-строки, с остальными особых заморочек нет.

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

И>>Ну так может ты приведешь конкретные примеры из твоего опыта, особенно интересны связанные с mutable/immutable?
WH>С immutable всегда проще.
WH>Причем это не только строк касается.
WH>Особенно если язык заточен на работу в этом стиле.
WH>Тут я уже приводил пример кода работающего исключительно с неизменяемыми данными.
WH>Даже если этот код оставить на немерле но переписать так чтобы AST изменялся по месту получится серьезное усложнение.
Не, ну хорошо, кто бы спорил. Раз подходит для каких-то задач, замечательно. Мне такое пока не нужно.

WH>Со строками все не так печально но там тоже хватает головной боли особенно в многопоточной среде.
Вот как раз с многопоточностью и строками я как-то никогда проблем не имел.

И>>Потому что я серьезных преимуществ пока не вижу, кроме как иногда хочется в С++ использовать что-то более легковесное а-ля const_string, только не как замену string.
WH>И создать еще одну строку...

Иногда для оптимизации и не такое приходится делать, например выкидывать std::vector, из-за того, что тот свой буфер зануляет.

И>>С другой стороны и в C# иногда хочется использовать какой-то аналог string с возможностью записи.
WH>Зачем?
Например есть строки размером от 50КБ до 5МБ, надо найти и вырезать какие-то куски без лишних релокейшинов. Все что мне нужно — хоть простой набор алгоритмов над текстовым writable буфером.

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

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

J>>Там в полный рост зоопарк компиляторов.
J>>Это можно записать в недостатки С++ как платформы, но не С++ как языка.
WH>Далеко не только.
WH>Там тонны костылей для извлечения метаинформации.
WH>Куча костылей для того чтобы сделать какой нибудь трюк.
WH>Короче почти все решения из серии через зад автогеном.
Ну, если ориентироваться только на нормальные компиляторы, то костыли эти достаточно прямые и простые, а веселье начинается, когда пытаешься заставить это работать на всех компиляторах, включая уродцев типа мс-шестерки и сана. Наверное, если бы AT&T изначально владела языком и вкладывалась в него, как Сан с явой или Мелкософт с шарпом, не допуская зоопарка, то такого не было бы, но тогда другие времена были, у всех языков была масса диалектов (да и сейчас, вон посмотри на хаскель).
Но главное то, что все это внутри библиотеки и пока тебе не понадобилось туда нырнуть, пользоваться библиотекой легко и приятно и зоопарка под капотом не видно. И, имхо, то, что на таком старом языке можно написать библиотеки уровня Boost.Fusion и Boost.Proto, говорит только в пользу этого языка.
Хотя, конечно, неплохо было бы иметь все это (метаинформацию) встроенным непосредственно в язык, с этим никто не спорит.
Но метаинформации в С++ не было изначально, просто потому что он — наследник С, а там это чуждая концепция.
Сам понимаешь, в язык с таким наследием добавлять новые фичи нужно очень аккуратно, иначе С++ кончит как D, который сам с собой не совместим.
Так что что есть, то есть.
Конечно, она в том или ином виде будет добавлена в язык, но в каком именно — это большой вопрос, которым нужно заниматься, а на это у комитета банально нету времени, потому что гораздо больше народу требуют многопоточности и сборки мусора (последнюю так и не успели вставить в С++0х).
Собственно, то, что будет с С++ дальше, можно увидеть здесь:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2869.html (прокрути до "Not ready for C++0x, but open to resubmit in future").

J>>Имхо, это совершенно некритично, и никто не мешает к этому чистому контракту привернуть пару невиртуальных функций — это никак на чистоте контракта не скажется, так как то, что было чисто виртуальным, им и останется.
WH>Не согласен.
WH>В принципе можно иметь реализацию по умолчанию но возможность перекрытия должна быть в обязательном порядке.
Так она и есть, или я тебя не так понял.
Плюс контракт — это гораздо более широкое понятие, чем интерфейс. И в этом смысле класс С++ подходит для выражения концепции контракта лучше, чем просто интерфейс, потому что интерфейс редуцирует контракт до набора (причем фиксированного!) функций, что не всегда оправдано.
WH>Иначе могут быть проблемы связанные с тем что конкретную реализацию таки не устраивает реализация по умолчанию.
WH>Именно по этому вообще любое наследование реализации зло.
В С++ наследование — это не только наследование в классическом понимании ООП.
Там, например, наследуются типы/тайпдефы, и тому подобное. Вспомни CRTP хотя бы.

WH>Одним из приемлемых вариантов было бы что-то вроде этого:

WH>

WH>interface Iface1
WH>{
WH>...
WH>}
WH>interface Iface2
WH>{
WH>...
WH>}

WH>mixin Iface1Impl
WH>  implements Iface1
WH>{
WH>...
WH>}

WH>mixin Iface2Impl
WH>  implements Iface2
WH>  required Iface1
WH>{
WH>...
WH>}

WH>class SomeClass
WH>  implements Iface1
WH>  implements Iface2
WH>  aggregate Iface1Impl
WH>  aggregate Iface2Impl
WH>{
WH>...
WH>}
WH>

WH>Миксин может реализовывать один или несколько интерфейсов и требовать реализации некоторых интерфейсов.
Это можно и сейчас dynamic_cast-ом сделать.

WH>К миксину привести нельзя.
Почему? В чем смысл такого ограничения?

WH>Таким образом можно получить все плюсы множественного наследования без его минусов.
А чем тебя не устраивает подход ATL/WTL?
Он, кстати, позволяет частичную реализацию интерфейса — как насчет твоих миксинов? Они должны реализовывать интерфейс полностью или частично тоже сойдет? И если да и если ты хочешь собрать свой класс из вот таких вот частичных реализаций, ты разве не поимеешь все проблемы множественного наследования, которые есть сейчас? А если нет — так уж ли оно полезно, если вспомнить про какой-нть интерфейс OLE-объекта с 53 функциями?

J>>+1. Но это спор не о языках, а о библиотеках.
WH>Скажи это 0xC0000005
В смысле? Я не помню всех кодов ошибок, расшифруй, плиз

J>>+1. Макросы Немерле было бы очень здорово поиметь в плюсах. Много проблем бы сразу ушло.
WH>Макросы немерла имеют своих тараканов. А именно они совершенно не формализованы и осень сильно подвязаны на конкретную реализацию конкретного компилятора.
WH>Но этот недостаток можно устранить.
WH>Правда серьезной переработкой языка и компилятора.
О чем и речь

Так просто наскоком такую подсистему в язык не добавить — цена ошибки слишком велика.
Для этой цели (обкатки концепций) такие молодые языки, как Немерле, подходят идеально, и их ценность в этом смысле сложно переоценить, и в этом их отличие от промышленных языков.
А вот когда обкатают и будет наработана достаточно большая база решений и, что более важно, граблей, тогда можно думать и о встраивании концепции в промышленные языки.

WH>Но не до конца. .NET собака такая под ногами со своей кривостью путается.
Прям как в С++

Ну, в общем, как я и говорил энтузиастам дотнета сколько-то там лет назад ("У вас тяжкое наследие, а у нас все свежее и необремененное" — "Ничего, поговорим лет через 10"), как мы скрипим от унаследованных недостатков С++, так и явисты/дотнетчики заскрипят, когда осознают, что их новые свежие языки-платформы неидеальны, и не упрутся в их пределы и в никуда не девшиеся требования совместимости с существующим кодом (а в случае явы/дотнета — еще и с существующим байт-кодом).
А особенно когда еще через лет появится какая-нть модная технология, про которую все будут говорить: "Это must have, она должна быть в любом нормальном языке по умолчанию, все остальные на помойку!" (как сейчас с рефлексией, сериализацией и т.п.) а явисты/дотнетчики будут чесать репу, понимая, что на их языках невозможно по-человечески эту фичу реализовать, потому что она не будет ни с чем совместима и сломает язык. И будут предлагаться библиотеки, дающие требуемую функциональность, а неофиты будут плеваться и называть их костылями, и будут показывать пальцем на какой-нть новый язык Ветч или Гед, в котором эта фича уже есть сразу и выглядит красиво и непротиворечиво (но это только пока ею не начали пользоваться достаточно широко — тут-то и будет собран урожай граблей, которых вначале видно не было).

Нету идеальных решений на свете.
Как говаривал Страуструп, есть два вида языков (шире — технологий): те, которые все ругают, и те, которыми никто не пользуется.

Так что у С++ есть свой хорошо известный набор проблем, есть не менее хорошо известный (и зачастую вполне удобный) набор средств по их устранению/недопущению/предупреждению, и профессиональные программисты вполне комфортно себя чувствуют, хотя это и не значит, что они не будут приветствовать усилия комитета по уменьшению этого набора.
Ну и у явы/дотнета/шарпа/немерле/etc есть свои проблемы и свои инструменты.
Let it be.