En Windows, Visual Studio y Emacs; en Linux, casi exclusivamente este último. Esto tanto en trabajo como en casa. El porqué es simplemente que Visual Studio es omnipresente en Windows y casi en cualquier empresa lo usan. En el caso de Emacs, porque es con el que soy más productivo, dada la forma de trabajar que tiene, y aunque otros editores tienen modos compatibles con Emacs, siento que no es lo mismo. Por cierto, y como detalle "curioso", tanto Emacs como Vim también se usan bastante en entornos profesionales, incluso al programar bajo Windows. Mucho más de lo que mucha gente cree.

No necesitas hacer nada especial. Dado que el servidor tiene que ejecutarse primero para escuchar, cuando el cliente se ejecute, el puerto que se le asignará siempre será uno distinto, por lo que el hecho de que cliente y servidor se ejecuten en el mismo equipo no causa ningún conflicto.

Creo que el más complicado de C++ que conozco es "Modern C++ Design" de Andrei Alexandrescu. Se mete bastante de lleno con la metaprogramación con templates y es bastante interesante, pero su aplicación práctica es limitada, por lo que si acaso lo recomendaría como curiosidad y para aprender un poco sobre la metaprogramación, pero no necesariamente para aplicar las técnicas que enseña.

De ejercicios no sabría realmente, ya que no es un tema que me llame mucho, pero algunos libros de gráficos sí que me han hecho dar topes contra la pared. Algunas partes de "Computational Geometry - Algorithms and applications" y "Real time collision detection", por ejemplo. Aunque hay quien los considera más libros de matemáticas que de programación, intentar implementar sus técnicas es muy entretenido y gratificante, si es que te gusta el tema.

En el caso del código que pusiste, en esta línea:

s _t = 6;
 

en realidad no se invoca al constructor por defecto ni al operator=. De hecho, dando  que tú ya escribiste un constructor, el compilador ya no genera la versión por defecto o sin parámetros (sólo la genera si tú no creas ninguno, o si se lo pides, con  = default). Y por supuesto, en ningún caso generaría una sobrecarga de operator= que tome como parámetro un int. El único operador de asignación que el compilador generará automáticamente toma como parámetro una referencia const (en algunos casos, no const) al mismo tipo de la clase, en este caso s.

Lo que en realidad sucede en esa línea es que se invoca al constructor que tú definiste, y se le pasa como parámetro 6. O sea, es equivalente a esto:

s _t(6);
 

En cuanto a tu última pregunta, en general, el compilador genera un operador de asignación para cualquier tipo que crees, salvo unas pocas excepciones (por ejemplo, si contiene alguna variable miembro no static que sea const, o referencia)

No uses gets. Es una función insegura y oficialmente ya ni siquiera es parte del lenguaje, aunque los compiladores aún permitan usarla.

Pasando al otro código, no es que el segundo cin.getline almacene el Enter, sino que cuando introduces una cadena mayor a la especificada, cin queda en un estado de error, y no va a funcionar mientras no lo arregles. Por ejemplo, si aquí:

 cin.getline(cadena,10,'\n');

introduces 10 caracteres o más, ocurre error, y cualquier intento de leer datos con cin (cin.getline(), cin >> variable, etc.) va a fallar, es decir, se saltará a la siguiente instrucción. La solución es que pongas esto inmediatamente después de cin.getline:

// Si el getline fallo:
if (cin.fail()) {
    // "Arreglar" cin
    cin.clear();
    // Opcional: descartar caracteres restantes en buffer. Incluir <limits>
    cin.ignore(numeric_limits<streamsize>::max(), '\n');
}

La última línea es por si quieres que el segundo cin.getline lea una cadena nueva. La función ignore lee y descarta caracteres hasta que haya leído la cantidad especificada en su primer parámetro, o hasta encontrar el caracter de su segundo parámetro. Es decir, esto:

    cin.ignore(20, '\n');

leería y descartaría del buffer hasta 20 caracteres o hasta encontrar una nueva línea, lo que suceda primero. El primer parámetro que yo usé en el ejemplo de arriba representa el tamaño máximo de un buffer de entrada/salida. Básicamente es decirle a ignore que limpie todo el buffer (por más grande que sea) hasta encontrar el´\n'.

Eso sí, sería mejor que usaras la clase string, como lo hizo string Manolo, en cuyo caso usarías la función global getline, que funciona un poco distinto a cin.getline, y en este caso específico lo  del estado de error no aplicaría como lo puse.

Lo que sucede es que cuando se llega aquí:

    s2 = s0 + s1;

el objeto temporal creado por el operador sobrecargado (ns) es asignado a s2. Esto hace que se ejecute el operador de asignación (operator=) para struct s. Dado que tú no programaste ninguno, se usa el generado por el compilador. Éste simplemente copia los valores de las variables miembro, es decir, que luego de la copia, s2.d apunta a la misma dirección que ns.d. Esa memoria se libera cuando ns es destruida. Y luego, cuando s2 es destruida, naturalmente, se vuelve a intentar liberar la misma dirección, lo cual es incorrecto. Que se trate de copias es irrelevante. Lo que importa es que apuntan a la misma dirección, y es un error intentar liberar memoria ya liberada. Pero eso ni siquiera es lo peor. Como te mencioné, en la línea 30, s2.d apuntará a la dirección de ns.d, pero antes de esa línea apuntaba a otra dirección distinta, la cual jamás fue liberada, por lo que tienes una "fuga de memoria" o memory leak.

La solución es sobrecargar también operator=, y en él no copiar los punteros, sino los valores de las direcciones a las que apuntan (reservando y liberando memoria, según sea necesario). Imagino que aún no habrás visto ese tema, pero ya llegarás y verás cómo implementarlo. En general, siempre que tengamos punteros habría que sobrecargar el operador de asignación y proporcionar un constructor de copia.

Ese ejemplo tuyo y lo que te comenta Eternal Idol es la razón por la que se suele recomiendar pasar los objetos por referencia, ya que así se evita la creación de copias temporales.

Sin embargo, en tu código, la línea 24 no invoca al constructor que tú escribiste, ya que se trata del constructor por defecto (sin parámetros). Ese sólo se llama cuando creas un objeto como en la línea 23. En la línea 24, como te indicaron, se está copiando un objeto, por lo que se invoca al constructor de copia de x. Tú no escribiste uno, por lo que el compilador lo hace por ti y es ése el que es llamado. Por eso, al ejecutar tu programa, deberías ver sólo un mensaje de " constructor ejecutado" y dos del destructor.

Primero, aclarar, tú lo quieres es probar si varios bits están todos encendidos o ninguno, porque probarlos individualmente ya lo sabes hacer, ¿cierto?

La forma más simple sería (suponiendo que mascara1, mascara2, etc. contienen cada una 1 bit a probar):

if ((variable & mascara1) && (variable & mascara2) &&  ... 

Pero si son muchos bits a probar quedaría una condición larguísima y tendrías demasiadas operaciones. Mejor preparar una máscara combinada y hacer algo así:

mascara = mascara1 | mascara2 | ...
 
// Todos on
if ( (variable & mascara) == mascara)
...
// Todos off
if (!(variable & mascara))

Creo que tienes una confusión. Estos #defines:

#define ID_EDIT 1
#define ID_BUTTON 2

no los vas a encontrar en ninguna cabecera. Esos los pone el programador, y sirven para identificar a cada control individual, no el tipo de control. Esto es un error:

hwndButton = CreateWindowW(L"button", L"ENTER", WS_VISIBLE | WS_CHILD, 335, 320, 80, 25, hwnd, (HMENU)ID_BUTTON, NULL, NULL);
 
hwndButton2 = CreateWindowW(L"button", NULL, WS_VISIBLE | WS_CHILD, 11, 150, 403, 3, hwnd, (HMENU)ID_BUTTON, NULL, NULL);

Porque estás creando dos botones, y a ambos les pones el mismo identificador (ID_BUTTON). No vas a tener forma de distinguirlos al procesar sus mensajes. Debes hacer algo tipo:

#define ID_EDIT1 1
#define ID_EDIT2 2
#define ID_BUTTON1 3
#define ID_BUTTON2 4

O podrías poner nombres más significativos (ID_BUTTON_SALIR, etc.), y asignarles el valor que quieras, pero debe ser único para cada control. Al crear cada control, a CreateWindow le pasas el valor correspondiente. Lo que determina el tipo de control es el primer parámetro que le pasas a esta función ("Edit", "Button", etc.). Esos son los que debes buscar, pero no en una cabecera sino en la documentación. Por ejemplo, aquí tienes la de los Button: https://docs.microsoft.com/en-us/windows/desktop/controls/buttons y a la izquierda tienes un listado con otros. El nombre de la clase para pasar a CreateWindow suele ser el del control: "Button", "Edit", etc., o también puedes pasar una constante que identifica la clase del control: https://docs.microsoft.com/en-us/windows/desktop/controls/common-control-window-classes . Y fíjate que algunos tipos de controles en realidad son "subtipos" de un mismo control. Como en el link de Button que te puse; hay una sección "Button types" donde puedes ver que, por ejemplo, el checkbox es en realidad un Button con el estilo BS_CHECKBOX o BS_AUTOCHECKBOX.

Sólo lo vi por encima, pero no hay nada ahí que impida o dificulte convertirlo a dll. Los puntos a tener en cuenta son los de siempre con las dll: si quieres que sea posible acceder desde programas creados con otros compiladores/lenguajes, como es tu caso, no puedes exportar clases ni funciones miembro; las funciones a exportar deberán tener el modificador extern "C"; etc.

La clase Serial en su constructor recibe como parámetro el nombre del puerto, pero el resto de la configuración la hace con valores fijos (dcbSerialParams.BaudRate=CBR_9600;
dcbSerialParams.ByteSize=8;). Puedes cambiar ese constructor para que acepte el resto de parámetros y los configure. Y creas y exportas una función con la misma cantidad de parámetos que se encargue de crear el objeto pasándole esos parámetros al constructor. Lo mismo para poder enviar y recibir datos, deberás crear y exportar funciones que llamen y le pasen los parámetros a ReadData y WriteData.