Я писал, что предупреждения 4 -го уровня уберегаю от трудноуловимых багов. Так о чём же здесь компилятор предупреждает? Согласен, что в оригинальном коде бага нет.
class X {
int const i_;
public:
X(int i) : i_ (i) {}
};
Но в будущем кто — нибудь вдруг захочет написать что-то такое:
X a(5);
X b(6);
a = b;
Компилятор здесь даст по рукам. Автор кода посмотрит на код, увидит, что operator= не определён и определит его как-нибудь так:
Я утрирую....
{
memcpy(this,&other,sizeof(X));
}
А если бы класс был бы non copybale, то пользователь бы уже пересмотрел бы свою точку зрения и поменял бы свой дизайн.
В общем, я думаю, предупреждение говорит о том, что этот класс не может поддерживать копирование, пожалуйста укажи это явно, чтобы будущих пользователей уберечь от трудно уловимых багов.
Спасибо за внимание
Re[11]: C++, неявное преобразование signed <-> unsigned
Здравствуйте, Слава, Вы писали:
С>А если бы класс был бы non copybale, то пользователь бы уже пересмотрел бы свою точку зрения и поменял бы свой дизайн.
Аргументация непонятна, чем этот пользователь думает, если модификатор const для него менее важный аргумент чем закрытый конструктор копирования? Оба предотвращают копирование присваиванием, причем const предотвращает копирование присваиванием везде, а закрытый конструктор копирования все-таки разрешает копирование присваиванием в функциях этого класса и его друзьях.
Re[12]: C++, неявное преобразование signed <-> unsigned
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Слава, Вы писали:
С>>А если бы класс был бы non copybale, то пользователь бы уже пересмотрел бы свою точку зрения и поменял бы свой дизайн.
I>Аргументация непонятна, чем этот пользователь думает, если модификатор const для него менее важный аргумент чем закрытый конструктор копирования? Оба предотвращают копирование присваиванием, причем const предотвращает копирование присваиванием везде, а закрытый конструктор копирования все-таки разрешает копирование присваиванием в функциях этого класса и его друзьях.
ХЗ, может быть const сидит глубоко в базах, а быдлокодер просто не просмотрел. A non copyable — типа декларация. кроме того, кроме закрытия оператора присвания, ему ещё и имплементацию не пишут, что правда приведёт к ошибке линковки, что быдлокодеру в принципе тоже будет непонятно, но он точно не сможет так использовать класс. Кроме того операторы — невиртуальные, что тоже ограничение, правда не сильное. Короче если прислушаться к предупреждению, и закрыть оператор присваивания явно, то толучаем декларацию, что класс не копируемый, и затрудняем быдлокодеру жизнь, если он решит пойти по пути ломания архитектуры.
Спасибо за внимание
Re[13]: C++, неявное преобразование signed <-> unsigned
Здравствуйте, Слава, Вы писали:
С>ХЗ, может быть const сидит глубоко в базах, а быдлокодер просто не просмотрел. A non copyable — типа декларация. кроме того, кроме закрытия оператора присвания, ему ещё и имплементацию не пишут, что правда приведёт к ошибке линковки, что быдлокодеру в принципе тоже будет непонятно, но он точно не сможет так использовать класс. Кроме того операторы — невиртуальные, что тоже ограничение, правда не сильное. Короче если прислушаться к предупреждению, и закрыть оператор присваивания явно, то толучаем декларацию, что класс не копируемый, и затрудняем быдлокодеру жизнь, если он решит пойти по пути ломания архитектуры.
Извини, я во всем этом не вижу ничего кроме попытки оправдания существующего положения вещей. Понимаю, хочется, чтобы все, что изучил было логично, но это не так.
PS. Да кстати, "он точно" "сможет так использовать класс". Ну просто использует memcpy.
1. Компиляции.... После Python это просто вымораживает, особенно, когда доводишь проект, созданный "гением от Александреску"
2. Шаблоны. Точнее, не шаблоны, а то, что их можно применять не в мирных целях (особенно смешать с макросами). В итоге, иногда приходится тратить куеву хучу времени на поиск какой-нибудь функции, объявление и определение которой выло сгенерировано по шаблонам с макросами.
3. Типизированность — нельзя взять и тупо сказать log() << some_variable, если эта переменная имеет тип, взятый из каких-то через 5 двор заинлайненых хедеров из третьего переименованного неймспейса. Да если этот тип даже и является в конце-концов каким-нибудь "стандартным" списком со вполне себе "стандартным" типом элементов.
Все это проявляется, когда смешиваешь работу в Python и С++.
Здравствуйте, CreatorCray, Вы писали:
Ytz>>5. Нет проверки переполнения, типа как в C#: checked { a = b * c; } CC>реализуется через перегрузку операторов.
Этот checked можно на уровне модуля контролировать опциями компилятора.
Здравствуйте, FR, Вы писали:
FR>В компайл-тайм как раз проще будет, ошибка сразу проявится.
а что считать ошибкой? f<1e10> и f<1e10-1e-10> — это один и тот же тип? Зависит от того, с какой точностью ведутся вычисления, правда? а f<0.9999999999999> и f<0.9999999999998> и f<1.0/3*3>? При том, что битность регистров сопроцессора обычно другая и не совпадает ни с double, ни с long double? Плюс, разные процессоры по-разному считают, даже при одной и той же битности. Хуже того, один и тот же компилятор, собранный с разными ключами компиляции, влияющими на работу с плавающей запятой, может считать эти инстанцирования как идентичными, так и различными. А если еще вспомнить про разные варианты НаНов, знаки нуля Оно тебе надо?
FR>И если уж поддерживаешь Compile Time Function Execution (CTFE) (C++0x constexpr) FR>то и поддержка плавающих чисел и строк в параметрах шаблонов логична.
строки — это вообще объекты. И то, и другое сейчас поддерживается через template<float*> и template<char*> . И там проблем с уникальностью нет, указатель один на все. А если очень хочется пометапрограммировать, рассматривая строки как последовательности символов, то к твоим услугам boost::mpl::string.
Я лично нахожу параметризацию шаблонов числами с плавющей запятой довольно опасной. Я согласен на ее введение при соблюдении некоторых ограничений (например, запрет статиков внутри, чтоб нельзя было написать код, который будет зависеть от идентичности. Хотя все равно взятие адреса никуда не денешь, и по нему можно будет вычислить уникальность...) в качестве средства оптимизации кода, в котором используются известные на момент компиляции константы. С другой стороны, я не вижу проблемы параметризовать шаблон инлайновой функцией, которая возвращает искомую константу — так как она инлайновая, компилятор должен встроить константу непосредственно в код:
Здравствуйте, jazzer, Вы писали:
J>а что считать ошибкой? f<1e10> и f<1e10-1e-10> — это один и тот же тип? Зависит от того, с какой точностью ведутся вычисления, правда? а f<0.9999999999999> и f<0.9999999999998> и f<1.0/3*3>? При том, что битность регистров сопроцессора обычно другая и не совпадает ни с double, ни с long double? Плюс, разные процессоры по-разному считают, даже при одной и той же битности. Хуже того, один и тот же компилятор, собранный с разными ключами компиляции, влияющими на работу с плавающей запятой, может считать эти инстанцирования как идентичными, так и различными. А если еще вспомнить про разные варианты НаНов, знаки нуля Оно тебе надо?
Ну при желании можно было бы стандартизировать compile-time вычисления с плавающими точками.
Хотя согласен для C++ то, что ты написал выше проблема, шаблон практически всегда определяет тип.
В D нет, в большинстве случаев шаблон выдает нечто константное без определения нового типа, в том же примере выше
template factorial(double n) if (n > 1.0)
{
const factorial = n * factorial!(n-1);
}
template factorial(double n) if (n <= 1.0)
{
const factorial = 1.0;
}
результатом инициации шаблона будет число типа const double.
J>строки — это вообще объекты. И то, и другое сейчас поддерживается через template<float*> и template<char*> . И там проблем с уникальностью нет, указатель один на все. А если очень хочется пометапрограммировать, рассматривая строки как последовательности символов, то к твоим услугам boost::mpl::string.
Неудобно и медленно по сравнению с D'шными строками параметрами шаблонов + CTFE.
J>Я лично нахожу параметризацию шаблонов числами с плавющей запятой довольно опасной. Я согласен на ее введение при соблюдении некоторых ограничений (например, запрет статиков внутри, чтоб нельзя было написать код, который будет зависеть от идентичности. Хотя все равно взятие адреса никуда не денешь, и по нему можно будет вычислить уникальность...) в качестве средства оптимизации кода, в котором используются известные на момент компиляции константы. С другой стороны, я не вижу проблемы параметризовать шаблон инлайновой функцией, которая возвращает искомую константу — так как она инлайновая, компилятор должен встроить константу непосредственно в код: J>
Ф>Есстественно, что имеется ввиду язык, на котором вы специализируетесь, т.е. если вы пишете на ЯП "А", но раз в неделю вам приходится написать 10 строчек на ЯП "Б", то не надо писать о "Б".
Ф>Пожалуйста, выносите в заголовок ответа название языка.
Ф>Очень надеюсь, что ветка не скатися в холливар.
Слегка кастрированные возможности ФП (например, отсутсвие многострочных лямбд)
Наличие разыменования, но отсутствие ПМ
Фича языка, которую надо знать, а я не знаю Присваивание объекта не копирует объект, а присваивает ссылку на объект. Из-за этого можно нарваться на явные и неявные глюки, когда модифицируешь один объект, а изменяется другой. Из-за этого относительно часто надо делать copy.copy()
Significant whitespace — зло Не всегда, но бывает
Javascript
Слабая типизация
Ошибка исполнения тупо убивает исполнение всех скриптов на странице
Прочее, что есть в "Javascript: The Good Parts" Крокфорда
Java
Многословность
Скука смертная. Хочется ФП и какой-то "живости"
Хочется ПМ
Из-за дикого количества даже стандартных библиотек, если с Java плотно не работаешь, то поиск нужного тебе способа что-то сделать может превратиться в адъ
Erlang
По сути есть только одна IDE — Erlide. Но Eclipse не нравится, хочется IDEA или на худой конец Netbeans. Но жить можно
Если файл уже module.erl, зачем еще раз указывать -module(module) в заголовке файла?
Хочется компонентность/модульность по типу java. Чтобы было не плоское/глобальное пространство имен
Хочется побольше библитек — как в Питоне/Java/.NET. Такого количества нет, но уже сейчас есть синдром NIH или просто незнание, что такие проекты уже есть (5 способов парсить JSON, 3 проекта по соединению с ruby и т.д. и т.п.)
Здравствуйте, nikov, Вы писали:
N>Вот, буквально на днях пришлось писать совершенно дурацкий код для преобразования Tuple<DerivedClass, string> в Tuple<BaseClass, string>. То же самое для immutable списка (я использовал FSharpList<T> из C#).
Поддерживаю.
N>Ну и как уже заметили, отсутствие краткого синтаксиса и pattern matching для этих типов.
Да. Хотелось бы синтаксис покороче. Особенно напрягает в Linq.
Re[2]: Что вам не нравится в языке, на котором вы пишете
C++
Кроме того что уже упоминали (поддержка функциональщины, скорость компиляции и зависимости, человекочитаемые ошибки в шаблонах), хочу в основном сладостей.
Таких:
// Переменные разных типовfor (xxx::iterator begin = x.begin(), xxx::const_iterator end = x.end(); ...)
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Undying, Вы писали:
U>>В шарпе не хватает NotNullable типов классов. Будь такие типы код бы стал проще и надежнее. WH>Правильное решение вообще выкинуть Null, а тем где нужно опциональное значение использовать тип Option[T] с двумя вариантами None и Some(T). WH>Причем чтобы достать оттуда значение нужно явно проверить, что там что-то есть.
Option — это паттерн какой-нибудь? Как называется? Где почитать можно об этом более детально?
Добавлю еще парочку. Благо только-только сегодня "выучил"
bash
Безусловно походит для простого (а иногда и не очень) скриптинга. Вернее, даже не так — для автоматизации рутинных действий, часто выполняемых из командной строки.
Все минусы — из-за того, что это — командная строка, насильно запихнутая в скриптовый файл.
Из-за этого:
1. абсолютно идиотские ключи для test/if
if [ "string" = "string" ]
if [ 0 -eq 0]
Почему в случае со строками "=", а в случае с числами "-eq" — тайна сия великая есть.
2. пляски с бубнами, если в параметрах/переменных встречаются пробелы
a="/home/user/dir with name"
cd $a #облом
cd "$a" #ура
Ээээ. Про него вообще надо что-то говорить? Это — просто звиздец. Абсолютно нечеловеческий синтаксис. Дикое количество спецсимволов на каждом шагу. Невменяемые сообщения об ошибках
Здравствуйте, TheOldMan, Вы писали:
TOM>Option — это паттерн какой-нибудь? Как называется? Где почитать можно об этом более детально? http://en.wikipedia.org/wiki/Option_type
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, TheOldMan, Вы писали:
TOM>>Option — это паттерн какой-нибудь? Как называется? Где почитать можно об этом более детально? WH>http://en.wikipedia.org/wiki/Option_type