Станислав Макаров

1. char - знаковый тип. Используйте unsigned char, а лучше std::byte если он доступен вам.
2. проверьте форматную строку.

https://support.microsoft.com/en-us/help/814777/ho...

To log on to Windows by using the disabled local Administrator account, start Windows in Safe mode. Even when the Administrator account is disabled, you are not prevented from logging on as Administrator in Safe mode. When you have logged on successfully in Safe mode, re-enable the Administrator account, and then log on again.

sqlfiddle.com/#!17/12350/11/0

select val from
(
    (select val from foo where val < 9 order by val desc limit 5)
    union
    (select val from foo where val >= 9 order by val asc)
) results
order by val asc

Или я что то не правильно понял?

Да, вы не понимаете сути слияния веток в Git.

Начнём с того, что когда вы сливаете ветки, по большому счёту не так уж важно какую ветку в какую вы будете сливать. Вы В ЛЮБОМ случае создаёте мёрж-коммит, и создание этого мёрж-коммита (и соответственно разрешение конфликтов которое происходит при создании этого коммита) подразумевает, что вы соединили вместе две ветки. Это значит что начиная с мёрж-коммита все последующие коммиты (дочерние к нему) будут иметь изменения из ОБОИХ веток. Уже не будет разницы между тем что было сделано в первой и во второй ветке, отныне "они едины" (c).

Другой вопрос в том, в какую ветку поместить этот мёрж-коммит и УКАЗАТЕЛЬ какой из веток СДВИНУТЬ на новый мёрж-коммит. Теоретически, мы можем сдвинуть оба указателя, но в большинстве случаев нам достаточно сдвига лишь в одной ветке (и нередко только в одной из веток, в вашем случае f1, мы имеем право двигать указатель).

Когда вы попытаетесь сделать "обратное сливание f1 в develop", если в develop ещё не успело появиться новых коммитов (не являющихся предками созданного вами мёрж-коммита), то на самом деле никакого сливания и НЕ БУДЕТ. Ведь у вас УЖЕ есть коммит, учитывающий изменения в ОБОИХ ветках. Достаточно лишь передвинуть указатель ветки develop на этот коммит. Другое дело, что решение о том, что это можно и нужно сделать, приняв тем самым изменения в ветке f1 в ветку develop, принимает мейнтенер ветки develop, а это вовсе не обязательно тот же человек, что и работающий с веткой f1.

Почему мы сначала сдвигаем указатель ветки f1? Ну очевидно потому, что это ветка в которой ведётся разработка, и обычно принято принимать в общую ветку (коей видимо у вас является develop) уже полностью готовые правки. Готовые - это в том числе интегрированные с текущим состоянием кодовой базы. Обычно это задача работающего в ветке f1 - порезолвить все конфликты и интегрироваться со свежим состоянием develop, чтобы мейнтейнер проекта мог максимально быстро и безболезненно вмёржить f1 в develop.

1. В теории реализация не обязана использовать стек для хранения локальных объектов value-типов (см. https://blogs.msdn.microsoft.com/ericlippert/2009/... ).
2. Тем не менее, в текущих реализациях используется именно стек, поэтому всё как и в остальных языках: https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B5%D... .
3. Помните, что значения value-типов иногда (не всегда) хранятся на стеке. Все значения value-типов, являющиеся частью объекта ссылочного типа (например, int-поле в классе или элементы массива double) рождаются и умирают вместе с этим объектом.

Итого:

• время жизни локальных объектов value-типов связывается с фреймом стека;
  
• время жизни объектов value-типов, находящихся в составе объектов reference-типов, связывается с временем жизни объемлющего объекта;
  

Более экзотические ситуации рассматривать не будем. И вообще, как говорит Липперт (см. ссылку), лучше не думать в терминах стека, т.к. это деталь реализации. Лучше говорить о времени жизни относительно вызываемых функций и относительно других объектов.

Но мне нужно докерезировать обычное Десктопное консольное приложение с .net framework 3.5+

На Windows 7, очевидно, докер будет работать только благодаря линуксовой виртуалке (кажется в VirtualBox-e). Т.к. .NET Framework никогда не работал и скорее всего не будет работать под Linux (в отличие например от Mono или .NET Core), вы не добьётесь своей цели с использованием имеющихся инструментов.

Вам как минимум нужны нативные контейнеры (Windows Containers), доступные в Windows 10 и Windows Server 2016.

Вот кстати неплохой пример, как раз консольное приложение: https://github.com/Microsoft/dotnet-framework-dock... . Цитаты из него:

To complete this sample you must have Windows 10 (or Windows Server 2016), Docker for Windows, Visual Studio, and Git installed.

You must use Windows Containers on Docker for Windows to run this image. Be sure to check that you are properly switched to Windows Containers. Do this by opening the system tray up arrow and right clicking on the Docker whale icon for a popup menu. In the popup menu make sure you select 'Switch to Windows Containers'.