Здравствуйте, DiPaolo, Вы писали: DP>На практике так конечно никто не пишет )) Но лично я отношусь к входящим параметрам как "к чужому" — не мне их менять, это стартовые условия для вычислений.
Практика С++ подразумевает разные подходы и разные предметные области. Если для вас скопировать какую-то переменную не критично ради лучше читаемости, то в другой предметной области это может очень даже болезненно. А еще есть обобщенный код, и вместо того int size может оказаться T size, которому подставили какого-то монстра с нетривиальным копированием. И вместо мува, мы получим копирование.
Re[5]: Как можно было так протупить с const параметрами?
Здравствуйте, Shtole, Вы писали:
S>Как бы, язык давно уже разделился на C++14, C++17, C++20. Вполне можно было бы ввести что-то типа 'use strict' #pragma strict.
SP>смысл такой же как и объявлять любую переменную const
SP>
SP>foo(const int i) // объявляем, что i меняться нигде дальше не будет
SP>{
SP> const int k = i; // тоже самое.
SP> ... // и тут кода на тыщу строк, чтобы сполна могли насладиться бонусами const
SP>}
SP>
Это намек компилятору, что можно вычислить в компайл-тайм один раз. С параметрами так не получится, они в любом случае живут в рантайме
Здравствуйте, T4r4sB, Вы писали:
SP>>А то, что нельзя мувать const объекты — это уже явная бага C++. Впрочем она растёт из "use after move".
TB>Она растёт из того, что move это не мув, а что-то типа свапа с чистым объектом.
Здравствуйте, DiPaolo, Вы писали:
DP>Ситуация, когда изменяется входящий параметр, достаточно нелогичная. Входящие параметры по значению — это, считай, настройки, конфиг. И менять их — весьма нетипичная и даже в некоторой степени является воркэраундом. Надо тебе что-то повычислять — заведи свою переменную, куда скопируй входное значение. А потом меняй его как хочешь. Изменение входящих параметров 100% ведет к багам и это является заложенной тайм-бомбой.
Вполне логичная. Ок. Это конфиг. Перед использованием заданные конфигом параметры надо проверить, и привести в допустимый диапазон.
void doSomething( string str )
{
str = trim(str);
str = to_upper(str);
str = replace(str,'-','_');
// еще куча вызовов для нормализации заданного аргумента
// колбасим рабочий код тут
}
DP>>На практике так конечно никто не пишет )) Но лично я отношусь к входящим параметрам как "к чужому" — не мне их менять, это стартовые условия для вычислений.
Тут речь шла про применение модификатора конст для входных параметров встроенных типов, типа const int param.
W>Практика С++ подразумевает разные подходы и разные предметные области. Если для вас скопировать какую-то переменную не критично ради лучше читаемости, то в другой предметной области это может очень даже болезненно.
Спасибо, я в курсе
Патриот здравого смысла
Re: Как можно было так протупить с const параметрами?
Здравствуйте. Да, век живи — век учись. Раз такое работает:
#include <iostream>
using namespace std;
struct A
{
void f(const int a);
};
void A::f(int a)
{
a = 5;
cout << "Wow!";
}
int main()
{
A a;
a.f(1);
return 0;
}
То вполне можно было сделать так, что в заголовке константность запрещать (она все равно игнорируется), а в реализации сделать константу по умолчанию, а разрешать менять словом mutable. Но, блин, это ломает обратную совместимость.
Re[4]: Как можно было так протупить с const параметрами?
Здравствуйте, Marty, Вы писали:
S>>Как бы, язык давно уже разделился на C++14, C++17, C++20. Вполне можно было бы ввести что-то типа 'use strict' #pragma strict.
M>Даёшь еще более навороченный и запутанный C++!!!
Это как раз способ распутать. А то задолбали уже всё на легаси сваливать.
Do you want to develop an app?
Re[5]: Как можно было так протупить с const параметрами?
Здравствуйте, Shtole, Вы писали:
S>>>Как бы, язык давно уже разделился на C++14, C++17, C++20. Вполне можно было бы ввести что-то типа 'use strict' #pragma strict.
M>>Даёшь еще более навороченный и запутанный C++!!!
S>Это как раз способ распутать. А то задолбали уже всё на легаси сваливать.
- У нас есть 14 способов сделать одно и то же
...
— Я придумал новый, универсальный способ!!!
ИМХО, на практике будет следующее. Какой-нибудь джун напишет auto size_mutable = size; (ну, чтобы можно было модифицировать, в этом же суть), а потом по невнимательности передаст size_mutable вместо size и... ничего плохого не случится. При первом же прогоне ошибка всплывёт и будет пофикшена. Всё это к реальным ошибкам (порче памяти) имеет мало отношения.
Но я, конечно, отнюдь не против, чтобы все параметры были константными по умолчанию.
Do you want to develop an app?
Re[6]: Как можно было так протупить с const параметрами?
Здравствуйте, Marty, Вы писали:
S>>>>Как бы, язык давно уже разделился на C++14, C++17, C++20. Вполне можно было бы ввести что-то типа 'use strict' #pragma strict.
M>>>Даёшь еще более навороченный и запутанный C++!!!
S>>Это как раз способ распутать. А то задолбали уже всё на легаси сваливать.
M>
M>- У нас есть 14 способов сделать одно и то же
M>...
M>- Я придумал новый, универсальный способ!!!
M>...
M>- У нас есть 15 способов сделать одно и то же
Почему это сработало в Джаваскрипте и не сработает тут? Только без пересказов анекдотов с xkcd, пожалуйста.
Do you want to develop an app?
Re[5]: Как можно было так протупить с const параметрами?
Здравствуйте, Marty, Вы писали:
M>Что ты подразумеваешь под "чистым" объектом?
Для строк — пустую строку, для коллекций — пустую коллекцию. В общем виде — состояние объекта после дефолтного конструктора.
Я вообще не очень представляю, можно ли представить не-надуманный пример объекта, у которого есть мув-конструктор, но нет дефолтного конструктора.
Re[6]: Как можно было так протупить с const параметрами?
Здравствуйте, T4r4sB, Вы писали:
M>>Что ты подразумеваешь под "чистым" объектом?
TB>Для строк — пустую строку, для коллекций — пустую коллекцию. В общем виде — состояние объекта после дефолтного конструктора. TB>Я вообще не очень представляю, можно ли представить не-надуманный пример объекта, у которого есть мув-конструктор, но нет дефолтного конструктора.
Меня смутило
TB>Она растёт из того, что move это не мув, а что-то типа свапа с чистым объектом.
мне казалось, что мув это типа свапа с непроинициализированным объектом
Здравствуйте, Shtole, Вы писали:
S>Как бы, язык давно уже разделился на C++14, C++17, C++20. Вполне можно было бы ввести что-то типа 'use strict'#pragma strict.
У комитета по этому поводу ещё стадия отрицания полностью не прошла.
Ну, по крайней мере, полумеры начали делать, а значит ещё лет 50 и придут к прагмам и ключам компилятора
Re[5]: Как можно было так протупить с const параметрами?
Здравствуйте, DiPaolo, Вы писали:
DP>Ситуация, когда изменяется входящий параметр, достаточно нелогичная. Входящие параметры по значению — это, считай, настройки, конфиг. И менять их — весьма нетипичная и даже в некоторой степени является воркэраундом. Надо тебе что-то повычислять — заведи свою переменную, куда скопируй входное значение. А потом меняй его как хочешь.
Есть типичная ситуация, когда входящий параметр меняется оставаясь "неизменным":
DP> Изменение входящих параметров 100% ведет к багам и это является заложенной тайм-бомбой.
Предположение, что не const переменная не меняется является ошибочным.
И каждый день — без права на ошибку...
Re[5]: Как можно было так протупить с const параметрами?