Мария Мальцева

C++

Вы там что-то приняли из запрещенных препаратов? Какое еще "ток понимает"?

Электрическое поле, блин, распространяется в проводниках, при подключении проводников к источнику питания. Согласно их свойствам. И уже из-за поля свободные электроны начинают двигаться (то есть течёт ток).

У LED-ламп очень малое потребление тока и обычно большой диапазон рабочего напряжения, чаще это 85-260В, поэтому они светятся даже от малейшей утечки тока.
Частые причины утечки:
1. Выключатель с подсветкой - в цепь постоянно под напряжением, его не хватает чтобы зажечь обычную или галогеновую лампу, но вполне хватает для подпитки светодиодной или энергосберегайки
2. Выключатель разрывает не ту цепь - в одно время правила предписывали схему где выключатель разрывает нулевую шину, а не фазную, типо для безопасности чтоб током меньше ударило, такая схема распространенно встречается в хрущевках и некоторых их последователях. она применима только для ламп накаливания, т.к. диодные и люминесцентные опять же получают утечку через железобетонные конструкции здания, паралленьные линии и тп.
3. Бывают иногда и другие реже встречающиеся факторы

Если делать статику:

class any_class
{
  public static function add()
  {
  }
}

... то, чтобы воспользоваться методом, не надо создавать объект, классу которого принадлежит этот метод, он доступен, если есть описание класса.
any_class::add()
А так лишний раз создавать объект по любому поводу, чтобы воспользоваться методом add().

class any_class
{
  public function add()
  {
  }
}

$any_class_object = new any_class;
$any_class_object->add();

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

Лучшей книгой для вас будет Эндрю Троелсен "Язык программирования C# 6.0 и платформа .NET 4.6".
Прекрасная книга для профессионалов, рассказывает обо всём в языке и почти обо всех возможностях и использованиях. В первую очередь, предназначена для программистов, которые уже умеют программировать, но не знают язык C#. В ей всё структурировано на разделы, каждый из них можно читать независимо и использовать как справочник.
У этой книги есть только один недостаток - написана для профессионалов, и автор пишет, как делать, но не пишет, почему так делать - вы и так уже это понимаете, иначе книга стала бы совсем уж гигантской.

Рекомендую взять время и попробовать написать несколько консольных программ на c#, начиная с моего любимого решателя квадратных уравнений :) и работы со списками (простой телефонный справочник). И только после этого начинайте работать с WPF.

А вот очень приличный учебник по wpf:
https://professorweb.ru/my/WPF/base_WPF/level1/inf...
Довольно суховато написано, но с неплохими примерами.

И опять же, рекомендую не начинать делать вашу программу, а сделать с помощью WPF те же программы, которые написали с консолью. И освойтё MVVM.

почему не могут избавиться от strcpy?

Ну наверное по той же причине, по которой на кухне до сих пор не могут избавиться от ножа.

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

Потому что код нельзя писать внутри класса вне методов и секций инициализации.

Потому что у вас в условиях не сравнения (==), а присвоения (=).
Используйте стиль Йоды.

https://ru.wikipedia.org/wiki/Условия_Йоды
Аж в двух местах.

Причём в Си не нужно ставить в сложных условиях скобки, как в Паскале, вполне покатит такое…

if ((a >= 11 && a <= 14) || m == 0 || (m >= 5 && m <= 9))

Но нет, вы наставили лишних скобок и заглушили ошибку.

Также, что мне не нравится.
Вместо 0,1,2,3 лучше использовать константы MANY/FEW/ONE/UNKNOWN.

В case 1 символ подстановки плохо содран с доски.

Если условие на MANY самое сложное и выполняется по остаточному принципу — почему его делаем самым первым? Лучше что-то типа…
• 10…20 → MANY
• 1 → ONE
• 2…4 → FEW
• Иначе MANY

Потому что C# миленький

Я не самый крутой программист, но попытаюсь внести какой-то вклад.

На чистом C игры обычно не пишут, т.к. C++ для этого удобней и мощнее, да и прикладное ПО писать на нём более удобно, но за это приходится платить сложностью языка, намучаешься с которым довольно сильно. Для MUD игр достаточно будет Java, т.к. будет полегче C++ и по моему мнению сокеты писать удобнее, нежели в Python, а клиент-серверные приложения используют не один язык, и зачастую тем языком, который обеспечивает связь клиент-сервер является как-раз Java. Есть хорошая книжка по ней, из серии Head First, в русском переводе вроде называлась "Изучаем Java", авторы Кэти Сьерра и Берт Бэйтс, легко читается и воспринимается и даёт основные знания по Java, в т.ч. веб-сокеты там тоже затрагиваются и объясняются понятным языком. Прикладное ПО же пишется в основном на C++ и C#, на остальном не особо удобно. По C# кстати тоже есть книжка из той серии, там вроде тоже про сокеты есть. Вообще эти языки отчасти похожи, так что зная один можно легко перейти на другой.

Есть ли у вас подобные проблемы и как вы с ними боретесь?

Таких проблем нет. Вы работаете 24/7? Если нет, то у вас масса времени на социализацию. Найдите занятие не связанное с программированием и подразумевающим социализацию. Хороший вариант - заняться каким-либо спортом, лучше командным. Например, я занимаюсь бегом по пересеченной местности. Постоянно тренировки, выезды с командой на различные соревнования и пр. Сами не заметите, как станете более комуникабельным человеком.
Просто не заморачивайтесь на работе, живите яркой жизнью.

Допустим есть команда профессиональных, финансово-неограниченных, C/C++ программистов, которые предпочитают писать на C++, но были вынуждены выбрать язык C для решения следующих задач....что это за задачи и почему?

1. Низкоуровневые задачи, где нужно иметь минимум абстракции от оборудования. Я лично хоть и не разделяю анти-C++ настроений Линуса, вполне согласен с тем что ядру полезно быть написанным на Си. В C++ есть довольно много абстракций, влияющих на исполнение кода, есть некоторые вещи "под капотом", которые могут быть недопустимы в низкоуровенвом коде.

2. Большие проекты, где сложно форсировать code-style. С++ - это такой язык... Он настолько разнообразен, что прежде чем некая команда сядет писать код, она должна выбрать некоторое ПОДМНОЖЕСТВО языка, и использовать его. Иными словами, Плюсы - это большой ящик с инструментами, и вовсе не обязательно (даже вредно) использовать сразу все. Важно отказываться от каких-либо возможностей или практик, особенно устаревших (а таких в C++ немало, "идиоматический" код на C++03 и C++17 - очень разный). Кто не хочет со всем этим заморачиваться (вспомним опять таки Линух - огромный проект с огромным числом участников) - вполне могут выбрать Си. Ведь можно считать, что выбор языка Си - это выбор только необходимого инструментария из того что предлагается в C++ (только помните что сейчас это всё-таки разные языки).

3. Программирование в сильных ресурсных ограничениях. Например под микроконтроллеры. Хоть в С++ программист "не платит за то чем не пользуется", иногда стандартные реализации различных механизмов недопустимо тяжелы или неэффективны. Например, если у вас очень медленный чип или мало памяти, возможно вы заходите свою собственную реализацию полиморфизма. Какой тогда смысл говорить что вы пишете на C++, если не сможете использовать его механизмы и то, что предлагает компилятор.