Здравствуйте, IT, Вы писали:
IT>Вот и не надо этого делать. Те кто используют C++ как-нибудь сами без тебя разберуться где его следует использовать.
Уже разобрались. Да так, что программируя на C# только и знаю, что C++ ругать.
E>>>>А можешь рассказать, как приведенный мной пример сделать без mutable? IT>>>Какой именно? E>>Описанный здесь
, про ресурсоемкий метод, который вызывается у объекта через контантную ссылку/указатель.
IT>Этот пример не описывает начальную постановку задачи. А решать проблему, в которую ты попал только известным тебе самому способом мне не интересно.
Так и запишем -- решение не предложено.
IT>>>Это всё тоже отговорки. Было бы чем хвастаться. Кобол тоже до сих пор живее всех живых и ещё и C++ переживёт. Только это вовсе не делает его языком номер один в мэйнстриме.
E>>А мне как-то фиолетово, номер один язык, которым я пользуюсь или номер двадцать. Считается ли он мейнстримом или нет. Если меня язык устраивает, есть к нему библиотеки, есть информационные ресурсы, есть community -- этого достаточно.
IT>Это мне понятно. Когда больше сказать нечего, то остаётся только надуть щёки и заявить "Уходи из нашей песочницы и больше не писай в мой горшок".
А это каким боком здесь?
IT>Я бы хотел в C++ иметь стандартный тип строки.
Он есть -- std::basic_string.
E>>Так ведь целью C++ было не это. Он никогда не задумывался как простой и безопасный язык. НИКОГДА. Пора бы это понять.
IT>О безопасности вроде как речь не шла. А то, что C++ как-то не так задумывался и вообще не для этого, то пора бы тебе понять самому — это всё ОТГОВОРКИ.
Это не отговорки. Отговорки -- это очередные попыки обвинить C++ в том, что кому-то его трудно использовать. Если трудно -- значит либо знаний не хватает (а скорее здравого смысла), либо не подходит C++ для конкретной задачи. В конце-концов, на Запорожце в Формуле-1 не гоняются, а Камазы в качестве пасажирского такси не используют.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[25]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, kan_izh, Вы писали:
>> Вот как он эти задачи решает _>Не решает, а решают те, кто не умеет читать документацию, у _bstr_t есть оператор приведения как к wchar_t*, так и к char*.
Молодец! Возьми на полке пирожок
А теперь включаем фантазию и попробуем представить проект, в котором одновременно используются MFC, ATL, #import и STL. В качестве примера можно взять какое-нибудь приложение на MFC, работающее как сервер автоматизации, поддерживающее дуальный IDispatch.
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Tcl как обоснование ненужности поддержки компонентности в С++
IT wrote: > А теперь включаем фантазию и попробуем представить проект, в котором > одновременно используются MFC, ATL, #import и STL. В качестве примера > можно взять какое-нибудь приложение на MFC, работающее как сервер > автоматизации, поддерживающее дуальный IDispatch.
У меня примерно такое: приложение на MFC с поддержкой автоматизации и
серверных документов, в котором объектная модель реализована на Comet,
включены #import'ами несколько бибилиотек и есть несколько
ActiveX-контролов на ATL+WTL.
После разборок с #include'ами — все нормально.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[27]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, eao197, Вы писали:
IT>>Вот и не надо этого делать. Те кто используют C++ как-нибудь сами без тебя разберуться где его следует использовать.
E>Уже разобрались. Да так, что программируя на C# только и знаю, что C++ ругать.
Ругают не язык, ругают комитет. А язык не ругать, а жалеть надо. И всех его пользователей-бедолаг.
IT>>Этот пример не описывает начальную постановку задачи. А решать проблему, в которую ты попал только известным тебе самому способом мне не интересно.
E>Так и запишем -- решение не предложено.
Лучше запиши -- задача не поставлена.
IT>>Я бы хотел в C++ иметь стандартный тип строки. E>Он есть -- std::basic_string.
Ой, не смешите мои тапочки. тоже мне стандартный тип. И вообще, STL — стандарт — это уже не смешно. Сам Страуструп его назвал компромисом (консенсусом?) между универсальностью и производительностью. В результате получилось ни два ни полтора, ни универсальности, ни производительности.
E>Это не отговорки. Отговорки -- это очередные попыки обвинить C++ в том, что кому-то его трудно использовать.
Ещё раз. Обвиняется здесь только комитет за нежелание развивать язык в сторону, востребованную пользователями. А сам язык жалко
E>Если трудно -- значит либо знаний не хватает (а скорее здравого смысла), либо не подходит C++ для конкретной задачи. В конце-концов, на Запорожце в Формуле-1 не гоняются, а Камазы в качестве пасажирского такси не используют.
Ты имеешь ввиду C# — это болид Формулы 1, а C++ — запорожец? Пожалуй с этой аналогией я соглашусь.
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: Tcl как обоснование ненужности поддержки компонентности в С++
IT wrote: > C>После разборок с #include'ами — все нормально. > Т.е. без приседаний и танцев с бубнами не обошлось?
Нет, просто пришлось сделать RTFM по тому какие #define'ы надо
проставлять — все оказалось вполне логично.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[25]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, kedik, Вы писали:
K>>А причем тут С++?
IT>А при том, что весь этот строковый зверинец живёт именно в нём.
Я конечно может сильно отстал... но насколько я знаю ничего кроме std::string к языку непосредственно не относиться... да и это вроде как всего лишь часть "стандартной" библиотеки...
Собственно я так и не понял причем тут С++... можно какнить более развернуто... для тупых
Re[26]: Tcl как обоснование ненужности поддержки компонентности в С++
IT wrote:
> А теперь включаем фантазию и попробуем представить проект, в котором > одновременно используются MFC, ATL, #import и STL. В качестве примера
MFC, ATL могут использовать один и тот же CString (а писался он до того, как С++ стандартизовался). STL также прекрасно
может с CString работать, хотя если очень хочется, можно basic_string<TCHAR> заюзать.
Это не проблемы языка, а проблемы используемых библиотек.
Надеюсь, тебя не удивляет, что в яве, в _стандартной библиотеке_ для обычного инта куча типов: int, Integer,
AtomicInteger?
> можно взять какое-нибудь приложение на MFC, работающее как сервер > автоматизации, поддерживающее дуальный IDispatch.
Напиши сервер автоматизации на какой-нибудь яве, чтобы оно легко с VB, JavaScript, и пр. взаимодействовало...
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, IT, Вы писали:
IT>Ругают не язык, ругают комитет. А язык не ругать, а жалеть надо. И всех его пользователей-бедолаг.
Ругать тех, кто что-нибудь делает всегда можно. Это не сложно.
Сложнее понять, что все, что с C++ происходило и происходит -- это гораздо более сложный процесс, чем мы себе можем представить. И что все произошедшее произошло не просто так.
E>>Так и запишем -- решение не предложено.
IT>Лучше запиши -- задача не поставлена.
Да уж... Имхо, описание было довольно конкретным.
Реальный код я тебе представить не могу, но в общем виде можно выразить так:
class Actor
{
public :
const std::string & name() const;
const std::string & address() const;
const std::string & role() const;
const std::string & unique_bit_string() const;
private :
std::string m_name;
std::string m_address;
std::string m_role;
mutable std::string m_unique_bit_string;
.../* еще закрытые поля */...
};
...
void process_actor( const Actor & a )
{
// Здесь у Actor вызываются, в основном, методы name(), address(), role().
// Но иногда, меньше чем в половине случаев, вызывается unique_bit_string().
}
Вычисление m_unique_bit_string операция ресурсоемкая, использующая все поля объекта Actor, включая и те, которые через методы getter-ы не доступны. Функций process_actor() несколько, объект может попасть последовательно в несколько из них. В каком порядке -- не известно. Причем, если метод unique_bit_string() для объекта вызывается хотя бы один раз, то практически в 100% случаях он будет вызываться еще раз (он нужен для регистрации объекта в нескольких каталогах, если объект оказался неизвестен).
IT>Ой, не смешите мои тапочки. тоже мне стандартный тип. И вообще, STL — стандарт — это уже не смешно. Сам Страуструп его назвал компромисом (консенсусом?) между универсальностью и производительностью. В результате получилось ни два ни полтора, ни универсальности, ни производительности.
Тем не менее STL (и basic_string как его часть) описаны в стандарте C++. И я тебя хочу заверить, что это очень спасает при переходе с одного компилятора на другой.
IT>Ещё раз. Обвиняется здесь только комитет за нежелание развивать язык в сторону, востребованную пользователями. А сам язык жалко
У C++ слишком много пользователей. У них у всех собственные взгляды на то, как C++ должен развиваться. Комитет следит за тем, чтобы крена в одну сторону не было.
IT>Ты имеешь ввиду C# — это болид Формулы 1, а C++ — запорожец? Пожалуй с этой аналогией я соглашусь.
Да без проблем. Главное, что на одних и тех же трасах они не втречаются.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[27]: Tcl как обоснование ненужности поддержки компонентности в С++
kedik wrote:
> Собственно я так и не понял причем тут С++... можно какнить более > развернуто... для тупых
Просто он считает, что во всех правильных языках программирования обязан быть универсальный класс для строк, который все
обязаны использовать.
Конечно, такое мнение имеет право на жизнь, но не слишком согласуется с практическими требованиями.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, kan_izh, Вы писали:
_>kedik wrote:
>> Собственно я так и не понял причем тут С++... можно какнить более >> развернуто... для тупых _>Просто он считает, что во всех правильных языках программирования обязан быть универсальный класс для строк, который все _>обязаны использовать. _>Конечно, такое мнение имеет право на жизнь, но не слишком согласуется с практическими требованиями.
А-аааа... ну тада понятно
Знаем, знаем, проходили... сначала хочу что бы было "стандарные строки", потом "стандартные файлы"...
... потом стандартные интрерфейсы... стандартный Гуй... и все чтоб работало на стандартном железе... и пользователей тоже надо стандартных ... а ещё лучше один... но очччень богатый
Это проходит... надо просто поучавствовать в проекте который разрабатываеться под... ну хотя бы под 3 платформы
... и вот тогда это желание "стандартности" быстро проходит... и приходит понимание что — никаких стандартов нет... и не может быть в принципе — это противоречит некоторым законам... эээ... скажим так, общим законам... типа "закона сохранения энергии"
А что есть?
А есть только некоторые соглашения между группой разработчиков... ну хотя бы теми кто работает над одним проектом... в идеале
Re[27]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, kedik, Вы писали:
K>Я конечно может сильно отстал... но насколько я знаю ничего кроме std::string к языку непосредственно не относиться...
Боюсь, что std::string непосредственно к языку тоже не относится.
K>да и это вроде как всего лишь часть "стандартной" библиотеки...
Появившейся в каком году?
K>Собственно я так и не понял причем тут С++... можно какнить более развернуто... для тупых
В самом языке типа string нет, в результате он есть в каждой более менее уважающей себя библиотеке. Что из этого получается я привёл в качестве примера выше.
А теперь вопрос. Почему нельзя добавить в сам язык давно напрашивающийся тип string и покончить раз и навсегда эту строковую вакханалию.
Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, kan_izh, Вы писали:
_>MFC, ATL могут использовать один и тот же CString (а писался он до того, как С++ стандартизовался).
Начиная с 2002 года. Это конечно большой прогресс.
_>Это не проблемы языка, а проблемы используемых библиотек.
Это очень серьёзный аргумент. Я даже больше скажу. Это не проблемы комитета, а тех, кто использует язык и библиотеки. Комитету же ведь дела нет ни до библиотек, ни до тех кто их использует. Они сконцентрированы только на языке, млин В результате, как я уже говорил, получается "компромис", ни два ни полтора.
_>Надеюсь, тебя не удивляет, что в яве, в _стандартной библиотеке_ для обычного инта куча типов: int, Integer, _>AtomicInteger?
Ключевое слово "в int Jave есть". А в C++ string нет.
_>Напиши сервер автоматизации на какой-нибудь яве, чтобы оно легко с VB, JavaScript, и пр. взаимодействовало...
Если ты думаешь нормальный сервер просто пишется на MFC, то ты ошибаешься. К тому же, из-за подобных строковых преобразований в коде и логики-то не видно.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Tcl как обоснование ненужности поддержки компонентности в С++
IT>Флаг в руки и барабан на шею. Впрочем, не думаю, что эти несчастные работают на фортране по собственной воле. А если им или они сами себе всё же внушили такую глупость, то не думаю, что они сами же полагают, что находятся на острие передовых технологий
Те кто пишет на фортране наверняка ближе к этому острию чем большинство пишущих на NET
Re[28]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, kan_izh, Вы писали:
_>Просто он считает, что во всех правильных языках программирования обязан быть универсальный класс для строк, который все _>обязаны использовать. _>Конечно, такое мнение имеет право на жизнь, но не слишком согласуется с практическими требованиями.
Это не только согласуется, но великолепно работает на практике.
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, IT, Вы писали:
IT>Давай рассуждать логически, давай? Интересы в группах, группы в комитете, значит интересы в результате где? Правильно, в комитете.
Обещенные цитаты из Страуструпа. Прошу прощения за большой объем, но это самые характерные высказывания по поводу комитета и процесса стандартизации.
Раздел 5.4:
...Перед комитетом по C++ стояли довольно трудные задачи:
* определение языка должно быть точным и полным;
* необходимо принять во внимание совместимость с C;
* нужно рассмотреть расширения, выходящие за пределы текущей практики применения C++;
* должны быть рассмотрены библиотеки.
Ко всему прочему сообщество пользователей C++ было очень неоднородным и совершенно неорганизованным, поэтому комитету по стандартизации пришлось стать его центром. В краткосрочной перспективе именно это и было самой важной его целью:
Комитет по C++ -- это место, где разработчики компиляторов и инструментальных средств, их коллеги и представители могут обсудить проблемы определения языка и -- насколько позволяет коммерческая конкуренция -- его реализации. Таким образом, комитет уже сослужил добрую службу обществу: помог сблизить различные реализации, предоставив площадку для дискуссий. В противном случае разработчики компиляторов вместе с немногими коллегами или в одиночестве строили бы догадки относительно тех вопросов, на которые нет ответа в ARM. Возможно, они связались бы со мной, но я не в состоянии один справиться со всеми возникающими проблемами. Отсутствие общения неизбежно ведет к появлению диалектов. Комитет противостоит таким тенденциям.
Стандартизация -- непростой процесс. В комитет входили люди, стремившиеся сохранить status quo; мечтавшими вернуться на несколько лет назад; были такие, кто хотел "порвать с проклятым прошлым" и спроектировать совершенно новый язык; те, кого волновал лишь один конкретный класс систем; люди, чьи голоса были куплены их работодателями, и представлявшие лишь себя; специалисты, озабоченные в основном теоретическими взглядами на программирование вообще и языки в частности; нетерпеливые и требовавшие принять стандарт немедленно, даже если некоторые детали останутся неразрешенными, и наоборот, те, которых не устраивало ничего, кроме идеального определения языка. Были такие, кто полагал, что C++ -- совсем новый язык, у которого и пользователей-то почти нет, и представители организаций, написавших за минувшее десятилетие миллионы строк кода и т.д. Но в соответствии с правилами стандартизации нам всем предстояло прийти к более или менее одинаковому мнению. Мы должны были достичь консенсуса (обычно под этим словом понимают подавляющее большинство). Это разумные правила, они имеют национальный и интернациональный характер. Все интересы законны, и если позволить большинству ущемлять интересы меньшинства, то получится стандарт, полезный лишь ограниченному кругу пользователей. Поэтому каждому члену комитета предстоит научиться уважать другие, чуждые ему точки зрения и идти на компромиссы. И это вполне соответствует стилю C++.
Раздел 6.2.1:
В комитет по C++ входят люди с разными интересами, ожиданиями и подготовкой. Одни работают на персональных компьютерах, другие на UNIX-машинах, третьи -- на мейнфреймах и т.д. Одни используют C++, другие -- нет. Кто-то хочет, чтобы C++ стал более объектно-ориентированным языком (причем "объектной ориентированности" даются очень разные определения), других бы больше устроило, если бы эволюция C остановилась на ANSI C. Многие, но не все работали с C. Некоторые имеют опыт работы над стандартами, но их меньшинство. Есть профессиональные программисты. Одни обслуживают интересы конечных пользователей, другие поставляют на рынок инструментальные средства. Некоторым интересны крупные проекты. Кому-то необходима совместимость с языком C, кому-то -- нет.
Если не считать того, что все входящие в комитет -- добровольцы, не получающие за свою работу в нем ни копейки (хотя некоторые представляют компании), то трудно выделить какие-то черты, присущие всем без исключения. И это хорошо: только очень разношерстная группа людей может выразить интересы весьма неоднородного сообщества пользователей C++. Правда, из-за этого дискуссии бывают не очень конструктивными и занимают много времени. Меня беспокоит также, что голос пользователей C++ (программистов и проектировщиков) может быть не услышан в хоре языковых пуристов, так называемых проектировщиков языков, бюрократов от стандартизации, разработчиков компиляторов и т.д.
Раздел 6.4:
Я уверен, что стремление добавить языку то или иное расширение неизбежно, и лучше, чтобы это происходило открыто, на публичном форуме, где есть хоть какие-то формальные правила. Альтернатива -- схватка за признание собственных идей через привлечение на свою сторону пользователей на рынке. Такой механизм не способствует спокойным размышлениям, открытым дискуссиям и попыткам удовлетворить потребностям всех пользователей. В результате мы получаем язык, распавшийся на диалекты.
Очевидные опасности, присущие рассмотрению указанного вопроса, лучще, чем хаос, который воцарится в противном случае. Большинство членов комитета согласилось со мной, но мы шли к той точке, когда работа над расширениями в том виде, в котором она ведется сейчас, должна была прекратиться, поскольку приближался момент принятия стандарта и все направили усилия на его критическое изучение.
Со временем кто-то переключился на другие языки, кто-то занялся экспериментальной работой, кто-то посвятил себя созданию библиотек. Интересно отметить, что группы по стандартизации, как и любые другие организации, расформировываются с большой неохотой. Часто такая группа возрождается, пусть даже в виде бюрократического механизма для создания стандарта следующего уровня, то есть комитета по проектированию нового языка или диалекта. Примерами подобного явления служат комитеты по языкам Algol, Fortran, Pascal и даже ANSI C. Тем временем я стараюсь обезопасить себя от попыток проектирования чего-либо самим комитетом, посвящая много времени каждому поступившему предложению. Стратегия эта хоть как-то защищает от принятия взаимоисключающих средств, и язык, возможно, не утратит внутреннюю целостность.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[29]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, kedik, Вы писали:
K>Знаем, знаем, проходили... сначала хочу что бы было "стандарные строки",
Что значит хочу? У меня уже есть стандартные строки. Причём не просто для одного языка, а для целой платформы, для которой сегодня сущесвует с пол сотни языков. System.String называется. Запоминай, будешь знать
K>потом "стандартные файлы"...
Тоже в наличии. Чем тебе XML формат не стандарт?
K>... потом стандартные интрерфейсы...
В смысле стандартные интерфейсы? Интерфейс как стандартная конструкция языка? Без проблем, записывай по буквам — i-n-t-e-r-f-a-c-e
K>стандартный Гуй...
WinForms например. Пока ещё далёк от совершенства, но уж лучше такой, чем разброд, который творится в мире C++.
K>и все чтоб работало на стандартном железе...
А оно у тебя какое?
K>и пользователей тоже надо стандартных
С этим проблемы, да.
K>... а ещё лучше один... но очччень богатый
Один — это не интересно. Пофлеймить в форуме не с кем будет
K>Это проходит... надо просто поучавствовать в проекте который разрабатываеться под... ну хотя бы под 3 платформы
K>... и вот тогда это желание "стандартности" быстро проходит... и приходит понимание что — никаких стандартов нет... и не может быть в принципе — это противоречит некоторым законам... эээ... скажим так, общим законам... типа "закона сохранения энергии"
Для некоторых это противоречит фобиям, застарелым привычкам и незнанию того, что происходит в мире.
K>А есть только некоторые соглашения между группой разработчиков... ну хотя бы теми кто работает над одним проектом... в идеале
Глупости. Стандарт на внешние интерфейсы модулей давно существует и с успехом применяется. Соглашения между разработчиками учитываются только на уровне соглашений о наименованиях. Да и на это уже выработался более менее вменяемый стандарт.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
