Хочу подробнее описать причину использования именно этой модели, а не стандартной и не модели с define-ами: С помошью стандартной модели можно реализовать все три типа параметров, но в местах вызова функций непонятно передается параметр по ссылке или по значению. Также для стандартной модели существует неавное приведение типов.
Для define-ов, так как они являются просто заглушками, характерны все высше перечисленные недостатки. К ним еще прибавляется несинхронизированность между вставленными IN, IN_OUT и OUT "украшательсвами" и реальными характеристиками параметров в результате частых изменений кода.
На синтетических тестах модель вроде бы работает. Мы бы очень хотели узнать узкие места такой реализации.
Re[5]: Реализация IN, IN-OUT и OUT параметров функций
On 09/14/2011 01:33 PM, Аноним 20 wrote:
> Нет не при передаче больших структур а именно при передаче по ссылке или указателю. > Думаю шаблоны дают компилятору какую-то дополнительную информацию о типе и по > этой пирине он убирает излишние проверки.
Ну это не очень похоже на правду.
Posted via RSDN NNTP Server 2.1 beta
Re[2]: Реализация IN, IN-OUT и OUT параметров функций
On 09/14/2011 05:16 PM, Galiulin Rishat Faimovich wrote:
> Хочу подробнее описать причину использования именно этой модели, а не > стандартной и не модели с define-ами: > > 1. С помошью стандартной модели можно реализовать все три типа параметров, но > в местах вызова функций непонятно передается параметр по ссылке или по > значению. Также для стандартной модели существует неавное приведение типов. > 2. Для define-ов, так как они являются просто заглушками, характерны все > высше перечисленные недостатки. К ним еще прибавляется > несинхронизированность между вставленными IN, IN_OUT и OUT > "украшательсвами" и реальными характеристиками параметров в результате > частых изменений кода.
Не, мне это всё лично не нравится. Нагорожен огород, а зачем, не понятно.
В С++ и так нужно всё время смотреть, как используются параметры внутри
функции, меняются или нет, либо в коде, либо в спецификации на функцию.
Ничего страшного тут нет.
Я лучше бы предпочёл смотреть куда-то при необходимости, чем писать
такие вот конструктивы.
Вообще, функция и параметры должны называться так, чтобы и так было всё
понятно.
Posted via RSDN NNTP Server 2.1 beta
Re[3]: Реализация IN, IN-OUT и OUT параметров функций
Здравствуйте, MasterZiv, Вы писали:
MZ>On 09/14/2011 05:16 PM, Galiulin Rishat Faimovich wrote:
>> Хочу подробнее описать причину использования именно этой модели, а не >> стандартной и не модели с define-ами: >> >> 1. С помошью стандартной модели можно реализовать все три типа параметров, но >> в местах вызова функций непонятно передается параметр по ссылке или по >> значению. Также для стандартной модели существует неавное приведение типов. >> 2. Для define-ов, так как они являются просто заглушками, характерны все >> высше перечисленные недостатки. К ним еще прибавляется >> несинхронизированность между вставленными IN, IN_OUT и OUT >> "украшательсвами" и реальными характеристиками параметров в результате >> частых изменений кода.
MZ>Не, мне это всё лично не нравится. Нагорожен огород, а зачем, не понятно. MZ>В С++ и так нужно всё время смотреть, как используются параметры внутри MZ>функции, меняются или нет, либо в коде, либо в спецификации на функцию. MZ>Ничего страшного тут нет. MZ>Я лучше бы предпочёл смотреть куда-то при необходимости, чем писать MZ>такие вот конструктивы.
MZ>Вообще, функция и параметры должны называться так, чтобы и так было всё MZ>понятно.
Спасибо за ваше мнение.
Re: Реализация IN, IN-OUT и OUT параметров функций
Я конечно извиняюсь и может чего-то недопонимаю, но с каких это пор код с шаблонами стал читабельнее?
Да и просто сравните длину в символах обычного написания и вашей разработки.
Re[2]: Реализация IN, IN-OUT и OUT параметров функций
Здравствуйте, DarkTranquillity, Вы писали:
DT>Здравствуйте, Galiulin Rishat Faimovich.
DT>Я конечно извиняюсь и может чего-то недопонимаю, но с каких это пор код с шаблонами стал читабельнее? DT>Да и просто сравните длину в символах обычного написания и вашей разработки.
Да я согласен что длина написания немного увеличилась. Но все же как мне кажется читать код стало легче.
Повторю с пример, который я уже написал:
int main( int argc, char **argv )
{
int Integer = argc;
short InShort = Integer * 2;
int InOutInteger = InShort * 3;
std::string InString( "std::string" );
std::string* pInOutString = &InString;
int* pInOutInteger = &InOutInteger;
Base b;
Derived d;
с параметром читающему код необходимо посмотреть объявление функции.
Теперь посмотрите на эти вызовы:
function_0( in< Base& >( b ) );
или
function_0( in< Base& >( d ) );
Здесь даже без просмотра объявления функции ясно что параметр не будет изменен функцией, а так же что он будет передан по ссылке (не произойдет срезка).
Re: Реализация IN, IN-OUT и OUT параметров функций
Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>Во многих языках есть поддержка со стороны языка IN, IN-OUT и OUT параметров, но в С++ такой нет вместо этого приходиться ипользовать константные и неконстантные ссылки и/или указатели. Поэтому я со своими коллегами решили что лучше было бы их раработать самим. В результате получилась такая реализация, но мы в ней не совсем уверены и хотели бы узнать мнение сообщества:
Мы поступили по-другому. Параметр может быть либо переменной, либо константой — по аналогии с объявлением переменных и констант в программе.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Реализация IN, IN-OUT и OUT параметров функций
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>>Во многих языках есть поддержка со стороны языка IN, IN-OUT и OUT параметров, но в С++ такой нет вместо этого приходиться ипользовать константные и неконстантные ссылки и/или указатели. Поэтому я со своими коллегами решили что лучше было бы их раработать самим. В результате получилась такая реализация, но мы в ней не совсем уверены и хотели бы узнать мнение сообщества:
LVV>Мы поступили по-другому. Параметр может быть либо переменной, либо константой — по аналогии с объявлением переменных и констант в программе.
Покажите, пожалуйста, примеры используя вашу нотацию.
Re: Реализация IN, IN-OUT и OUT параметров функций
Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>Во многих языках есть поддержка со стороны языка IN, IN-OUT и OUT параметров, но в С++ такой нет вместо этого приходиться ипользовать константные и неконстантные ссылки и/или указатели. Поэтому я со своими коллегами решили что лучше было бы их раработать самим. В результате получилась такая реализация, но мы в ней не совсем уверены и хотели бы узнать мнение сообщества:
Бессмысленный и беспощадный overdesign, который, к тому же, не всегда работает:
class A
{
};
void sink1(std::unique_ptr<const A> arg)
{
}
void sink2(in<std::unique_ptr<const A>> arg)
{
}
int main()
{
std::unique_ptr<A> p1(new A);
sink1(std::move(p1)); // ok
std::unique_ptr<A> p2(new A);
sink2(in<std::unique_ptr<const A>>(std::move(p2))); // error
}
и не всегда применим:
MyType z = in<MyType&>(in<MyType&>(a) + in<MyType&>(in<MyType&>(b) * in<MyType&>(c)));
во что это превратится с использованием expression templates я даже думать не хочу, впрочем, как я понял, некоторым такой вариант кажется более читабельным по сравнению с
MyType z = a + b * c;
Re[2]: Реализация IN, IN-OUT и OUT параметров функций
Здравствуйте, k.o., Вы писали:
KO>Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>>Во многих языках есть поддержка со стороны языка IN, IN-OUT и OUT параметров, но в С++ такой нет вместо этого приходиться ипользовать константные и неконстантные ссылки и/или указатели. Поэтому я со своими коллегами решили что лучше было бы их раработать самим. В результате получилась такая реализация, но мы в ней не совсем уверены и хотели бы узнать мнение сообщества:
KO>Бессмысленный и беспощадный overdesign, который, к тому же, не всегда работает:
KO>
В нашей нотации необходимо несколько изменить вызов и определение:
class A
{
};
void sink1( const std::unique_ptr< const A > arg)
{
}
void sink2( in< std::unique_ptr< const A >& > arg)
{
}
int main( int argc, char **argv )
{
std::unique_ptr< A > p1( new A );
sink1( std::move( p1 ) ); // ok
std::unique_ptr< A > p2( new A );
sink2( in< std::unique_ptr< const A >& >( std::move( p2 ) ) ); // okreturn 0;
}
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>
Мы и не планировали что in, in_out и out будут так применяться .
Посмотрите, пожалуйста, примеры использования в самом первом сообщении .
Re[3]: Реализация IN, IN-OUT и OUT параметров функций
Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>Здравствуйте, DarkTranquillity, Вы писали:
DT>>Здравствуйте, Galiulin Rishat Faimovich.
DT>>Я конечно извиняюсь и может чего-то недопонимаю, но с каких это пор код с шаблонами стал читабельнее? DT>>Да и просто сравните длину в символах обычного написания и вашей разработки.
GRF>Да я согласен что длина написания немного увеличилась. Но все же как мне кажется читать код стало легче. GRF>Для того чтобы понять что примерно делает GRF>
GRF>function_0( b );
GRF>
GRF>или GRF>
GRF>function_0( d );
GRF>
GRF>с параметром читающему код необходимо посмотреть объявление функции.
GRF>Теперь посмотрите на эти вызовы: GRF>
GRF>function_0( in< Base& >( b ) );
GRF>
GRF>или GRF>
GRF>function_0( in< Base& >( d ) );
GRF>
GRF>Здесь даже без просмотра объявления функции ясно что параметр не будет изменен функцией, а так же что он будет передан по ссылке (не произойдет срезка).
Хм.. а я думал, что еще лучше прикидывать, что делает функция, исходя из ее названия(грамотного, естессно).
По типу параметра, честно, даже в голову не приходило.
Что делает функция f(<in> x) или f(<out> x)?
Еще раз повторюсь, а ниже коллега это подмечает — для Вас шаблоны выглядят читабельнее обычного кода?
Re[4]: Реализация IN, IN-OUT и OUT параметров функций
Здравствуйте, DarkTranquillity, Вы писали:
DT>Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>>Здравствуйте, DarkTranquillity, Вы писали:
DT>>>Здравствуйте, Galiulin Rishat Faimovich.
DT>>>Я конечно извиняюсь и может чего-то недопонимаю, но с каких это пор код с шаблонами стал читабельнее? DT>>>Да и просто сравните длину в символах обычного написания и вашей разработки.
GRF>>Да я согласен что длина написания немного увеличилась. Но все же как мне кажется читать код стало легче. GRF>>Для того чтобы понять что примерно делает GRF>>
GRF>>function_0( b );
GRF>>
GRF>>или GRF>>
GRF>>function_0( d );
GRF>>
GRF>>с параметром читающему код необходимо посмотреть объявление функции.
GRF>>Теперь посмотрите на эти вызовы: GRF>>
GRF>>function_0( in< Base& >( b ) );
GRF>>
GRF>>или GRF>>
GRF>>function_0( in< Base& >( d ) );
GRF>>
GRF>>Здесь даже без просмотра объявления функции ясно что параметр не будет изменен функцией, а так же что он будет передан по ссылке (не произойдет срезка).
DT>Хм.. а я думал, что еще лучше прикидывать, что делает функция, исходя из ее названия(грамотного, естессно). DT>По типу параметра, честно, даже в голову не приходило. DT>Что делает функция f(<in> x) или f(<out> x)? DT>Еще раз повторюсь, а ниже коллега это подмечает — для Вас шаблоны выглядят читабельнее обычного кода?
Иногда да , например: xxx_cast< T >, to< T >
Re: Реализация IN, IN-OUT и OUT параметров функций
Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
Я за такое избил бы коллегу клавиатурой. Это называется "синдром засирания всего кода ради ничтожной цели". Эта болезнь часто поражает начинающих программистов на C++ — неумение оценивать отношение важности задачи и сложности решения, сосредоточенность на второстепенных вещах, а также на коде вместо самой задачи. У меня тоже было что-то подобное.
Эта проблема — указание направления параметра, — не является такой серьезной, чтобы ради нее так изуродовать всю программу, катастрофически увеличить время компиляции, размер исполняемых файлов и превратить отладку в ад (даже в функцию отладчиком нормально будет не зайти).
И в любом случае нет необходимости указывать указывать направление "in" — оно и так понятно "по умолчанию", и в нормально написанных программах встречается в 99,99% случаев.
Re[3]: Реализация IN, IN-OUT и OUT параметров функций
Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>Здравствуйте, k.o., Вы писали:
KO>>Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>>>Во многих языках есть поддержка со стороны языка IN, IN-OUT и OUT параметров, но в С++ такой нет вместо этого приходиться ипользовать константные и неконстантные ссылки и/или указатели. Поэтому я со своими коллегами решили что лучше было бы их раработать самим. В результате получилась такая реализация, но мы в ней не совсем уверены и хотели бы узнать мнение сообщества:
KO>>Бессмысленный и беспощадный overdesign, который, к тому же, не всегда работает:
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 будут так применяться .
А как же ещё им применяться? Входные параметры есть, почему их не надо помечать? Впрочем, я, кажется, понимаю: благодаря удачным названиям функций способ использования передаваемых параметров очевиден, может, тогда, вместо изобретения велосипедов, стоит давать более удачные названия функциям?
Re[2]: Реализация IN, IN-OUT и OUT параметров функций
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
А>Я за такое избил бы коллегу клавиатурой. Это называется "синдром засирания всего кода ради ничтожной цели". Эта болезнь часто поражает начинающих программистов на C++ — неумение оценивать отношение важности задачи и сложности решения, сосредоточенность на второстепенных вещах, а также на коде вместо самой задачи. У меня тоже было что-то подобное.
А>Эта проблема — указание направления параметра, — не является такой серьезной, чтобы ради нее так изуродовать всю программу, катастрофически увеличить время компиляции, размер исполняемых файлов и превратить отладку в ад (даже в функцию отладчиком нормально будет не зайти).
А>И в любом случае нет необходимости указывать указывать направление "in" — оно и так понятно "по умолчанию", и в нормально написанных программах встречается в 99,99% случаев.
Спасибо за ваше мнение. Я действительно пишу на С++ довольно короткое время — всего 1 год, до этого я писал на Java. Идея ввести IN, IN-OUT и OUT параметры вначале мне тоже не понравилась, и в начале мы хотели ввести параметры просто как define-ы. Но решающим для меня доводом от коллег было то, что новичкам будет легче понять уже существующий код, если ввести такие "подсказки". Я пошел немного дальше и решил возложить проверку параметров также на компилятор.
Re[4]: Реализация IN, IN-OUT и OUT параметров функций
Здравствуйте, k.o., Вы писали:
KO>Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>>Здравствуйте, k.o., Вы писали:
KO>>>Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>>>>Во многих языках есть поддержка со стороны языка IN, IN-OUT и OUT параметров, но в С++ такой нет вместо этого приходиться ипользовать константные и неконстантные ссылки и/или указатели. Поэтому я со своими коллегами решили что лучше было бы их раработать самим. В результате получилась такая реализация, но мы в ней не совсем уверены и хотели бы узнать мнение сообщества:
KO>>>Бессмысленный и беспощадный overdesign, который, к тому же, не всегда работает:
KO>>>
GRF>>В нашей нотации необходимо несколько изменить вызов и определение:
KO>И получить другое поведение? Нет уж, так не пойдёт, боюсь, небольшим изменением тут не отделаться.
Нет вы получите именно то поведение которое желаете, попробуйте.
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 будут так применяться .
KO>А как же ещё им применяться? Входные параметры есть, почему их не надо помечать? Впрочем, я, кажется, понимаю: благодаря удачным названиям функций способ использования передаваемых параметров очевиден, может, тогда, вместо изобретения велосипедов, стоит давать более удачные названия функциям?
Например в определении функции так:
void function( in< MyType& > a, in< MyType& > b, in< MyType& > c )
{
MyType z = a() + b() * c();
}
Для того чтобы писать:
MyType z = a + b * c;
надо будет перегрузить операторы.
Re[5]: Реализация IN, IN-OUT и OUT параметров функций
Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>>>В нашей нотации необходимо несколько изменить вызов и определение:
KO>>И получить другое поведение? Нет уж, так не пойдёт, боюсь, небольшим изменением тут не отделаться.
GRF>Нет вы получите именно то поведение которое желаете, попробуйте.
Но позвольте, конструкторы класса 'in' принимают константную ссылку на значение аргумента, мне же нужно передавать аргумент по-значению, для unique_ptr передача по константной ссылке и передача по значению это две большие разницы. Впрочем, я попробовал, как и ожидалось, "эквивалентный" код успешно компилируется, там где оригинальный (как и задумывалось) приводит к ошибке компиляции.
KO>>>>и не всегда применим:
KO>>>>
KO>>>>MyType z = in<MyType&>(in<MyType&>(a) + in<MyType&>(in<MyType&>(b) * in<MyType&>(c)));
KO>>>>
KO>>>>во что это превратится с использованием expression templates я даже думать не хочу, впрочем, как я понял, некоторым такой вариант кажется более читабельным по сравнению с
GRF>>>Мы и не планировали что in, in_out и out будут так применяться .
KO>>А как же ещё им применяться? Входные параметры есть, почему их не надо помечать? Впрочем, я, кажется, понимаю: благодаря удачным названиям функций способ использования передаваемых параметров очевиден, может, тогда, вместо изобретения велосипедов, стоит давать более удачные названия функциям?
GRF>Например в определении функции так: GRF>
GRF>void function( in< MyType& > a, in< MyType& > b, in< MyType& > c )
GRF>{
GRF> MyType z = a() + b() * c();
GRF>}
GRF>
Здравствуйте, k.o., Вы писали:
KO>Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>>>>В нашей нотации необходимо несколько изменить вызов и определение:
KO>>>И получить другое поведение? Нет уж, так не пойдёт, боюсь, небольшим изменением тут не отделаться.
GRF>>Нет вы получите именно то поведение которое желаете, попробуйте.
KO>Но позвольте, конструкторы класса 'in' принимают константную ссылку на значение аргумента, мне же нужно передавать аргумент по-значению, для unique_ptr передача по константной ссылке и передача по значению это две большие разницы. Впрочем, я попробовал, как и ожидалось, "эквивалентный" код успешно компилируется, там где оригинальный (как и задумывалось) приводит к ошибке компиляции.
KO>>>>>и не всегда применим:
KO>>>>>
KO>>>>>MyType z = in<MyType&>(in<MyType&>(a) + in<MyType&>(in<MyType&>(b) * in<MyType&>(c)));
KO>>>>>
KO>>>>>во что это превратится с использованием expression templates я даже думать не хочу, впрочем, как я понял, некоторым такой вариант кажется более читабельным по сравнению с
GRF>>>>Мы и не планировали что in, in_out и out будут так применяться .
KO>>>А как же ещё им применяться? Входные параметры есть, почему их не надо помечать? Впрочем, я, кажется, понимаю: благодаря удачным названиям функций способ использования передаваемых параметров очевиден, может, тогда, вместо изобретения велосипедов, стоит давать более удачные названия функциям?
GRF>>Например в определении функции так: GRF>>
GRF>>void function( in< MyType& > a, in< MyType& > b, in< MyType& > c )
GRF>>{
GRF>> MyType z = a() + b() * c();
GRF>>}
GRF>>
Здравствуйте, k.o., Вы писали:
KO>Здравствуйте, Galiulin Rishat Faimovich, Вы писали:
GRF>>>>В нашей нотации необходимо несколько изменить вызов и определение:
KO>>>И получить другое поведение? Нет уж, так не пойдёт, боюсь, небольшим изменением тут не отделаться.
GRF>>Нет вы получите именно то поведение которое желаете, попробуйте.
KO>Но позвольте, конструкторы класса 'in' принимают константную ссылку на значение аргумента, мне же нужно передавать аргумент по-значению, для unique_ptr передача по константной ссылке и передача по значению это две большие разницы. Впрочем, я попробовал, как и ожидалось, "эквивалентный" код успешно компилируется, там где оригинальный (как и задумывалось) приводит к ошибке компиляции.
KO>>>>>и не всегда применим:
KO>>>>>
KO>>>>>MyType z = in<MyType&>(in<MyType&>(a) + in<MyType&>(in<MyType&>(b) * in<MyType&>(c)));
KO>>>>>
KO>>>>>во что это превратится с использованием expression templates я даже думать не хочу, впрочем, как я понял, некоторым такой вариант кажется более читабельным по сравнению с
GRF>>>>Мы и не планировали что in, in_out и out будут так применяться .
KO>>>А как же ещё им применяться? Входные параметры есть, почему их не надо помечать? Впрочем, я, кажется, понимаю: благодаря удачным названиям функций способ использования передаваемых параметров очевиден, может, тогда, вместо изобретения велосипедов, стоит давать более удачные названия функциям?
GRF>>Например в определении функции так: GRF>>
GRF>>void function( in< MyType& > a, in< MyType& > b, in< MyType& > c )
GRF>>{
GRF>> MyType z = a() + b() * c();
GRF>>}
GRF>>