Error: ambiguous overload for 'operator<<' (operand types are 'std::ofstream {aka std::basic_ofstream<char>}'

@taras atavin · Регистрация: 24.11.2009

error: ambiguous overload for 'operator<<' (operand types are 'std::ofstream {aka std::basic_ofstream<char>}' and 'size_t {aka long long unsigned int}')|

на

C++

#define LOG(Variable) Log<<"<"; Log<<StripXML(#Variable)<<">"<<std::endl<<"<Bits>x"<<std::dec<<std::noshowbase<<8*sizeof(Variable)<<std::hex<<std::showbase<<"</Bits>"<<std::endl<<"<Line>"<<std::dec<<std::noshowbase<<__LINE__<<std::hex<<std::showbase<<"</Line>"<<std::endl<<"<Adress>"<<(void*)&Variable<<"</Adress>"<<std::endl<<"<Value>"; Log<<Variable<<"</Value>"<<std::endl<<"</"; Log<<StripXML(#Variable)<<">"<<std::endl

. Как исправить?

Добавлено через 1 час 13 минут
Проблема решена, но не понята:

C++

#define LOG(Variable) Log<<"<"; Log<<StripXML(#Variable)<<">"<<std::endl<<"<Bits>x"<<std::dec<<std::noshowbase<<8*sizeof(Variable)<<std::hex<<std::showbase<<"</Bits>"<<std::endl<<"<Line>"<<std::dec<<std::noshowbase<<__LINE__<<std::hex<<std::showbase<<"</Line>"<<std::endl<<"<Adress>"<<(void*)&Variable<<"</Adress>"<<std::endl<<"<Value>"; Log<<Variable; Log<<"</Value>"<<std::endl<<"</"; Log<<StripXML(#Variable)<<">"<<std::endl

.

@TheCalligrapher · 25.11.2014, 20:27

Сообщение от taras atavin

Как исправить?

Не пытаться посылать на выход значения типа 'size_t'. В стандартных потоках не гарантируется наличие оператора вывода для того типа , который скрывается за 'size_t' . Хотите выводить 'size_t' - явно приводите его к конкретному стандартному целочисленному типу.

Сообщение от taras atavin

Проблема решена,

Никакого "решения проблемы" в этой ковровой дорожке длиной в три километра я не увидел и высматривать не собираюсь. Если вы нашли какое-то решение проблемы - описывайте его нормальным русским языком.

@taras atavin · 26.11.2014, 05:51 **[ТС]**

Сообщение от TheCalligrapher

Если вы нашли какое-то решение проблемы - описывайте его нормальным русским языком.

Я даже не понимаю, в чём проблема была.

@Toshkarik · 26.11.2014, 07:30

Сообщение от TheCalligrapher

В стандартных потоках не гарантируется наличие оператора вывода для того типа , который скрывается за 'size_t' .

Можно узнать, почему? size_t это гарантированно alias на один из фундаментальных типов. А операторы ввода/вывода вроде перегружены для всех фундаментальных типов.

Добавлено через 9 минут
taras atavin, а как Вы используете этот макрос и что за функция ( или макрос ) StripXML?

@taras atavin · 26.11.2014, 07:37 **[ТС]**

Макрос выводит переменную в xml-лог, записывая её имя, адрес, значение и в какой конкретно строке программы она имеет такое значение. А функция экранирует символы &<>.

@Toshkarik · 26.11.2014, 07:44

Вы не перегружали operator<<? У меня оба варианта отрабатывают нормально.

Добавлено через 2 минуты
И не понятно, зачем экранировать &<>? Откуда им взяться в имени переменной?

@TheCalligrapher · 26.11.2014, 07:49

Сообщение от Toshkarik

size_t это гарантированно alias на один из фундаментальных типов.

Как раз таки не гарантируется, что за 'size_t' скрывается стандартный тип. Это может быть и какой-то платформенно-зависимый нестандартный тип.

Например, до С++11 самым большим целым типом в С++ был 'long', который не обязан быть 64-битным, но при этом 64-битные С++ платформы (с соответственно 64-битным 'size_t') появились задолго до С++11. Понятно, что на таких платформах за 'size_t' скрывалось что-то нестандартное. На таких платформах формально не гарантируется существование потоковых операторов ввода-вывода для 'size_t'.

К примеру, можно взять тот же MS Visual Studio - С++ платформу, которая относительно давно поддерживает 64-битный код (т.е. 64-битный 'size_t'), но до относительно недавнего времени не поддерживала 'long long'.

И даже на платформах с 'long long' не гарантируется, что 'size_t' будет использовать именно его.

@taras atavin · 26.11.2014, 08:03 **[ТС]**

Сообщение от Toshkarik

И не понятно, зачем экранировать &<>? Откуда им взяться в имени переменной?

Функция предназначена для значений, для имён я её не смог сделать. Предположим, я хочу залогировать член Name безыменного объекта по указателю Child, в браузере это должно выглядеть так:
Название: Скрин.png
Просмотров: 78

Размер: 5.8 Кб

Название: Скрин.png
Просмотров: 78

Размер: 5.8 Кб

. Или я хочу вместо этого залогировать безыменный unsigned long long int по указателю s, в браузере это должно выглядеть так:
Название: Скрин1.png
Просмотров: 78

Размер: 5.4 Кб

Название: Скрин1.png
Просмотров: 78

Размер: 5.4 Кб

. Так вот, этого я пока не добился. На адрес не смотрите, он здесь с абсолютно потолочного фрагметнта лога.

@taras atavin · 26.11.2014, 08:07 **[ТС]**

Сообщение от TheCalligrapher

К примеру, можно взять тот же MS Visual Studio - С++ платформу, которая относительно давно поддерживает 64-битный код (т.е. 64-битный 'size_t'), но до относительно недавнего времени не поддерживала 'long long'.

Она поддерживала тип hyper.

@Toshkarik · 26.11.2014, 08:29

TheCalligrapher, так речь не о догадках о том, как ой именно это тип. А о том, что он является одним из фундаментальных типов для этой платформы. В gcc на x86_64 платформе, собственно, long равен 64 битам.
По Вашей логике получается, что в некоторой реализации может отсутсвовать возможность вывода индекса, так как просто может не быть типа необходимого размера при приведении size_t к беззнаковому целому. Собственно, сам суфикс _t намекает на то, что это typedef некоторого типа ( есть, конечно, шанс, что не стандартного ). Хотя может это сокращение не от typedef, а от type . Если Вы вдруг встречали такую реализацию ( может упомянутый VS? но не указана версия ), то буду признателен, если Вы ее назовете. Самому инетресно.

Добавлено через 8 минут

Сообщение от taras atavin

для имён я её не смог сделать

Variable в данном макросе является параметром. Оператор # в макросах, обрамляет параметр в двойные кавычки.
Например:

C++

int a = 10;
 
LOG( a ); //в StripXML передается "a"
 
int *p = new int( 12 );
 
LOG( *a ); //в StripXML передается "*P"

@taras atavin · 26.11.2014, 08:35 **[ТС]**

Сообщение от Toshkarik

Variable в данном макросе является параметром. Оператор # в макросах, обрамляет параметр в двойные кавычки. То есть получается имя параметра в виде C-строки. Откуда следует, что в StripXML передается имя параметра.Например:

Вот только это не единственный макрос, где участвует эта функция. В данном макросе это просто хвост от попыток добиться правильного отображения в браузере тегов, соответствующих членам и безымянным переменным, функция же после безуспешных попыток добиться экранирования символов в тегах осталась для значений и используется в других макросах.

@Toshkarik · 26.11.2014, 08:44

Понянто. Тогда без полной картины нельзя точно сказать, что не так. Я создал StripXML, которая просто возращает свой аргумент ( const char * ) и у меня все работает нормально. В качестве Log использовал std::cout.

@TheCalligrapher · 26.11.2014, 08:53

Сообщение от taras atavin

на поддерживала тип hyper.

Она поддерживала тип '__int64', который стандартным не являлся.

@taras atavin · 26.11.2014, 08:55 **[ТС]**

Переписал так:

C++

#define LOG(Variable) Log<<"<Variable>"<<std::endl<<"<Identifier>"; Log<<StripXML(#Variable); Log<<"</Identifier>"<<std::endl<<"<Bits>x"<<std::dec<<std::noshowbase<<8*sizeof(Variable)<<std::hex<<std::showbase<<"</Bits>"<<std::endl<<"<Line>"<<std::dec<<std::noshowbase<<__LINE__<<std::hex<<std::showbase<<"</Line>"<<std::endl<<"<Adress>"<<(void*)&Variable<<"</Adress>"<<std::endl<<"<Value>"; Log<<Variable; Log<<"</Value>"<<std::endl<<"</Variable>"<<std::endl

, теперь и имена экранирутся, а значения экранируют перегруженные операторы.

Добавлено через 16 секунд

Сообщение от TheCalligrapher

Она поддерживала тип '__int64', который стандартным не являлся.

Тип hyper.

@TheCalligrapher · 26.11.2014, 09:20

Сообщение от Toshkarik

А о том, что он является одним из фундаментальных типов для этой платформы.

Я не знаю, что такое "фундаментальные типы для этой платформы" и к чему они тут. Речь идет о том, что список операторов форматированного ввода вывода в спецификации языка содержит только стандартные типы. А на какие-то "фундаментальные типы для этой платформы" стандарту языка глубоко наплевать. Операторов ввода-вывода для остальных - нестандартных - типов спецификацией языка не требуется. Если специального оператора для нестандартного 'size_t' нет, то компилятор будет пытаться использовать какой-то из уже существующих с возникновением ambiguity. Я думаю, что ошибка, отрапортованная в первом сообщении ТС произошла именно из-за этого.

Сообщение от Toshkarik

По Вашей логике получается, что в некоторой реализации может отсутсвовать возможность вывода индекса, так как просто может не быть типа необходимого размера при приведении size_t к беззнаковому целому.

Именно так.

Порывшись в С++11 я не увидел нигде требования, чтобы стандартные потоки умели выводить 'size_t'.

Сообщение от Toshkarik

Собственно, сам суфикс _t намекает на то, что это typedef некоторого типа ( есть, конечно, шанс, что не стандартного ).

Да, это typedef. Хотя С++11 вроде уже ушел от того, чтобы заявлять об этом явно. Но в спецификации языка ясно же сказано, что это - платформенно-зависимый тип. Известно только, что он должен быть беззнаковым. Но нигде не требуется, чтобы этот тип совпадал с каким-то стандартным типом.

Сообщение от Toshkarik

Если Вы вдруг встречали такую реализацию ( может упомянутый VS? но не указана версия ), то буду признателен, если Вы ее назовете.

О какой именно реализации идет речь? Я уже называл реализацию: любая VS с поддержкой x64, но без поддержки 'long long'. Такая VS использовала 'unsigned __int64' в качестве 'size_t'. Это - нестандартный тип. Вот чего я не помню, так это был ли в ней реализованы операторы ввода-вывода для 'unsigned __int64'...

Добавлено через 5 минут

Сообщение от taras atavin

Тип hyper.

Нет, именно '__int64'. Тип 'hyper' - это тип из каких-то настолько замшелых и покрытых песками памяти версий Visual Studio, что о нем не помнит даже Интернет. Когда существовал тип 'hyper', 64-битный тип 'size_t' был еще не нужен.

Забудь про 'hyper' навсегда. Это было давно и неправда...

@Toshkarik · 26.11.2014, 09:28

Сообщение от TheCalligrapher

Вот чего я не помню, так это был ли в ней реализованы операторы ввода-вывода для 'unsigned __int64'...

Вот в этом суть вопроса была.

Добавлено через 2 минуты
То есть об вводе/выводе типа size_t должно быть что то сказано в стандарте. Нужно будет поискать.

Добавлено через 2 минуты
Вот здесь http://www.cplusplus.com/reference/cstring/size_t/ сказано, что он

Alias of one of the fundamental unsigned integer types.

Сайт является справочником.

@taras atavin · 26.11.2014, 09:36 **[ТС]**

Сообщение от TheCalligrapher

Такая VS использовала 'unsigned __int64' в качестве 'size_t'. Это - нестандартный тип.

Мелкомягко-студийный тип разрядности 64 бита зовут hyper.

Добавлено через 1 минуту

Сообщение от TheCalligrapher

Нет, именно '__int64'. Тип 'hyper' - это тип из каких-то настолько замшелых и покрытых песками памяти версий Visual Studio, что о нем не помнит даже Интернет. Когда существовал тип 'hyper', 64-битный тип 'size_t' был еще не нужен.
Забудь про 'hyper' навсегда. Это было давно и неправда...

Не так уже давно, всего лишь четвёртая версия.

@TheCalligrapher · 26.11.2014, 10:21

Сообщение от Toshkarik

Сайт является справочником.

cplusplus.com - сравнительно низкокачественный сайт, на котором часто встречаются неточности именно вот в таких деталях. Существенно более уважаемый сайт - cppreference.com - относится к спецификации языка более педантично.

Сообщение от taras atavin

Мелкомягко-студийный тип разрядности 64 бита зовут hyper.

Нет, никакого типа 'hyper' в компиляторах C и C++ студии уж давно как нет. Когда то такой тип был, но его уже давно заменили на '__int64'. Причем именно заменили: ни одна студия с тех пор не знает никакого 'hyper'.

@Toshkarik · 26.11.2014, 10:54

Сообщение от TheCalligrapher

cplusplus.com - сравнительно низкокачественный сайт, на котором часто встречаются неточности именно вот в таких деталях. Существенно более уважаемый сайт - cppreference.com - относится к спецификации языка более педантично.

По мне так наоборот. Больше неточностей встречал на cppreference, поэтому считаю cplusplus выше уровнем, он и существует дольше.

Сообщение от TheCalligrapher

Нет, никакого типа 'hyper' в компиляторах C и C++ студии уж давно как нет.

С Тарасом можно даже не спорить. Бесполезно.
По найденым клочкам, сделал вывод, что вроде этот тип был еще во времена перехода с 16 на 32 битные системы.

MrGluck · 26.11.2014, 11:16

taras atavin, если много где используется xml - советую либу pugixml. Она простая и может быть "one header file".

Добавлено через 33 секунды
И чем не устраивает шаблонная функция?

Добавлено через 3 минуты

Сообщение от Toshkarik

Больше неточностей встречал на cppreference, поэтому считаю cplusplus выше уровнем, он и существует дольше.

Да что тут мериться, справочники они и есть справочники. В них полезно быстренько про функцию/контейнер почитать и способ применения посмотреть. В остальном есть только один достоверный источник информации - стандарт, остальное от лукавого. Думаю, все тут с этим согласны.

@TheCalligrapher С чаем беда... 9257 / 4757 / 1288 Регистрация: 18.10.2014 Сообщений: 10,817
	26.11.2014, 09:20	15
	Сообщение от Toshkarik А о том, что он является одним из фундаментальных типов для этой платформы. Я не знаю, что такое "фундаментальные типы для этой платформы" и к чему они тут. Речь идет о том, что список операторов форматированного ввода вывода в спецификации языка содержит только стандартные типы. А на какие-то "фундаментальные типы для этой платформы" стандарту языка глубоко наплевать. Операторов ввода-вывода для остальных - нестандартных - типов спецификацией языка не требуется. Если специального оператора для нестандартного 'size_t' нет, то компилятор будет пытаться использовать какой-то из уже существующих с возникновением ambiguity. Я думаю, что ошибка, отрапортованная в первом сообщении ТС произошла именно из-за этого. Сообщение от Toshkarik По Вашей логике получается, что в некоторой реализации может отсутсвовать возможность вывода индекса, так как просто может не быть типа необходимого размера при приведении size_t к беззнаковому целому. Именно так. Порывшись в С++11 я не увидел нигде требования, чтобы стандартные потоки умели выводить 'size_t'. Сообщение от Toshkarik Собственно, сам суфикс _t намекает на то, что это typedef некоторого типа ( есть, конечно, шанс, что не стандартного ). Да, это typedef. Хотя С++11 вроде уже ушел от того, чтобы заявлять об этом явно. Но в спецификации языка ясно же сказано, что это - платформенно-зависимый тип. Известно только, что он должен быть беззнаковым. Но нигде не требуется, чтобы этот тип совпадал с каким-то стандартным типом. Сообщение от Toshkarik Если Вы вдруг встречали такую реализацию ( может упомянутый VS? но не указана версия ), то буду признателен, если Вы ее назовете. О какой именно реализации идет речь? Я уже называл реализацию: любая VS с поддержкой x64, но без поддержки 'long long'. Такая VS использовала 'unsigned __int64' в качестве 'size_t'. Это - нестандартный тип. Вот чего я не помню, так это был ли в ней реализованы операторы ввода-вывода для 'unsigned __int64'... Добавлено через 5 минут Сообщение от taras atavin Тип hyper. Нет, именно '__int64'. Тип 'hyper' - это тип из каких-то настолько замшелых и покрытых песками памяти версий Visual Studio, что о нем не помнит даже Интернет. Когда существовал тип 'hyper', 64-битный тип 'size_t' был еще не нужен. Забудь про 'hyper' навсегда. Это было давно и неправда... 0

@taras atavin 4200 / 1792 / 211 Регистрация: 24.11.2009 Сообщений: 27,563
	26.11.2014, 09:36 [ТС]	17
	Сообщение от TheCalligrapher Такая VS использовала 'unsigned __int64' в качестве 'size_t'. Это - нестандартный тип. Мелкомягко-студийный тип разрядности 64 бита зовут hyper. Добавлено через 1 минуту Сообщение от TheCalligrapher Нет, именно '__int64'. Тип 'hyper' - это тип из каких-то настолько замшелых и покрытых песками памяти версий Visual Studio, что о нем не помнит даже Интернет. Когда существовал тип 'hyper', 64-битный тип 'size_t' был еще не нужен. Забудь про 'hyper' навсегда. Это было давно и неправда... Не так уже давно, всего лишь четвёртая версия. 0

@TheCalligrapher С чаем беда... 9257 / 4757 / 1288 Регистрация: 18.10.2014 Сообщений: 10,817
	26.11.2014, 10:21	18
	Сообщение от Toshkarik Сайт является справочником. cplusplus.com - сравнительно низкокачественный сайт, на котором часто встречаются неточности именно вот в таких деталях. Существенно более уважаемый сайт - cppreference.com - относится к спецификации языка более педантично. Сообщение от taras atavin Мелкомягко-студийный тип разрядности 64 бита зовут hyper. Нет, никакого типа 'hyper' в компиляторах C и C++ студии уж давно как нет. Когда то такой тип был, но его уже давно заменили на '__int64'. Причем именно заменили: ни одна студия с тех пор не знает никакого 'hyper'. 0

@Toshkarik 1174 / 887 / 94 Регистрация: 03.08.2011 Сообщений: 2,457
	26.11.2014, 10:54	19
	Сообщение от TheCalligrapher cplusplus.com - сравнительно низкокачественный сайт, на котором часто встречаются неточности именно вот в таких деталях. Существенно более уважаемый сайт - cppreference.com - относится к спецификации языка более педантично. По мне так наоборот. Больше неточностей встречал на cppreference, поэтому считаю cplusplus выше уровнем, он и существует дольше. Сообщение от TheCalligrapher Нет, никакого типа 'hyper' в компиляторах C и C++ студии уж давно как нет. С Тарасом можно даже не спорить. Бесполезно. По найденым клочкам, сделал вывод, что вроде этот тип был еще во времена перехода с 16 на 32 битные системы. 0

@TheCalligrapher С чаем беда... 9257 / 4757 / 1288 Регистрация: 18.10.2014 Сообщений: 10,817
	25.11.2014, 20:27	2
	Сообщение от taras atavin Как исправить? Не пытаться посылать на выход значения типа 'size_t'. В стандартных потоках не гарантируется наличие оператора вывода для того типа , который скрывается за 'size_t' . Хотите выводить 'size_t' - явно приводите его к конкретному стандартному целочисленному типу. Сообщение от taras atavin Проблема решена, Никакого "решения проблемы" в этой ковровой дорожке длиной в три километра я не увидел и высматривать не собираюсь. Если вы нашли какое-то решение проблемы - описывайте его нормальным русским языком. 0

@taras atavin 4200 / 1792 / 211 Регистрация: 24.11.2009 Сообщений: 27,563
	26.11.2014, 05:51 [ТС]	3
	Сообщение от TheCalligrapher Если вы нашли какое-то решение проблемы - описывайте его нормальным русским языком. Я даже не понимаю, в чём проблема была. 0

@Toshkarik 1174 / 887 / 94 Регистрация: 03.08.2011 Сообщений: 2,457
	26.11.2014, 07:30	4
	Сообщение от TheCalligrapher В стандартных потоках не гарантируется наличие оператора вывода для того типа , который скрывается за 'size_t' . Можно узнать, почему? size_t это гарантированно alias на один из фундаментальных типов. А операторы ввода/вывода вроде перегружены для всех фундаментальных типов. Добавлено через 9 минут taras atavin, а как Вы используете этот макрос и что за функция ( или макрос ) StripXML? 0

@taras atavin 4200 / 1792 / 211 Регистрация: 24.11.2009 Сообщений: 27,563
	26.11.2014, 07:37 [ТС]	5
	Макрос выводит переменную в xml-лог, записывая её имя, адрес, значение и в какой конкретно строке программы она имеет такое значение. А функция экранирует символы &<>. 0

@Toshkarik 1174 / 887 / 94 Регистрация: 03.08.2011 Сообщений: 2,457
	26.11.2014, 07:44	6
	Вы не перегружали operator<<? У меня оба варианта отрабатывают нормально. Добавлено через 2 минуты И не понятно, зачем экранировать &<>? Откуда им взяться в имени переменной? 0

@TheCalligrapher С чаем беда... 9257 / 4757 / 1288 Регистрация: 18.10.2014 Сообщений: 10,817
	26.11.2014, 07:49	7
	Сообщение от Toshkarik size_t это гарантированно alias на один из фундаментальных типов. Как раз таки не гарантируется, что за 'size_t' скрывается стандартный тип. Это может быть и какой-то платформенно-зависимый нестандартный тип. Например, до С++11 самым большим целым типом в С++ был 'long', который не обязан быть 64-битным, но при этом 64-битные С++ платформы (с соответственно 64-битным 'size_t') появились задолго до С++11. Понятно, что на таких платформах за 'size_t' скрывалось что-то нестандартное. На таких платформах формально не гарантируется существование потоковых операторов ввода-вывода для 'size_t'. К примеру, можно взять тот же MS Visual Studio - С++ платформу, которая относительно давно поддерживает 64-битный код (т.е. 64-битный 'size_t'), но до относительно недавнего времени не поддерживала 'long long'. И даже на платформах с 'long long' не гарантируется, что 'size_t' будет использовать именно его. 0

@taras atavin 4200 / 1792 / 211 Регистрация: 24.11.2009 Сообщений: 27,563
	26.11.2014, 08:03 [ТС]	8
	Сообщение от Toshkarik И не понятно, зачем экранировать &<>? Откуда им взяться в имени переменной? Функция предназначена для значений, для имён я её не смог сделать. Предположим, я хочу залогировать член Name безыменного объекта по указателю Child, в браузере это должно выглядеть так: . Или я хочу вместо этого залогировать безыменный unsigned long long int по указателю s, в браузере это должно выглядеть так: . Так вот, этого я пока не добился. На адрес не смотрите, он здесь с абсолютно потолочного фрагметнта лога. 0

@taras atavin 4200 / 1792 / 211 Регистрация: 24.11.2009 Сообщений: 27,563
	26.11.2014, 08:07 [ТС]	9
	Сообщение от TheCalligrapher К примеру, можно взять тот же MS Visual Studio - С++ платформу, которая относительно давно поддерживает 64-битный код (т.е. 64-битный 'size_t'), но до относительно недавнего времени не поддерживала 'long long'. Она поддерживала тип hyper. 0

@taras atavin 4200 / 1792 / 211 Регистрация: 24.11.2009 Сообщений: 27,563
	26.11.2014, 08:35 [ТС]	11
	Сообщение от Toshkarik Variable в данном макросе является параметром. Оператор # в макросах, обрамляет параметр в двойные кавычки. То есть получается имя параметра в виде C-строки. Откуда следует, что в StripXML передается имя параметра.Например: Вот только это не единственный макрос, где участвует эта функция. В данном макросе это просто хвост от попыток добиться правильного отображения в браузере тегов, соответствующих членам и безымянным переменным, функция же после безуспешных попыток добиться экранирования символов в тегах осталась для значений и используется в других макросах. 0

@Toshkarik 1174 / 887 / 94 Регистрация: 03.08.2011 Сообщений: 2,457
	26.11.2014, 08:44	12
	Понянто. Тогда без полной картины нельзя точно сказать, что не так. Я создал StripXML, которая просто возращает свой аргумент ( const char * ) и у меня все работает нормально. В качестве Log использовал std::cout. 0

@TheCalligrapher С чаем беда... 9257 / 4757 / 1288 Регистрация: 18.10.2014 Сообщений: 10,817
	26.11.2014, 08:53	13
	Сообщение от taras atavin на поддерживала тип hyper. Она поддерживала тип '__int64', который стандартным не являлся. 0

@Toshkarik 1174 / 887 / 94 Регистрация: 03.08.2011 Сообщений: 2,457
	26.11.2014, 09:28	16
	Сообщение от TheCalligrapher Вот чего я не помню, так это был ли в ней реализованы операторы ввода-вывода для 'unsigned __int64'... Вот в этом суть вопроса была. Добавлено через 2 минуты То есть об вводе/выводе типа size_t должно быть что то сказано в стандарте. Нужно будет поискать. Добавлено через 2 минуты Вот здесь http://www.cplusplus.com/reference/cstring/size_t/ сказано, что он Alias of one of the fundamental unsigned integer types. Сайт является справочником. 0

MrGluck Форумчанин 8170 / 5020 / 1436 Регистрация: 29.11.2010 Сообщений: 13,453
	26.11.2014, 11:16	20
	taras atavin, если много где используется xml - советую либу pugixml. Она простая и может быть "one header file". Добавлено через 33 секунды И чем не устраивает шаблонная функция? Добавлено через 3 минуты Сообщение от Toshkarik Больше неточностей встречал на cppreference, поэтому считаю cplusplus выше уровнем, он и существует дольше. Да что тут мериться, справочники они и есть справочники. В них полезно быстренько про функцию/контейнер почитать и способ применения посмотреть. В остальном есть только один достоверный источник информации - стандарт, остальное от лукавого. Думаю, все тут с этим согласны. 0