Berkus
так что разница конечно же есть
Ivan
Ваще это уже проблема необразованности какая-то.
Для примитивных типов разницы не было, вот и говорили по значению
cyberzx 🇷🇺
указывает на семантику параметра
Ivan
Поэтому примитивные типы передают копированием
Ivan
Ты амперсанд забыл
Anonymous
и
cyberzx 🇷🇺
Нет там никакой семантики.
http://ideone.com/gRyM4p
Как это подтвержает отсутсвие семантики иммутабельности аргумента функции?
cyberzx 🇷🇺
Понятно, что так почти никто не делает. Но это не значит. что так нельзя сделать
Andrei
Компилятор считает, что нельзя.
Matway
Как это подтвержает отсутсвие семантики иммутабельности аргумента функции?
Заголовок функции - это часть контракта с окружающим миром. Для вызывающего int& и const int& - совершенно разные вещи, потому что в первом случае ты можешь сломать то, на что он тебе дал ссылку. int и const int, даже если бы была разрешена такая разница (а современные компиляторы, как видно из примера выше, этого не допускают), ничем не помогало бы вызывающему. Какая мне разница, что функция сделает с копией значения? Это её и значения внутренние тёрки.
Anatoly
const int говорит о том, что модифицировать стековую переменную запрещено в теле функции. какой в этом смысл? для int, в принципе, никакого, а вот для объектов классов смысл может быть то ли по причине сайдэффектов модифицирующих состояние методов, то ли просто отразить иммутабельность объекта
Andrew
https://godbolt.org/g/eZbAZm
cyberzx 🇷🇺
Заголовок функции - это часть контракта с окружающим миром. Для вызывающего int& и const int& - совершенно разные вещи, потому что в первом случае ты можешь сломать то, на что он тебе дал ссылку. int и const int, даже если бы была разрешена такая разница (а современные компиляторы, как видно из примера выше, этого не допускают), ничем не помогало бы вызывающему. Какая мне разница, что функция сделает с копией значения? Это её и значения внутренние тёрки.
Есть разница. Есть объекты, с расшаренным состоянием. Например std::shared_ptr<T>
Можно передать const std::shared_ptr<T> в функцию, тем самым запретив дальнейшую передачу владения
Matway
Есть разница. Есть объекты, с расшаренным состоянием. Например std::shared_ptr<T>
Можно передать const std::shared_ptr<T> в функцию, тем самым запретив дальнейшую передачу владения
Вместо тысячи слов:
http://ideone.com/9Hxe2b
И модифицировать объект удалось, и владение передать. Плохой, в общем, пример.
Matway
Да понятное ж дело :) Разговор идёт за бессмысленность передачи по const значению.
vladislav
так у тебя шаред_птр константный, а не значение в нём
Danil
так у тебя шаред_птр константный, а не значение в нём
ты по мимо сишарпа еще и 1С начал учить?)
vladislav
остановите эту аддскую машину юмора
Matway
так у тебя шаред_птр константный, а не значение в нём
Народ, читайте дискуссию, пожалуйста :)
cyberzx 🇷🇺
Вместо тысячи слов:
http://ideone.com/9Hxe2b
И модифицировать объект удалось, и владение передать. Плохой, в общем, пример.
Я не говорил про запрет модификации. А мув позволяет ломать контракты константности. Это такой же абьюз как конст каст
Ivan
Ахахахаха
cyberzx 🇷🇺
А кто говорил про запрет модификации?
А move это позволяет ломать контракты константности, это факт
cyberzx 🇷🇺
Я в таких ситуациях его восприним
Matway
А кто говорил про запрет модификации?
А move это позволяет ломать контракты константности, это факт
Мув там чисто для красоты. Убрал. Ничего не изменилось.
Ivan
"передача по значению" не знал, что столько шума наведет
Berkus
давайте теперь "передачу по незнанию" обсудим
Matway
"передача по значению" не знал, что столько шума наведет
Я знаю программистов, которые годами отстаивают право вставлять const для значений в заголовок.
cyberzx 🇷🇺
Значит шаред_птр так криво реализован
vladislav
const у параметров это же больше стилистическая вещь, мол ты сообщаешь чуваку, который юзает данный метод, что параметры не будут изменены. Только нужно по факту при передчае по референсу.
Matway
const у параметров это же больше стилистическая вещь, мол ты сообщаешь чуваку, который юзает данный метод, что параметры не будут изменены. Только нужно по факту при передчае по референсу.
Прикол в том, что нормальные компиляторы вообще нафиг выкидывают эту вещь из сигнатуры функции.
http://ideone.com/0Jvn6v
vladislav
так ты же не сгенерированный компилятором код читаешь
Taras
Приветствую вас эксперты, в общем такая ситуация. Я экспортирую класс из dll в котором два метода
std::string xxx ComPtr<IMessageHandler> msg.
Компилятор естественно ругается и бьет по рукам. Так вот я завернул все это в структуру и все хорошо. Но меня гложет сомнения правило ли я выбрал решение?
cyberzx 🇷🇺
Приветствую вас эксперты, в общем такая ситуация. Я экспортирую класс из dll в котором два метода
std::string xxx ComPtr<IMessageHandler> msg.
Компилятор естественно ругается и бьет по рукам. Так вот я завернул все это в структуру и все хорошо. Но меня гложет сомнения правило ли я выбрал решение?
Неправильно. У тебя нет гарантии ABI совместимости std::string в dll и в приложении, которое его юзает
Taras
И пока не решил вопрос с умными указателями, для структуры (завернуть её)
cyberzx 🇷🇺
Они вообще могут быть с разными стандартными библиотеками быть собраными
Taras
Вот спасибо, буду переделывать по другому тогда.
Taras
А вообще лучшее решение это pimpl?
Ivan
cyberzx 🇷🇺
Так же память выделенная в dll должна освобождаться тоже в dll. У тебя могут быть разные аллокаторы
Ivan
Pimpl раньше был популярен, когда программы долго компилировалась. Сейчас широко используется в Qt
Taras
Очень весело тогда бы получилось если к вам не обратился..
Matway
?
Ну, люди разные. Есть чисто вкусовщина, когда спорить незачем. А бывают вот такие вещи, которые приводят к тому, что человек накодил, как ему нравится, а оно потом упало на conformant-компиляторе. И человек ещё спорит, что компилятор не прав :)
Ivan
Я вообще не понял, что ты до этого написал. Что они отстаивают?
Anatoly
Pimpl раньше был популярен, когда программы долго компилировалась. Сейчас широко используется в Qt
это нормальная практика для сокращения зависимости реализации от интерфейса
Matway
Я вообще не понял, что ты до этого написал. Что они отстаивают?
Право писать
void myQewlFunction(const int a)
Ivan
это нормальная практика для сокращения зависимости реализации от интерфейса
Ну ок. Просто производительность ухудшается) тут каждому своё.
Andrew
"передача по значению" не знал, что столько шума наведет
Да пиздец, как будто бензин в печь ))
cyberzx 🇷🇺
Значит шаред_птр так криво реализован
К сожалению, это вообще проблема в С++, когда часть стейта объекта располагается в хипе по указателю. И по логике контсантность объекта обязана распространятся на константность этого стейта. А по факту мы легко можем модифицировать этот стейт из константных методов
cyberzx 🇷🇺
И это неправильно. Так же как и то, что стандарт это юзает в тех же shared_ptr
Andrew
По-моему в цпп таки запрещается вызывать неконстантные методы по указателю, из константного метода
cyberzx 🇷🇺
должен быть какой-то модификатор для мемберов указателей, который связывает константность объекта владельца и того, на который указывает указатель
cyberzx 🇷🇺
По-моему в цпп таки запрещается вызывать неконстантные методы по указателю, из константного метода
Это было бы нелогично. У тебя константой является в этом случае значение указателя.
Компилятор же не знает, что то на что указывает указатель это часть состояния объекта. Может быть это указатель на какую-нибудь внешнюю систему. Типа D3D device
Ivan
Потом надо будет сделать частотный анализ слов чата для таких слов как: "указатель", "ссылка", "класс", "объект", "компилятор", "строка", "переменная"
Matway
К сожалению, это вообще проблема в С++, когда часть стейта объекта располагается в хипе по указателю. И по логике контсантность объекта обязана распространятся на константность этого стейта. А по факту мы легко можем модифицировать этот стейт из константных методов
Речь о том, что в C++ const выбрасывается из сигнатуры функции, если параметр - значение:
http://ideone.com/Rs2tT6
Andrew
Anatoly
Речь о том, что в C++ const выбрасывается из сигнатуры функции, если параметр - значение:
http://ideone.com/Rs2tT6
да, он выбрасывает при рассмотрении перегрузки, но не удаляет свойство константности из самого параметра
Anatoly
void foo(const int i) {
i = 10; // CE
}
cyberzx 🇷🇺
Речь о том, что в C++ const выбрасывается из сигнатуры функции, если параметр - значение:
http://ideone.com/Rs2tT6
Я это знаю. Но тем не менее http://ideone.com/7QiYrV
Ivan
Потому что константность на настоящее имя функции не влияет
cyberzx 🇷🇺
Потому что константность формального параметра не является внешним контрактом
Ivan
Ты конечно пафосно говоришь, но две функции которые принимают инт с одинаковым названием и возвращаемым знанием не могут быть
Anatoly
Потому что константность на настоящее имя функции не влияет
это какая-то интересная теория, посмотри манглированное имя функции void foo(const int) и увидишь, что там int будет с const-ом
Ivan
Да? Оо
Ivan
Я думал конст только на этапе компиляции
Ivan
Тогда я не прав. )
Ivan
Но я поражён
Matway
это какая-то интересная теория, посмотри манглированное имя функции void foo(const int) и увидишь, что там int будет с const-ом
Ага. И это очень странная вещь ;)
Anatoly
а что поражает? что параметр может быть константным? ну не хочу, чтобы в теле функции его модифицировали, ну использую такой экравагатный способ. возможно, еще этот хинт могут использовать оптимизаторы
Ivan
В рантайме то пофиг) компилятор не даст это сделать до запуска программы
Ivan
В смысле зачем в мангленное имя зашивать const?
Matway
это какая-то интересная теория, посмотри манглированное имя функции void foo(const int) и увидишь, что там int будет с const-ом
Хотя на Clang что-то нифига:
void test1(int) -> ?test1@@YAXH@Z
void test2(const int) -> ?test2@@YAXH@Z
Ivan
хехехе)
Andrew
В смысле зачем в мангленное имя зашивать const?
Потому, что это может быть либа, которая может даже из рантайма грузиться
Anatoly
да, интересно
Ivan
И что?
Matway
Ivan
В смысле? Ты из кода если вызываешь, то компилятор проверит. Если уже рантайм, то пофигу вообще