Qu'est ce qu'un bon projet de la structure en C

Je travaille en Java/J2ee projets, dont j'ai suivi l'Maven de la structure.
Je veux développer [dire un interpréteur de ligne de commande sous linux {ubuntu}] dans C.
Je n'ai jamais développer des projets en C. je veux savoir ce que la structure d'un projet je dois suivre.

InformationsquelleAutor mohit | 2010-04-09
  1. 10

    Il n'y a pas de "standard" pour le projet C dans cet aspect. Certes, si votre projet est de petite taille, puis souvent tout sera placé dans un répertoire unique.

    Vous pouvez essayer de télécharger certains populaire open-source C de projets et de prendre un coup d'oeil à leur code.

    À un moindre niveau, le code doit être modulaire. Chaque module (qui en C se manifeste généralement dans une structure de données avec un ensemble de fonctions pour agir sur lui) a sa propre paire de .h et .c fichiers, avec l' .h fichier de l'interface publique visible pour les clients du module, et le .c fichier en cours de la mise en œuvre privée.

    • Je suis en train d'essayer de trouver quelque chose comme cela. Je suis de la pensée "maven" mais pour C. Il devrait y avoir un fichier makefile, certains tests? Maven est devenu le standard de facto en Java pour le projet de la structure.
    InformationsquelleAutor Eli Bendersky
  2. 8

    Comme Eli Bendersky sayd, il dépend strictement quelle est la complexité de votre projet.

    La norme suggère de diviser le plus possible dans les bibliothèques. Le point est que vous pouvez réutiliser vos bibliothèques ailleurs. Par exemple c'est un projet de la mine:

    ├── AUTHORS
├── COPYING
├── ChangeLog
├── Makefile.am
├── NEWS
├── README
├── configure.ac
├── libs
│   ├── featsel
│   │   ├── Makefile.am
│   │   ├── commander.c
│   │   ├── featsel
│   │   │   ├── commander.h
│   │   │   ├── feattuple.h
│   │   │   └── types.h
│   │   ├── featsel.h
│   │   ├── feattuple.c
│   │   ├── headers
│   │   │   └── datatypes.h
│   │   └── tests
│   │       ├── Makefile.am
│   │       └── test00.c
│   ├── mbox
│   │   ├── Makefile.am
│   │   ├── README
│   │   ├── control.c
│   │   ├── error.c
│   │   ├── headers
│   │   │   ├── datatypes.h
│   │   │   ├── mail.h
│   │   │   ├── parse.h
│   │   │   ├── split.h
│   │   │   └── strings.h
│   │   ├── interface.c
│   │   ├── mail.c
│   │   ├── mbox
│   │   │   ├── descriptor.h
│   │   │   ├── error.h
│   │   │   ├── mail.h
│   │   │   └── types.h
│   │   ├── mbox.h
│   │   ├── parse.c
│   │   ├── split.c
│   │   └── strings.c
│   └── thread_queue
│       ├── Makefile.am
│       ├── thrdqueue.c
│       └── thrdqueue.h
├── reconf
└── src
├── Makefile.am
└── main.c

    Personnellement, je préfère mettre toutes les bibliothèques dans un libs répertoire. Chaque bibliothèque à l'exception insignifiants a son propre en-tête de répertoire et les exportations d'un en-tête public par le biais d'un répertoire ayant le même nom de la bibliothèque.

    Le fichier source du programme lui-même est placée dans le répertoire src.

    InformationsquelleAutor Dacav
  3. 6

    Séparer les fonctions dans les modules: .c des fichiers avec des détails de mise en œuvre/définitions jumelé avec .h les fichiers avec déclarations.

    Essayez de ne pas polluer les espaces de noms en utilisant statique pour les fonctions communes et d'un module de préfixe pour les symboles externes.

    Créer des bibliothèques si vous avez des fonctionnalités qui peuvent être encapsulés et réutilisés.

    InformationsquelleAutor piotr
  4. 5

    Une suggestion: 

    /project
README
LICENCE
Makefile 
# mabe configure.am Makefile.am etc. 
# see http://en.wikipedia.org/wiki/GNU_build_system
/src
Makefile
a.h
a.c
b.h
b.c 
/subunit
x.h
x.c
y.h
y.c
# each file.c has a header file.h but not necessarily
...

    Regarder Nginx sur github et de parcourir la structure du projet en ligne.

    InformationsquelleAutor clyfe
  5. 3

    Vous pouvez vous référer à la OpenSSL de la structure de Projet. C'est un open source et dispose d'une bonne structure de projet.

    InformationsquelleAutor Jay