HEURE ATOMIQUE AVEC UNE SOCKET POUR C++ BUILDER

Commentaire de Kirua le 25/09/2004 01:02:04

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

Commentaire de Kirua le 25/09/2004 12:53:35

c'est pour C++ Builder, un RAD / EDI professionnel qui est tellement bien fait que ce genre de programme met 3 lignes à coder.

Commentaire de Kirua le 25/09/2004 13:11:00

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.

Commentaire de Kirua le 25/09/2004 13:20:48

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!

Commentaire de plus_plus_fab le 25/09/2004 16:59:38

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.

Commentaire de BruNews le 25/09/2004 17:15:37 administrateur CS

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.

Commentaire de plus_plus_fab le 25/09/2004 17:34:17

"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).

Commentaire de plus_plus_fab le 25/09/2004 18:22:38

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 !

Commentaire de uxtobirza le 25/09/2004 18:30:16

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 ?

Commentaire de plus_plus_fab le 27/09/2004 00:18:10

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

Commentaire de Kirua le 27/09/2004 00:31:10

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é.

Commentaire de BlackGoddess le 27/09/2004 09:37:22

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 ...

Commentaire de plus_plus_fab le 27/09/2004 19:25:52

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 ...