HEURE ATOMIQUE AVEC UNE SOCKET POUR C++ BUILDER

Signaler
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
-
cs_ProgVal
Messages postés
33
Date d'inscription
dimanche 23 avril 2006
Statut
Membre
Dernière intervention
22 octobre 2006
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/26379-heure-atomique-avec-une-socket-pour-c-builder

cs_ProgVal
Messages postés
33
Date d'inscription
dimanche 23 avril 2006
Statut
Membre
Dernière intervention
22 octobre 2006

J'ai essayé le programme: j'ai une erreur avec OldCreatOrder sur certains composants, comme Form1, AboutBox, ...
cs_Nebula
Messages postés
790
Date d'inscription
samedi 8 juin 2002
Statut
Membre
Dernière intervention
7 juin 2007
1
T'es vraiment irrécupérable, hein ?
plus_plus_fab
Messages postés
232
Date d'inscription
vendredi 9 janvier 2004
Statut
Membre
Dernière intervention
8 janvier 2005

excuse BlackGodess, c'est pas tout faux ce que tu dis, mais tu parles de la portabilité d'un exécutable, on parlait de la portabilité des sources ...
plus_plus_fab
Messages postés
232
Date d'inscription
vendredi 9 janvier 2004
Statut
Membre
Dernière intervention
8 janvier 2005

bon, dans l'ordre :
Brunews : tant mieux si ça satisfait tes clients ! J'attend de savoir en quoi une application n'utilisant que l'API w$ est plus rapide qu'une application respectant le standard (mes arguments précédents n'ayant pas été contredits).

Kirua : OK, je prends note de ta remarque, et je ne suis pas le genre de gonz qui ne se remet jamais en question ...

Nebula :
"Non, mais tu réfléchis avant d'écrire ?"
no comment ...
"tu oses dire que ce sera plus performant qu'une application Win32 native ?"
démontre moi le contraire ! (j'ai donné de nombreux exemples dans les posts précédents).

Moi aussi, j'aime l'optimisation, et ça ne m'empeche pas de faire du code portable. Si tout le monde écrit du code non portable, on ne pourra plus rien échangé, c'est regrettable tu ne trouves pas ?

"toi tu fais du portable, c'est bien. Fais ce qui t'amuse, .... du pro-linuxien de base, tu donnes ainsi une mauvaise image du système ainsi que de ses utilisateurs."
me voila taxé de "pro-linuxien de base", alors que je n'ai pas évoqué Linux !
Je donne une mauvaise image alors que je souhaite que les codes C/C++ puissent etre partagés par tous (utilisateurs de w$, Linux, Mac, BSD, ...) ?
sérieux, relis toi.

BlackGodess : tout faux !
(Je parle de programmes C/C++ sans morceaux écrits en asm)
C'est le compilateur qui génère des instructions propres à chaque processeur (et donc parfois incompatible meme sur un OS identique), si on lui en donne l'ordre !!!
voir les options -mcpu et -march de gcc/g++.
Si l'exécutable n'est pas portable, ce n'est pas un problème. L'objectif du C et du C++ (tous en coeur), c'est la performance !!! L'essentiel est que le source soit portable.
OK pour le cran supérieur ! effectivement, les librairies sont optimisées (meme quelques fois à l'assembleur) pour les différents OS.

on trolle quand on avance avance quelquechose (un sujet à débat) sans argumentation (genre la lib std est super lente ! les appels systèmes, c'est super ! ...) Je pense que ça n'a pas été mon cas.

@+
BlackGoddess
Messages postés
338
Date d'inscription
jeudi 22 août 2002
Statut
Membre
Dernière intervention
14 juin 2005

Je pense que l'optimisation et la portabilité sont deux points opposés, et ce n'est pas nouveau.
Par exemple faire un programme qui marche sur plusieurs processeurs n'utilisera pas les instructions spécifiques à chaque processeur, d'ou une perte d'optimisation mais un gain de portabilité. A l'inverse, utiliser les instructions d'un processeur rend le programme incompatible avec un autre processeur.
On peut monter d'un cran et voir la même chose au niveau de l'OS, et des librairies standards.
Apres les choix techniques dépendent bien sur des besoins, comme l'ont dit Brunews et Kirua. Jpense pas que ca vaille la peine de troller 10 posts la dessus ...
cs_Nebula
Messages postés
790
Date d'inscription
samedi 8 juin 2002
Statut
Membre
Dernière intervention
7 juin 2007
1
Pour c++ fab :

Non, mais tu réfléchis avant d'écrire ? Parce qu'avec ta stdlib, on ne va pas loin... On peut évidemment utiliser des toolkits comme Qt / GTK ou autres wxWidgets, mais sérieusement, tu oses dire que ce sera plus performant qu'une application Win32 native ? D'ailleurs ta chère stdlib est tellement rapide que j'ai cherché à m'en débarasser il n'y a pas si longtemps, afin de ne retenir QUE du code API pur...

Et non, je ne jure pas que par Microsoft : je trouve leur API très moyenne à utiliser (surtout comparée à celle de GTK), mais elle est performante et c'est tout ce qui compte. Je me suis mis au C pour la rapidité et l'optimisation, pas pour faire du "portable". Toi tu fais du portable, c'est bien. Fais ce qui t'amuse, et ne viens pas dévier les commentaires d'une source conçue EXPLICITEMENT pour Win32 (Borland C++ Builder oblige) avec des arguments du pro-linuxien de base, tu donnes ainsi une mauvaise image du système ainsi que de ses utilisateurs.

Je concluerais en rajoutant qu'un bon code standard sera toujours plus rapide qu'un mauvais code système, et inversement. L'API est pleine de subtilités et que ce soit sur des fichiers ou des sockets, seules des personnes qualifiées sauront exploiter les finesses de chacune...
cs_Kirua
Messages postés
3006
Date d'inscription
dimanche 14 avril 2002
Statut
Membre
Dernière intervention
31 décembre 2008

je pense aussi que tu es plein de certitudes, plus_plus_fab... les solutions qui sont pour toi les meilleures, ne le sont pas forcément pour les autres.

ceci dit, j'utilise également la lib std, la portabilité m'importe. ce n'est pourtant pas une contrainte à laquelle tout le monde est lié.
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16
Ben non, quand on produit du code, le minimum c'est qu'il soit le plus rapide possible chez les clients.
Il se trouve que j'ai 100% de clients sous Windows et c'est tres bien ainsi, pas du tout envie de jouer les transporteurs et autre SERNAM, les bidouilloux s'en chargeront.
plus_plus_fab
Messages postés
232
Date d'inscription
vendredi 9 janvier 2004
Statut
Membre
Dernière intervention
8 janvier 2005

de quelle API tu parles ?
allez, je me doute bien que c'est l'API w$ ...
je vous rappelle que le minimum, (je dis bien le minimum) quand on fait du C ou du C++, c'est d'écrire du code standard ! La lib standard est aussi faite pour uniformiser tout ça.

>Nebula : "On met plus longtemps mais on sait (presque) toujours où on va."
merci, mais personellement, je sais ou je vais quand j'utilise la lib standard.

Bref, il me semble avoir exposer les principaux arguments pour vous convaincre d'utiliser la lib standard, mais vous en faites ce que vous voulez ...
Votre argument c'est la performance, c'est bien ça ? Vous avez fait des tests comparatifs (lib std vs appels systemes)? surement pas les bons alors ! J'en ai fait un (qui a humilié la version appel systeme), qui testait en fait l'utilité de tamponner les flux. C'est sans appel !

Apres, c'est sur que si vous ecrivez une bibliotheque de flux sans controles d'erreur serieux, vous allez aller plus vite, mais ce n'est pas acceptable.

PS : désolé pour le HS uxtobirza
cs_Nebula
Messages postés
790
Date d'inscription
samedi 8 juin 2002
Statut
Membre
Dernière intervention
7 juin 2007
1
Oui : upx permet de compresser des exécutables et ainsi d'en réduire la taille (pratique pour Delphi/C++ Builder), le tout en le laissant autonome puisqu'il sera décompressé à la volée lors de son lancement, de manière automatique !

Sinon pour l'optimisation, je pense comme Brunews : vive le C et l'API ! On met plus longtemps mais on sait (presque) toujours où on va.

PS : "presque" à cause des subtilités parfois déroutantes de ladite API...
uxtobirza
Messages postés
16
Date d'inscription
dimanche 2 février 2003
Statut
Membre
Dernière intervention
3 juin 2008

on peut copier coller les 250 lignes de codes de winmain et tous ses sacs à switch dans dev c++
et pareil pour le code d'une socket. C'était vrai à l'époque de windows 95 avant visual et builder.
De nos jours ça n'a plus aucun intérêt.
Avec builder on peut choisir l'option de compiler sans utiliser de dll. On peut aussi utiliser time.h, stdlib.h au lieu des api, ce qui est certainement plus fiable.
Mon but n'est pas de réinventer la roue mais de l'utiliser. avez vous des commentaires utiles et suceptibles d'améliorer cette souce ?
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16
bah, point de vue que je ne partage absolument pas en regardant le code des libs standards et comparant avec les appels directs API. Tous les tests que nous avons fait ici meme etaient sans appel, la lib standard est une jeep sur un circuit de F1.
plus_plus_fab
Messages postés
232
Date d'inscription
vendredi 9 janvier 2004
Statut
Membre
Dernière intervention
8 janvier 2005

oui bien sur, tu peux gerer un tampon toi meme ... encore faut-il savoir quelle est la taille la plus approprié !

Tu peux t'amuser à optimiser tout ça, mais ça te conduira inexorablement à réécrire une version voisine de la lib standard. Faire une lib maison qui surclasse une lib incorporé au standard, c'est une utopie ! oui, c'est frustrant pour l'ego je sais ...

Je sais bien qu'en prog, il ne faut jamais dire : défendu de faire ça. Il y aura toujours un cas bien particulier, ou tu manipulera un appel système, mais dans l'immense majorité des cas, ben faut éviter.

la performance d'un système tiens énormément à la façon de réduire les chargements et défauts de pages. Rien que cet argument me semble suffisant pour opter pour les librairies standard.
Sauf dans le cas ou l'on souhaite s'amuser ou progresser bien sur !
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16
Il vaut toujours mieux un buffer (tampon) gere soi meme qu'un qui sera gere dans une lib qu'on ne maitrise pas, on peut avec des pointeurs le manipuler directement. Les performances sont justement de ce cote et non dans les libs standards.
plus_plus_fab
Messages postés
232
Date d'inscription
vendredi 9 janvier 2004
Statut
Membre
Dernière intervention
8 janvier 2005

"Je n'ai pas 'd'idee' sur ce que contient msvcrt.dll mais une absolue certitude ayant son code devant les yeux. "
quelle chance !

oui, les appels de procédure de bibliothèque, provoque au final des appels systèmes, en optimisant (utilisation de tampons dans le cas des flux par exemple).
plus_plus_fab
Messages postés
232
Date d'inscription
vendredi 9 janvier 2004
Statut
Membre
Dernière intervention
8 janvier 2005

rien !
ça a l'air d'etre un terme qui désigne des librairies compilés statiquement ou dynamiquement (je ne parle pas d'edition de lien dynamique ou statique mais bien de compilation, ce qui n'a rien a voir).
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16
Je n'ai pas 'd'idee' sur ce que contient msvcrt.dll mais une absolue certitude ayant son code devant les yeux.
Tous les appels qu'on lui ferait sous la forme de lib standard C renvoient apres quelques manips (errno et autres fariboles inutiles) vers un appel API normal.
cs_Kirua
Messages postés
3006
Date d'inscription
dimanche 14 avril 2002
Statut
Membre
Dernière intervention
31 décembre 2008

et RT pr toi ça veut dire quoi ??
plus_plus_fab
Messages postés
232
Date d'inscription
vendredi 9 janvier 2004
Statut
Membre
Dernière intervention
8 janvier 2005

Je sais que cette erreur est courante chez les programmeurs w$, mais parmis les milliers de fonctions de l'API w$ , beaucoup ne sont pas des appels systèmes (ie ne basculent pas en mode noyau).
le basculement en mode noyau est couteux sur tout les OS, donc il faut éviter de faire de multiples appels systèmes. Les fonctions de bibliothèques (standard C et C++) optimisent en utilisant les tampons du système, et donc en réduisant le nombre d'appels système.
Sans parler du fait que l'utilisation des appels systèmes (ou dans ce cas de l'API w$) , brise nette lla portabilité ...

L'avantage d'utiliser les librairies standards est aussi d'économiser la RAM. La plupart des programmes utilises ces librairies, ce qui fait que ces fichiers sont mappés en mémoire (presque entirement) et quasiment en permanence. Un exemplaire pour tout le monde quoi ! Il ne se produit alors que tres peu de defaut de pages ...

Je n'ai aucune affinité avec cette msvcrt.dll (qui n'est autre qu'une bibliotheque dynamique !!! pourquoi parler de run-time ???), mais savez-vous ce qu'elle contient ? mon idée serait quelle contient des objets liées au système d'exploitation, aux librairies standard C et C++, et peut etre au compilateur-linker. Cette librairie est surement mappé en mémoire régulièrement, et c'est à mon avis une erreur de ne pas l'utiliser.
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16
La difference est que si on prog proprement on a aucune reference sur msvcrt.dll, pour t'en convaincre tu peux aller regarder mes EXEs avec depends.exe, il faut pour cela tout coder a base d'appels directs au systeme (API).
cs_Kirua
Messages postés
3006
Date d'inscription
dimanche 14 avril 2002
Statut
Membre
Dernière intervention
31 décembre 2008

sous VC++ il y a aussi un RT... la msvcrt sauf erreur, ça veut bien dire: Microsoft Visual C++ Run Time, non ?

sinon, je suis bien d'accord avec toi, pour avoir utilisé BCB pdt un moment, j'ai eu largement le temps de me rendre compte que je serais jamais content de ce que je faisais avec BCB, puisque c'est l'EDI qui fait tout... t'as beau te casser la tête a faire un vrmnt beau programme très utile etc, ... ben les sockets: c'est pas toi; le gui: c'est pas toi; les conteneurs: c'est pas toi; et puis tu as toutes les facilités de gestion et toutes les fonctions super utiles déjà codées, pour toi. c'est déprimant en fait cet EDI :p pour ça que j'ai arrêté. mais si tu cherches l'efficacité plus que le ludique: ben c'est, je pense, ce qui se fait de mieux!
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16
Me semblait que quand on venait au C/C++ c'etait pour coder et non se servir d'un runtime, mais bon....
cs_Kirua
Messages postés
3006
Date d'inscription
dimanche 14 avril 2002
Statut
Membre
Dernière intervention
31 décembre 2008

non, c'est pas vrai pour BCB, tu peux configurer qq options, (deux), et ça te sort des exe autonomes, mais de facilement 500Ko - 1Mo.
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16
Kirua> oui tout comme VB, il faut un setup complet qui pose tout le runtime pour le moindre petit exe.
cs_Kirua
Messages postés
3006
Date d'inscription
dimanche 14 avril 2002
Statut
Membre
Dernière intervention
31 décembre 2008

c'est pour C++ Builder, un RAD / EDI professionnel qui est tellement bien fait que ce genre de programme met 3 lignes à coder.
Saros
Messages postés
921
Date d'inscription
vendredi 20 décembre 2002
Statut
Membre
Dernière intervention
23 septembre 2010

Missing file vcl.h...
cs_Kirua
Messages postés
3006
Date d'inscription
dimanche 14 avril 2002
Statut
Membre
Dernière intervention
31 décembre 2008

l'heure atomique avec un dixième de seconde de décalage...
c'est un peu pompeux comme titre lol. dire que tu te connectes à un Time Server aurait suffit ;)

bonne journée
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16