Но! Истина была как всегда рядом. Жаль я не додумался использовать Unicode раньше :)
| CODE |
#include <iostream> int main() { std::wcout.imbue(std::locale(".866")); std::wcout << L"Привет всем!" << std::endl; } |
Выводит на эран именно:
Привет всем!
а не:
¦ЁштхЄ тёхь!
:)
PS. Если найдутся люди, кому это интересно, могу продолжить. За время работы скопилась масса различных "ах если б молодость знала"
PPS. Буду рад, если кто еще захочет поделиться опытом!
Как думаете, что делает это код?
| CODE |
size = std::accumulate(diskSpaces.begin(), diskSpaces.end(), int(), compose_f_gx_hy( std::plus<int>(), std::bind1st(std::plus<int>(), int()), std::mem_fun_ref(&DiskSpace::GetSize))); |
При условии, что:
| CODE |
struct DiskSpace { int GetSize(); }; std::vector<DiskSpace> DiskSpaces; |
Всего лишь вычисляет сумму Size всех элементов контейнера. Причем стандартными средствами STL это сделать нельзя. Использован функтор, расширяющий возможности стандартной библиотеки compose_f_gx_hy . Его описание можно найти в книге Николая Джосаттиса "The C++ Standard Library" .
Это сообщение отредактировал GregZ - 21-04-2006 - 23:36
http://www.sexnarod.ru/index.php?showtopic=96226
(вопрос с подвохом)
Для каких вариантов наследования стандарт разрешает преобразование указателя базового класса на указатель производного при помощи static_cast?
| CODE |
class A {}; class B : /* вариант наследования */ A {}; int main() { A* a; B* b = static_cast<B*>(a); } |
1 public
2 protected
3 private
4 virtual public
5 virtual protected
6 virtual private
Кто первый ответит правильно и объяснит ответ, не пожалею 20 сексо. Больше просто нет :). Ну и конечно репутацию!
Неужели ни кто не знает ответа?
| QUOTE (GregZ @ 22.05.2006 - время: 21:50) |
| Судя по всему придётся отвечать самому. :)) Неужели ни кто не знает ответа? |
А народу тяжело... :) Стандарт открывать или компилятор запускать - нечестно, а так не помнят... Это я про себя. :)
| QUOTE (JeyLo @ 22.05.2006 - время: 22:01) |
А народу тяжело... :) Стандарт открывать или компилятор запускать - нечестно, а так не помнят... Это я про себя. :) |
Вопрос не даром с подвохом. Большинство современных компиляторов не дадут полностью правильного ответа на этот вопрос. В частности ошибутся VS8.0 и даже хваленый Comeau.
Вот стандарт - другое дело. Но я совсем не против этого! Даже - за. Лишь бы правильно.
Итак ответ:
4 virtual public
5 virtual protected
6 virtual private
Эти варианты отметаются сразу. Реализация виртуального наследования в языке С++ не позволяет во время компиляции получить указатель производного класса из базового. Другое дело - во время выполнения, но для этого нужно использовать dynamic_cast.
1 public
Ответ вполне однозначен. Преобразование возможно.
2 protected
3 private
Самые сложные варианты. Как известно при закрытом и защищенном наследовании невозможно преобразовать даже указатель производного класса к указателю на базовый класс. Следовательно обратное преобразование (суть вопроса) вдвойне не имеет смысла, хотя практически (для компилятора) возможно.
НО! Первое ограничение легко обойти. Достаточно открытой функции-члена в производном классе, возвращающей указатель на базовый класс. Что же тогда произойдет попытке обратного преобразования!?
Компиляторы 8 студии и Comeau со спокойной душой допустят его. И... будут не правы. Лишь gcc корректно сообщит об ошибке преобразования. Дело в том, что стандарт явно запрещает преобразования от базового класса с производному, если невозможно преобразования от производного к базовому. :) Вот такое разночтение стандарта.
ЗЫ. ISO/IEC 14882-2003 (Пункт 5.2.9 стих 5)
| QUOTE |
An lvalue of type “cv1 B”, where B is a class type, can be cast to type “reference to cv2 D”, where D is a class derived (clause 10) from B, if a valid standard conversion from “pointer to D” to “pointer to B” exists (4.10), cv2 is the same cv-qualification as, or greater cv-qualification than, cv1, and B is not a virtual base class of D. The result is an lvalue of type “cv2 D.” If the lvalue of type “cv1 B” is actually a sub-object of an object of type D, the lvalue refers to the enclosing object of type D. Otherwise, the result of the cast is undefined. |
По его канонам мне надо было задавать такие вопросы:1. Перечислить производителей компиляторов (только С++). Не менее 3. :)
2. Перечислить ключевые слова языка программирования С++. Не менее 5. :)
3. На бумаге какого цвета напечатан стандарт 2003 адаптированный INCITS? :)
| QUOTE (GregZ @ 26.05.2006 - время: 21:02) |
| 1. Перечислить производителей компиляторов (только С++). Не менее 3. :) 2. Перечислить ключевые слова языка программирования С++. Не менее 5. :) 3. На бумаге какого цвета напечатан стандарт 2003 адаптированный INCITS? :) |
А че такие сложные вопросы? :) Папроще!
| QUOTE (tetro @ 26.05.2006 - время: 22:57) |
| По поводу производителей компиляторов, кого мы считаем: у кого полностью свой, чей C++ frontend или чей backend? |
Без разницы. Лишь бы современные. :)
| QUOTE (GregZ @ 26.05.2006 - время: 21:02) |
| 3. На бумаге какого цвета напечатан стандарт 2003 адаптированный INCITS? :) |
Я его распечатала на розовой...
Причем буквами magenta. Симпатишненько получилось
При перегрузке функции foo:
| CODE |
void foo(int) {} void foo(const int&) {} |
компилятор не может выбрать наиболее подходящую функцию. Для него они: indistinguishable conversion sequences.
Т.е.:
| CODE |
int f = 1; const int& rf = f; foo(f); // Error: ambiguous foo(rf); // Error: ambiguous |
В стандарте [C++03] п. 13.3.3.2 стих 3:
Standard conversion sequence S1 is a better conversion sequence than standard conversion sequence
S2 if:
...
- S1 and S2 are reference bindings (8.5.3), and the types to which the references refer are the same
type except for top-level cv-qualifiers, and the type to which the reference initialized by S2 refers is
more cv-qualified than the type to which the reference initialized by S1 refers.
...
| CODE |
| #include <iostream> int main() { std::wcout.imbue(std::locale(".866")); std::wcout << L"Привет всем!" << std::endl; } |
Не работает...
| QUOTE (Roman @ 01.06.2006 - время: 00:41) |
| Не работает... |
Не компилируется, или работает некорректно? Если второе, что конкретно не так?
| QUOTE (GregZ @ 01.06.2006 - время: 12:37) | ||
Не компилируется, или работает некорректно? Если второе, что конкретно не так? |
Не то выводит: "¦ЁштхЄ тёхь!".
| QUOTE (Roman @ 02.06.2006 - время: 00:53) |
| Не то выводит: "¦ЁштхЄ тёхь!". |
Быть такого не может. Компилятор какой? Локаль?
| QUOTE (GregZ @ 02.06.2006 - время: 01:00) | ||
Быть такого не может. Компилятор какой? Локаль? |
Borland Developer Studio 2006, винда ХР с СП2.
| QUOTE (Roman @ 02.06.2006 - время: 01:06) | ||||
Borland Developer Studio 2006, винда ХР с СП2. |
А локаль какая у компилятора? Вывод осуществляете в консоль?
| QUOTE |
| Вывод осуществляете в консоль? |
Да.
Замени wcout на cout и убери юникод. Что получится?
| QUOTE (GregZ @ 02.06.2006 - время: 01:22) |
| Еще раз спрашиваю, какая локаль у компилятора? Как компилятор должен интерпретировать последовательность байтов L"Привет всем!", чтобы перевести их в юникод? Замени wcout на cout и убери юникод. Что получится? |
Какая локаль не знаю.
Получается 4060cb
| QUOTE (Roman @ 02.06.2006 - время: 01:45) |
| Получается 4060cb |
Юникод не убрал. Убери префик L у текста.
Локаль определяется виндой в региональных стандартах. Язык программ, не поддерживающих юникод должен быть русским.
| QUOTE (GregZ @ 02.06.2006 - время: 01:58) | ||
Юникод не убрал. Убери префик L у текста. Локаль определяется виндой в региональных стандартах. Язык программ, не поддерживающих юникод должен быть русским. |
Локаль русская стоит.
L убрал - всё тоже самое. ("¦ЁштхЄ тёхь!")
| QUOTE (Roman @ 02.06.2006 - время: 02:15) | ||||
Локаль русская стоит. L убрал - всё тоже самое. ("¦ЁштхЄ тёхь!") |
Не знаю, что сказать. Компилятора Borland Developer Studio 2006 под рукой нет, проверить не могу.
#include <iostream>
int main()
{
std::wcout.imbue(std::locale(".866"));
std::wcout << L"Привет всем!" << std::endl;
}
При попытке компиляции с выводом в консоль(Builder 5), винда выдала сообщение о недостатке виртуальной памяти.
Приведеный мною код абсолютно корректен и соответствует стандарту.
| QUOTE |
| При попытке компиляции с выводом в консоль(Builder 5), винда выдала сообщение о недостатке виртуальной памяти. |
Ну такого я никак не ожидал.
Но меня больше беспокоит то, что при попытке установить Интербейс я увидел синий экран (при каждой попытке). Прямо в начале установки... Называется скачал новый Интербейс...
Что касается оберток, одни убеждали использовать std::auto_ptr, уповая на ее наличие в стандартной библиотеке, быстроту работы и ключевую особенность копирования использующую "move semantics" называемую также "передачей владения". Другие предлагали использовать boost::shared_ptr или std::tr1::shared_ptr. Их аргументами являлись универсализм, возможность безболезненного "разделения" указателя несколькими сущностями одновременно, и поддержку собственной функции освобождения ресурса.
У обеих оберток есть свои неисправимые преимущества и несомненные недостатки :)
Что по этому вопросу скажет народ?
| QUOTE (GregZ @ 06.06.2006 - время: 23:12) |
| Что по этому вопросу скажет народ? |
Народ, как всегда, безмолствует...
Будто сам с собой на форуме разговариваю. Так и тронуться недолго.
Были отличные бойцы: JeyLo, tetro, AngeLR. Только пропали...
| QUOTE (GregZ @ 08.06.2006 - время: 22:06) |
| Народ, как всегда, безмолствует... |
Народ еле думает. Жара... :) И самолеты крыльями машут...
Мы STL не знаем, у нас свойная кросспроджект шаред либрари есть. В ней есть что-то типа auto_ptr.
На чистые указатели с операциями выделения или освобождения памяти запрет.