regexp en C

K. Ahausse

03/09/2004 à 10:25

"Emmanuel Delahaye" a écrit dans le message de
news:

K. Ahausse wrote on 26/08/04 :
La charte ne mentionne pas de norme C, mais seules les questions sur la
norme C seraient tolérables.

Il y a comme un bug, dans la charte
Si les gens lisent la norme C de la même façon qu'ils lisent la charte,
ça

promet ...

Essayons d'être clair.

La charte dit que le sujet principal est 'Le Langage C'.

Comment est défini le langage C ? Par une norme internationale de type
ISO. Cette norme constitue le noyau dur du langage (The Core) composé
d'une syntaxe, d'une grammaire et d'une bibliothèque de fonctions.

Elle a l'avantage de définir un langage commun et portable
indépendemment de la machine. Tout code posté ici respectant cette
norme peut être compilé et testé par n'importe quel intervenant
disposant d'une machine avec une compilateur.

D'autre part, il existe de nombreuses extensions au langage C, qui sont

- Des bibliothèques plus ou moins portables
- Des fonctions systèmes avec interface C (POSIX ou non)
- L'assembleur inline
- Des mots clés et types spécifiques (interrupt, far, int64 etc.)

Ces extensions ne font pas partie de la définition du langage C et ne
peuvent donc pas être discutées ici, surtout que dans la plupart des
cas, il existe un forum spécialisé.

Enfin, nous (professionels) considérons qu'il est important de bien
distinguer le noyau du langage de ses extensions, afin d'être capable
d'écrire du code le plus portable possible. Nous n'avons pas
l'intention de promouvoir des pratiques menant à la non-portabilité ou
à l'ecriture de code non réutilisable ou immaintenable.

Tout ça n'est qu'une interprétation personnelle.
La charte ne parle JAMAIS de norme.

En outre même la norme n'est pas aussi sectaire :

<citation C99 page 9 ligne 33 ecrit en gras >

"C code can be non-portable".

</citation C99 page 9 ligne 33 ecrit en gras >

Je cite le paragraphe en entier :
" C code can be non-portable. Although it strove to give programmers the
opportunity to write truly portable programs, the C89 Committee did not want
to force programmers into writing portably, to preclude the use of C as a
"high-level assembler": the ability to write machinespecific code is one of
the strengths of C. It is this principle which largely motivates drawing the
35 distinction between strictly conforming program and conforming program
(§4)."

"Emmanuel Delahaye" <emdel@YOURBRAnoos.fr> a écrit dans le message de
news:mn.152c7d49c1c89e52.15512@YOURBRAnoos.fr...

K. Ahausse wrote on 26/08/04 :

La charte ne mentionne pas de norme C, mais seules les questions sur la
norme C seraient tolérables.

Il y a comme un bug, dans la charte
Si les gens lisent la norme C de la même façon qu'ils lisent la charte,
ça

promet ...

Essayons d'être clair.

La charte dit que le sujet principal est 'Le Langage C'.

Comment est défini le langage C ? Par une norme internationale de type
ISO. Cette norme constitue le noyau dur du langage (The Core) composé
d'une syntaxe, d'une grammaire et d'une bibliothèque de fonctions.

Elle a l'avantage de définir un langage commun et portable
indépendemment de la machine. Tout code posté ici respectant cette
norme peut être compilé et testé par n'importe quel intervenant
disposant d'une machine avec une compilateur.

D'autre part, il existe de nombreuses extensions au langage C, qui sont

- Des bibliothèques plus ou moins portables
- Des fonctions systèmes avec interface C (POSIX ou non)
- L'assembleur inline
- Des mots clés et types spécifiques (interrupt, far, int64 etc.)

Ces extensions ne font pas partie de la définition du langage C et ne
peuvent donc pas être discutées ici, surtout que dans la plupart des
cas, il existe un forum spécialisé.

Enfin, nous (professionels) considérons qu'il est important de bien
distinguer le noyau du langage de ses extensions, afin d'être capable
d'écrire du code le plus portable possible. Nous n'avons pas
l'intention de promouvoir des pratiques menant à la non-portabilité ou
à l'ecriture de code non réutilisable ou immaintenable.

Tout ça n'est qu'une interprétation personnelle.
La charte ne parle JAMAIS de norme.

En outre même la norme n'est pas aussi sectaire :

<citation C99 page 9 ligne 33 ecrit en gras >

"C code can be non-portable".

</citation C99 page 9 ligne 33 ecrit en gras >

Je cite le paragraphe en entier :
" C code can be non-portable. Although it strove to give programmers the
opportunity to write truly portable programs, the C89 Committee did not want
to force programmers into writing portably, to preclude the use of C as a
"high-level assembler": the ability to write machinespecific code is one of
the strengths of C. It is this principle which largely motivates drawing the
35 distinction between strictly conforming program and conforming program
(§4)."

Vous avez filtré cet utilisateur ! Consultez son message

"Emmanuel Delahaye" a écrit dans le message de
news:

K. Ahausse wrote on 26/08/04 :
La charte ne mentionne pas de norme C, mais seules les questions sur la
norme C seraient tolérables.

Il y a comme un bug, dans la charte
Si les gens lisent la norme C de la même façon qu'ils lisent la charte,
ça

promet ...

Essayons d'être clair.

La charte dit que le sujet principal est 'Le Langage C'.

Comment est défini le langage C ? Par une norme internationale de type
ISO. Cette norme constitue le noyau dur du langage (The Core) composé
d'une syntaxe, d'une grammaire et d'une bibliothèque de fonctions.

Elle a l'avantage de définir un langage commun et portable
indépendemment de la machine. Tout code posté ici respectant cette
norme peut être compilé et testé par n'importe quel intervenant
disposant d'une machine avec une compilateur.

D'autre part, il existe de nombreuses extensions au langage C, qui sont

- Des bibliothèques plus ou moins portables
- Des fonctions systèmes avec interface C (POSIX ou non)
- L'assembleur inline
- Des mots clés et types spécifiques (interrupt, far, int64 etc.)

Ces extensions ne font pas partie de la définition du langage C et ne
peuvent donc pas être discutées ici, surtout que dans la plupart des
cas, il existe un forum spécialisé.

Enfin, nous (professionels) considérons qu'il est important de bien
distinguer le noyau du langage de ses extensions, afin d'être capable
d'écrire du code le plus portable possible. Nous n'avons pas
l'intention de promouvoir des pratiques menant à la non-portabilité ou
à l'ecriture de code non réutilisable ou immaintenable.

Tout ça n'est qu'une interprétation personnelle.
La charte ne parle JAMAIS de norme.

En outre même la norme n'est pas aussi sectaire :

<citation C99 page 9 ligne 33 ecrit en gras >

"C code can be non-portable".

</citation C99 page 9 ligne 33 ecrit en gras >

Je cite le paragraphe en entier :
" C code can be non-portable. Although it strove to give programmers the
opportunity to write truly portable programs, the C89 Committee did not want
to force programmers into writing portably, to preclude the use of C as a
"high-level assembler": the ability to write machinespecific code is one of
the strengths of C. It is this principle which largely motivates drawing the
35 distinction between strictly conforming program and conforming program
(§4)."

Emmanuel Delahaye

03/09/2004 à 10:34

La charte ne parle JAMAIS de norme.

ALors selon toi, comment est défini le langage C?

En outre même la norme n'est pas aussi sectaire :

<citation C99 page 9 ligne 33 ecrit en gras >

"C code can be non-portable".

</citation C99 page 9 ligne 33 ecrit en gras >

Je cite le paragraphe en entier :
" C code can be non-portable. Although it strove to give programmers the
opportunity to write truly portable programs, the C89 Committee did not want
to force programmers into writing portably, to preclude the use of C as a
"high-level assembler": the ability to write machinespecific code is one of
the strengths of C. It is this principle which largely motivates drawing the
35 distinction between strictly conforming program and conforming program
(§4)."

Ta citation n'est pas claire. Tu parles de C99, puis de C89. La page 9
de C99 est la suivante
<<
©ISO/IEC ISO/IEC 9899:1999 (E)
5. Environment
1 An implementation translates C source files and executes C programs
in two dataprocessing-
system environments, which will be called the translation environment
and
the execution environment in this International Standard. Their
characteristics define and
constrain the results of executing conforming C programs constructed
according to the
syntactic and semantic rules for conforming implementations.
Forward references: In this clause, only a few of many possible forward
references
have been noted.
5.1 Conceptual models
5.1.1 Translation environment
5.1.1.1 Program structure
1 A C program need not all be translated at the same time. The text of
the program is kept
in units called source files, (or preprocessing files) in this
International Standard. A
source file together with all the headers and source files included via
the preprocessing
directive #include is known as a preprocessing translation unit. After
preprocessing, a
preprocessing translation unit is called a translation unit. Previously
translated translation
units may be preserved individually or in libraries. The separate
translation units of a
program communicate by (for example) calls to functions whose
identifiers have external
linkage, manipulation of objects whose identifiers have external
linkage, or manipulation
of data files. Translation units may be separately translated and then
later linked to
produce an executable program.
Forward references: linkages of identifiers (6.2.2), external
definitions (6.9),
preprocessing directives (6.10).
5.1.1.2 Translation phases
1 The precedence among the syntax rules of translation is specified by
the following
phases.5)
1. Physical source file multibyte characters are mapped, in an
implementationdefined
manner, to the source character set (introducing new-line characters
for
end-of-line indicators) if necessary. Trigraph sequences are replaced
by
corresponding single-character internal representations.
2. Each instance of a backslash character () immediately followed by a
new-line
character is deleted, splicing physical source lines to form logical
source lines.
Only the last backslash on any physical source line shall be eligible
for being part
5) Implementations shall behave as if these separate phases occur, even
though many are typically folded
together in practice.
§5.1.1.2 Environment 9

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

La charte ne parle JAMAIS de norme.

ALors selon toi, comment est défini le langage C?

En outre même la norme n'est pas aussi sectaire :

<citation C99 page 9 ligne 33 ecrit en gras >

"C code can be non-portable".

</citation C99 page 9 ligne 33 ecrit en gras >

Je cite le paragraphe en entier :
" C code can be non-portable. Although it strove to give programmers the
opportunity to write truly portable programs, the C89 Committee did not want
to force programmers into writing portably, to preclude the use of C as a
"high-level assembler": the ability to write machinespecific code is one of
the strengths of C. It is this principle which largely motivates drawing the
35 distinction between strictly conforming program and conforming program
(§4)."

Ta citation n'est pas claire. Tu parles de C99, puis de C89. La page 9
de C99 est la suivante
<<
©ISO/IEC ISO/IEC 9899:1999 (E)
5. Environment
1 An implementation translates C source files and executes C programs
in two dataprocessing-
system environments, which will be called the translation environment
and
the execution environment in this International Standard. Their
characteristics define and
constrain the results of executing conforming C programs constructed
according to the
syntactic and semantic rules for conforming implementations.
Forward references: In this clause, only a few of many possible forward
references
have been noted.
5.1 Conceptual models
5.1.1 Translation environment
5.1.1.1 Program structure
1 A C program need not all be translated at the same time. The text of
the program is kept
in units called source files, (or preprocessing files) in this
International Standard. A
source file together with all the headers and source files included via
the preprocessing
directive #include is known as a preprocessing translation unit. After
preprocessing, a
preprocessing translation unit is called a translation unit. Previously
translated translation
units may be preserved individually or in libraries. The separate
translation units of a
program communicate by (for example) calls to functions whose
identifiers have external
linkage, manipulation of objects whose identifiers have external
linkage, or manipulation
of data files. Translation units may be separately translated and then
later linked to
produce an executable program.
Forward references: linkages of identifiers (6.2.2), external
definitions (6.9),
preprocessing directives (6.10).
5.1.1.2 Translation phases
1 The precedence among the syntax rules of translation is specified by
the following
phases.5)
1. Physical source file multibyte characters are mapped, in an
implementationdefined
manner, to the source character set (introducing new-line characters
for
end-of-line indicators) if necessary. Trigraph sequences are replaced
by
corresponding single-character internal representations.
2. Each instance of a backslash character () immediately followed by a
new-line
character is deleted, splicing physical source lines to form logical
source lines.
Only the last backslash on any physical source line shall be eligible
for being part
5) Implementations shall behave as if these separate phases occur, even
though many are typically folded
together in practice.
§5.1.1.2 Environment 9

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Vous avez filtré cet utilisateur ! Consultez son message

La charte ne parle JAMAIS de norme.

ALors selon toi, comment est défini le langage C?

En outre même la norme n'est pas aussi sectaire :

<citation C99 page 9 ligne 33 ecrit en gras >

"C code can be non-portable".

</citation C99 page 9 ligne 33 ecrit en gras >

Je cite le paragraphe en entier :
" C code can be non-portable. Although it strove to give programmers the
opportunity to write truly portable programs, the C89 Committee did not want
to force programmers into writing portably, to preclude the use of C as a
"high-level assembler": the ability to write machinespecific code is one of
the strengths of C. It is this principle which largely motivates drawing the
35 distinction between strictly conforming program and conforming program
(§4)."

Ta citation n'est pas claire. Tu parles de C99, puis de C89. La page 9
de C99 est la suivante
<<
©ISO/IEC ISO/IEC 9899:1999 (E)
5. Environment
1 An implementation translates C source files and executes C programs
in two dataprocessing-
system environments, which will be called the translation environment
and
the execution environment in this International Standard. Their
characteristics define and
constrain the results of executing conforming C programs constructed
according to the
syntactic and semantic rules for conforming implementations.
Forward references: In this clause, only a few of many possible forward
references
have been noted.
5.1 Conceptual models
5.1.1 Translation environment
5.1.1.1 Program structure
1 A C program need not all be translated at the same time. The text of
the program is kept
in units called source files, (or preprocessing files) in this
International Standard. A
source file together with all the headers and source files included via
the preprocessing
directive #include is known as a preprocessing translation unit. After
preprocessing, a
preprocessing translation unit is called a translation unit. Previously
translated translation
units may be preserved individually or in libraries. The separate
translation units of a
program communicate by (for example) calls to functions whose
identifiers have external
linkage, manipulation of objects whose identifiers have external
linkage, or manipulation
of data files. Translation units may be separately translated and then
later linked to
produce an executable program.
Forward references: linkages of identifiers (6.2.2), external
definitions (6.9),
preprocessing directives (6.10).
5.1.1.2 Translation phases
1 The precedence among the syntax rules of translation is specified by
the following
phases.5)
1. Physical source file multibyte characters are mapped, in an
implementationdefined
manner, to the source character set (introducing new-line characters
for
end-of-line indicators) if necessary. Trigraph sequences are replaced
by
corresponding single-character internal representations.
2. Each instance of a backslash character () immediately followed by a
new-line
character is deleted, splicing physical source lines to form logical
source lines.
Only the last backslash on any physical source line shall be eligible
for being part
5) Implementations shall behave as if these separate phases occur, even
though many are typically folded
together in practice.
§5.1.1.2 Environment 9

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

K. Ahausse

03/09/2004 à 11:32

"Emmanuel Delahaye" a écrit dans le message de
news:

La charte ne parle JAMAIS de norme.

ALors selon toi, comment est défini le langage C?

La définition du langage C est un autre débat. Là, il est question de la
charte de fr.comp.lang.c.

En outre même la norme n'est pas aussi sectaire :

<citation C99 page 9 ligne 33 ecrit en gras >

"C code can be non-portable".

</citation C99 page 9 ligne 33 ecrit en gras >

Je cite le paragraphe en entier :
" C code can be non-portable. Although it strove to give programmers the
opportunity to write truly portable programs, the C89 Committee did not
want

to force programmers into writing portably, to preclude the use of C as
a

"high-level assembler": the ability to write machinespecific code is one
of

the strengths of C. It is this principle which largely motivates drawing
the

35 distinction between strictly conforming program and conforming
program

(§4)."

Ta citation n'est pas claire. Tu parles de C99, puis de C89.

Moi ? j'ai parlé de c89 ? non !

La page 9 de C99 est la suivante

C99, Revision 5.10, april-2003,
0.introduction, ligne 33 à 36.

Emmanuel Delahaye

03/09/2004 à 13:57

K. Ahausse wrote on 03/09/04 :

La charte ne parle JAMAIS de norme.

ALors selon toi, comment est défini le langage C?

La définition du langage C est un autre débat. Là, il est question de la
charte de fr.comp.lang.c.

Certes, mais dans la charte il est question de "Langage C". Selon toi,
de quoi parles-t-on ? Comment est défini ce langage ? Quel est le but
exact de tes remarques ?

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Richard Delorme

03/09/2004 à 15:30

K. Ahausse wrote on 26/08/04 :

La charte ne mentionne pas de norme C, mais seules les questions sur la
norme C seraient tolérables.

Il y a comme un bug, dans la charte
Si les gens lisent la norme C de la même façon qu'ils lisent la
charte, ça
promet ...

Essayons d'être clair.

La charte dit que le sujet principal est 'Le Langage C'.

Non, la charte dit le « langage C et _assimilés_.» On peut mettre
beaucoup de chose sous le terme « assimilés...»

--
Richard

Anthony

03/09/2004 à 15:37

Bonjour,

Emmanuel Delahaye wrote:
[...]

D'autre part, il existe de nombreuses extensions au langage C, qui sont

- Des bibliothèques plus ou moins portables
- Des fonctions systèmes avec interface C (POSIX ou non)
- L'assembleur inline
- Des mots clés et types spécifiques (interrupt, far, int64 etc.)

Ces extensions ne font pas partie de la définition du langage C et ne
peuvent donc pas être discutées ici, surtout que dans la plupart des
cas, il existe un forum spécialisé.

Dans le cas de posix, le *plus* approprié serait fr.comp.os.unix, n'est-ce
pas ? Or il a été dit que dans ce cas ce choix de forum n'était pas très
convaincant pour une personne qui débarque sur les news. En effet, je le
lis et on y voit surtout des problèmes de shell et autre, j'y vois rarement
des questions de C.

De plus, POSIX me parait tout de même assez répendu et une mesure qui
consisterait à isoler dans ce forum les questions HS relatives à POSIX me
parait assez faible, trop peu pour former un nouveau groupe.
Je me demandais donc pourquoi être aussi restrictif si on considère que pas
mal de monde ici peuvent y répondre correctement, et que ca a quand même un
rapport pas si lointain que ca avec le C ?
Exemple la question de l'OP dans ce cas, je la rappelle :

int main (int argc, char **argv)
{
  regex_t  regexp;

  if (!regcomp(&regexp, "192.168.0.22", REG_ICASE))
    {
      if (regexec(&regexp, "192.168.0.22", 0, NULL, 0))
        printf("Match...n");

On voit ici que même si il fait un appel à une fonction non standard, il
s'est un peu emmelé les pinceaux (ou alors a mal lu la doc) sur le if().

Dans ce cas, est ce HS ou pas ?

Enfin, nous (professionels) considérons qu'il est important de bien
distinguer le noyau du langage de ses extensions, afin d'être capable
d'écrire du code le plus portable possible. Nous n'avons pas
l'intention de promouvoir des pratiques menant à la non-portabilité ou
à l'ecriture de code non réutilisable ou immaintenable.

N'est ce pas un peu "abusé" ? surtout la présence du immaintenable ? Je suis
pour ma part encore étudiant donc pas professionnel, mais ce que j'ai vu de
l'informatique en entreprise est loin de ce qui est énoncé dans la phrase
précédente.
Je suis d'accord que la portabilité est importante, mais POSIX existe depuis
longtemps et est bien éprouvée et je ne pense pas être le seul à inclure
des fonctions non standard dans mes sources en C, même si j'essaye de bien
les séparer d'une partie standard (ce qui est plus facile à dire qu'à faire
dans un gros code).

Anthony
--
It's a bird.. It's a plane..
No, it's KernelMan, faster than a speeding bullet, to your rescue.
Doing new kernel versions in under 5 seconds flat..
-- Linus, in the announcement for 1.3.27

Bonjour,

Emmanuel Delahaye wrote:
[...]

D'autre part, il existe de nombreuses extensions au langage C, qui sont

- Des bibliothèques plus ou moins portables
- Des fonctions systèmes avec interface C (POSIX ou non)
- L'assembleur inline
- Des mots clés et types spécifiques (interrupt, far, int64 etc.)

Ces extensions ne font pas partie de la définition du langage C et ne
peuvent donc pas être discutées ici, surtout que dans la plupart des
cas, il existe un forum spécialisé.

Dans le cas de posix, le *plus* approprié serait fr.comp.os.unix, n'est-ce
pas ? Or il a été dit que dans ce cas ce choix de forum n'était pas très
convaincant pour une personne qui débarque sur les news. En effet, je le
lis et on y voit surtout des problèmes de shell et autre, j'y vois rarement
des questions de C.

De plus, POSIX me parait tout de même assez répendu et une mesure qui
consisterait à isoler dans ce forum les questions HS relatives à POSIX me
parait assez faible, trop peu pour former un nouveau groupe.
Je me demandais donc pourquoi être aussi restrictif si on considère que pas
mal de monde ici peuvent y répondre correctement, et que ca a quand même un
rapport pas si lointain que ca avec le C ?
Exemple la question de l'OP dans ce cas, je la rappelle :

int main (int argc, char **argv)
{
  regex_t  regexp;

  if (!regcomp(&regexp, "192.168.0.22", REG_ICASE))
    {
      if (regexec(&regexp, "192.168.0.22", 0, NULL, 0))
        printf("Match...n");

On voit ici que même si il fait un appel à une fonction non standard, il
s'est un peu emmelé les pinceaux (ou alors a mal lu la doc) sur le if().

Dans ce cas, est ce HS ou pas ?

Enfin, nous (professionels) considérons qu'il est important de bien
distinguer le noyau du langage de ses extensions, afin d'être capable
d'écrire du code le plus portable possible. Nous n'avons pas
l'intention de promouvoir des pratiques menant à la non-portabilité ou
à l'ecriture de code non réutilisable ou immaintenable.

N'est ce pas un peu "abusé" ? surtout la présence du immaintenable ? Je suis
pour ma part encore étudiant donc pas professionnel, mais ce que j'ai vu de
l'informatique en entreprise est loin de ce qui est énoncé dans la phrase
précédente.
Je suis d'accord que la portabilité est importante, mais POSIX existe depuis
longtemps et est bien éprouvée et je ne pense pas être le seul à inclure
des fonctions non standard dans mes sources en C, même si j'essaye de bien
les séparer d'une partie standard (ce qui est plus facile à dire qu'à faire
dans un gros code).

Anthony
--
It's a bird.. It's a plane..
No, it's KernelMan, faster than a speeding bullet, to your rescue.
Doing new kernel versions in under 5 seconds flat..
-- Linus, in the announcement for 1.3.27

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

Emmanuel Delahaye wrote:
[...]

D'autre part, il existe de nombreuses extensions au langage C, qui sont

- Des bibliothèques plus ou moins portables
- Des fonctions systèmes avec interface C (POSIX ou non)
- L'assembleur inline
- Des mots clés et types spécifiques (interrupt, far, int64 etc.)

Ces extensions ne font pas partie de la définition du langage C et ne
peuvent donc pas être discutées ici, surtout que dans la plupart des
cas, il existe un forum spécialisé.

Dans le cas de posix, le *plus* approprié serait fr.comp.os.unix, n'est-ce
pas ? Or il a été dit que dans ce cas ce choix de forum n'était pas très
convaincant pour une personne qui débarque sur les news. En effet, je le
lis et on y voit surtout des problèmes de shell et autre, j'y vois rarement
des questions de C.

De plus, POSIX me parait tout de même assez répendu et une mesure qui
consisterait à isoler dans ce forum les questions HS relatives à POSIX me
parait assez faible, trop peu pour former un nouveau groupe.
Je me demandais donc pourquoi être aussi restrictif si on considère que pas
mal de monde ici peuvent y répondre correctement, et que ca a quand même un
rapport pas si lointain que ca avec le C ?
Exemple la question de l'OP dans ce cas, je la rappelle :

int main (int argc, char **argv)
{
  regex_t  regexp;

  if (!regcomp(&regexp, "192.168.0.22", REG_ICASE))
    {
      if (regexec(&regexp, "192.168.0.22", 0, NULL, 0))
        printf("Match...n");

On voit ici que même si il fait un appel à une fonction non standard, il
s'est un peu emmelé les pinceaux (ou alors a mal lu la doc) sur le if().

Dans ce cas, est ce HS ou pas ?

Enfin, nous (professionels) considérons qu'il est important de bien
distinguer le noyau du langage de ses extensions, afin d'être capable
d'écrire du code le plus portable possible. Nous n'avons pas
l'intention de promouvoir des pratiques menant à la non-portabilité ou
à l'ecriture de code non réutilisable ou immaintenable.

N'est ce pas un peu "abusé" ? surtout la présence du immaintenable ? Je suis
pour ma part encore étudiant donc pas professionnel, mais ce que j'ai vu de
l'informatique en entreprise est loin de ce qui est énoncé dans la phrase
précédente.
Je suis d'accord que la portabilité est importante, mais POSIX existe depuis
longtemps et est bien éprouvée et je ne pense pas être le seul à inclure
des fonctions non standard dans mes sources en C, même si j'essaye de bien
les séparer d'une partie standard (ce qui est plus facile à dire qu'à faire
dans un gros code).

Anthony
--
It's a bird.. It's a plane..
No, it's KernelMan, faster than a speeding bullet, to your rescue.
Doing new kernel versions in under 5 seconds flat..
-- Linus, in the announcement for 1.3.27

Emmanuel Delahaye

03/09/2004 à 15:56

Anthony wrote on 03/09/04 :

Enfin, nous (professionels) considérons qu'il est important de bien
distinguer le noyau du langage de ses extensions, afin d'être capable
d'écrire du code le plus portable possible. Nous n'avons pas
l'intention de promouvoir des pratiques menant à la non-portabilité ou
à l'ecriture de code non réutilisable ou immaintenable.

N'est ce pas un peu "abusé" ? surtout la présence du immaintenable ? Je suis
pour ma part encore étudiant donc pas professionnel, mais ce que j'ai vu de
l'informatique en entreprise est loin de ce qui est énoncé dans la phrase
précédente.

Il existe de mauvais professionels (trop à mon goût). Je pense que l'un
des buts de ce forum est promouvoir les bonnes pratiques.

Je suis d'accord que la portabilité est importante, mais POSIX existe depuis
longtemps et est bien éprouvée et je ne pense pas être le seul à inclure
des fonctions non standard dans mes sources en C, même si j'essaye de bien
les séparer d'une partie standard (ce qui est plus facile à dire qu'à faire
dans un gros code).

Ce qui rend le code inmaintenable, c'est la dissémination des appels et
des pratiques non standards. Il est courant dans l'industrie de
'wrapper'les appels non standard dans une surcouche que l'on aimerait
être la plus standard possible (POSIX), mais dont, à défaut, on a les
sources, ce qui facilite le portage.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

K. Ahausse

03/09/2004 à 16:08

"Emmanuel Delahaye" a écrit dans le message de
news:

K. Ahausse wrote on 03/09/04 :
La charte ne parle JAMAIS de norme.

ALors selon toi, comment est défini le langage C?

La définition du langage C est un autre débat. Là, il est question de la
charte de fr.comp.lang.c.

Certes, mais dans la charte il est question de "Langage C". Selon toi,
de quoi parles-t-on ? Comment est défini ce langage ?

Bon, donc, au moins, nous sommes d'accord sur deux points :
- la charte de fr.comp.lang.c parle du langage C, sans mentionner aucune
norme.
- d'après la norme C99, un programme écrit en langage C peut entre
non-portable.

Quel est le but exact de tes remarques ?

Simplement corriger des inexactitudes.

Emmanuel Delahaye

03/09/2004 à 16:10

K. Ahausse wrote on 03/09/04 :

Certes, mais dans la charte il est question de "Langage C". Selon toi,
de quoi parles-t-on ? Comment est défini ce langage ?

Bon, donc, au moins, nous sommes d'accord sur deux points :
- la charte de fr.comp.lang.c parle du langage C, sans mentionner aucune
norme.

Il est un fait indéniable que le langage C est un langage norlmalisé
dont la définition s'impose à tout le monde. Si on parle de langage C
sans autreprécisions, c'est de celui-ci que l'on parle, sinon, il fait
préciser de quel langage régional il s'agit : Turbo C, GNU-C etc.

- d'après la norme C99, un programme écrit en langage C peut être
non-portable.

Bien sûr, l'important est de bien faire la différence, ce qui n'est pas
du tout évident pour un débutant, surtout si les réponses partent dans
tous les sens et commencent à utiliser des 'régionalismes', d'où une
certaine rigueur (appelle la rigidité si ça te fait plaisir) que tu
n'aimes pas, mais que d'autres apprécient.

Quel est le but exact de tes remarques ?

Simplement corriger des inexactitudes.

Alors nous poursuivons le même but. Des exemples ?

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

K. Ahausse

03/09/2004 à 16:21

"Emmanuel Delahaye" a écrit dans le message de
news:

Anthony wrote on 03/09/04 :

Enfin, nous (professionels) considérons qu'il est important de bien
distinguer le noyau du langage de ses extensions, afin d'être capable
d'écrire du code le plus portable possible. Nous n'avons pas
l'intention de promouvoir des pratiques menant à la non-portabilité ou
à l'ecriture de code non réutilisable ou immaintenable.

N'est ce pas un peu "abusé" ? surtout la présence du immaintenable ? Je
suis

pour ma part encore étudiant donc pas professionnel, mais ce que j'ai vu
de

l'informatique en entreprise est loin de ce qui est énoncé dans la
phrase

précédente.

Il existe de mauvais professionels (trop à mon goût). Je pense que l'un
des buts de ce forum est promouvoir les bonnes pratiques.

Et donc pour faire le ménage parmi les mauvais professionnels il faut jeter
les débutants ?
Il faut aussi jeter ceux qui ne sont plus débutants mais on besoin d'un coup
de main dans des domains particuliers ?

En fait, les seuls qu'il faudrait tolérer sur fr.comp.lang.c. c'est le : bon
professionnel, celui là même qui n'a pas besoin de poser de question.

regexp en C

10 réponses

Veuillez sélectionner un problème