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

IT>>Почему неправда? Я про небольшую часть и говорю. Небольшую часть, отвечающую интересам комитета.
E>Потому что не было такого понятия, как "интересы комитета". Были интересы отдельных групп в коммитете.

Давай рассуждать логически, давай? Интересы в группах, группы в комитете, значит интересы в результате где? Правильно, в комитете.

IT>>Вот расскажи мне. Ты когда нибудь пользовался такой фигнёй в плюсах как mutable? Я никогда. Не понадобилось за 10 лет ни разу

E>Пользовался. И пользуюсь время от времени (где-то раз в полгода).

А class, if, while ты тоже раз в пол года используешь?

E>А вот у меня никогда ни возникало желания использовать property.

Не знал, что такое возможно, вот никогда и не возникало желание.

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

NB>>а const_cast эмулировать нельзя.

IT>(const XXX*)? Или ты dynamic имел ввиду?

const_cast -- это вот для этого:

void f( const int * i )
  {
    *(const_cast< int * >( i )) = 0;
  }

Он снимает константность (заодно и volatile).
Без него можно обойтить приведением в стиле C:

*((int *)i) = 0;

Но приведения в стиле C в C++ не приветствуются. Как и вообще приведения типов.

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

IT>Давай рассуждать логически, давай? Интересы в группах, группы в комитете, значит интересы в результате где? Правильно, в комитете.

Странная какая-то логика, ведь у групп разные интересы, а комитет один. Поэтому нельзя считать, что интерес комитета -- это сумма интересов групп. Как раз интерес комитета состоял в том, чтобы сделать сделать жизнеспособное и востребованное пересечение из всех интересов групп.

Давай я тебе лучше чуть по позже цитату из Страуструпа приведу, он очень красочно описал работу комитета. Сейчас просто книги нет под рукой.

IT>>>Вот расскажи мне. Ты когда нибудь пользовался такой фигнёй в плюсах как mutable? Я никогда. Не понадобилось за 10 лет ни разу

E>>Пользовался. И пользуюсь время от времени (где-то раз в полгода).

IT> А class, if, while ты тоже раз в пол года используешь?

А при чем здесь это. Ты про mutable спрашивал -- я тебе ответил. mutable -- это способ указать компилятору, что объект при видимой логической константности не имеет физической константности (как в приведенном мной примере). Поэтому такой объект нельзя размещать в ROM. Поскольку такие случаи по определению не могут быть слишком частыми, то mutable и используется на несколько порядков раз реже чем остальные конструкции языка. Но зато это единственный способ сказать компилятору о своих намерениях. В отличии от использования const_cast где-то под ковром.

E>>А вот у меня никогда ни возникало желания использовать property.

IT>Не знал, что такое возможно, вот никогда и не возникало желание.

Ага, и про наличие множественного наследования, шаблонов и исключений в C++ узнал только сегодня. И вообще мне не более года от роду

Ты мне лучше скажи, кроме Borland C++ и Visual C++ в каких еще компиляторах поддерживались property?
И были ли property в Borland C++ синтаксически и семантически эквивалентны таковым в Visual C++.

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

NB>>>а const_cast эмулировать нельзя.
IT>>(const XXX*)? Или ты dynamic имел ввиду?

E>const_cast -- это вот для этого:

Я в курсе, что это нужно для хаков.

E>Но приведения в стиле C в C++ не приветствуются. Как и вообще приведения типов.

Т.е. НЕЛЬЗЯ!!! Но если очень хочется, то можно

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

NB>>а const_cast эмулировать нельзя.

IT>(const XXX*)? Или ты dynamic имел ввиду?

из той же оперы что и mutable, только более опасный. снимает с объекта константность.

const int * y = &x;
int * z = const_cast<int *> (y);

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

IT>Я в курсе, что это нужно для хаков.

E>>Но приведения в стиле C в C++ не приветствуются. Как и вообще приведения типов.

IT>Т.е. НЕЛЬЗЯ!!! Но если очень хочется, то можно

А это вообще философия C++: дать инструмент, который позволяет обходиться без хаков. НО! Если сильно-сильно захочется, то дать возможность обойти ограничения компилятора. Ответственность при этом полностью перекладывается на программиста в расчете на то, что программист сам знает, что делает.

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

extern int crypt_file( char * file_name, char * crypt_device_name );

то у меня нет другого выхода, кроме как написать:

void some_my_code( const std::string & file_name, const crypting_params_t & params )
  {
    crypt_file( const_cast< char * >( file_name.c_str() ),
      const_cast< char * >( params.device_name().c_str() ) );
    ...
  }

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

E> Странная какая-то логика, ведь у групп разные интересы, а комитет один. Поэтому нельзя считать, что интерес комитета -- это сумма интересов групп. Как раз интерес комитета состоял в том, чтобы сделать сделать жизнеспособное и востребованное пересечение из всех интересов групп.

Т.е. ты это называешь нахождением компромисса?

E>А при чем здесь это. Ты про mutable спрашивал -- я тебе ответил. mutable -- это способ указать компилятору, что объект при видимой логической константности не имеет физической константности (как в приведенном мной примере).

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

E>Ты мне лучше скажи, кроме Borland C++ и Visual C++ в каких еще компиляторах поддерживались property?

Без понятия

E>И были ли property в Borland C++ синтаксически и семантически эквивалентны таковым в Visual C++.

Разные. Но я тебе вот что скажу. После того как я пересел на VC++, меня другие компиляторы волновали раз или два, когда надо было написать кросскомпиляторный код. Но этот код был каплей в море в сравнении с тем, что мне приходилось делать на VC++ и только на нём. Разница в синтаксисе меня не волновала совсем. Гораздо важнее было удобство разработки, а совместимый синтаксис было nice to have, что я и имел с успехом ввиду, особенно учитывая, что приходлось много писать на MFC и ATL.

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

E>А это вообще философия C++:

Это философия граблей.

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

E>> Странная какая-то логика, ведь у групп разные интересы, а комитет один. Поэтому нельзя считать, что интерес комитета -- это сумма интересов групп. Как раз интерес комитета состоял в том, чтобы сделать сделать жизнеспособное и востребованное пересечение из всех интересов групп.

IT>Т.е. ты это называешь нахождением компромисса?

Страуструп называл это нахождением консенсуса.

E>>А при чем здесь это. Ты про mutable спрашивал -- я тебе ответил. mutable -- это способ указать компилятору, что объект при видимой логической константности не имеет физической константности (как в приведенном мной примере).

IT>Чушь это всё, не находишь? Почему в других языках без этого прекрасно обходятся, а вот в плюсах инересы групп сошлись и решились на такую злободневную вещь, которая используется программистами от раз в пол года до никогда.

Нет не нахожу. Я, например, никогда не сталкивался с компилятором и платформой, где объекты могут размещаться в ROM. Но, говорят, такие платформы есть. И кто-то для них пишет код каждый день. Я думаю, что для них mutable был очень важен и нужен. А его появление позволило сделать код переносимый на такие платформы. Без него приходилось бы разбираться, почему код с const_cast прекрасно работает на одном компиляторе, но ломает программу на другом.

Что касается других языков, то это вообще не разговор. Языки разные и возможности у них разные. Java, например, лет шесть обходилась без generic-ов. И до сих пор обходится без множественного наследования классов. Как это удается мне лично не понятно.

E>>И были ли property в Borland C++ синтаксически и семантически эквивалентны таковым в Visual C++.

IT>Разные. Но я тебе вот что скажу. После того как я пересел на VC++, меня другие компиляторы волновали раз или два, когда надо было написать кросскомпиляторный код. Но этот код был каплей в море в сравнении с тем, что мне приходилось делать на VC++ и только на нём. Разница в синтаксисе меня не волновала совсем. Гораздо важнее было удобство разработки, а совместимый синтаксис было nice to have, что я и имел с успехом ввиду, особенно учитывая, что приходлось много писать на MFC и ATL.

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

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

E>>А это вообще философия C++:

IT>Это философия граблей.

На этот счет могут быть разные мнения , но словесное жонглирование не имеет смысла, т.к. философия C++ такая какая есть. Другой она уже не будет.

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

Вообще, после вот этой книги

Автор(ы): Бьерн Страуструп

В книге, написанной создателем языка C++ Бьерном Страуструпом, представлено описание
процесса проектирования и разработки языка программирования C++. Здесь изложены цели,
принципы и практические ограничения, наложившие отпечаток на структуру и облик C++,
обсужден дизайн недавно добавленных в язык средств: шаблонов, исключений, идентификации
типа во время исполнения и пространств имен. Автор анализирует решения, принятые в ходе
работы над языком, и демонстрирует, как правильно применять реальный
объектно-ориентированный язык программирования.

я пришел к выводу о том, что проблема C++ не в самом C++ (все его особенности, грабли, просчеты и пр. -- это объективная реальность, она никуда не денется). Проблема в том, что C++ популяризировал (продвинул в массы) ООП больше, чем Smalltalk, CLOS, Eiffel и иже с ними. И C++ начали применять там, где его использовать вообще не следовало. За что и поплатились.

А теперь ругают C++ за то, что он такой плохой. Только это все равно, что ругать пустыню за отсутствие воды и невозможность выращивать в пустыне орхидеии. Проблема здесь не в пустыне, проблема в тех, кто взялся за выращивание орхидей в пустыне. Себя нужно винить, за то, что из множества доступных языков был выбран далеко не самый подходящий, а не разработчиков C++ за то, что они его таким сделали. Они ведь его делали для себя и успешно использовали для своих задач.

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

IT>>Т.е. ты это называешь нахождением компромисса?
E>Страуструп называл это нахождением консенсуса.

Т.е. консенсус — это когда ни вашим ни нашим. В результате такой консенсус медленно, но уверенно превращает язык в динозавра.

IT>>Чушь это всё, не находишь? Почему в других языках без этого прекрасно обходятся, а вот в плюсах инересы групп сошлись и решились на такую злободневную вещь, которая используется программистами от раз в пол года до никогда.

E>Нет не нахожу. Я, например, никогда не сталкивался с компилятором и платформой, где объекты могут размещаться в ROM. Но, говорят, такие платформы есть. И кто-то для них пишет код каждый день. Я думаю, что для них mutable был очень важен и нужен. А его появление позволило сделать код переносимый на такие платформы. Без него приходилось бы разбираться, почему код с const_cast прекрасно работает на одном компиляторе, но ломает программу на другом.

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

E>Что касается других языков, то это вообще не разговор. Языки разные и возможности у них разные. Java, например, лет шесть обходилась без generic-ов. И до сих пор обходится без множественного наследования классов. Как это удается мне лично не понятно.

И главное заметь, отсутствие дженериков не сделало java лучше.

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

Каждый поплевал на каждого, потом все вместе поплевали на пользователей. В результате получился современный C++.

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

E>На этот счет могут быть разные мнения , но словесное жонглирование не имеет смысла, т.к. философия C++ такая какая есть. Другой она уже не будет.

Философия и не должна быть другой. Нужно всего лишь сделать нормальный дизайн, соостветствующий современным требованиям.

E>А теперь ругают C++ за то, что он такой плохой. Только это все равно, что ругать пустыню за отсутствие воды и невозможность выращивать в пустыне орхидеии.

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

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

E>>Страуструп называл это нахождением консенсуса.

IT>Т.е. консенсус — это когда ни вашим ни нашим. В результате такой консенсус медленно, но уверенно превращает язык в динозавра.

Скорее, язык перестают использовать там, где не следовало. И те, кому его в руки брать не следуюет.

E>>Нет не нахожу. Я, например, никогда не сталкивался с компилятором и платформой, где объекты могут размещаться в ROM. Но, говорят, такие платформы есть. И кто-то для них пишет код каждый день. Я думаю, что для них mutable был очень важен и нужен. А его появление позволило сделать код переносимый на такие платформы. Без него приходилось бы разбираться, почему код с const_cast прекрасно работает на одном компиляторе, но ломает программу на другом.

IT>Думаю, что они и так в этих проблемах по уши. И никакой mutable тут не поможет. Это как раз хороший пример того, что надо правильно проектировать, а не полагаться на допущение хаков компилятором.

А можешь рассказать, как приведенный мной пример сделать без mutable?

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

IT>Каждый поплевал на каждого, потом все вместе поплевали на пользователей. В результате получился современный C++.

Ну получился же. Теперь его можно в грязь втоптать. А можно вспомнить сотни языков, которые были до C++, были с C++ и будут после C++, но которые вообще никому не известны. Есть такой замечательный пример -- Eiffel. По совокупности всех имеющихся в нем возможностей, да еще с учетом времени его появления (1985) это вообще отличный язык. Глядя на него невольно задаешься вопросом -- как же вообще место для Java и C# под солнцем нашлось? А на практике -- где тот Eiffel, кому он на фиг нужен кроме тех, кого Бертран Мейер на бабки развел. Вот и получилось, что отличный в теории язык на практике не восстребован. И наоборот, корявый и убогий C++, в который здесь только ленивый не плюет, жив себе, курилка. Чего и всем остальным желает

Может быть это из-за того, что C++ создавался не для красоты, а чтобы практичекие задачи решать? Какие были задачи, такой и язык.

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

IT>Философия и не должна быть другой. Нужно всего лишь сделать нормальный дизайн, соостветствующий современным требованиям.

Видишь ли, понятие нормальности меняется не только в зависимости от области использования языка, но и от времени. То, что было нормально в 1986, тебе сейчас кажется не нормальным. А если гоняться за современной модой, то никакой компилятор не будет за этим успевать. И уж тем более сохранять совместимость с ранее написанным кодом.

E>>А теперь ругают C++ за то, что он такой плохой. Только это все равно, что ругать пустыню за отсутствие воды и невозможность выращивать в пустыне орхидеии.

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

Не мешает говоришь? Так введи. Какие проблемы? Берешь GCC или OpenWatcom и подкручиваешь C++ под себя.
А потом объясняешь, почему еще в двадцати (или сколько их там сейчас) компиляторах C++ нет никаких свойств или делегатов. И пытаешься заставить разработчиков этих компиляторов добавить их в свои творения.

К тому же рассуждать о том, что C++ динозавр и не соответствует современным требованиям действительно проще, чем признать, что нафиг не нужно было на C++ COM-ы писать.

IT wrote:
> Думаю, что они и так в этих проблемах по уши. И никакой mutable тут не
> поможет. Это как раз хороший пример того, что надо правильно
> проектировать, а не полагаться на допущение хаков компилятором.
Стандартный пример для mutable — кэши и счетчики ссылок. Там mutable как
раз очень нужен и вполне логичен — так как изменение членов объекта не
приводит к изменению его инварианта.

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

E>Скорее, язык перестают использовать там, где не следовало. И те, кому его в руки брать не следуюет.

А как ты определяешь где и кому следует, где и кому не следует? И вообще, а судьи кто?

E>А можешь рассказать, как приведенный мной пример сделать без mutable?

Какой именно?

IT>>Каждый поплевал на каждого, потом все вместе поплевали на пользователей. В результате получился современный C++.

E>Ну получился же. Теперь его можно в грязь втоптать. А можно вспомнить сотни языков, которые были до C++, были с C++ и будут после C++, но которые вообще никому не известны.

Это всё тоже отговорки. Было бы чем хвастаться. Кобол тоже до сих пор живее всех живых и ещё и C++ переживёт. Только это вовсе не делает его языком номер один в мэйнстриме.

E>Может быть это из-за того, что C++ создавался не для красоты, а чтобы практичекие задачи решать? Какие были задачи, такой и язык.
Вот как он эти задачи решает

CString fun(std::string s)
{
    return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
}

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

E>>Скорее, язык перестают использовать там, где не следовало. И те, кому его в руки брать не следуюет.

IT>А как ты определяешь где и кому следует, где и кому не следует? И вообще, а судьи кто?

Мне не нужно ничего определять и судить. Я на C++ помои не выливаю. Хотя мне не нравится, что с языком происходит. ИМХО, гораздо проще и конструктивнее сменить язык.

А кому и где не следует -- ты сам привел пример.

E>>А можешь рассказать, как приведенный мной пример сделать без mutable?

IT>Какой именно?

Описанный здесь

Автор: eao197
Дата: 02.06.06

, про ресурсоемкий метод, который вызывается у объекта через контантную ссылку/указатель.

IT>Это всё тоже отговорки. Было бы чем хвастаться. Кобол тоже до сих пор живее всех живых и ещё и C++ переживёт. Только это вовсе не делает его языком номер один в мэйнстриме.

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

IT>Вот как он эти задачи решает

IT>

IT>CString fun(std::string s)
IT>{
IT>    return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
IT>}
IT>

А что бы ты хотел вместо этого? Чтобы C++ не позволял писать такой жуткий код? Так ведь целью C++ было не это. Он никогда не задумывался как простой и безопасный язык. НИКОГДА. Пора бы это понять.

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

E>>Может быть это из-за того, что C++ создавался не для красоты, а чтобы практичекие задачи решать? Какие были задачи, такой и язык.
IT>Вот как он эти задачи решает

IT>

IT>CString fun(std::string s)
IT>{
IT>    return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
IT>}
IT>

Вот тебе еще один пример:

void f(CORBA::Octet o);
void f(CORBA::Boolean b); // Ambiguous
cout << ref—>getString(); // Leak
r1—>putString(r2—>getString()); // Leak
char *p = getString();
delete p; // Heap corruption
std::string s(ref—>getString()); // Leak
if(ref1 == ref2) ... // Undefined

(взят из документа A New Approach to Middleware Track Object-Oriented Middleware найденого когда-то на сайте http://www.zeroc.com).

Вот здесь C++ виноват в провоцировании всех показанных проблем или те, кто спроектировал такой маппинг CORBA на C++? Причем они ведь знали что такое C++ и чем черевато его неправильное использование.

IT wrote:

> Вот как он эти задачи решает
Не решает, а решают те, кто не умеет читать документацию, у _bstr_t есть оператор приведения как к wchar_t*, так и к char*.

> CString fun(std::string s)
> {
>     return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
> }
> 
Достаточно
CString fun(std::string s)
{
    return _bstr_t(s.c_str());
}

и это необходимо только для unicode версии, т.к. тут перекодируется. Так что лучше не std::string использовать, а
std::basic_string<TCHAR> и тогда вообще не понадобится перекодирование.

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

E>>>Скорее, язык перестают использовать там, где не следовало. И те, кому его в руки брать не следуюет.

IT>>А как ты определяешь где и кому следует, где и кому не следует? И вообще, а судьи кто?

E>Мне не нужно ничего определять и судить.

Вот и не надо этого делать. Те кто используют C++ как-нибудь сами без тебя разберуться где его следует использовать.

E>Я на C++ помои не выливаю. Хотя мне не нравится, что с языком происходит.

Больше всего помоев в языке от комитета, поэтому он не нравится не только тебе.

E>ИМХО, гораздо проще и конструктивнее сменить язык.

Я именно это и сделал.

E>>>А можешь рассказать, как приведенный мной пример сделать без mutable?
IT>>Какой именно?
E>Описанный здесь

Автор: eao197
Дата: 02.06.06

, про ресурсоемкий метод, который вызывается у объекта через контантную ссылку/указатель.

Этот пример не описывает начальную постановку задачи. А решать проблему, в которую ты попал только известным тебе самому способом мне не интересно.

IT>>Это всё тоже отговорки. Было бы чем хвастаться. Кобол тоже до сих пор живее всех живых и ещё и C++ переживёт. Только это вовсе не делает его языком номер один в мэйнстриме.

E>А мне как-то фиолетово, номер один язык, которым я пользуюсь или номер двадцать. Считается ли он мейнстримом или нет. Если меня язык устраивает, есть к нему библиотеки, есть информационные ресурсы, есть community -- этого достаточно.

Это мне понятно. Когда больше сказать нечего, то остаётся только надуть щёки и заявить "Уходи из нашей песочницы и больше не писай в мой горшок".

E>А что бы ты хотел вместо этого? Чтобы C++ не позволял писать такой жуткий код?

Я бы хотел в C++ иметь стандартный тип строки.

E>Так ведь целью C++ было не это. Он никогда не задумывался как простой и безопасный язык. НИКОГДА. Пора бы это понять.

О безопасности вроде как речь не шла. А то, что C++ как-то не так задумывался и вообще не для этого, то пора бы тебе понять самому — это всё ОТГОВОРКИ.