Pull to refresh

Comments 208

Ну вот, теперь его перетащат в ReactOS и сделают программируемым и графическим.
Он работает на UWP. Я ожидал C#, получил нечитаемый (по сравнению с C#) С++.
Почитал, что за UWP. Значит, не перетащат.

Получается в MS не используют свой же C# даже для калькулятора.

C# по историческим причинам не популярен среди команды Windows

Так какого же лысого они им весь мир кормят?
«Они»? Вы про команду Windows или про команду Development Tools?
  1. Команда винды и команда development tools, представляете, разные команды.
  2. Команда Windows крайне консервативна и любит велосипеды. В частности, убедить из перейти на git удалось только в 2018 году, кажется.
  3. Команда development tools, наоборот, очень любит Шарп и всюду его пихает.
  4. Вообще C# популярен в MS, например в бинге
The purpose of this platform is to help develop universal apps that run on Windows 10, Windows 10 Mobile, Xbox One and HoloLens without the need to be re-written for each.

Замечательно. Братва, кто хочет поиграть в калькулятор на Xbox? :)

Ага, с мультиплеером на сто юзеров.

Дэсматч в калк по сети на хололинзах (ёпт)

Это как — проигравший делит на ноль (фаталити!)?
Но он же тогда станет стремиться к бесконечности, то есть станет бессмертным!
Видимо Шарпей настолько хорош, что Майкрософт не использует его даже для калькулятора :)))
Возразить есть что? Или правда глаза колет? :) Больше минусов, больше!!! Обожаю анти-кармодрочество.
Отговорок наверняка можно найти множество. Однако подавляющая часть софта Майкрософтом выполнена не на Сишарпе. Это очевидно и бесспорно. Даже гуй Скайпа и VSCode сделали на Электроне. И это явно не из-за консервативности.
А подавляющая часть софта сан/оракл не на джаве, а гугла — не на дарте/голанге, джетбрейнс — не на котлине, и т.д.
Все эти языки лажа?

Выбор языка для проекта вообще не показатель. Команда выбирает инструмент под свои задачи. И не важно, разработан инструмент в этой компании другим отделом, или в другой компании.
Тем более что проект создавался ещё до появления С#
Все эти языки лажа?
Видимо — да. Были бы языки действительно хороши, на них бы мейнстрим и писался. Все языки вроде как общего назначения.
Тем более что проект создавался ещё до появления С#
Проект создавался и до UWP, однако был переписан.
Да уж. То есть даже то, что проект старше языка на несколько лет, не является аргументом. Видимо, Майкрософт должен был сразу переписать свои продукты на c# как только он появился.
Тут бы даже я поставил минус если бы мог

Проект не был переписан на UWP. Потому что UWP не язык

Кстати, а почему c#, а не f#?
А если бы переписали на c#, это говорило бы о том, что f# «настолько хорош»?

А по поводу плюсов, которые были упомянуты — видимо они настолько универсальные и крутые, что чуть не каждый год новый стандарт выходит. Странно, что такой хороший язык продолжают дорабатывать.
Видимо, Майкрософт должен был сразу переписать свои продукты на c# как только он появился.
Шарпею, уже, слава Богу, сто лет в обед. Могли бы и переписать, хотя бы часть софта. Начиная хотя бы и с калькулятора как раз. Однако увы.
Проект не был переписан на UWP. Потому что UWP не язык
UWP не язык, но одна из технологий. Почему UWP используют, а .net нет? Причем почти нигде.
Кстати, а почему c#, а не f#?
Не имеет значения, пусть и F#.
А по поводу плюсов, которые были упомянуты — видимо они настолько универсальные и крутые, что чуть не каждый год новый стандарт выходит. Странно, что такой хороший язык продолжают дорабатывать.
Ладно старые, так и новые вещи пишут не на .net. Я уже писал, но повторюсь: гуй Скайпа, VSCode.
Тут бы даже я поставил минус если бы мог
Очередной кармадрочер? :)))
Как же хабровчане обожают душить альтернативные мнения :)
Шарпею, уже, слава Богу, сто лет в обед. Могли бы и переписать, хотя бы часть софта. Начиная хотя бы и с калькулятора как раз. Однако увы.

Переписать для чего? Ради того, чтобы переписать? Что за бред

UWP не язык, но одна из технологий. Почему UWP используют, а .net нет? Причем почти нигде.

Потому что .net это платформа. И на неё надо именно переписывать. Её нельзя внедрить частично.

И .net используется в массе продуктов. Не верю, что вы никогда не слышали про хотя бы unity

Не имеет значения, пусть и F#.

Угу, вам всё равно, я понял

Ладно старые, так и новые вещи пишут не на .net. Я уже писал, но повторюсь: гуй Скайпа, VSCode.

vscode это вообще-то atom. Я понимаю, что уровень аргументации примерно такой: они могли переписать атом на c#, но раз не сделали этого, значит c# отстой — но такая аргументация не имеет отношения к здравому смыслу.

Visual studio на шарпе написана. Как вам это?

Очередной кармадрочер? :)))
Как же хабровчане обожают душить альтернативные мнения :)

Дело не во мнении. А в неспособности к адекватной оценке. Заявлять, что с# плох потому что майрософт не переписала на нём свои продукты это именно неспособность к адекватной оценке.
Переписать для чего? Ради того, чтобы переписать? Что за бред
Ради продвижения своей «мега-технологии» хотя бы.
Потому что .net это платформа. И на неё надо именно переписывать. Её нельзя внедрить частично.
Ок, отлично. Что можно сделать лучше того, для продвижения своей технологии в мире, чем писать свой же софт на ней? Однако же нет.
Угу, вам всё равно, я понял
Мне — да. Удобно писать на F# — пусть так. Главное — результат.
vscode это вообще-то atom. Я понимаю, что уровень аргументации примерно такой: они могли переписать атом на c#, но раз не сделали этого, значит c# отстой — но такая аргументация не имеет отношения к здравому смыслу.
Atom+Electron, интерфейс — JS+CSS, Сишарпа, увы, нет. Аргументация простая: если Шарп действительно настолько хорош, насколько о нем рассказывают, то логично же его максимально использовать во всех своих продуктах. Однако этого и близко нет.
Visual studio на шарпе написана. Как вам это?
Частично да, но не полностью.
Заявлять, что с# плох потому что майрософт не переписала на нём свои продукты это именно неспособность к адекватной оценке.
Моё мнение такое, что если бы язык/платформа были действительно отличными и революционными, то большая часть продуктов была бы переписана. А уж новые и подавно.
Ради продвижения своей «мега-технологии» хотя бы.

Она и так отлично продвигается

Ок, отлично. Что можно сделать лучше того, для продвижения своей технологии в мире, чем писать свой же софт на ней? Однако же нет.

Так пишут же

Atom+Electron, интерфейс — JS+CSS, Сишарпа, увы, нет. Аргументация простая: если Шарп действительно настолько хорош, насколько о нем рассказывают, то логично же его максимально использовать во всех своих продуктах. Однако этого и близко нет.

Не atom + electron, а просто atom. Который уже сделан на электроне. Как вы видите использование c# в электроне?
Было бы верхом идиотизма брать продукт, переписывать его на новом языке и обеспечивать поддержку всех расширений и плагинов. Вы именно такой идиотизм предлагаете судя по всему.

Это исключительно ваша логика. Ms не один язык создала. И если бы они руководствовались вашей извращённой логикой, то они должны были бы сначала всё переписать на vb, потом на visual j++, потом на c#, потом на f#, потом на typescript…
Наверняка я что-то упустил.

Частично да, но не полностью.

Частично недостаточно? Какой процент должен быть, 80? 90? 146?

Моё мнение такое, что если бы язык/платформа были действительно отличными и революционными, то большая часть продуктов была бы переписана. А уж новые и подавно.

Ваше мнение вызвано тем, что вы не понимаете пары вещей:
1 — бизнес не переписывает продукт просто для того, чтобы переписать на новую технологию
2 — нет универсальных языков программирования

C# отличный язык. Один из самых удобных, на которых мне доводилось писать. Какие именно его концепции вы считаете плохими?
Она и так отлично продвигается
Она настолько «отлично» продвигается, что Шарпей просел в 3 раза по популярности:
www.tiobe.com/tiobe-index/cplusplus
Это исключительно ваша логика. Ms не один язык создала. И если бы они руководствовались вашей извращённой логикой, то они должны были бы сначала всё переписать на vb, потом на visual j++, потом на c#, потом на f#, потом на typescript…
Я всегда за платформу говорил, Шарп — как наиболее яркий представитель. Язык значения не имеет, как уже писал. .net в продуктах Майкрософта используется минимально. Большая часть кода — плюсы.
C# отличный язык. Один из самых удобных, на которых мне доводилось писать. Какие именно его концепции вы считаете плохими?
Мне сложно говорить, какие именно особенности .net Майкрософт считает плохими, раз его почти не использует. Возможно это скорость, возможно фактическое отсутствие кросс-платформенности до .net core. Возможно еще что-то.
бизнес не переписывает продукт просто для того, чтобы переписать на новую технологию
Всякое бывает, по собственному опыту. У меня софтверный бизнес уже почти 20 лет работает, довольно успешно.
нет универсальных языков программирования
C/C++ вполне универсальны.
Она настолько «хорошо» продвигается, что Шарпей просел в 3 раза по популярности:
www.tiobe.com/tiobe-index/cplusplus
Там график C++, а не C#, или что вы имели ввиду?
UFO just landed and posted this here
Вот комбинированный график с того сайта. Но рейтинг обычно не показатель при выборе реализации большинства проектов.
Прошу прощения, не та ссылка, конечно же. Ниже привели, впрочем.
Xamarin, если что, не их продукт. Купили.
Даже то, что калькулятор написан не на шарпе…
Не в калькуляторе дело. А в общем подходе. .net используется самими майками почти нигде. При том технология продвигается, как замена всего сущего
Майками может и «почти нигде». А вот некоторый софт вовсю требует — «Поставь хотя бы .Net Framework 4.0, если умудрился меня поставить на чистую Win 7».

Раз уж вы говорите о платформе, а не о языке, странно производить ссылку на тиобе.
Да и вообще странно приводить ссылку на тиобе как аргумент того, что язык "плохой".
Кстати, как там себя плюсы и си в нём ведут?
Или вам уже указали, что за график с# вы выдали график плюсов.


Xamarin, unity, visual studio — этих продуктов вам мало? Мне честно лень искать что-то ещё


Ну а по поводу универсальности си и плюсов — vscode не на них написан. Отсюда вывод: плохой язык :)

Почему UWP используют, а .net нет? Причем почти нигде.
Если претензия к этому калькулятору, то это .net приложение, о чём говорит точка входа не int main() / WinMain(), а класс App (ресурс app.xaml).
UFO just landed and posted this here
А как вы настраиваете кодировку? У меня вместо русских — крякозябли.
UFO just landed and posted this here
Я только под Win7x64 запускал.
Заголовок спойлера

Вы не понимаете, самый крутой был в Windows XP. А потом ввели глупое ограничение, не дающее считать результат величиной 1010000 и более. А я так хотел посчитать на своем процессоре 250000!..
Нет, калькулятор из XP лучше — в семёрке просто бесит, что для того, чтобы перевести число в шестнадцатиричный вид, или из него в десятичный, нужно переключаться из инженерного режима в режим «Программист», при этом текущий результат стирается, и теряется возможность вычислений с дробной частью!
Звучит как идея для Pull Request или хотя бы Issue.
Ну, кстати да. Для меня лично единственный объективный минус это отсутствие графического переключателя режимов (инженерный, программист, etc). Если бы кто-нибудь выкатил точно такой же как системный, но всего лишь с дополнительной полоской радио-селекта режима, вынесенной из меню — скачал бы не раздумывая.
Самый лучший калькулятор был в девяностовосьмерке. У него экранные кнопки «нажимаются», когда вводишь с клавиатуры, т.е. слепой ввод облегчается. Хорошо, что и в десятке (20 лет спустя!) его можно использовать.

Только что проверил в 10 калькуляторе экранные кнопки тоже нажимаются при вводе с клавиатуры
Слева нажатая кнопка, справа ненажатая.



Если в Windows 10 экранная кнопка визуально меняется при вводе с клавиатуры, то это хорошо. И удивительно. Потому что в XP, Vista, 7, 8 — ничего подобного не было, а было последний раз в 98.

Сам проверить не могу, у меня Windows 10 LTSB и метро нет, а стандартный калькулятор от семерки.
Хорошо, что и в десятке (20 лет спустя!) его можно использовать.
Это, кстати, мой личный предмет дикой зависти как юниксоида: WinAPI, при всех его недостатках, предоставляет достаточно богатый baseline (стандартную графику, работу со звуком и пр.) для создания в т.ч. весьма сложных программ, работающих хоть на WinNT 4.0, хоть на «десятке» (без перекомпиляции). Фрюниксы таким похвастаться, к сожалению, не могут. :-(
Тролли загадили ишью лист топиками вроде «деление на ноль не работает».
Маленький шаг для сообщества и гигантский для Микрософт.
Что же тут удивительного? Это ведь не высокоуровневый язык вроде JS или Python, где многое выполняется за тебя автоматически.

Хотя, в эту цифру они наверно еще xml и С# код посчитали
А с каких пор C++ стал низкоуровневым? И что такого за меня автоматически выполняется в JS, что в плюсах придется писать руками?
Я имел ввиду более высокоуровневые, поскольку C++ обычно все считают более близким к железу.

А на счет того, что JS делает автоматически — управление памятью, к примеру. Да в C++ есть поинтеры, позволяющие уменьшить количество мусора, но попробуйте написать 35000 строк идеально структурированого кода без автоматического сборщика мусора. В сравнении с той же программой на JS, тут неизбежно увеличится количество кода.
Честно говоря, мне трудно представить архитектуру приложение, подобного калькулятору, в котором автоматическое управление памятью сколько-нибудь серьезно уменьшило бы объем кода.
попробуйте написать 35000 строк идеально структурированого кода без автоматического сборщика мусора
Если не считать за автоматическое управление памятью упомянутые Вами «умные» указатели, то занимаюсь этим на постоянной основе. Было бы нескромно называть свой код «идеально структурированным», но что уж точно не сильно влияет на его приближение к идеалу, так это отсутствие встроенного в язык сборщика мусора. Помимо C++, приходилось писать и на Java, и на JavaScript, и ни один из этих языков за счет наличия GC автоматически не приближал мой код к идеалу. Более того, в Java сильно не хватало так привычного по плюсам RAII, ведь ресурсы, которыми приходится управлять, не сводятся только к памяти.
Ручное управление памятью (разрушение) в более-менее структурированном коде занимает примерно 0.1% строк программы. То есть в калькуляторе примерно 35-50 строк. Можно проверить.
но попробуйте написать 35000 строк идеально структурированого кода без автоматического сборщика мусора.
У меня, например, проекты по миллиону строк достаточно стуктурированного кода без автоматического сборщика. Так даже удобнее.
С другой стороны, 35 тысяч строк — это в самом деле замного для калькулятора.
Что же тут удивительного?

Удивительно то, что если написать на C++ приложение калькулятора с аналогичным функционалом на чистом WinAPI, со всеми плюшками по валидации данных, поддержке разных языков и т.д., там все равно должно получиться этак на порядок меньше строк.

Вы про код телеметрии забыли!

Нет. Но вы зря сомневаетесь в моей способности (и вообще в способности любого среднестатистического программиста) написать калькулятор, подобный виндовому, уложившись в 3500 строк на С++ :)

Забыли добавить: за выходные вечерами.

А чо там писать?
Алгоритм сортировочной станции, работающий по обратной польской записи.
Этого хватит для любого матиматического действия

UFO just landed and posted this here
Отправка телеметрии, и именно на сервера Microsoft, входит в условия задачи?
ну что-ж начнём: я уго… кхм реализую этот функционал за 5 но… кхм тысяч строк
Хотел съязвить, что половина из них — это комментарии с перечислением копирайтов, авторов и т.д. в заголовке каждого файла. Но был не прав — оказалось, что заголовок один из самых коротких, что видел на GitHub:
// Copyright (c) Microsoft Corporation. All rights reserved.
// Licensed under the MIT License.

Обычно комментарии в таких случаях не считаются. Все современные инструменты анализа объема кода пропускают всё, что находится под комментарием, т.к. оно никак не влияет на сложность программы.

Согласен, но при желании насчитать побольше можно и wc -l использовать.
Интересно, если бы он был написан на C#, было бы меньше строк?
Вам тоже понравилась вот эта функция? :)
TraceLogger::LogInvalidInputPasted
    void TraceLogger::LogInvalidInputPasted(wstring_view reason, wstring_view pastedExpression, ViewMode mode, int programmerNumberBase, int bitLengthType)
    {
        if (!GetTraceLoggingProviderEnabled()) return;

        LoggingFields fields{};
        fields.AddString(L"Mode", NavCategory::GetFriendlyName(mode)->Data());
        fields.AddString(L"Reason", reason);
        fields.AddString(L"PastedExpression", pastedExpression);
        fields.AddString(L"ProgrammerNumberBase", GetProgrammerType(programmerNumberBase).c_str());
        fields.AddString(L"BitLengthType", GetProgrammerType(bitLengthType).c_str());
        LogTelemetryEvent(EVENT_NAME_INVALID_INPUT_PASTED, fields);
    }

fields.AddString(L"PastedExpression", pastedExpression);

Т.е. если ты случаяно вставишь предыдущий скопированный текст в калькулятор (думая, что ты вставляешь скопированное число), то программа автоматически отправит этот текст в Майкрософт, здорово…
Я глубоко не копал, могу ошибаться, но похоже так и есть.
Скорее всего так и есть, ведь скопированный текст, картинки, и тп. не буду считаться валидным вставленным числом (что как раз и регистрирует ::LogInvalidInputPasted), что автоматически выдаст ошибку, и вызовет данного логгера, который отправит телеметрию с этими 5 значениями (одно из которых «pastedExpression» — вставленное значение)

Я все-таки надеюсь, что отправляют на сервер не всегда, а при определенных условиях, например при креше приложения.

А если посмотреть на LogTelemetryEvent
void TraceLogger::LogTelemetryEvent(wstring_view eventName, LoggingFields fields) const
    {
        g_calculatorProvider.LogEvent(eventName, fields, LoggingLevel::Verbose, LoggingOptions(MICROSOFT_KEYWORD_TELEMETRY));
    }

то можно удивить, что это все-лишь Event Tracing, но ведь это скучнее, чем Microsoft следит за всеми. Я думаю, что если покопаться, то окажется, что по умолчанию он вообще отключен и его нужно специально включать для отладки.
А как по-вашему выглядит «настоящий» код отправки телеметрии? Могу предположить, она реализована именно как event tracing, где событию, относящемуся к телеметрии, ставится соответствующий флаг (MICROSOFT_KEYWORD_TELEMETRY). А системный сервис уже решает, что делать с таким событием на основе своих настроек.

// Telemetry events. Uploaded to asimov.
/* вырезано */

#ifdef SEND_TELEMETRY
    // c.f. WINEVENT_KEYWORD_RESERVED_63-56 0xFF00000000000000 // Bits 63-56 - channel keywords
    // c.f. WINEVENT_KEYWORD_*              0x00FF000000000000 // Bits 55-48 - system-reserved keywords
    constexpr int64_t MICROSOFT_KEYWORD_CRITICAL_DATA = 0x0000800000000000; // Bit 47
    constexpr int64_t MICROSOFT_KEYWORD_MEASURES = 0x0000400000000000; // Bit 46
    constexpr int64_t MICROSOFT_KEYWORD_TELEMETRY = 0x0000200000000000; // Bit 45
    constexpr int64_t MICROSOFT_KEYWORD_RESERVED_44 = 0x0000100000000000; // Bit 44 (reserved for future assignment)
#else
    // define all Keyword options as 0 when we do not want to upload app telemetry
    constexpr int64_t MICROSOFT_KEYWORD_CRITICAL_DATA = 0;
    constexpr int64_t MICROSOFT_KEYWORD_MEASURES = 0;
    constexpr int64_t MICROSOFT_KEYWORD_TELEMETRY = 0;
    constexpr int64_t MICROSOFT_KEYWORD_RESERVED_44 = 0;
#endif

Опция SEND_TELEMETRY включается для билдов для «production configuration to be released to the Store and the Windows image», т.е. как раз для релизов в официальном магазине и в дисках с windows.
// Telemetry events. Uploaded to asimov.
 ...
constexpr auto EVENT_NAME_INVALID_INPUT_PASTED = L"InvalidInputPasted";
Неплохо.
Объявляем переменную:
wchar_t m_resolvedName[LOCALE_NAME_MAX_LENGTH];

Затем сравниваем ее значение со строкой:
if (m_resolvedName == L"en-US")

Microsoft — запредельный профессионализм сотрудников и традиционно высокое качество!
Студентам на начальном курсе C/C++ за такое двойки ставят, а для них норм!
Ну вообще забавно, да, весьма корявая конструкция. Можно более подробно в каком файле вы это нашли? А то вообще не очень понятно, что именно тут хотели сделать. Насколько я понимаю, это такая корявая попытка понять разрядность текущей системы (подозреваю, что в x64 LOCALE_NAME_MAX_LENGTH будет больше чем L«en-US», хотя не уверен, поскольку не знаю правил типизации для компилятора, используемого в VS).

В общем, хотелось бы понять, что конкретно вам не нравится. Вы думаете это опечатка (я про L перед строкой) или вас в принципе смущает корявый способ преобразования типа сей строки и использование «магической константы» «en-US»?
Здесь вместо сравнения строк по значению сравниваются указатели (на объявленный массив и на строковую константу, которая тоже массив). Указатели эти, понятное дело, не совпадут никогда.
А, я чёт не обратил внимания на квадратные скобки… Тогда всё ещё более коряво, согласен.

и на строковую константу, которая тоже массив
А разве L, перед этой константой, никак не повлияет на способ передачи этого массива в оператор сравнения?

Впрочем, если ранее в коде не было перегрузки оператора "==" для массивов, тогда в любом случае будет выполнено сравнение с указателем…
UFO just landed and posted this here
перегружать оператор сравнения для типов вроде… массивов нельзя

Можно подробнее? Впервые об этом слышу.
UFO just landed and posted this here
А, я понял, вы имели ввиду, что нельзя перегружать операторы для встроенных типов вообще, без обёртки их в класс.

Но тут как раз вот это объявление:
wchar_t m_resolvedName[LOCALE_NAME_MAX_LENGTH]
Внутри класса, поэтому внутри этого же класса может быть перегружен оператор сравнения для это типа. По вашей же ссылке в Restrictions нет ничего про "==".
UFO just landed and posted this here
UFO just landed and posted this here
Ну я согласен, что в исходном варианте, который обсуждается практически гарантированно будет сравнение указателей, перегрузка оператора сравнения это достаточно редкий кейс, насколько я могу по своему опыту судить.

Мне хотелось в деталях разобраться просто.
UFO just landed and posted this here
Если хотя бы один аргумент — объект класса
Но это не наш случай (wchar_t m_resolvedName[100] — не объект класса).
Невыполнимое условие. А внутри него можно написать много всякого разного. Индусский код же.
Собственно, код взят отсюда.
В массив m_resolvedName кладется (видимо) название локали, после чего в функции GetEnglishValueFromLocalizedDigits проводится вышеуказанная проверка — если мы уже в американской локали, тогда конструируем строку как есть, иначе начинаем ковырять переданную строку.
Проблема, однако, в том, что само имя m_resolvedName — это не строка, а указатель. Сравнение указателя со строковым литералом, как мне подсказывает статический анализатор — unspecified behavior. Здесь правильно воспользоваться семейством функций *str(n)cmp.

В массив m_resolvedName кладется (видимо) название локали
Я так понимаю, тут ещё веселее. Туда вообще ничего не кладётся, это тупо объявление массива длиной LOCALE_NAME_MAX_LENGTH.
Ну, в смысле где-то между объявлением переменной и вызовом функции с этой проверкой туда кладется имя локали.
А зачем вообще имя локали кладётся в массив? Не логичнее было бы для этой цели строку использовать, и сравнивать потом уже эту строку со строкой, чтобы такой огород не городить?
Не логичнее было бы для этой цели строку использовать, и сравнивать потом уже эту строку со строкой, чтобы такой огород не городить?

Да, конечно, логичнее. Почему автор так не сделал и ни один из его инструментов разработки ему не подсказал — загадка.
Вообще, понятно, что имя локали лучше положить в переменную отдельного типа LocaleName, ведь мы не любую строку туда можем запихать — как минимум есть ограничения по длине, уверен много других. Но автор поленился — и вот.

Ну так код компилировали с /w3. Кто-то уже попробовал с w/4 и компилятор выдал предупреждение на эти строки.

А зачем вообще имя локали кладётся в массив? Не логичнее было бы для этой цели строку использовать
Массив из wchar_t — это и есть строка.
Это строка в C. Конечно, можно и в C++ использовать строки в стиле C, но зачем?
Видимо потому что функции по получению имени локали из API используют C-style строки. А потом их пытаются сравнить как std::string, что естественно не срабатывает.
Windows API, как и многие другие API, весь написан в C-style. Но это не мешает программистам, работающим на C++, преобразовывать полученные от него данные в более высокоуровневые типы и далее, оперируя уже только ими, избегать подобных «детских» ошибок.
Да? И что, методы типа empty() или clear() для такого массива тоже работают?
Вангую, что скоро мы увидим статью от Andrey2008 на тему проверки калькулятора при помощи PVS-Studio.
Вангую, что не скоро (либо совсем не увидим), т.к. калькулятор написан на MC++ (managed C++/CLI), который синтаксически не совместим с C++, т.е. анализатор упадёт уже на создании AST.
PVS-Studio. Поддерживаемые языки и компиляторы:
  • Windows. Visual Studio 2010-2017 C, C++, C++/CLI, C++/CX (WinRT), C#
и т.д.
  • Windows. IAR Embedded Workbench, C/C++ Compiler for ARM C, C++
  • Windows/Linux. Keil µVision, DS-MDK, ARM Compiler 5/6 C, C++
  • Windows/Linux. Texas Instruments Code Composer Studio, ARM Code Generation Tools C, C++
  • Windows/Linux/macOS. GNU Arm Embedded Toolchain, Arm Embedded GCC compiler, C, C++
  • Windows/Linux/macOS. Clang C, C++
  • Linux/macOS. GCC C, C++
  • Windows. MinGW C, C++
  • Windows/Linux/macOS. Java

Коллега уже в процессе написания заметки.
UFO just landed and posted this here
В данном случае не member, так что ваша цитата ни при чём.

Слово "индиоты" не из ниоткуда появилось...

Ну значит я зря удивлялся почему в стандартном калькуляторе 2 + 2 * 2 = 8. Теперь все ясно.

Калькулятор в простом режиме вычисляет последовательно. Поэтому и так

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

На научных калькуляторах порядок действий соблюдается, а иногда еще и скобки есть. На бухгалтерских — вряд ли соблюдается.

Вот я не поленился и взял в руки Citizen LC-110N. Это самый простой из тех, что имеются у меня. Ничего нового не узнал. Калькулятор не соблюдает приоритет операций, но при этом ведет себя честно, в отличие от сабжа. Так, если ввести 2 + 2, а затем нажать на *, то он сразу посчитает промежуточный результат и отобразит 4. Т.о. четко видно, что следующее действие будет выполнятся над 4. И результат будет закономерным — 8. «Стандартный» же калькулятор просто наглым образом врет, позволяя полностью записать выражение 2+2*2 и при этом получить неверный с математической точки зрения результат.
Стандартный» же калькулятор просто наглым образом врет
Стандартный калькулятор точно так же
сразу посчитает промежуточный результат и отобразит 4. Т.о. четко видно, что следующее действие будет выполнятся над 4
UFO just landed and posted this here
Ой, извините за оффтоп, а как он у вас на русском языке?
У меня русская 10-ка (уже 1809), но все «стандартные» проги винды на английском.
У Вас язык интерфейса русский. Стор (и прочая Метро братия) Тянет язык интерфейса приложений. В настройках языковых параметров переключите все на русский. В принципе, «метод ввода по умолчанию» можно оставить на английском, если программируете. Хотя лучше поставить галку запоминать для каждого приложения.
Вообще-то там —
std::wstring m_resolvedName;
(строка 382 файла LocalizationSettings.h)

Где именно вы нашли то, о чем рассказываете?
Revision: c85d7ec4549ff06a7b7dc08201c671336725fba8
Author: Michał Janiszewski <janisozaur@users.noreply.github.com>
Date: 09.03.2019 1:45:39
Message:
Compare locale strings, not their pointers (#183)

Change the stored locale type to wstring to make the comparison operator work.
----
Modified: src/CalcViewModel/Common/LocalizationSettings.h

-            wchar_t m_resolvedName[LOCALE_NAME_MAX_LENGTH];
+            std::wstring m_resolvedName;

Они читают Хабр!

В комментарии призывается Andrey2008 — как раз для его PVS-студии развлечение, ну и мы посмеёмся.
> Компания открыла код для того, чтобы любой желающий мог ознакомиться с такими технологиями Microsoft как Fluent, Universal Windows Platform, Azure Pipelines и другими.

Без этого уже калькулятор никак не написать?

"При изготовлении часов использованы самые современные технологии: сварка взрывом, клёпка газом, сборка трезвым." ©

Ага, «Позолоченный корпус куркучасов оцинкован вольфрамом» )))
М.б. понесло? Было как-то. Писал одну прогу для себя. Работы там было на 2-3 дня зевая. Но это же скучно. И понесло меня в абстракции: всякие менеджеры, какие-то зачатки недоСОА, хитрая сигнальная библиотека на C++ шаблонах (её м.б. как-нибудь даже на хабр вытащу, если допилю). В общем, пилил я это всё месяца два, да так и не допилил.

Расскажите, как бы вы написали калькулятор без Azure Pipelines например. Вручную бы собирали и в релиз добавляли?

*минутка рекламы калькуляторов*

Открытый кросс-платформенный speedcrunch умеет всё то же самое и даже больше, как-то обходясь без сбора телеметрии.
Ну если пошла такая пьянка — писать выражения вручную, то тогда уже надо ставить Jupyter, который поддерживает разные ядра (языки) с разными прилагающимися библиотеками. Фактически это учебный стандарт.
Ну это уже другого класса инструмент, так можно и до Maxima/Mathcad докатиться :)

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


А просто набрать в строке поиска Google? Например 2+2*2? Кстати — ответ 6.
Вы забыли про самый лучший из всех калькуляторов — qalculate (основанный на qalc), Открытый, кроссплатформенный,…
О да, он чертовски хорош.
Хоть старый добрый Numlock Calculator 3.2 и всплывает быстрее, но тут такая мощь…
У меня qalc прикручен к запускалке albert, и поэтому открывается мгновенно. Позволяет делать всё, что может понадобиться вычислительно-считательного и даже немного больше.
UFO just landed and posted this here
Так он небось всю GTK с собой в гости ведет?
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Открытый кросс-платформенный SpeedCrunch
Действительно, весьма фичастый и приятный калькулятор; странно, что вас заминусовали. Обновил FreeBSD'шный порт до мастера бхагавад-гиты.
Мне как почти полному нубу в программировании всегда было интересно- почему нажатие кнопок в этом гадском калькуляторе не всегда срабатывало? Причем это не зависило от мощности ресурсов.
При каких вводных данных это было и на какой ОС?
Чтобы программист мог найти ошибку, он должен ее сначала воспроизвести. Копаться в 35к строках чужого кода сложно, намного проще запустить в отладчике.

Зря кто-то чуваку минус поставил, есть непонятные траблы с этим калькулятором. Например, Win 10 1809, после смены раскладки клавиатуры калькулятор перестаёт реагировать на нажатие Backspace. Но на нескольких других компах это не воспроизводится.
Впрочем, мельком взглянув на исходники, у меня уже пропало всякое желание в этом разбираться.

Версии виндовс от 97 до 10
проявляется в несрабатывании кнопок калькулятора при клике на них мышкой. Клик быстрый. Визуально видно что кнопка нажимается, но на экране нет отклика (не появляется цифра)
Возможно mouseup происходит уже за пределами кнопки? Тогда она не активируется, да, нажатие в винде срабатывает именно на up, а не на down. Можно зажать мышью кнопку, держать, увести курсор с кнопки, отпустить, и ничего не произойдёт.
UFO just landed and posted this here

Зачем писать калькулятор когда можно использовать Python или R? Там есть куда больше возможностей для вычисления чего угодно, даже тех формул которые ещё не существует.

Потому что эта куча возможностей большинству не нужна, а нужен аналог самого обычно калькулятора, к ктоторому люди привыкли в обычной жизни. Люди хотят видеть и нажимать ровно теже кнопки которые они нажимают на обычном калькуляторе и никого не волнуют функции которых не существует, нужны те, которые уже существуют сотни лет и чтобы пользоваться было так же, как и в докомпьютерную эпоху.
Ну и потом, калькулятор, который был до Win10, просто удобный. Как вы на питоне переведете число из десятичной системы в шестнадцатиричную, а потом мышкой битики пощелкаете, чтобы увидеть как оно меняется? Один клик мышкой по биту позволяет изменить его состояние и увидеть как изменилось само число. Никакой python или R такой фичей не похвастается.

Если сотни лет, то умножать придется в столбик.

Windows калькулятор тоже графики строить умеет одной командой? А посчитать сумму серии?
Desmos прямо никто не использует вместо калькулятора? Wolfram Alpha? Symbolab?
Покликать мышкой по битикам не оправдание, этим мало кто вообще пользуется (только для понимания принципа бинарных чисел?)


Я просто пытаюсь объяснить что именно Windows калькулятор не умеет почти ничего, что возможно в вышеперечисленных продуктах.
Почему на хабре так Python не любят? Он мягкий и пушистый особенно для единоразовых вычислений. Также имеет историю и возможность сохранить формулы вычисления на потом, и сохранить все это в виде программы.

Я просто пытаюсь объяснить что именно Windows калькулятор не умеет почти ничего, что возможно в вышеперечисленных продуктах.

Так с этим никто не спорит. Ещё калькулятор Windows вам не защитит сеть от кибератак, не загрузит свежие фоточки в облако и не проведет анализ семантического ядра сайта.
Но зато он похож на обычный калькулятор. Вы можете набрать на клавиатуре, или даже мышкой, выражение и увидеть результат, ничего вообще не зная про командные строки, как скачивать и устанавливать Питона и т.д.
Это ведь важнее, чем возможность сохранять формулы вычисления на потом и т.д. (я без сарказма). Сложных навороченных агрегатов с побочной функцией «могу посчитать выражение» немало, и Питон не первый, и не последний из них. Калькулятор крут тем, что он простой и понятный всем (ну, по крайней мере, простой в тех инкарнациях, которые без телеметрии и 35000 строк счастья).
А я так надеялся, что это будет калькулятор из семерки. Его код, мне почему-то думается, что был бы несколько более элегантным.

В старой утечке исходников Windows 2000 тоже был ещё старый калькулятор. Любопытно, что эти исходники лежат на гитхабе. Интересно, в курсе ли Микрософт?..

Там sloccount насчитывает всего 3065 строк. Это явно недостаточно для таких заявлений, как:
Компания открыла код для того, чтобы любой желающий мог ознакомиться с такими технологиями Microsoft как Fluent, Universal Windows Platform, Azure Pipelines и другими. Благодаря этому проекту разработчики могут больше узнать о том, как выполняется работа по созданию тех либо иных проектов в Microsoft.

Ну так это почти двадцать лет назад было. С тех пор технологии калькулирования-то сильно шагнули вперёд!

По моему гениально, выкладываем код стандартных приложений. Сообщество их приводит в порядок, обновленные приложения набиваем телеметрией и выкладываем с новым апдейтом венды, не забывая взять денег за лицензию.
Вы описали традиционную бизнес-модель Red Hat :-)
Я так и не понял в связи с чем такой ажиотаж. Когда в «детстве» я писал на дельфях, такую поделку сделал бы за часок и никто бы этому не удивился. Там кто-то увидел какие-то гениальные откровения в коде?
Так это в детсве и на делфях. А сейчас для этого нужно 35 тысяч строк, отдел программистов и тестировщиков :)))

Ещё один. Давайте за два часа. Напишете?

Для этого мне надо найти машину с Виндусом, найти где-то дистриб Дельфей, установить и всё для того, чтобы доказать вам, что я умею класть кнопочки на форму и писать простые обработчики? Мммм, пожалуй, мне это не интересно.
Нет никаких проблем накидать калькулятор на Delphi.

Ждем статью. За два часа аналог калькулятора винды :-)

Немного намекаю на то, что может вы поторопились с оценкой в 1 час? Это нормально для разработчиков, мы всегда так делаем. Сейчас время подумать и оценку изменить :-)


А то бросаться выводами, не подумав, недостойно инженера. Вот сейчас например вы сделали вывод, что я не знаком с Delphi. Зачем? :-)

даже если я и поторопился и это будет не 1 час, а 1 вечер, это всё равно не материально и не сравнимо с 35000 строк и человеко-годами, затраченными MS. И никто так и не ответил мне на мой изначальный вопрос — в связи с чем такой ажиотаж и в чём ценность этого кода, щедро предоставленного МS?
А вам я просто ответил, что если вам интересно как на Дельфи сделать калькулятор, то всё уже давно сделано 1000 раз, не надо ждать 1001 статьи на ту же тему. Вашего уровня знакомства с Дельфи я неимею чести знать.

Сделать на Дельфи калькулятор так же, как и везде: взять и написать :-)
Вопрос-то не в этом. Вопрос в том, что вы даёте совершенно нереалистичные оценки с умным видом. Зачем?
Вот сейчас вы написали про человеко-годы. На основании чего?
Вы понимаете разницу между написанием прототипа и законченным программным продуктом?

Сделать на Дельфи калькулятор так же, как и везде: взять и написать :-)


а как же кровавый энтерпрайз, аджайл, совещания? чем занять толпу менеджеров? :):):):):)
Меня удивляет, что статьи о действительно важных, сложных разработкаx, как habr.com/ru/company/inobitec/blog/441204, например, собирают в 5 раз меньше комментаторов, чем калькулятор от Винды. Именно этим вызвано моё недоумение интересом к этой новости и тому, что она вообще тут появилась. Вы считаете это великой разработкой, которая стоит тех человеко-часов, которые люди тут потратили на её обсуждение? Ок, а я нет :-) Вам охота пободаться со мной на предмет правильно ли я рассчитал трудозатраты на эту поделку «продукт»? :-) И с «умным видом» доказать мне, что я не знаю разницы между прототипом и и бла-бла-бла? Мне это скучно, я лучше почитаю о чём-нибудь интересном :-)
Скорее всего в два часа уложусь. Если на Лазарусе, то будет еще и кросс-платформенный. В отличие от :)

Ждем статью. За два часа аналог калькулятора винды :-) Кроссплатформенный.

UFO just landed and posted this here
сделают все что угодно для отвода глаз, лишь бы не выкладывать пинболл.
Думаю причина в этом: habr.com/ru/post/163105
этот код был написан несколькими годами ранее сторонней компанией, и никто в Microsoft никогда не понимал, как он работает (ещё меньше до сих пор это понимают), и бóльшая часть кода была полностью без комментариев. Поэтому мы просто не могли понять, почему детектор столкновений не работает. Чёрт, мы даже не могли найти детектор столкновений!

Кстати я бы тоже посмотрел на код игрушек MS, пусть даже бы и только новых, последний сапер на UWP был неплох.
Как сейчас помню, что окончательно переехал на unix, когда калькулятор в чистой свежеустановленной win 10 вдруг выбросил исключение при запуске.
вы еще не видели как калькулятор предлагал оценить его звездочками после некоторой эксплуатации.
Программа написана на С++ и содержит более 35000 строк кода.

не слишком ли много?
в то время премии платили за «сколько поработал».
Вспомнилось из юности, когда калькуляторы были в новинку и их только недавно разрешили использовать на «предприятиях советской торговли и общественного питания» — но только после тестирования: необходимо было умножить число 12345679 (без восьмёрки!) на любое число из строки таблицы умножения для девятки (9, 18, 27, 36, 54 и т.д.). Если в результате получалось число вида 111111111, 222222222, 333333333 — то это должно было документироваться и калькулятор допускался к использованию.
Мне помнится, был когда-то «неофициальный калькулятор от MS» (из пакета «PowerToys»), который ещё и графики рисовал.
В нём доблестные программисты вычисляли синус разложением в ряд, не приводя аргумент к небольшому диапазону.
Результат был немного предсказуем:
синус достигал «военных значений» (10 и более).
Компания открыла код для того, чтобы любой желающий мог ознакомиться с такими технологиями Microsoft как Fluent, Universal Windows Platform, Azure Pipelines и другими. Благодаря этому проекту разработчики могут больше узнать о том, как выполняется работа по созданию тех либо иных проектов в Microsoft

Теперь понятно, почему встроенный калькулятор Windows 10 просит оценить себя в магазине приложений.

Кстати, а XPшный в десятке будет работать?
UFO just landed and posted this here
Вот бы они выпустили исходники Пейнта — багов там целый список можно набрать.
UFO just landed and posted this here
Sign up to leave a comment.

Other news