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

_>>Надеюсь, тебя не удивляет, что в яве, в _стандартной библиотеке_ для обычного инта куча типов: int, Integer,
_>>AtomicInteger?

IT>Ключевое слово "в int Jave есть". А в C++ string нет.

Кстати, String в Java -- это не ключевое слово. Просто класс в стандартной библиотеке.
А int в Java -- это даже не объект

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

E>Кстати, String в Java -- это не ключевое слово. Просто класс в стандартной библиотеке.
E>А int в Java -- это даже не объект

Совершенно верно. В C# тоже. Но Java без стандартной библиотеки, так же как и C# не представляют никакой ценности. В C++ такой библиотеки нет, вот все и лепят на коленках что у кого получится.

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

E>Обещенные цитаты из Страуструпа. Прошу прощения за большой объем, но это самые характерные высказывания по поводу комитета и процесса стандартизации.

Особенно вот это порадовало:

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

Что можно сказать? Очень важно иметь в комитете людей, которые даже не используют язык, который взялись стандартизировать.

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

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

Ну почему ж нельзя... можно конечно...

Пока "строка" в библиотеке... пускай даже в стандартной... я могу её выкинуть, если по каким-то причинам она меня не устраивает... а если её добавить в язык — тогда сам язык станет заточен под какие-то определённые требования и задачи потеряв универсальность — вот тогда действительно начнуться проблемы.

1) Какой стандарт "строк" т.е. кодировки текста возмем за основу? UTF-8? UTF-16? UTF-32? а как на счет остальных?
2) Что эта строка будет уметь?

1)
Но что делать с проектами в которых нафик не нужна кодировка которую мы выберем?
Можно конечно реализацию (т.е. кодировку) спрятать внутри класса, но что делать если под Виндами стандарт UTF-16, а на Униксах UTF-32... или UTF-8? ... на лету кoнвертить будем? Хм... в некоторых местах — это непозволительная роскошь...
2)
И даже если эту проблему решить... то на самом деле существует, проблема гораздо серьезнее: какой набор методов такая "строка" будет предоставлять? На все случаи жизни?... Хм... нереально... а что бы этот набор расширить для требований проекта нужна будет возможность эти методы добавлять... а для этого нам надо будет иметь доступ к непосредственно к данным строки и знать, как она устроена... и тогда мы возвращаемся к п.1 ...


Если всерьез задаться целью создать совершенно универсальный класс универсальной строки, то резутьтат будет, только один — как минимум лекгая шизофрения у его разработчиков

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


PS. Как начсет добавить в язык тип "время"?

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

IT>>Ругают не язык, ругают комитет. А язык не ругать, а жалеть надо. И всех его пользователей-бедолаг.

E>Ругать тех, кто что-нибудь делает всегда можно. Это не сложно.

Как раз тех, кто что-то сделал ругать сложно. Легко ругать тех, кто ничего не делает.

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

В том, что происходит с C++ происходит что-то не так. Сложный это процесс или лёгкий — это уже не важно.

E>Да уж... Имхо, описание было довольно конкретным.

Это не постановка. Это приглашение отрефакторить твой код. Этого я делать не собираюсь. Если ты объяснишь мне задачу (на словах, а не в коде), я попробую её решить без mutable. Но пытаться выкрутится в ситуации, когда без них уже никуда мне не интересно.

E>Тем не менее STL (и basic_string как его часть) описаны в стандарте C++. И я тебя хочу заверить, что это очень спасает при переходе с одного компилятора на другой.

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

IT>>Ещё раз. Обвиняется здесь только комитет за нежелание развивать язык в сторону, востребованную пользователями. А сам язык жалко

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

Следит, чтобы крена не было ни в плохую сторону, ни в хорошую.

IT>>Ты имеешь ввиду C# — это болид Формулы 1, а C++ — запорожец? Пожалуй с этой аналогией я соглашусь.

E>Да без проблем. Главное, что на одних и тех же трасах они не втречаются.

К счастью это не возможно. Болиды не ездят по разбитым просёлочным дорогам.

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

FR>Те кто пишет на фортране наверняка ближе к этому острию чем большинство пишущих на NET

В IT? Сомневаюсь.

IT wrote:
> K>Я конечно может сильно отстал... но насколько я знаю ничего кроме
> std::string к языку непосредственно не относиться...
> Боюсь, что std::string непосредственно к языку тоже не относится.
Достало уже.

std::string описывается в ISO-IEC-14882 в секции 21. На титульной
странице этого документа записано:

INTERNATIONAL
STANDARD
ISO/IEC
14882
Second edition
2003-10-15
Programming languages — C++

Так что std::string — это такая же часть языка, как и string в C#.

> K>да и это вроде как всего лишь часть "стандартной" библиотеки...
> Появившейся в каком году?
В 94 году был первый вариант (у SGI?), кажется. В середине 90-х были уже
вполне нормальные многочисленные реализации.

> В самом языке типа string нет, в результате он есть в каждой более менее
> уважающей себя библиотеке. Что из этого получается я привёл в качестве
> примера выше.
В C# реализация строки тоже находится в библиотеке.

> А теперь вопрос. Почему нельзя добавить в сам язык давно напрашивающийся
> тип string и покончить раз и навсегда эту строковую вакханалию.
А с какой семантикой — нужна ли SSO (если да, то какой размер буффера?),
а может еще и refcount'инг нужен? Или лучше просто копировать
содержимое? А может использовать GC и дать ему собирать мусор? Нужна ли
мутируемость строк? Нужно ли поддерживать использование хранения внешней
строки по ссылке? А как насчет передачи содержимого строки в вектор без
копирования? А нужно ли вставлять концевой 0 сразу или делать это по
требованию в c_str? А как насчет поддержки move construction? А если
потребуется положить строку в shared memory? А нужна ли поддержка
хэширования строки? А нужно ли кэшировать результат хэша, если да, то
как синхронизировать в многопоточном режиме? А если нужна своя
хэширующая функция? А если захочется utf-32? А если нужен utf-8?

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

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

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

K>Пока "строка" в библиотеке... пускай даже в стандартной... я могу её выкинуть, если по каким-то причинам она меня не устраивает... а если её добавить в язык — тогда сам язык станет заточен под какие-то определённые требования и задачи потеряв универсальность — вот тогда действительно начнуться проблемы.

Почему-то в других языках такой проблемы нет

K>1) Какой стандарт "строк" т.е. кодировки текста возмем за основу? UTF-8? UTF-16? UTF-32? а как на счет остальных?

Юникод вполне подойдёт.

K>2) Что эта строка будет уметь?

Посмотри в MSDN Members System.String.

K>на лету кoнвертить будем? Хм... в некоторых местах — это непозволительная роскошь...

Здесь надо жирным выделить в некоторых. Т.е. если мне один раз в некотором месте не подошло, то такой тип надо считать вредным для всей индустрии. Логично.

K>И даже если эту проблему решить... то на самом деле существует, проблема гораздо серьезнее: какой набор методов такая "строка" будет предоставлять? На все случаи жизни?... Хм... нереально... а что бы этот набор расширить для требований проекта нужна будет возможность эти методы добавлять... а для этого нам надо будет иметь доступ к непосредственно к данным строки и знать, как она устроена... и тогда мы возвращаемся к п.1 ...

Ознакомься с System.String. В .NET такой "серьёзной" проблемы не существует.

K>Если всерьез задаться целью создать совершенно универсальный класс универсальной строки, то резутьтат будет, только один — как минимум лекгая шизофрения у его разработчиков

На C++ — вполне возможно.

K>Собственно с С/С++ этой проблемы не существует — есть кусок памяти и делай ты с ней что хошь... только будь добр поставить ноль в конце если передаешь наружу — все... хотя и это необязательно, если есть соответствующая договоренность...

Мы же не о массиве байт говорим, который как ты сам правильно заметил, неизвестно как конвертрировать, а типе string.

K>PS. Как начсет добавить в язык тип "время"?

Я понимаю. Если строка, то это обязательно должен быть массив байт, если дата, то длинное целое. От этих привычек очень трудно избавиться. Но всё же, будет время, взгляни на тип System.DateTime.

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

C>Так что std::string — это такая же часть языка, как и string в C#.

Это абсолютно неверное утверждение. Начнём хотя бы с того, что std::string появилась в C++ десять лет спустя. Результат нам всем хорошо известен. Даже по прошествии 10 лет, std::string так и не стала фактическим стандартом.

C>А как насчет передачи содержимого строки в вектор...

А как насчёт посмотреть реализации в других языках или хотя бы взять за основу реализацию одной из C++ библиотек?

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

Это называется отмазаться. Хотели строку? Нате подавитесь

C>Но C++ хорош тем, что позволяет делать выбор когда это нужно

Достоинства C++ мне прекрасно известны. Мы сейчас не о них

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

IT>Для некоторых это противоречит фобиям, застарелым привычкам и незнанию того, что происходит в мире.

Знаешь, IT, вы, с VladD2, например, тут конечно люди умные... без фобий и застарелых привычек...

Стандарты то они конечно стандарты... но то что ты перечистил... ты почему-то видимо свято уверен, что жизни за пределами Windows не существует

Я тебе такую реальную историю расскажу...

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

Все довольны и разработчики и потенциальные клиенты после демонстрации в восторге... но...

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

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

IT wrote:

> _>Это не проблемы языка, а проблемы используемых библиотек.
> Это очень серьёзный аргумент. Я даже больше скажу. Это не проблемы
> комитета, а тех, кто использует язык и библиотеки. Комитету же ведь дела
> нет ни до библиотек, ни до тех кто их использует. Они сконцентрированы
> только на языке, млин В результате, как я уже говорил, получается
> "компромис", ни два ни полтора.
Главное — работает.

> _>Надеюсь, тебя не удивляет, что в яве, в _стандартной библиотеке_ для
> обычного инта куча типов: int, Integer,
> _>AtomicInteger?
> Ключевое слово "в int Jave есть". А в C++ string нет.
Есть basic_string, чем не устраивает???
Ну есть в яве/.нете String, а он всего 2-байтный. Как оно с UTF-32 дружить будет?.. Ладно нам 2-х байт хватает, а что
китайцам с японцами делать?

> _>Напиши сервер автоматизации на какой-нибудь яве, чтобы оно легко с VB,
> JavaScript, и пр. взаимодействовало...
> Если ты думаешь нормальный сервер просто пишется на MFC, то ты
> ошибаешься. К тому же, из-за подобных строковых преобразований в коде и
> логики-то не видно.
Не просто, но на яве явно не проще, и строковые преобразования тут роль не играют.

IT wrote:
> C>Так что std::string — это такая же часть языка, как и string в C#.
> Это абсолютно неверное утверждение.
Покажит международный стандарт на C# и место где в нем описывается строка.

> Начнём хотя бы с того, что
> std::string появилась в C++ десять лет спустя. Результат нам всем хорошо
> известен. Даже по прошествии 10 лет, std::string так и не стала
> фактическим стандартом.
std::string — это Стандарт (с большой буквы). Практически это
тоже сейчас распространенный стандарт, но не абсолютный. Что вполне всех
устраивает.

> C>А как насчет передачи содержимого строки в вектор...
> А как насчёт посмотреть реализации в других языках или хотя бы взять за
> основу реализацию одной из C++ библиотек?
А как ты думаешь комитет поступил? Они как раз взяли за пример строки из
других языков, в результате в интерфейсе std::string сейчас 84 публичных
метода. При правильном проектировании их число уменьшается до пары
десятков, а остальное становится алгоритмами (см. flex_string у
Александреску).

А самого идеального решения не существует. Например, refcount-строки
часто неэффективны в многопоточных приложениях, а SSO может приводить к
сильному замедлению в дегенеративных случаях.

> C>В Стандарт добавили что-то среднее между всем этим, с достаточно
> посредственными характеристиками для многих задач.
> Это называется отмазаться. Хотели строку? Нате подавитесь
Да, примерно так и есть. Комитет попытался найти золотую середину —
получилось... средне.

Но это не так важно — в С++ есть все средства, чтобы это компенсировать.

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

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

K>>1) Какой стандарт "строк" т.е. кодировки текста возмем за основу? UTF-8? UTF-16? UTF-32? а как на счет остальных?
IT>Юникод вполне подойдёт.
Какой Юникод? 2.x? 3.x? — UTF-8? UTF-16? UTF-32?

IT>Я понимаю. Если строка, то это обязательно должен быть массив байт, если дата, то длинное целое. От этих привычек очень трудно избавиться. Но всё же, будет время, взгляни на тип System.DateTime.

В том что все и дело, что это не привычки это требования!
С++ — это язык системного уровня — и в нем все быты и байты. Если при разработке это напрягает, значит С++ явно не нужен...

Взглянуть то на System.String и System.DateTime я могу, только как они решат мои задачи на Sun и HP например при хиром алгоритме обработки фалов на диске, к примеру?


PS. Решение абстрактых проблем это конечно интересно и увлекательно... только за решения таких проблем платят исключительно абстрактные деньги... котороый можно потратить на все что угодно... чисто абстрактно конечно

IT wrote:

> UTF-8? UTF-16? UTF-32? а как на счет остальных?
> Юникод вполне подойдёт.
Юникод это не кодировка, а набор символов. А UTF — Unicode Transfer Format, кодировки юникода.

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

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

E>Видишь ли, понятие нормальности меняется не только в зависимости от области использования языка, но и от времени. То, что было нормально в 1986, тебе сейчас кажется не нормальным.

Я же ясно написал, что понимаю под нормальным дизайном.

E>А если гоняться за современной модой, то никакой компилятор не будет за этим успевать.

Гонятся не надо. Но и по 10 лет обсуждать каждую фичу тоже не имеет смысла. К этому времени фича уже успеет устареть.

E>И уж тем более сохранять совместимость с ранее написанным кодом.

А это тут при чём? Все компиляторы развиваются, включая C++ и тем не менее остаются совместимы с легаси кодом.

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

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

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

Давай мы будем говорить о реальных вещах.

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

А были альтернативы? Как только мне предоставилась другая возможность, я поднапрягся, сжал силу воли в кулак и расстался с пережитками прошлого И, поверь мне на слово, ни капельки не жалею. Даже наоборот, чувствую, что прошёл один level и перешёл на следующий.

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

>> Т.е. без приседаний и танцев с бубнами не обошлось?
C>Нет, просто пришлось сделать RTFM по тому какие #define'ы надо проставлять — все оказалось вполне логично.

Т.е. RTFM по тому как приседать и стучать в бубен.

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

>> В результате, как я уже говорил, получается "компромис", ни два ни полтора.
_>Главное — работает.

Ну что это такое? А где стремление к совершенству, где забота о потомках, где желание писать код, по которому сегодняшние школьники будут учиться программировать серьёзные системы?

>> Ключевое слово "в int Jave есть". А в C++ string нет.
_>Есть basic_string, чем не устраивает???

Очередной коспромис?

_>Ну есть в яве/.нете String, а он всего 2-байтный. Как оно с UTF-32 дружить будет?.. Ладно нам 2-х байт хватает, а что китайцам с японцами делать?

Ничего не делать. И главное не задумываться о глупостях вроде сколько там байт в символе. Тогда и китайцам и японцам будет хорошо.

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

NB>ваша эрудиция прямо таки потрясает воображение.
NB>а вы разговор о теории упругости тоже сведете к обсуждению убогости С++?
NB>наверно это очень увлекательно, бороться с ветряными мельницами...

С теореией упругости это не сюда.

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

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

NB>поправь если ошибаюсь. мне казалось что в этой ветке мы тикл обсуждали

Поправляю, tcl сюда был приплетен в опровдание тому факту, что на С++ без внешних подпорок нельзя создавать полноценный ГУЙ. Оправдание правда скорее является приговором, но многим фанатам этого устаревшего языка и оно сойдет.

ЗЫ

Ты хоть смотри к чему присоеденяешся.

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

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

Да, да. Надо срочно подменять тему разговора...

Особенно хорошо для этого подходят такие "полезные" вещи как const_cast. Если бы не они и указатели, то язык мог бы получиться безопасным.