HEURE ATOMIQUE AVEC UNE SOCKET POUR C++ BUILDER
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
-
24 sept. 2004 à 19:40
cs_ProgVal Messages postés 33 Date d'inscription dimanche 23 avril 2006 Statut Membre Dernière intervention 22 octobre 2006 - 23 avril 2006 à 11:34
cs_ProgVal Messages postés 33 Date d'inscription dimanche 23 avril 2006 Statut Membre Dernière intervention 22 octobre 2006 - 23 avril 2006 à 11:34
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
https://codes-sources.commentcamarche.net/source/26379-heure-atomique-avec-une-socket-pour-c-builder
23 avril 2006 à 11:34
27 sept. 2004 à 19:48
27 sept. 2004 à 19:25
27 sept. 2004 à 18:41
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.
@+
27 sept. 2004 à 09:37
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 ...
27 sept. 2004 à 01:12
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...
27 sept. 2004 à 00:31
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é.
27 sept. 2004 à 00:25
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.
27 sept. 2004 à 00:18
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
26 sept. 2004 à 21:00
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...
25 sept. 2004 à 18:30
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 ?
25 sept. 2004 à 18:28
25 sept. 2004 à 18:22
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 !
25 sept. 2004 à 17:47
25 sept. 2004 à 17:34
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).
25 sept. 2004 à 17:18
ç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).
25 sept. 2004 à 17:15
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.
25 sept. 2004 à 17:03
25 sept. 2004 à 16:59
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.
25 sept. 2004 à 13:27
25 sept. 2004 à 13:20
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!
25 sept. 2004 à 13:16
25 sept. 2004 à 13:11
25 sept. 2004 à 13:05
25 sept. 2004 à 12:53
25 sept. 2004 à 10:36
25 sept. 2004 à 01:02
c'est un peu pompeux comme titre lol. dire que tu te connectes à un Time Server aurait suffit ;)
bonne journée
24 sept. 2004 à 19:40
http://brunews.free.fr/brunews/download/CP5.zip
http://brunews.free.fr/brunews/download/CP5Sources.zip