FUUUUUUUUUUU UUUUUUUUUU UUUUUUUUUUU UUUUUUUUUUUUU - Page 66

si, printf.

vince > ?

J'ai proche de moi un prototype d'une carte PowerVR

et maintenant, trouver pourquoi j'ai 2 fps....

http://i.imgur.com/MBfTPDh.gifv

Tu as vu la complexité de ta scène 3D, aussi ? Faut pas trop en demander...

Bon j'ai réglé ça, par contre maintenant mes sources de lumière font la gueule ...

(j'avais lu "font la gaule" O_o)

Debian de MERDE

$ sudo apt-get install libsdl2-dev
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libpam-systemd : Depends: systemd (= 232-19)
 udev : Breaks: systemd (< 232-11)
        Breaks: systemd:i386 (< 232-11)
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

Bordel pourquoi tu me fait chier avec SystemD et libpam pour installer la version DEV de SDL2? putain de distribution de M E R D E au meme titre que l'init utilisé
Il est vraiment temps que je switch cette machine vers un VraiOS

Parce que apt-get, de par sa conception, refuse de faire quoi que ce soit si le système est en un état incohérent. Corrige ton bordel (si je comprends bien tes messages, en mettant à jour systemd tout simplement) et ça marchera.

Il y a un problème de versions sur des parties critiques du système, c'est quand même pas terrible

Ca arrive régulièrement dans testing, mais qui par définition, n'est pas donné comme stable...

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
...............
...............
...............
...............
...............
aaaaaaaaaaaaaaaaaaaa






pfffffff. non mais sérieux, quoi.
fin bref, on verra demain, mais ça devrait être plus cohérent...

Kékiya ?

Nouveau stagiaire ?

non un ancien, je pense.

yyy.cpp :
include "xxx.cpp"

• Pen^2 travaille sur xxx.cpp

c'est curieux, mes modifs ne sont pas souvent prises en compte... Ah tiens, c'est pris en compte quand je rebuilde tout. Ah tiens, le contenu de xxx.cpp est déjà dans yyy.o et le reste est ignoré.

=> ./1964

Dépendance manquante dans le makefile. FAIL.

Et l'include d'un fichier .cpp, ça ne te choque pas ?

C'est très moche et je me suis battu contre ça (avec des .c ou des .s/.asm) dans le contexte de TIGCC. En C++, il y a quand-même le cas des templates où l'inclusion est inévitable, mais dans ce cas, l'extension .cpp est mal choisie, il vaut mieux appeler le fichier *.hpp ou *-impl.h ou *-impl.hpp. Mais même dans ce cas, il faut une dépendance pour que ça marche correctement. Ou alors on utilise CMake qui détecte ces dépendances automatiquement.

Ça se fait les include .cpp, si tu as commencé sur des systèmes bas niveau et un peu absents de conception (pour rester poli ) ça ne te choque pas forcément de faire ça ^^

./1969 et ./1970
Oué, c'est pas tant une histoire de dépendance que d'inclusion débile, et en plus je ne vois rien qui la justifie.
Ajouter une dépendance d'un cpp vers un autre, au mieux je dirais que c'est un marche autour %o

(concernant les hpp, il y a une fonctionnalité prévue dans le cpp, ils suffirait qu'elle soit implémentée au lieu d'obliger les gens à faire des trucs moisis)

Brunni > bof, si moi ça me choque, et en plus c'est dangereux, la preuve.

dangereux non, ne pas avoir le comportement auquel tu pense oui.

Pour toi c'est pas un comportement dangereux d'avoir une implémentation prise en compte selon la manière dont tu compiles ?

Ce n'est pas selon la maniere dont tu compile.

C'est un bug, mais ce n'est pas dangeureux.

1 - tu t'en rends compte rapidement
2 - quand tu build ton projet pour release tu es sensé faire un clean build, tes outils d'integration doivent aussi faire la meme chose, donc le probleme est de TON cote, c'est toi qui est emmerdé.

Ca reste un bug, au pire du makefile, au mieux du projet, include un .c/.cpp ne doit etre fait que de maniere claire et explicite, et le makefile doit aussi s'assurer que si le fichier source inclue est change, tout est mis a jour.

Mais on est d'accord, ce n'est pas normal et ton .cpp devrait etre integre comme n'importe quel autre fichier:

.cpp -> .o -> linker

Pen^2 (./1972) :
(concernant les hpp, il y a une fonctionnalité prévue dans le cpp, ils suffirait qu'elle soit implémentée au lieu d'obliger les gens à faire des trucs moisis)

Si tu parles de l'export de templates, pratiquement aucun compilateur n'implémente cette partie du standard (et elle a été retirée du C++11).

Pen^2 (./1972) :
Brunni > bof, si moi ça me choque, et en plus c'est dangereux, la preuve.

C'est un bug du makefile qui rend ça dangereux, ça n'a rien de dangereux en réalité. Le souci avec ça c'est juste que c'est un truc possible mais pas franchement justifiable en temps normal, donc à interdire par convention car ça rend la lecture/navigation compliquée je dirais. Mais ce n'est pas dangereux.

Godzil (./1975) :
tu t'en rends compte rapidement

Pas tant que ça, c'est une config dll jni un peu pénible expérimentale, et je ne voyais pas pourquoi mes différences subtiles n'étaient pas prises en compte. J'ai fini par faire des trucs de moins en moins subtils, et j'ai finalement compris. Mais j'ai perdu pas mal d'heures, donc si c'est dangereux.

Godzil (./1975) :
quand tu build ton projet pour release tu es sensé faire un clean build

Je ne vois pas pourquoi ?

Kevin Kofler (./1976) :
pratiquement aucun compilateur n'implémente cette partie du standard

Oui, et je ne vois pas pourquoi non plus, ça a une vraie utilité et c'est pas parce qu'il existe un workaround connu que c'est une bonne idée.

Kevin Kofler (./1976) :
(et elle a été retirée du C++11)

Ah... ? OK !

Brunni (./1977) :
C'est un bug du makefile qui rend ça dangereux

Oui, un peu comme tout, tant qu'il n'y a pas de problème c'est pas dangereux, mais bon.

Brunni (./1977) :
ça n'a rien de dangereux en réalité

Bah si, quand même, deux .o qui contiennent la même chose (ou presque la même chose ) c'est ultra malsain.

Pen^2 (./1978) :

Kevin Kofler (./1976) :
(et elle a été retirée du C++11)

Ah... ? OK !

Sous la pression de Microsoft (représenté par Herb Sutter) qui refuse catégoriquement d'implémenter ça parce que ça obligerait à mettre le code source (ou une représentation tokénisée facile à rétrocompiler) des templates exportés dans les fichiers objet, ce qu'ils considèrent une "menace" pour la "propriété intellectuelle" des développeurs (de logiciels propriétaires).

OK merci. Cela dit, il me semble que GCC ne l'implémentait pas non plus, si ?