Les messages erreurs g=E9n=E9r=E9s par la compilation de codes C++ (en
particulier avec les template) sont parfois tr=E8s long.
Avez-vous connaissance d'outils permettant d'en faciliter la lecture ?
Les messages erreurs générés par la compilation de codes C++ (en particulier avec les template) sont parfois très long. Avez-vous connaissance d'outils permettant d'en faciliter la lecture ?
Merci pour votre aide.
Laurent
Perso, j'utilise ma_commande_de_build 2>&1 | less Et je m'en sors relativement bien, même avec du Boost.Fusion.
Le plus gros problème en fait, c'est que les templates sont pas bien indentés. Si quelqu'un a un outil qui indente ça, ce serait top.
On 7 sep, 10:26, Laurent Plagne <laurent.pla...@gmail.com> wrote:
Bonjour,
Les messages erreurs générés par la compilation de codes C++ (en
particulier avec les template) sont parfois très long.
Avez-vous connaissance d'outils permettant d'en faciliter la lecture ?
Merci pour votre aide.
Laurent
Perso, j'utilise ma_commande_de_build 2>&1 | less
Et je m'en sors relativement bien, même avec du Boost.Fusion.
Le plus gros problème en fait, c'est que les templates sont pas bien
indentés. Si quelqu'un a un outil qui indente ça, ce serait top.
Les messages erreurs générés par la compilation de codes C++ (en particulier avec les template) sont parfois très long. Avez-vous connaissance d'outils permettant d'en faciliter la lecture ?
Merci pour votre aide.
Laurent
Perso, j'utilise ma_commande_de_build 2>&1 | less Et je m'en sors relativement bien, même avec du Boost.Fusion.
Le plus gros problème en fait, c'est que les templates sont pas bien indentés. Si quelqu'un a un outil qui indente ça, ce serait top.
Laurent
On 7 sep, 23:24, Marc wrote:
Laurent wrote: > J'utilise gcc le + souvent. > J'applique aussi ta stratégie (corriger les pbs en début de message > avant de recompiler) mais mon problème est que j'utilise des types > paramétrés par des type paramétrés etc.... > Un simple type peut prendre beaucoup de place et j'imaginais un > système où les paramètres puissent être réduits/développé s à la > souris...
J'utilise souvent une technique simple : la couleur du texte est donnée par la profondeur de template (la seule subtilité est si on veut évit er un décallage avec les opérateurs contenant < ou >). En particulier, p our une fonction dont le type de retour prend 3 pages, le nom de la fonction saute aux yeux. Ça reste beaucoup moins bien qu'un système qui factor ise les sous-types, mais ça s'écrit en quelques minutes.
J'entends souvent du bien de stlfilt, mais je n'ai jamais eu l'occasion de l'essayer (il n'est pas packagé par debian et j'ai toujous eu la flemme de passer 1min30 à l'installer).
J'a
On 7 sep, 23:24, Marc <marc.gli...@gmail.com> wrote:
Laurent wrote:
> J'utilise gcc le + souvent.
> J'applique aussi ta stratégie (corriger les pbs en début de message
> avant de recompiler) mais mon problème est que j'utilise des types
> paramétrés par des type paramétrés etc....
> Un simple type peut prendre beaucoup de place et j'imaginais un
> système où les paramètres puissent être réduits/développé s à la
> souris...
J'utilise souvent une technique simple : la couleur du texte est donnée
par la profondeur de template (la seule subtilité est si on veut évit er
un décallage avec les opérateurs contenant < ou >). En particulier, p our
une fonction dont le type de retour prend 3 pages, le nom de la fonction
saute aux yeux. Ça reste beaucoup moins bien qu'un système qui factor ise
les sous-types, mais ça s'écrit en quelques minutes.
J'entends souvent du bien de stlfilt, mais je n'ai jamais eu l'occasion
de l'essayer (il n'est pas packagé par debian et j'ai toujous eu la
flemme de passer 1min30 à l'installer).
Laurent wrote: > J'utilise gcc le + souvent. > J'applique aussi ta stratégie (corriger les pbs en début de message > avant de recompiler) mais mon problème est que j'utilise des types > paramétrés par des type paramétrés etc.... > Un simple type peut prendre beaucoup de place et j'imaginais un > système où les paramètres puissent être réduits/développé s à la > souris...
J'utilise souvent une technique simple : la couleur du texte est donnée par la profondeur de template (la seule subtilité est si on veut évit er un décallage avec les opérateurs contenant < ou >). En particulier, p our une fonction dont le type de retour prend 3 pages, le nom de la fonction saute aux yeux. Ça reste beaucoup moins bien qu'un système qui factor ise les sous-types, mais ça s'écrit en quelques minutes.
J'entends souvent du bien de stlfilt, mais je n'ai jamais eu l'occasion de l'essayer (il n'est pas packagé par debian et j'ai toujous eu la flemme de passer 1min30 à l'installer).
J'a
Laurent
On 7 sep, 23:24, Marc wrote:
Laurent wrote: > J'utilise gcc le + souvent. > J'applique aussi ta stratégie (corriger les pbs en début de message > avant de recompiler) mais mon problème est que j'utilise des types > paramétrés par des type paramétrés etc.... > Un simple type peut prendre beaucoup de place et j'imaginais un > système où les paramètres puissent être réduits/développé s à la > souris...
J'utilise souvent une technique simple : la couleur du texte est donnée par la profondeur de template (la seule subtilité est si on veut évit er un décallage avec les opérateurs contenant < ou >). En particulier, p our une fonction dont le type de retour prend 3 pages, le nom de la fonction saute aux yeux. Ça reste beaucoup moins bien qu'un système qui factor ise les sous-types, mais ça s'écrit en quelques minutes.
J'entends souvent du bien de stlfilt, mais je n'ai jamais eu l'occasion de l'essayer (il n'est pas packagé par debian et j'ai toujous eu la flemme de passer 1min30 à l'installer).
J'ai installé et essayé stlfilt qui permet effectivement de mettre en forme les messages erreurs (indentation (ok pour Mathias ?)). En revanche, cela ne permet pas de colorier en fonction de la profondeur ce qui me parait plus adapté à mon problème particulier. A propos de flemme, c'est possible de récupérer la technique de coloriage de Marc ?
Laurent
On 7 sep, 23:24, Marc <marc.gli...@gmail.com> wrote:
Laurent wrote:
> J'utilise gcc le + souvent.
> J'applique aussi ta stratégie (corriger les pbs en début de message
> avant de recompiler) mais mon problème est que j'utilise des types
> paramétrés par des type paramétrés etc....
> Un simple type peut prendre beaucoup de place et j'imaginais un
> système où les paramètres puissent être réduits/développé s à la
> souris...
J'utilise souvent une technique simple : la couleur du texte est donnée
par la profondeur de template (la seule subtilité est si on veut évit er
un décallage avec les opérateurs contenant < ou >). En particulier, p our
une fonction dont le type de retour prend 3 pages, le nom de la fonction
saute aux yeux. Ça reste beaucoup moins bien qu'un système qui factor ise
les sous-types, mais ça s'écrit en quelques minutes.
J'entends souvent du bien de stlfilt, mais je n'ai jamais eu l'occasion
de l'essayer (il n'est pas packagé par debian et j'ai toujous eu la
flemme de passer 1min30 à l'installer).
J'ai installé et essayé stlfilt qui permet effectivement de mettre en
forme les messages erreurs (indentation (ok pour Mathias ?)). En
revanche,
cela ne permet pas de colorier en fonction de la profondeur ce qui me
parait plus adapté à mon problème particulier.
A propos de flemme, c'est possible de récupérer la technique de
coloriage de Marc ?
Laurent wrote: > J'utilise gcc le + souvent. > J'applique aussi ta stratégie (corriger les pbs en début de message > avant de recompiler) mais mon problème est que j'utilise des types > paramétrés par des type paramétrés etc.... > Un simple type peut prendre beaucoup de place et j'imaginais un > système où les paramètres puissent être réduits/développé s à la > souris...
J'utilise souvent une technique simple : la couleur du texte est donnée par la profondeur de template (la seule subtilité est si on veut évit er un décallage avec les opérateurs contenant < ou >). En particulier, p our une fonction dont le type de retour prend 3 pages, le nom de la fonction saute aux yeux. Ça reste beaucoup moins bien qu'un système qui factor ise les sous-types, mais ça s'écrit en quelques minutes.
J'entends souvent du bien de stlfilt, mais je n'ai jamais eu l'occasion de l'essayer (il n'est pas packagé par debian et j'ai toujous eu la flemme de passer 1min30 à l'installer).
J'ai installé et essayé stlfilt qui permet effectivement de mettre en forme les messages erreurs (indentation (ok pour Mathias ?)). En revanche, cela ne permet pas de colorier en fonction de la profondeur ce qui me parait plus adapté à mon problème particulier. A propos de flemme, c'est possible de récupérer la technique de coloriage de Marc ?
Laurent
Marc
Laurent wrote:
A propos de flemme, c'est possible de récupérer la technique de coloriage de Marc ?
Je ne trouve plus la version perl qui protège les opérateurs (je dois l'avoir quelque part, mais où ?), juste un truc c++ qui doit être la première version que j'avais écrite. C'est fait pour écrire g++ ... 2>&1 | colortemplate dans un terminal particulier (ou une invocation plus subtile pour récupérer le code de retour de g++). J'ai honte de poster ça, pas la peine de critiquer.
A propos de flemme, c'est possible de récupérer la technique de
coloriage de Marc ?
Je ne trouve plus la version perl qui protège les opérateurs (je dois
l'avoir quelque part, mais où ?), juste un truc c++ qui doit être la
première version que j'avais écrite. C'est fait pour écrire g++ ... 2>&1
| colortemplate dans un terminal particulier (ou une invocation plus
subtile pour récupérer le code de retour de g++). J'ai honte de poster
ça, pas la peine de critiquer.
A propos de flemme, c'est possible de récupérer la technique de coloriage de Marc ?
Je ne trouve plus la version perl qui protège les opérateurs (je dois l'avoir quelque part, mais où ?), juste un truc c++ qui doit être la première version que j'avais écrite. C'est fait pour écrire g++ ... 2>&1 | colortemplate dans un terminal particulier (ou une invocation plus subtile pour récupérer le code de retour de g++). J'ai honte de poster ça, pas la peine de critiquer.
Laurent wrote: > A propos de flemme, c'est possible de récupérer la technique de > coloriage de Marc ?
Je ne trouve plus la version perl qui protège les opérateurs (je dois l'avoir quelque part, mais où ?), juste un truc c++ qui doit être l a première version que j'avais écrite. C'est fait pour écrire g++ ... 2>&1 | colortemplate dans un terminal particulier (ou une invocation plus subtile pour récupérer le code de retour de g++). J'ai honte de poste r ça, pas la peine de critiquer.
On 8 sep, 23:59, Marc <marc.gli...@gmail.com> wrote:
Laurent wrote:
> A propos de flemme, c'est possible de récupérer la technique de
> coloriage de Marc ?
Je ne trouve plus la version perl qui protège les opérateurs (je dois
l'avoir quelque part, mais où ?), juste un truc c++ qui doit être l a
première version que j'avais écrite. C'est fait pour écrire g++ ... 2>&1
| colortemplate dans un terminal particulier (ou une invocation plus
subtile pour récupérer le code de retour de g++). J'ai honte de poste r
ça, pas la peine de critiquer.
Laurent wrote: > A propos de flemme, c'est possible de récupérer la technique de > coloriage de Marc ?
Je ne trouve plus la version perl qui protège les opérateurs (je dois l'avoir quelque part, mais où ?), juste un truc c++ qui doit être l a première version que j'avais écrite. C'est fait pour écrire g++ ... 2>&1 | colortemplate dans un terminal particulier (ou une invocation plus subtile pour récupérer le code de retour de g++). J'ai honte de poste r ça, pas la peine de critiquer.
