Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>Здравствуйте, k.o., Вы писали:
KO>>Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>>>Во многих языках есть поддержка со стороны языка IN, IN-OUT и OUT параметров, но в С++ такой нет вместо этого приходиться ипользовать константные и неконстантные ссылки и/или указатели. Поэтому я со своими коллегами решили что лучше было бы их раработать самим. В результате получилась такая реализация, но мы в ней не совсем уверены и хотели бы узнать мнение сообщества:
KO>>Бессмысленный и беспощадный overdesign, который, к тому же, не всегда работает:
KO>>KO>>class A
KO>>{
KO>>};
KO>>void sink1(std::unique_ptr<const A> arg)
KO>>{
KO>>}
KO>>void sink2(in<std::unique_ptr<const A>> arg)
KO>>{
KO>>}
KO>>int main()
KO>>{
KO>> std::unique_ptr<A> p1(new A);
KO>> sink1(std::move(p1)); // ok
KO>> std::unique_ptr<A> p2(new A);
KO>> sink2(in<std::unique_ptr<const A>>(std::move(p2))); // error
KO>>}
KO>>
GRF>В нашей нотации необходимо несколько изменить вызов и определение:
И получить другое поведение? Нет уж, так не пойдёт, боюсь, небольшим изменением тут не отделаться.
KO>>и не всегда применим:
KO>>KO>>MyType z = in<MyType&>(in<MyType&>(a) + in<MyType&>(in<MyType&>(b) * in<MyType&>(c)));
KO>>
KO>>во что это превратится с использованием expression templates я даже думать не хочу, впрочем, как я понял, некоторым такой вариант кажется более читабельным по сравнению с
KO>>KO>>MyType z = a + b * c;
KO>>
GRF>Мы и не планировали что in, in_out и out будут так применяться 
.
А как же ещё им применяться?
Входные параметры есть, почему их не надо помечать? Впрочем, я, кажется, понимаю: благодаря удачным названиям функций способ использования передаваемых параметров очевиден, может, тогда, вместо изобретения велосипедов, стоит давать более удачные названия функциям?
