pantoriy

Можно поставить юникод utf8 system("chcp 65001>nul"); Но тогда все строки придётся предварять префиксом u8. Иначе поставьте 1251. Но это тоже вопрос если вы откуда-то тащите строки и они у вас мультибайтовые а потом перегоняются в консоль то вам придётся устанавливать кодировку utf8...

Ну тут надо шифровка типа хэш, а не синхронное. А то можно взломать! Это не пойдёт сразу... нужна функция получения хэша по алгоритму скажем MD5. Хотя желательно найти получше. Есть такие... ну а дальше всё просто пароль сразу же после ввода переводите в хэш и в этом виде и храните. Для проверки сравниваете хэши... Никто нигде никакие пароль не хранит, только хэши. Которые придуманы так чтобы нельзя было по ним восстановить пароль... Это самый безопасный способ. Если конечно не взломать сам алгоритм хэширования. MD5 взламывается. Уже были прецеденты. так что если вам нужна высокая защита, то надо брать другой более надёжный алгоритм.

Нет, ну определять макрос gettext_noop ни к чему. Собственно и макрос N_ тоже! Просто не вызывайте от него макрос _. И тогда утилита генерации файла локализации xgettext просто не включить вашу строку в выходной po файл. Кстати с базой это не сработает. Точнее не сработает xgettext. Ну потому что он должен знать какую строку надо выдёргивать на момент её запуска. А её там нет, она появится только в момент обращения к БД. Так работает только статическая локализация. Но можно обмануть если вы знаете какие строки там появляются мы можете вручную добавить их в ваш po файл... Это конечно не обезопасит вас от сбоев, если к примеру появятся новые. Можно будет каждый раз дописывать этот файл и перекомпилить а потом подкладывать. Но это неблагодарное занятие. Гораздо лучше написать перевод в самой базе добавив туда поле с соответсвующим языком и таскать срзу строк в нужном языке. Тогда при добавлении записи в бд вы можете потребовать так же добавить и её перевод. А не добавили ну их проблемы... Как хотят! Ну куда-то её надо добавлять, либо туда либо сюда и в любом случае вручную...

Ну это так называемый канонический режим считывания с терминала. Ведь вы тут с него пытаетесь считать. Можно конечно перенастроить терминал и включить режим посимвольного считывания, но это может привести к краху терминала, если не сделать это аккуратно... Вообще не рекомендуется менять режимы терминала ибо с терминалом работают все проги в сессии... Вы просто завалите сессию. Это катастрофа... Аккуратно это как операцией delete. Не забудьте восстановить канонический режим когда это уже не надо! А так при первом запуске getchar() происходит считывание до конца строки, вместе с концом строки. Или пока весь буфер не будет заполнен. Размер буфера устанавливается в системе и он мб 4 кб 8 или 16 или сколько вы там установите. Менять эту величину не стоит. Особенно в сторону уменьшения. Др проги об этом не знают. Обычно строка намного короче. Вот тут дан совет, попробовать read. Говорю сразу, не прокатит! Будет тоже самое. Вообще это не имеет отношения к тому каким образом вы будете считывать. Потому что режим работы терминала не изменится!!! Что делаю я? Я когда считал нужное кол-во символов просто сбрасываю остаток. И это самое разумное. Я не нашёл спецфункции для этого. Надо просто считывать пока не считаешь конец строки. Есть др функция, getline. Она сразу выдаёт всю строку. Но ей надо подсунуть адрес указателя на строку предварительно установленный в NULL. Она выделит память под нужное кол-во и заполнит его вместе с концом строки. Вы получите сразу 2 геморроя: 1 в конце память под строку надо освободить или вы автоматом получите утечку памяти. Второе возня с символом конца строки. Ну и сами понимаете это неэффективно... особенно если это в цикле, а так и бывает. Я выяснил, самое лучшее это записать типа scanf(" %[^\n]%*c", str). str обычная стековая строка с фиксированым размером. Для страховки можно указать макс длину считывания. Но потом сбр буфер можно той же командой scanf("%*[^\n]%*c") правда не уверен, что она не зациклится(не проверял...). Кстати в винде такой проблемы нет. И если написать на др языке тоже. На фортране к примеру.

Синус 30 гр = 0.5 далее через формулу тройного угла легко найти точный ответ. Никакие ряды не надо, известен точный результат в радикалах. А да, получится уравнение 3-ей степени, которое вам придётся решить. Но ничё, оно решается, по формулам Кардано. Какой сейчас сказать не могу, не помню формулу тройного угла... поищите в гугле... Кстати Тейлор плохой вариант. его базис неортогонален в функ пространстве. Поэтому ошибки начинают расти при увеличении числа членов. Синус собственно это вектор в бесконечномерном функциональном пространстве. Мы ищем его координаты. Для тейлора они известны и для Чебышева тоже. Уже всё давно подсчитано и не только ждя этих двух базисов. Но для синуса, периодической ограниченной фунции они не годятся. Но увеличение числа членов по разложению по Чебышеву уже стабильно повышает точность в отличие от Тейлора. Было бы веселее посчитать синус 6 градусов в радикалах... Хе-хе...