Re[10]: C++, неявное преобразование signed <-> unsigned
От: Слава Израиль  
Дата: 27.04.11 13:57
Оценка:
Здравствуйте, igna, Вы писали:

ОК.

Я писал, что предупреждения 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
От: igna Россия  
Дата: 27.04.11 14:26
Оценка:
Здравствуйте, Слава, Вы писали:

С>А если бы класс был бы non copybale, то пользователь бы уже пересмотрел бы свою точку зрения и поменял бы свой дизайн.


Аргументация непонятна, чем этот пользователь думает, если модификатор const для него менее важный аргумент чем закрытый конструктор копирования? Оба предотвращают копирование присваиванием, причем const предотвращает копирование присваиванием везде, а закрытый конструктор копирования все-таки разрешает копирование присваиванием в функциях этого класса и его друзьях.
Re[12]: C++, неявное преобразование signed <-> unsigned
От: Слава Израиль  
Дата: 27.04.11 14:35
Оценка:
Здравствуйте, igna, Вы писали:

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


С>>А если бы класс был бы non copybale, то пользователь бы уже пересмотрел бы свою точку зрения и поменял бы свой дизайн.


I>Аргументация непонятна, чем этот пользователь думает, если модификатор const для него менее важный аргумент чем закрытый конструктор копирования? Оба предотвращают копирование присваиванием, причем const предотвращает копирование присваиванием везде, а закрытый конструктор копирования все-таки разрешает копирование присваиванием в функциях этого класса и его друзьях.


ХЗ, может быть const сидит глубоко в базах, а быдлокодер просто не просмотрел. A non copyable — типа декларация. кроме того, кроме закрытия оператора присвания, ему ещё и имплементацию не пишут, что правда приведёт к ошибке линковки, что быдлокодеру в принципе тоже будет непонятно, но он точно не сможет так использовать класс. Кроме того операторы — невиртуальные, что тоже ограничение, правда не сильное. Короче если прислушаться к предупреждению, и закрыть оператор присваивания явно, то толучаем декларацию, что класс не копируемый, и затрудняем быдлокодеру жизнь, если он решит пойти по пути ломания архитектуры.
Спасибо за внимание
Re[13]: C++, неявное преобразование signed <-> unsigned
От: igna Россия  
Дата: 27.04.11 14:50
Оценка:
Здравствуйте, Слава, Вы писали:

С>ХЗ, может быть const сидит глубоко в базах, а быдлокодер просто не просмотрел. A non copyable — типа декларация. кроме того, кроме закрытия оператора присвания, ему ещё и имплементацию не пишут, что правда приведёт к ошибке линковки, что быдлокодеру в принципе тоже будет непонятно, но он точно не сможет так использовать класс. Кроме того операторы — невиртуальные, что тоже ограничение, правда не сильное. Короче если прислушаться к предупреждению, и закрыть оператор присваивания явно, то толучаем декларацию, что класс не копируемый, и затрудняем быдлокодеру жизнь, если он решит пойти по пути ломания архитектуры.


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

PS. Да кстати, "он точно" "сможет так использовать класс". Ну просто использует memcpy.
Re: C++
От: March_rabbit  
Дата: 27.04.11 15:23
Оценка:
Здравствуйте, Философ, Вы писали:

1. Компиляции.... После Python это просто вымораживает, особенно, когда доводишь проект, созданный "гением от Александреску"
2. Шаблоны. Точнее, не шаблоны, а то, что их можно применять не в мирных целях (особенно смешать с макросами). В итоге, иногда приходится тратить куеву хучу времени на поиск какой-нибудь функции, объявление и определение которой выло сгенерировано по шаблонам с макросами.
3. Типизированность — нельзя взять и тупо сказать log() << some_variable, если эта переменная имеет тип, взятый из каких-то через 5 двор заинлайненых хедеров из третьего переименованного неймспейса. Да если этот тип даже и является в конце-концов каким-нибудь "стандартным" списком со вполне себе "стандартным" типом элементов.

Все это проявляется, когда смешиваешь работу в Python и С++.
Re[3]: C++
От: vdimas Россия  
Дата: 27.04.11 18:13
Оценка:
Здравствуйте, CreatorCray, Вы писали:

Ytz>>5. Нет проверки переполнения, типа как в C#: checked { a = b * c; }

CC>реализуется через перегрузку операторов.

Этот checked можно на уровне модуля контролировать опциями компилятора.
Re[8]: C++
От: jazzer Россия Skype: enerjazzer
Дата: 28.04.11 00:47
Оценка:
Здравствуйте, 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.

Я лично нахожу параметризацию шаблонов числами с плавющей запятой довольно опасной. Я согласен на ее введение при соблюдении некоторых ограничений (например, запрет статиков внутри, чтоб нельзя было написать код, который будет зависеть от идентичности. Хотя все равно взятие адреса никуда не денешь, и по нему можно будет вычислить уникальность...) в качестве средства оптимизации кода, в котором используются известные на момент компиляции константы. С другой стороны, я не вижу проблемы параметризовать шаблон инлайновой функцией, которая возвращает искомую константу — так как она инлайновая, компилятор должен встроить константу непосредственно в код:
inline double pi() { return 3.1415926; }
template<double(*)()> struct C {};
C<&pi> c;
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: C++
От: FR  
Дата: 28.04.11 02:06
Оценка:
Здравствуйте, 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>
J>inline double pi() { return 3.1415926; }
J>template<double(*)()> struct C {};
J>C<&pi> c;
J>


Угу как всегда в C++ шаблонах все окольными путями.
В общем по теме топика для C++ требуется Templates Revisited
Re: Что вам не нравится в языке, на котором вы пишете
От: Mamut Швеция http://dmitriid.com
Дата: 29.04.11 08:08
Оценка:
Ф>Есстественно, что имеется ввиду язык, на котором вы специализируетесь, т.е. если вы пишете на ЯП "А", но раз в неделю вам приходится написать 10 строчек на ЯП "Б", то не надо писать о "Б".

Ф>Пожалуйста, выносите в заголовок ответа название языка.


Ф>Очень надеюсь, что ветка не скатися в холливар.


Пишу на многих.

PHP

О его недостатках сказано столько, что лучше не повторяться. Например: http://wiki.rsdn.ru/php-defects.ashx

Python


Javascript



Java


Erlang
... << RSDN@Home 1.2.0 alpha 5 rev. 1498>>


dmitriid.comGitHubLinkedIn
Re[2]: C#: отсутствие ковариантности для immutable классов
От: Mihas  
Дата: 29.04.11 08:19
Оценка:
Здравствуйте, nikov, Вы писали:

N>Вот, буквально на днях пришлось писать совершенно дурацкий код для преобразования Tuple<DerivedClass, string> в Tuple<BaseClass, string>. То же самое для immutable списка (я использовал FSharpList<T> из C#).

Поддерживаю.

N>Ну и как уже заметили, отсутствие краткого синтаксиса и pattern matching для этих типов.

Да. Хотелось бы синтаксис покороче. Особенно напрягает в Linq.
Re[2]: Что вам не нравится в языке, на котором вы пишете
От: Курилка Россия http://kirya.narod.ru/
Дата: 29.04.11 08:19
Оценка: 17 (1)
Здравствуйте, Mamut, Вы писали:

M>Java

M>
как вариант — https://bitbucket.org/stepancheg/bolts/wiki/Home

M>Erlang

M>
а emacs?
Re[3]: Что вам не нравится в языке, на котором вы пишете
От: Mamut Швеция http://dmitriid.com
Дата: 29.04.11 08:28
Оценка:
M>>Java
M>>
К>как вариант — https://bitbucket.org/stepancheg/bolts/wiki/Home



Как много нам открытий чудных готовит извращений дух

M>>Erlang

M>>
К>а emacs?


Что-то я к emacs'у так и не привык
... << RSDN@Home 1.2.0 alpha 5 rev. 1498>>


dmitriid.comGitHubLinkedIn
Re: Что вам не нравится в языке, на котором вы пишете
От: MescalitoPeyot Украина  
Дата: 10.05.11 21:32
Оценка:
C++
Кроме того что уже упоминали (поддержка функциональщины, скорость компиляции и зависимости, человекочитаемые ошибки в шаблонах), хочу в основном сладостей.
Таких:
//    Переменные разных типов
for (xxx::iterator begin = x.begin(), xxx::const_iterator end = x.end(); ...)

вот таких:
//    Указание размера перечисления
enum YetAnotherProtocolShit : uint8_t { };

и вот таких:
//    Специализируемые перечислениями шаблоны
template <enum YetAnotherProtocolShit>

Еще хочу ключевое слово override.

В целом все Ok, только надоело уже.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Re[3]: C# NotNullable типов
От: TheOldMan  
Дата: 17.05.11 11:11
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


U>>В шарпе не хватает NotNullable типов классов. Будь такие типы код бы стал проще и надежнее.

WH>Правильное решение вообще выкинуть Null, а тем где нужно опциональное значение использовать тип Option[T] с двумя вариантами None и Some(T).
WH>Причем чтобы достать оттуда значение нужно явно проверить, что там что-то есть.

Option — это паттерн какой-нибудь? Как называется? Где почитать можно об этом более детально?


Спасибо
суть в простоте, а простота в сути
Re[2]: bash, .bat
От: Mamut Швеция http://dmitriid.com
Дата: 17.05.11 13:38
Оценка:
Добавлю еще парочку. Благо только-только сегодня "выучил"

bash

Безусловно походит для простого (а иногда и не очень) скриптинга. Вернее, даже не так — для автоматизации рутинных действий, часто выполняемых из командной строки.

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

Из-за этого:

1. абсолютно идиотские ключи для test/if

if [ "string" = "string" ]
if [ 0 -eq 0]


Почему в случае со строками "=", а в случае с числами "-eq" — тайна сия великая есть.

2. пляски с бубнами, если в параметрах/переменных встречаются пробелы
a="/home/user/dir with name"

cd $a   #облом
cd "$a" #ура


Здесь-то это понятно, но иногда бывает соовсем нетривиально: http://ubuntuforums.org/showthread.php?t=379668


И всякая разная мелочь еще есть, ща не упомню

.bat

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


dmitriid.comGitHubLinkedIn
Re[3]: bash, .bat
От: TheOldMan  
Дата: 17.05.11 13:48
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Почему в случае со строками "=", а в случае с числами "-eq" — тайна сия великая есть.


Кстати в perl тоже есть это отличие. Интересно почему?
суть в простоте, а простота в сути
Re[4]: C# NotNullable типов
От: WolfHound  
Дата: 17.05.11 13:56
Оценка: 7 (2)
Здравствуйте, TheOldMan, Вы писали:

TOM>Option — это паттерн какой-нибудь? Как называется? Где почитать можно об этом более детально?

http://en.wikipedia.org/wiki/Option_type
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: C# NotNullable типов
От: TheOldMan  
Дата: 17.05.11 14:24
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


TOM>>Option — это паттерн какой-нибудь? Как называется? Где почитать можно об этом более детально?

WH>http://en.wikipedia.org/wiki/Option_type

Спасибо!

Еще вот это нашел!
суть в простоте, а простота в сути
Re[6]: C# NotNullable типов
От: WolfHound  
Дата: 17.05.11 15:03
Оценка: 1 (1)
Здравствуйте, TheOldMan, Вы писали:

TOM>Еще вот это нашел!

Мрак! Это совершенно из другой оперы.
Завязывай ты с паттернами. Не доводят они до добра.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: C# NotNullable типов
От: TheOldMan  
Дата: 17.05.11 15:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


TOM>>Еще вот это нашел!

WH>Мрак! Это совершенно из другой оперы.

Ага, уже понял это.
суть в простоте, а простота в сути
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.