C++ sexnarod journal ;

В былые времена лабораторных работ часто требовался вывод на консоль русских букв, ибо транслит и ломаный английский очень смущал преподов. Приходилось изворачиваться либо вставляя к месту и не к месту CharToOem либо (находились и такие) заменяя строки в тексте программы строками с использованием кодовой страницы 866.

Но! Истина была как всегда рядом. Жаль я не додумался использовать 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" .

Извиняйте народ. Продолжения не будет.
https://sxn.io/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 сексо. Больше просто нет :). Ну и конечно репутацию!

Судя по всему придётся отвечать самому. :))
Неужели ни кто не знает ответа?

(GregZ @ 22.05.2006 - время: 21:50) Судя по всему придётся отвечать самому. :))
Неужели ни кто не знает ответа?
А народу тяжело... :) Стандарт открывать или компилятор запускать - нечестно, а так не помнят... Это я про себя. :)

(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)

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? :)

(GregZ @ 26.05.2006 - время: 21:02) 1. Перечислить производителей компиляторов (только С++). Не менее 3. :)
2. Перечислить ключевые слова языка программирования С++. Не менее 5. :)
3. На бумаге какого цвета напечатан стандарт 2003 адаптированный INCITS? :)

А че такие сложные вопросы? :) Папроще!

Только чур не гуглить! :)

По поводу производителей компиляторов, кого мы считаем: у кого полностью свой, чей C++ frontend или чей backend?

(tetro @ 26.05.2006 - время: 22:57) По поводу производителей компиляторов, кого мы считаем: у кого полностью свой, чей C++ frontend или чей backend?
Без разницы. Лишь бы современные. :)

(GregZ @ 26.05.2006 - время: 21:02)
3. На бумаге какого цвета напечатан стандарт 2003 адаптированный INCITS? :)



Я его распечатала на розовой...
Причем буквами magenta. Симпатишненько получилось

Практически все производители специфических процессоров сразу лезут вперед: и HP и Sun и SGI (светлая ему память) не говоря о IBM ...

Столкнулся с интересной особенность в языке С++.
При перегрузке функции 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

В стандарте п. 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;
}
Не работает...

(Roman @ 01.06.2006 - время: 00:41)Не работает...
Не компилируется, или работает некорректно? Если второе, что конкретно не так?

(GregZ @ 01.06.2006 - время: 12:37) (Roman @ 01.06.2006 - время: 00:41)Не работает...
Не компилируется, или работает некорректно? Если второе, что конкретно не так?
Не то выводит: "¦ЁштхЄ тёхь!".