C Programme Différences de plate-forme multiples sur Windows et Unix OS

Le langage C lui-même est le portable de Windows à UNIX. Mais les détails du système d'exploitation sont différents et parfois ceux qui entrent dans votre code.

Par exemple, les systèmes UNIX n'utilisent généralement que "\ n" pour séparer les lignes dans un fichier texte, tandis que la plupart des outils Windows s'attendent à voir "\ r \ n". Il existe des moyens de gérer ce genre de différence d'une manière qui obtient le temps d'exécution C pour le gérer pour vous, mais si vous ne faites pas attention à eux, il est assez facile d'écrire un code C spécifique au système d'exploitation.

Je pourrais que vous exécutez une unité unique dans une machine virtuelle et utilisez-la pour tester votre code avant de la partager avec vos étudiants.

Je pense que c'est critique que vous vous familiarisez avec UNIX en ce moment.

Un excellent moyen de faire ceci est un knoppix cd.

Essayez de compiler vos programmes sous Linux à l'aide de GC, et quand ils ne fonctionnent pas, suivez les problèmes (#include ?) et le faire fonctionner. Puis retournez à Windows et cela compilera probablement OK.

De cette façon, vous découvrirez que vos programmes deviennent plus propres et meilleurs enseignants, même pour des exercices de laboratoire sur des machines Windows.

Ce type de problèmes apparaissent généralement lorsque vous ne vous tenez pas à la norme nette C et faites des hypothèses sur l'environnement qui pourraient ne pas être vraies. Ceux-ci peuvent inclure la dépendance sur:

• Non standard, spécifique à la plate-forme Inclus ( , , .);
• comportement non défini ( fflush (stdin) , comme le signalait quelqu'un d'autre, il n'est pas nécessaire de faire quoi que ce soit de la norme - c'est en fait un comportement non défini à invoquer fflush sur quoi que ce soit Les flux de sortie; en général, les compilateurs plus âgés étaient plus indulgent quant à la violation de règles subtiles telles que le strict aliasing, alors soyez prudent avec des astuces "intelligentes");
• Type de données Taille (le court = 16 bit, int = long = 32 bits hypothèse ne contient pas partout - 64 bits Linux , par exemple, a 64 bits long );
• en particulier, la taille du pointeur ( vide * n'est pas toujours 32 bits et ne peut pas toujours être déposé en toute sécurité à un non signé long ); En général, vous devriez faire attention aux conversions et aux comparaisons qui impliquent des pointeurs, et vous devez toujours utiliser les types fournis pour ce type de tâches au lieu de "normal" int s (voir en particulier taille_t < / code>, ptrdiff_t , uintptr_t )
• Type de données "Format intérieur" (la norme ne dit pas que float s et double s est dans IEEE 754, bien que je n'ai jamais vu des plates-formes le faisant différemment. );
• Fonctions non standard ( __ BEGINTHREAD , MS Safe Strings Fonctions; de l'autre côté, POSIX / GNU Extensions)
• Extensions du compilateur ( __ inline , __ DeclSpec , #pragma s, ...) et en général tout ce qui commence par un double sens (ou Même avec un seul soulignement, dans d'anciennes implémentations non standard);
• Console Codes d'évacuation de la console (ce problème est généralement un problème lorsque vous essayez d'exécuter un code UNIX sous Windows);
• Format de retour de chariot: Dans les chaînes normales, c'est \ n partout, mais quand écrit sur fichier c'est \ n sur * Nix, \ r \ n sous Windows, \ r sur les Mac pré-OSX; La conversion est gérée automatiquement par les flux de fichiers, veillez donc à ouvrir des fichiers en binaire lorsque vous souhaitez réellement écrire des données binaires et les laisser en mode texte lorsque vous souhaitez écrire du texte.

  Quoi qu'il en soit, un exemple de programme qui ne compile pas sur * Nix serait utile, nous pourrions vous donner des suggestions de préciser.

  Les détails du programme sont encore à obtenir. Les étudiants provenaient de notre précédent lot. Ont demandé cela. Turbo C est ce qui est utilisé actuellement.

  Comme indiqué dans le commentaire, Veuillez déposer Turbo C et (si vous l'utilisez) Turbo C ++, de nos jours, ils sont à la fois des morceaux d'historique et ont de nombreuses incompatibilités avec les normes C et C ++ actuelles (et Si je me souviens bien, ils génèrent tous les deux des exécutables 16 bits, cela ne fonctionnera même pas sur des OS 64 bits sur X86_64).

  Il y a beaucoup d'alternatives gratuites, fonctionnelles et conformes à la normalisation (VC ++ Express, Mingw, Pelles C, Cygwin sous Windows et GCC / G ++ est la norme de facto sur Linux, rivalisée par Clang), vous venez d'avoir choisir un.