> я имел ввиду, что название статьи
ясно, недопонял, что вы имели ввиду.
> по поводу mpl, то это дело вкуса
да, мне на первый взгляд показалось, что с mpl проще будет и универсальнее. хотя сейчас уже кажется, что профит не такой уж и большой.
> но по сути у вас пока только кучка специализаций заменена на mpl::map
выходит, что да :)
> я бы все равно заменил на макрос с говорящим названием
макросов боюсь, и стараюсь избегать :)
для упрощения понимания можно было-бы сделать, что-то вроде:
template < int i, typename T >
struct bindValueCodeOnResultType
{
typedef typename pair< int_< i >, T > type;
};
и в списке типов использовать
bindValueCodeOnResultType< 0, int >::type,
> далее для того, чтобы привязать метод к константе
привязывать разные функции явно впринципе не обязательно для этого случая.
это может понадобиться если к примеру, если нам надо будет по разному доставать значения одинакового типа.
и в этом случае — да, скорее всего прийдется совать структурки с operator() или каким-то методом и конструктором по умолчанию.
> вот что это лучше я с вами согласен, но это абсолютно не меняет дела, внутри скорее всего будет так же как у автора.
Только если использовать внутри WinInet. А ведь может быть и boost::asio, либо какие-то libghttp, да вообще что-угодно.
> а тут мне все-таки кажется что макросами намного проще, быстрее и понятней, чем юзать mpl.
возможно. хотя никто не мешает добавление в mpl::map задефайнить :)
автор сделал много специализаций, я же обошелся списком типов. впринципе это основная разница.
Я буст очень люблю и постоянно использую, но именно в mpl не силен.
Но все же попробую из азарта :)
#include <boost/mpl/map.hpp>
#include <boost/mpl/at.hpp>
#include <boost/mpl/int.hpp>
#include <boost/config.hpp>
#include <iostream>
#include <string>
// accessor functions stubs
// in these function you will obtain value with HttpQueryInfo by valueCode
template< typename ResultT >
ResultT get_value( int valueCode );
template< >
std::string get_value< std::string >( int valueCode )
{
return "hi!";
}
template< >
int get_value< int >( int valueCode )
{
return valueCode * 42;
}
using namespace boost::mpl; // just for simplify
// mpl::map valueCode on result type
typedef map<
pair< int_< 0 >, int >,
pair< int_< 1 >, int >,
pair< int_< 2 >, std::string >,
pair< int_< 3 >, int >
> test1;
// helper structure which help us to avoid to use
// long - at< test1, int_< i > >::type
template< int i >
struct toResultType
{
typedef typename at< test1, int_< i > >::type type;
};
// interface function
template < int i >
typename toResultType< i >::type func()
{
return get_value< toResultType< i >::type > ( i );
}
int
main()
{
std::cout << func<0>() << "\n"
<< func<1>() << "\n"
<< func<2>() << "\n"
<< func<3>() << "\n";
}
Упрощенный ваш пример.
Еще надо будет попробовать связать разные ф-цие с разными valueCode.
Сейчас идет связка тип — valueCode.
>> В идеале хочется получать значение заголовка в одной строке кода:
>> const int code = get_header<HTTP_QUERY_STATUS_CODE>(hRequest);
>> const int responseBodySize = get_header<HTTP_QUERY_CONTENT_LENGTH>(hRequest);
>> const CString allHeaders = get_header<HTTP_QUERY_RAW_HEADERS_CRLF>(hRequest);
Как по мне, так в идеале хотелось бы писать примерно вот-так:
const header_t header = request.header();
const int status = header.statusCode();
const header_t::body_t body = header.responseBody();
// header_t::body_t какая-то структура типа вектора, возможно ref-counting
// и хранящая внутри указатель, во избежание копирования
const size_t bodyLength = body.size(); // итд
— По сути дела вы связали значения констант со способом добычи результата.
Думаю в зависимости от контекста это можно было бы сделать и проще с помощью того же mpl или в run-time c помощью обычных макросов
PS: Мои поправки не имеют отношения к вашей идее, только к ее применению, названию и способу использования. Сама идея, думаю, вполне жизнеспособна.
Что вы называете модулем?
Это еденица уровня инклуда, или уровня статической/динамической библиотеки, или нечто среднее?
ЗЫ: не хочу обидеть, но мне кажется вы не так давно мигрировали с паскаля или делфи на с++, выучили синтаксис недоразобравшись в философии языка и теперь его критикуете :)
>> а что происходит с техникой которую покупают в складчину в офис если все те кто покупал уволились
по негласному правилу — последний из скидывавшихся — хозяин вещи. и он на свое усмотрение либо оставляет ее в офисе либо продает с разных интернет аукционов либо забирает домой :)
research.microsoft.com/en-us/projects/detours/
средние люди обсуждают события,
а мелкие – обсуждают других людей.» (с)
ясно, недопонял, что вы имели ввиду.
> по поводу mpl, то это дело вкуса
да, мне на первый взгляд показалось, что с mpl проще будет и универсальнее. хотя сейчас уже кажется, что профит не такой уж и большой.
выходит, что да :)
> я бы все равно заменил на макрос с говорящим названием
макросов боюсь, и стараюсь избегать :)
для упрощения понимания можно было-бы сделать, что-то вроде:
template < int i, typename T > struct bindValueCodeOnResultType { typedef typename pair< int_< i >, T > type; }; и в списке типов использовать bindValueCodeOnResultType< 0, int >::type,> далее для того, чтобы привязать метод к константе
привязывать разные функции явно впринципе не обязательно для этого случая.
это может понадобиться если к примеру, если нам надо будет по разному доставать значения одинакового типа.
и в этом случае — да, скорее всего прийдется совать структурки с operator() или каким-то методом и конструктором по умолчанию.
Только если использовать внутри WinInet. А ведь может быть и boost::asio, либо какие-то libghttp, да вообще что-угодно.
> а тут мне все-таки кажется что макросами намного проще, быстрее и понятней, чем юзать mpl.
возможно. хотя никто не мешает добавление в mpl::map задефайнить :)
автор сделал много специализаций, я же обошелся списком типов. впринципе это основная разница.
Спасибо :)
Но все же попробую из азарта :)
#include <boost/mpl/map.hpp> #include <boost/mpl/at.hpp> #include <boost/mpl/int.hpp> #include <boost/config.hpp> #include <iostream> #include <string> // accessor functions stubs // in these function you will obtain value with HttpQueryInfo by valueCode template< typename ResultT > ResultT get_value( int valueCode ); template< > std::string get_value< std::string >( int valueCode ) { return "hi!"; } template< > int get_value< int >( int valueCode ) { return valueCode * 42; } using namespace boost::mpl; // just for simplify // mpl::map valueCode on result type typedef map< pair< int_< 0 >, int >, pair< int_< 1 >, int >, pair< int_< 2 >, std::string >, pair< int_< 3 >, int > > test1; // helper structure which help us to avoid to use // long - at< test1, int_< i > >::type template< int i > struct toResultType { typedef typename at< test1, int_< i > >::type type; }; // interface function template < int i > typename toResultType< i >::type func() { return get_value< toResultType< i >::type > ( i ); } int main() { std::cout << func<0>() << "\n" << func<1>() << "\n" << func<2>() << "\n" << func<3>() << "\n"; }Упрощенный ваш пример.
Еще надо будет попробовать связать разные ф-цие с разными valueCode.
Сейчас идет связка тип — valueCode.
>> или в run-time c помощью обычных макросов
или в run-time c помощью обычных map-ов и функторов.
пора идти спать
>> const int code = get_header<HTTP_QUERY_STATUS_CODE>(hRequest);
>> const int responseBodySize = get_header<HTTP_QUERY_CONTENT_LENGTH>(hRequest);
>> const CString allHeaders = get_header<HTTP_QUERY_RAW_HEADERS_CRLF>(hRequest);
Как по мне, так в идеале хотелось бы писать примерно вот-так:
— Также, помоему вы немного не верно толкуете идиому trait.
Сверьтесь с сылками отсюда: en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Traits
— По сути дела вы связали значения констант со способом добычи результата.
Думаю в зависимости от контекста это можно было бы сделать и проще с помощью того же mpl или в run-time c помощью обычных макросов
PS: Мои поправки не имеют отношения к вашей идее, только к ее применению, названию и способу использования. Сама идея, думаю, вполне жизнеспособна.
И хотел что-то попроще и поменьше, но с флаком и хорошим звуком.
Плюс органически не перевариваю плееров на которые записать музыку можно только через какую-то специальную программу а не как на Mass Storage device.
Это еденица уровня инклуда, или уровня статической/динамической библиотеки, или нечто среднее?
ЗЫ: не хочу обидеть, но мне кажется вы не так давно мигрировали с паскаля или делфи на с++, выучили синтаксис недоразобравшись в философии языка и теперь его критикуете :)
по негласному правилу — последний из скидывавшихся — хозяин вещи. и он на свое усмотрение либо оставляет ее в офисе либо продает с разных интернет аукционов либо забирает домой :)
есть два печальных опыта.
Турник,
Столик для армрестлинга,
Powerball.
Пару раз были мысли скинуться и вызывать массажиста в офис, но места нету.
*ваш КО*