2011-01-29 9 views
13

Sto creando main con una macro e devo essere in grado di controllare il sottosistema selezionato in fase di compilazione,/SUBSYSTEM: WINDOWS o/SUBSYSTEM: CONSOLE, per generare l'appropriato funzione principale. C'è un #define che posso verificare per ottenere questo risultato?C'è un #define associato al sottosistema

+0

Non dovresti generare una funzione principale, perché generarla è inutile per te e un ostacolo per gli altri. Cioè ha utilità negativa per farlo. Ma se lo fai, ti piace, è deciso a generare una funzione 'main', quindi * genera uno standard' main' *. Funziona bene indipendentemente dal sottosistema della build. Nota: con gli strumenti Microsoft, che sono un po 'sfidati in questo reparto, impostare l'opzione linker '/ entry: mainCRTStartup' a meno che non si stia facendo un'applicazione MFC, nel qual caso si sta affrontando il problema di altri (ovvero Microsoft) che hanno ha avuto la stessa Really Bad Idea ™ di occuparsi di 'main'. –

risposta

4

Se si sta cercando di semplificare gli utenti della libreria (o qualsiasi cosa sia), è possibile generare sia WinMain e main dalla propria macro. Il linker imposta per impostazione predefinita le app della console per l'avvio da main e le app per win32 per l'avvio da WinMain. L'altra funzione "principale" verrà ignorata.

(Presumibilmente il resto del codice non utilizza nessuno degli argomenti principali funzionali (argc, argv, hInstance, ecc), se è lavorare con entrambi.)

Il _CONSOLE define potrebbe essere utilizzato , ma non appare automaticamente; devi aggiungerlo manualmente alle proprietà del progetto. La selezione del simbolo di avvio, d'altra parte, è automatica. Quindi solo fornire entrambe le funzioni e lasciare che il linker scelga, potrebbe rendere la vita più facile, perché il creatore del progetto non deve impostare nulla, e può davvero passare da Windows a console (eventualmente anche per configurazione) senza dover fare nulla.

11

_CONSOLE dovrebbe fare il trucco per voi.
Inoltre, è possibile selezionare il sottosistema utilizzando #pragma comment(linker, "/subsystem:windows") o #pragma comment(linker, "/subsystem:console") se si vuole davvero percorrere questa rotta.

+2

Questa è sicuramente la risposta migliore in quanto risponde direttamente alla domanda originale specificando manualmente il sistema e lasciando che il linker lo determini (o modificando le impostazioni del progetto). –

+0

Come/dove viene definito '_CONSOLE'? – jww

3

Non è così che funziona davvero. Devi scrivere codice radicalmente diverso in un'app console rispetto a un'app nativa di Windows. In un'app console, si usa printf o cout per produrre output, non avere molto o nessun uso per un mouse. Un'app nativa di Windows richiede un ciclo di messaggi e crea una finestra con una procedura di finestra che rileva il messaggio WM_PAINT per aggiornare la finestra. Eccetera.

Ma è possibile scrivere codice che fa entrambe le cose. Basta scrivere sia una funzione main() che una funzione WinMain(), il CRT chiama automaticamente quella corretta.

+0

+1: Scrivo entrambe le funzioni. – Puppy

+1

Mentre le affermazioni che hai fatto sono vere, non raccontano tutta la storia. È possibile scrivere un'applicazione che funziona con o senza il sottosistema della console tramite alcuni piccoli tweek. In genere questa sarebbe un'applicazione senza finestre (o potrebbe semplicemente chiamare MessageBox) e non ha thread UI. Le pipe standard sono disponibili anche per le app non-console, anche se ovviamente il loro output non verrà visualizzato a meno che non venga reindirizzato. – Tergiver

+2

Infatti. Tutte le mie app sono app per console nella build di debug, ed essenzialmente sono 6 righe di codice extra: una funzione principale che restituisce WinMain (0,0,0,0), tutto all'interno di # #fdef _CONSOLE'. Non hai nemmeno bisogno del '# ifdef'. –