Ф>>строки должны быть единственными
Ф>>а тут только в std уже 2 варианта

O>Спорно.
O>Допустим, для какой-то задачи мне нужны очень компактные, пусть и не быстрые, строки.
O>Стандартная std::string не подходит, так как на 32-битных системах весит "аж" 24 байта.
O>Зато есть CString (MFC), QString (Qt) и всякие велосипеды, при желании можно найти или
O>собрать реализацию с объектами размером в указатель.
O>Прелесть в том, что C++ позволяет выбирать.

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

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

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

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

Ф>>строки должны быть единственными
Ф>>а тут только в std уже 2 варианта

O>32-битных системах весит "аж" 24 байта.


ржал аки конь

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

XC>После многих вариантов я остановился на таком варианте синтаксиса функций, ИМХО самый оптимальный из всех возможных:
XC>

def Func(int a, b, c) int x, y
XC>{
XC>  x = a*b + c;
XC>  y = a/b - c;
XC>}
XC>// ну и вызов, какие-то две переменные объявленные где-то, объединяем их в кортеж и принимаем результат функции
XC>(i, j) = Func(100,200,300);

гм...
попробую развить идею

[code]def T Func(int a, b, c) int x, y
{
x = a*b + c;
y = a/b — c;
}
[code]

[code]
deftype T Func(int a, b, c) int x, y;
[code]

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

S>>>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++?
D>>>учи дальше плюсы.
S>>Чем дальше вникаю тем больше нравится.

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

Автор: Mamut
Дата: 23.07.08

Но дядя Линус же писал на С, значит земноводные и прочие дотнеты сосудожны умереть в болоте.

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

M>Ничего он не позволяет. Все вышеописанное — это не прелесть, а костыли для обхода того факта, что нормальных строк в С++ нет. Поэтому каждый пишет собственные велосипеды, которые еще и между собой несовместимы.

Критерий нормальности строк, пожалуйста. Иначе как-то необъективно.

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

Ф>ржал аки конь

Расскажи, что смешного — я тоже поржать люблю.

M>>Ничего он не позволяет. Все вышеописанное — это не прелесть, а костыли для обхода того факта, что нормальных строк в С++ нет. Поэтому каждый пишет собственные велосипеды, которые еще и между собой несовместимы.

O>Критерий нормальности строк, пожалуйста. Иначе как-то необъективно.

Вообще-то, в 21-м веке нормальность — это поддержка хотя бы utf8. У С++ с этим вообще швах. Во всех остальных — кто на что горазд

Ну и да, количество реализаций строк для С++ намекает на то, что в консерватории что-то не так. А rationale для этих реализаций искать лень.

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

M>И про ФФ с Хромом.
Про них в сравнении с кальпаклаудом я говорил.


M>И в любом случае они, в основном, позволяют хранить и выводить текст, но не позволяют других манипуляций. Не говоря уже о «удобстве» иметь два набора функций для манипуляции типа strlen и wcslen и т.п.
Ок, пожалуй соглашусь, так как других способов не знаю, хотя они поидее должны быть.

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

M>Вообще-то, в 21-м веке нормальность — это поддержка хотя бы utf8.

Не совсем соответствует действительности. Работать с UTF-8 (и не только) можно посредством
UnicodeString из ICU, QString из Qt, это как минимум. Не могу привести больше примеров,
так как в WinAPI UTF-8 не особо популярна. А еще для обеспечения поддержки UTF-8 используют
все тот же std::string, у меня несколько месяцев назад был спор с uzhas на эту тему.

M>Ну и да, количество реализаций строк для С++ намекает на то, что в консерватории что-то не так.

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

Здравствуйте, netch80, Вы писали:
N>Здравствуйте, x-code, Вы писали:
XC>>Ужасная система #include и препоцессора,
N>Для своих задач препроцессор вполне адекватен. С другой стороны, ничто не мешает при необходимости сделать над ним что-то своё. Например, на m4, не к ночи будь сказано (но всё равно для мелких задач начинают выбор с него) или на любом другом макропроцессоре, какой понравится.

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

XC>> отсутствие нормальной модульной системы
N>Если речь про схему в стиле Вирта (тут interface, а тут implementation), то несложно заметить, что почему-то она не прижилась в промышленности и не была принята ни в одном языке, начатом "с нуля", заведомо позже массового распространения Паскаля. Например, она не была принята ни в Java ни в C#. Зато подход с заголовочными описаниями распространяется практически на все языки. Я думаю, у "нормальной модульной системы" всё-таки есть какой-то фатальный недостаток.

Где ещё, кроме C/C++ (и нескольких непродуманных язычков вроде PHP) используется «модульность» на основе #include? Как раз в Java отдельный файл — отдельный класс, единица трансляции, пространство имён, единица организации кода.

Есть два преимущества системы C — раздельная компиляция и совместимость со старым кодом на ассемблере и Фортране. Первое сейчас не критично, в память влазит полностью и файл-исходник, и выход, и промежуточное представление, и интерфейсы других модулей. Совместимость же сейчас интереснее с другими языками (Java, Python,...).

XC>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)
N>В принципе согласен. Более того, система namespace неудобна.
N>Постоянно хочется решений в стиле питоновского import X.Y.Z as W.

namespace W = X::Y::Z;

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

XC>>> отсутствие нормальной модульной системы
N>>Если речь про схему в стиле Вирта (тут interface, а тут implementation), то несложно заметить, что почему-то она не прижилась в промышленности и не была принята ни в одном языке, начатом "с нуля", заведомо позже массового распространения Паскаля. Например, она не была принята ни в Java ни в C#. Зато подход с заголовочными описаниями распространяется практически на все языки. Я думаю, у "нормальной модульной системы" всё-таки есть какой-то фатальный недостаток.

MOP>Где ещё, кроме C/C++ (и нескольких непродуманных язычков вроде PHP) используется «модульность» на основе #include? Как раз в Java отдельный файл — отдельный класс, единица трансляции, пространство имён, единица организации кода.

MOP>Есть два преимущества системы C — раздельная компиляция и совместимость со старым кодом на ассемблере и Фортране. Первое сейчас не критично, в память влазит полностью и файл-исходник, и выход, и промежуточное представление, и интерфейсы других модулей. Совместимость же сейчас интереснее с другими языками (Java, Python,...).

Ну вот в C# вроде нормальная модульная система. Раздельная компиляция, но никаких include, То, что объявлено в одном файле, свободно доступно в другом. Я не думаю что такое сложно сделать для нативного языка типа С++.
При чем тут совместимость с кодом на других языках — вообще непонял.

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

Ф>чтоб C++ начал умирать должен появиться действительно хороший нативный ЯВУ, поддерживаемый софтверными гигантами
Ой таки шота он так умирает шо ещё нас с вами переживёт.

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

XC>>>Отсутствие вложенных блочных комментариев
LVV>>Это мелочь
XC>Из мелочей состоит все. И красота языка программирования именно в мелочах.
Красота побоку. Главное чтоб задачи решил как надо. Существующая система include мне ещё ни разу не мешала, и showstopperом не была.

XC> Я кстати придумал третий совершенно новый и очень удобный вид комментариев (кроме блочных и однострочных).
И какой же?

XC>>>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно)
LVV>>Зачем?
XC>Для различных хакерских целей возможно и понадобится. Или для целей защиты программ от взлома.
Я понимаю зачем такое может быть нужно, и уже решал подобные задачи защиты. Но для работы с телом функции я лучше заюзаю debug information. Это будет куда правильнее чем волочь эту редкоиспользуемую функциональность в язык в ущерб качеству генерируемого кода.

XC>Все должно быть полноценными объектами, и числа, и строки. То есть должны быть вызовы вида 10.ToStr(), "Hello".ToUpper(), но при этом эти "объекты" должны оставаться простыми сущностями.
Получится жуткий кадавр.

LVV>>Это мелочь. Особенно ghyb наличии goto/ Если goto убрать, то да.
XC>goto тоже нужно оставить, это уникальный оператор безусловного перехода, и в некоторых особых случаях заменой ему могут быть только ассемблерные вставки. Уберем — и получим очередную джаву, на которой ничего кроме бизнес-бухгалтерии и не напишешь.
Мы пишем системные вещи но goto только в plain С наблюдается, в основном потому что там RAII нету.

XC>>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this
LVV>>Сильно напрягает?
XC>Если возможность может быть, она ДОЛЖНА быть.
Ты лучше объясни зачем. А то получается что в языке должна быть встроена любая возможность какая только может быть придумана.

XC>>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT
LVV>>А где такое еще есть?
XC>Ну вот в ObjC и QT есть.
Где такое ещё есть? Кроме ObjC и QT.

XC>>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)
LVV>>ИМХО сотни методов — это проблема реализации. И следствие отсутствия нормальной модульности.
XC>Да пусть у меня всего 4 метода в классе, но я хочу разделить их в две группы, что не имею права?
А как ты их потом будешь вызывать? Указывая namespace каждый раз? Сделаешь using namespace? Ну так а нахрена их тогда было разделять?

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

XC>Комментарии лексически корректного блока.
XC>

rem if(x>0) { 
XC>  // ...
XC>  while(b) {
XC>      // ...
XC>      for(int i=0; i<n; i++)
XC>       {
XC>          // ...
XC>       }
XC>  }
XC>  x = y;
XC>  // ...
XC>}

IMHO это мало кому нужно чтоб добавлять в язык.

XC>Не. У меня есть объект конкретного класса, у которого внутри сотни методов, полученных ЛЮБЫМ путем, может быть — длинная цепочка наследования, может быть все сразу объявлены, неважно. Я в IDE пишу "obj." и мне автокомплит выдает ПРОСТЫНЮ из методов, отсортированных тупо в алфавитном порядке. А я хочу, чтобы мне выдавалось около 10 внутренних неймспейсов, между которыми методы разгруппированы ПО СМЫСЛУ. Кстати, кроме иерархических неймспейсов можно ввести и "теги", правда это я еще не обдумывал.
Так это тебе надо в GUI добавлять функциональность а не в язык. А то ты усложняешь язык ради группировки методов в подсказке.

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

XC>>goto тоже нужно оставить
TSP>Сказал бы я. Но меня тут недавно в бан отправляли уже за высказывания относительно пробелов и табов.

А ты корректно выражайся, и не категорично а с обоснованием. Корректным опять таки.
То что мне вспоминается про тебя и пробелы и табы — исключительно "слова не мужа, но юнца".

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

Ф>строки должны быть единственными
Вот есть у тебя единственный формат строк. И входные/выходные данные в UTF8 и UTF32. Как с ними будешь работать? Приводить все к UTF16 а потом назад?

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

O>Критерий нормальности строк, пожалуйста. Иначе как-то необъективно.

Для меня — полная совместимость всех строк и их "абстрактность".
Я хочу, чтобы строка в кавычках была просто объектом. Чтобы не было даже привязки к кодировке (utf16, utf8, windows...), к внутреннему устройству и т.д.
Чтобы для юникода не писать ужасных _T("hello"). И вообще, строка — это как число, просто абстрактный способ представления данных.

А конкретная реализация строки (std::string, CString, QString...) подключается каким-то образом на этапе компиляции. По умолчанию — стандартная, поставляемая вместе с компилятором. Хочешь нестандартную — например, чтобы все строки хранились в бинарнике в зашифрованном виде — пиши какой-то специальный модуль-плагин к компилятору и подключай. При этом любая нестандартная реализация должна реализовывать некий интерфейс — список операций, которые можно сделать со строкой.

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

BBI>Красота побоку. Главное чтоб задачи решил как надо. Существующая система include мне ещё ни разу не мешала, и showstopperом не была.
Циклические include всякие. Да и вообще я не хочу, чтобы особенности расположения файлов были как-то связаны с программой. Должна быть система пространств имен и операторы подключения типа using.

XC>>Все должно быть полноценными объектами, и числа, и строки. То есть должны быть вызовы вида 10.ToStr(), "Hello".ToUpper(), но при этом эти "объекты" должны оставаться простыми сущностями.
BBI>Получится жуткий кадавр.
При наличии методов-расширений все получится вообще элементарно. string ToStr(this int x) и т.д.

BBI>Мы пишем системные вещи но goto только в plain С наблюдается, в основном потому что там RAII нету.
В каком-нибудь ядре Linux наверняка немало goto. А оно написано на древнем Си.

XC>>>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this
LVV>>>Сильно напрягает?
XC>>Если возможность может быть, она ДОЛЖНА быть.
BBI>Ты лучше объясни зачем. А то получается что в языке должна быть встроена любая возможность какая только может быть придумана.
Для функциональной полноты языка. Если есть фичи X и Y, то должны быть и их "суперпозиции" X(Y) и Y(X). Чтобы не было непонятных ограничений.
Простейший пример — если в функцию можно передать строку как адрес массива char*, то почему нельзя передать явный массив любых других объектов?
Или еще: если в классе можно объявить функцию (метод) и другой (вложенный) класс, в функции можно объявить вложенный класс, то почему в функции нельзя объявить вложенную функцию?

XC>>>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT
LVV>>>А где такое еще есть?
XC>>Ну вот в ObjC и QT есть.
BBI>Где такое ещё есть? Кроме ObjC и QT.

Все языки с динамической типизацией.
В том же C# 4 ввели "dynamic", с которым также можно вызывать несуществующие методы.
Кроме того, в проектах на обычном си я видел реализации аналогов "мягкого связывания", сделанные вручную. Естественно, выглядит это коряво и громоздко.

XC>>Да пусть у меня всего 4 метода в классе, но я хочу разделить их в две группы, что не имею права?
BBI>А как ты их потом будешь вызывать? Указывая namespace каждый раз? Сделаешь using namespace? Ну так а нахрена их тогда было разделять?

Чтобы сгруппировать логически. Вызывать — в основном, указывая namespace как часть имени каждый раз. Внутри namespace естественно не указываем.

BBI>А ты корректно выражайся, и не категорично а с обоснованием. Корректным опять таки.
Есть вопросы, в которых единых обоснований нет.
BBI>То что мне вспоминается про тебя и пробелы и табы — исключительно "слова не мужа, но юнца".
Демагогия. Приплетать юнцов к пробелам, табам и С++

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

MOP>Здравствуйте, netch80, Вы писали:
N>>Здравствуйте, x-code, Вы писали:
XC>>>Ужасная система #include и препоцессора,
N>>Для своих задач препроцессор вполне адекватен. С другой стороны, ничто не мешает при необходимости сделать над ним что-то своё. Например, на m4, не к ночи будь сказано (но всё равно для мелких задач начинают выбор с него) или на любом другом макропроцессоре, какой понравится.
MOP>Проблема в том, что это слишком неформальная, свободная система, трудно автоматизировать построение зависимостей, особенно с учётом макроопределений. Поэтому для каждого нового набора опций сборки нужно отдельное дерево, и выгоды раздельной компиляции всё чаще идут лесом, и ошибиться легко, собрав несовместимые объектники.

Да, неформальная и свободная. Но для Си в общем-то другая и не пойдёт. Более того, постоянно возникает необходимость аналогичных средств к другим языкам — например, к Питону.
На сейчас приходится при необходимости выбирать реализацию на старте заниматься хаками типа вынести зависимое от внешних условий в мелкие функции и вызывать их по ссылке из основного кода. А это может заметно тормозить выполнение программы. При препроцессоре стиля Си условная компиляция с самого начала помогла бы сэкономить на этом.

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

XC>>> отсутствие нормальной модульной системы
N>>Если речь про схему в стиле Вирта (тут interface, а тут implementation), то несложно заметить, что почему-то она не прижилась в промышленности и не была принята ни в одном языке, начатом "с нуля", заведомо позже массового распространения Паскаля. Например, она не была принята ни в Java ни в C#. Зато подход с заголовочными описаниями распространяется практически на все языки. Я думаю, у "нормальной модульной системы" всё-таки есть какой-то фатальный недостаток.
MOP>Где ещё, кроме C/C++ (и нескольких непродуманных язычков вроде PHP) используется «модульность» на основе #include? Как раз в Java отдельный файл — отдельный класс, единица трансляции, пространство имён, единица организации кода.

Не-а. Нормальная модульность была бы, если бы можно было отделить объявления от того, что их реализует. Например, есть модуль — вот вам список функций в нём, а сами функции где-то в другом месте. Никакая Java такого не умеет и не собирается, хочешь взять определения откуда-то — изволь принести полную реализацию. А заголовочные файлы для C/C++ хоть и бардачны, но позволяют именно это — в них только объявления функций, определения констант и enum'ов и тому подобное.

MOP>Есть два преимущества системы C — раздельная компиляция и совместимость со старым кодом на ассемблере и Фортране. Первое сейчас не критично, в память влазит полностью и файл-исходник, и выход,

При чём тут влезает или не влезает в память? Есть куча причин не компилировать всё вместе. Только для студенческой песочницы годится требовать всё одним скопом, и то — ОС сюда уже никто не включает.

XC>>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)
N>>В принципе согласен. Более того, система namespace неудобна.
N>>Постоянно хочется решений в стиле питоновского import X.Y.Z as W.

MOP>

MOP>namespace W = X::Y::Z;
MOP>

Я уже давно объяснил в соседних сообщениях, что эта ерунда не имеет ничего общего с тем, что я хотел.
Читай с конца, не будешь повторять уже пережёванное.