Plus inattendue, la présence d'un README.SCO dans l'archive. Il contient une explication de la FSF à propos des accusations de SCO, non prouvées, et de leur demande d'obliger le paiement des licences, en violation de la GPL. Malgré les demandes reçues par la FSF de ne plus supporter SCO Unix avec GCC, et pour ne pas pénaliser les utilisateurs de ce système, il a été choisi de conserver le support, pour l'instant. Les utilisateurs de SCO Unix sont invités à faire entendre leurs protestations auprès de SCO.
Aller plus loin
- GCC (1 clic)
- Changelog de la série 3.3 (1 clic)
- Changelog de la série 3.4 (0 clic)
- README.SCO (1 clic)
- Un miroir français pour le téléchargement (1 clic)
# Re: Sortie de GCC 3.3.1
Posté par gloups . Évalué à 8.
Ce moyen est surement inattendu de la part de SCO et surement plus efficace dans le temps que les brevets et autre combats juridiques qui sont de l'ordre de quelques années.
Le libre peut avoir un réel moyen de pression en faisant priviléger d'autres OS...
[^] # Re: Sortie de GCC 3.3.1
Posté par Pascal Terjan (site web personnel) . Évalué à 10.
Ca leur fera pas grand mal si leur OS meurt alors qu'ils gagnent un procès. Si ils le perdent ils sont morts de toute façon...
[^] # Re: Sortie de GCC 3.3.1
Posté par jmfayard . Évalué à 10.
La décision de la FSF est très sage : SCO étant devenue une boîte d'avocats, ce n'est pas l'absence des dernières versions de (très bons) logiciels sur leurs machines dépassées qui va les géner. Par contre les quelques utilisateurs qui restent sur de tels machines le seraient effectivement.
La FSF n'adopte donc pas la tactique des majors du disque d'emmerder les gens honnêtes lorsqu'elle est attaquée par une bande de crétins.
Par contre le README.SCO et les prises de consciences && protestations que ça peut engendrer sont AMHA une bonne idée.
[^] # Re: Sortie de GCC 3.3.1
Posté par Aiua . Évalué à 9.
[^] # Re: Sortie de GCC 3.3.1
Posté par Nap . Évalué à 2.
[^] # Re: Sortie de GCC 3.3.1
Posté par undeuxtroisout . Évalué à 3.
[^] # Re: Sortie de GCC 3.3.1
Posté par jmfayard . Évalué à 5.
Ils ne disent pas par qui !
Ca peut être par la FSF, mais aussi par des libristes mécontents : il suffit de regarder slashdot, SCO y a largement détroné MS comme société la plus haïe et cette idée de boycotter SCO y est souvent avancée.
Bon de toute façon ce n'est pas trop important.
[^] # Re: Sortie de GCC 3.3.1
Posté par undeuxtroisout . Évalué à 9.
Par la FSF. Lis le paragraphe en entier.
Bon de toute façon ce n'est pas trop important.
Exactement. Tu as raison et c'est aussi ce qu'ils pensent.
C'est pour ça qu'ils ne pointent pas la FSF du doigt parce qu'alors il faudrait aussi mentionner les libristes acharnés,... et ils ne veulent apparemment pas lancer de polémique.
L'important pour GCC est d'affirmer leur soutient aux utilisateurs avant tout, même s'ils utilisent une plate-forme controversée.
Je trouve leur position raisonnable et respectueuse, et donc respectable.
[^] # Re: Sortie de GCC 3.3.1
Posté par ptit_tux . Évalué à 1.
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00214.html(...)
Désolé pour le post plus bas.
[^] # Re: Sortie de GCC 3.3.1
Posté par Yusei (Mastodon) . Évalué à 3.
overriding goal is to protect the freedom of the free software
community, including developers and users, but we also want to serve
users.
Ils semblent parler au nom de la FSF, pas au nom de l'équipe GCC. Et ils ne disent pas qui leur a demandé de ne plus supporter SCO Unix.
[^] # Re: Sortie de GCC 3.3.1
Posté par Aiua . Évalué à 2.
[^] # Re: Sortie de GCC 3.3.1
Posté par undeuxtroisout . Évalué à 3.
"FSF" == eux, ils
Ils ne parlent pas au nom de la FSF, ce serait incorrect et impoli.
C'est un message de GCC dans lequel ils clarifient leur position et mentionnent la position de la FSF.
[^] # Re: Sortie de GCC 3.3.1
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Sortie de GCC 3.3.1
Posté par ptit_tux . Évalué à 1.
[^] # Re: Sortie de GCC 3.3.1
Posté par ptit_tux . Évalué à 2.
[^] # Re: Sortie de GCC 3.3.1
Posté par ptit_tux . Évalué à -1.
J'ai pas vu ça :
The Free Software Foundation's overriding goal is to protect the freedom of the free software community, including developers and users, but we also want to serve users.
De plus :
We will have a further announcement concerning continuing support of SCO Unix
by GCC before our next release.
C'est "We" et non "The Free Software Foundation".
J'ai vu sur la mailing-list gcc, que certains développeurs de gcc étaient assez chaud par rapport à SCO (le début du thread) :
http://gcc.gnu.org/ml/gcc/2003-07/msg01564.html(...)
# Objective-C (++)
Posté par jmfayard . Évalué à 7.
Dommage pour Nicolas Roard, Fabien Vallon et les autres gourous GNUstep ;-)
[^] # Re: Objective-C (++)
Posté par MagicNinja . Évalué à 4.
Comme ca on aura peut etre un WebCore pour GNUstep. En passant, la nouvelle version de OmniWeb utilise dorenavant WebCore et JavaScriptCore.
[^] # Re: Objective-C (++)
Posté par Jak . Évalué à 2.
La raison en est simple : la version 3.4 a déjà passé le stage 1, c'est-à-dire le moment (si j'ai bien suivi la façon dont est géré le processus de décision pour gcc) où l'on décide ce qu'on va rajouter dans cette version. C'est trop tard donc pour y inclure l'ObjC++.
[^] # Re: Objective-C (++)
Posté par spell (site web personnel) . Évalué à -1.
comme c'est original !
vice-versa
[^] # Re: Objective-C (++)
Posté par Nap . Évalué à 2.
[^] # Re: Objective-C (++)
Posté par imr . Évalué à 0.
"et vice à versailles, sana!"
[^] # Re: Objective-C (++)
Posté par jmfayard . Évalué à -2.
[^] # Re: Objective-C (++)
Posté par let antibarbie = xp <- xp - 1 . Évalué à 0.
ok ok... je sors -> []
[^] # Re: Objective-C (++)
Posté par syntaxerror . Évalué à 4.
[^] # Re: Objective-C (++)
Posté par beb . Évalué à 2.
[^] # Re: Objective-C (++)
Posté par Philip Marlowe . Évalué à 2.
[^] # Re: Objective-C (++)
Posté par pikachu . Évalué à 10.
# Re: Sortie de GCC 3.3.1
Posté par Elrik de Melnibone . Évalué à 7.
[^] # Re: Sortie de GCC 3.3.1
Posté par Nap . Évalué à 6.
[^] # Re: Sortie de GCC 3.3.1
Posté par skimmy . Évalué à 5.
[^] # Re: Sortie de GCC 3.3.1
Posté par Pascal Terjan (site web personnel) . Évalué à 4.
[^] # Re: Sortie de GCC 3.3.1
Posté par yosch . Évalué à 4.
"Because ed is the standard editor!"
http://gnuwww.epfl.ch/fun/jokes/ed.msg.html(...)
Et les über-moules mettent ça dans leur .emacs:
http://www.emacswiki.org/cgi-bin/wiki.pl/ViQuit(...)
[^] # Re: Sortie de GCC 3.3.1
Posté par skimmy . Évalué à 1.
[^] # Re: Sortie de GCC 3.3.1
Posté par izn0g . Évalué à 2.
D'ailleurs, je me fade directement les binaires, pour éviter tous les étages de la compilation de gcc 3.3.1, et hop ! in topic.
[^] # Re: Sortie de GCC 3.3.1
Posté par wismerhill . Évalué à 2.
Y a que les newbie qui enregistrent leur programmes, les vrai geek dialoguent directement en binaire avec le processeur.
[^] # Re: Sortie de GCC 3.3.1
Posté par Tonton Th (Mastodon) . Évalué à 3.
[^] # Re: Sortie de GCC 3.3.1
Posté par un_brice (site web personnel) . Évalué à 2.
# Re: Sortie de GCC 3.3.1
Posté par pikachu . Évalué à -1.
# Re: Sortie de GCC 3.3.1
Posté par Jean-Philippe COMBE . Évalué à 3.
ouais, y'en a meme des milliers :
je vous en donne seulement 2 qui ont été dupliquées des tas de fois :
1ère ligne : {
2ème ligne : }
mais par contre dans MultiDeskOS y'en a pas !,
pas fou l'autre, il a mis
1ère ligne : begin
2ème ligne : end;
il ne prend pas de risques d'être attaqué par SCO, pas folle la guêpe !
[^] # Re: Sortie de GCC 3.3.1
Posté par Dugland Bob . Évalué à 1.
et pourtant : http://groups.google.com/groups?q=author:support%40multideskos.com&(...)
[^] # Re: Sortie de GCC 3.3.1
Posté par thedidouille . Évalué à 3.
if(...) {
...
} /*FucKSCO*/
# Re: Sortie de GCC 3.3.1
Posté par linuxidable . Évalué à -1.
j'ai un problème pour porter du code C++ de windows vers unix avec gcc 3.2.3, ça conserne les iterators de map de la stl, voilà l'erreur :
In member function `void
no match for `
std::_Rb_tree_iterator<std::pair<const _bstr_t, maClasse*>,
std::pair<const _bstr_t, maClasse*>&, std::pair<const _bstr_t,
maClasse*>*>& = void' operator
/usr/local/include/c++/3.2.3/bits/stl_tree.h:184: candidates are:
std::_Rb_tree_iterator<std::pair<const _bstr_t, maClasse*>,
std::pair<const _bstr_t, maClasse*>&, std::pair<const _bstr_t,
maClasse*>*>& std::_Rb_tree_iterator<std::pair<const _bstr_t,
maClasse*>, std::pair<const _bstr_t, maClasse*>&,
std::pair<const _bstr_t, maClasse*>*>::operator=(const
std::_Rb_tree_iterator<std::pair<const _bstr_t, maClasse*>,
std::pair<const _bstr_t, maClasse*>&, std::pair<const _bstr_t,
maClasse*>*>&)
Si ça vous dit quelque chose et que vous pouvez apporter une réponse à ma question, je serais super content :o)
[^] # Re: Sortie de GCC 3.3.1
Posté par Caeies . Évalué à 2.
J'ai déja eu ce type de message dans le cas ou je faisais de l'héritage multiple sur des classes instantiable, il ne savait pas quelle fonction choisir (alors qu'à priori ce sont les mêmes !)
Donc il faut que tu spécifie l'une des classes desquelles tu hérites.
Si tu n'as pas fait un héritage multiple, ben je sais pas ...
Caeies, onnepeutplusclair :)
[^] # Re: Sortie de GCC 3.3.1
Posté par linuxidable . Évalué à 2.
> Bon même si c'est pas le lieu pour répondre :)
Personnellement, ça ne me choque pas plus que ça :o). Après tout, DLFP ça peut aussi être utile et puis on n'est pas si hors-sujet que ça :).
[^] # Re: Sortie de GCC 3.3.1
Posté par Snark_Boojum . Évalué à 1.
* le C++ n'est pas fait pour faire de l'objet, ça se saurait depuis le temps qu'il existe; il faut plutôt utiliser Eiffel, Java ou Objective C;
* la STL, pour qu'elle marche bien, il faudrait la porter dans un langage objet, en l'état il ne faut pas compter dessus, voir problème précédent;
* de toutes façons, on ne porte pas du code depuis une plateforme impure , on le réécrit complètement!
Où ça un troll?!
[^] # Re: Sortie de GCC 3.3.1
Posté par Moby-Dik . Évalué à -1.
[^] # Re: Sortie de GCC 3.3.1
Posté par Epsos . Évalué à 1.
Il te dit qu'il essaie de chercher un operateur du style
Iterator::operator =(void)
alors qu'il ne connait que :
Iterator& Iterator::operator=(const Iterator &)
Bref, ton membre de droite a l'air d'etre a l'ouest dans une expression comme
Iterator it = expression
[^] # Re: Sortie de GCC 3.3.1
Posté par Nap . Évalué à 3.
forcément y a une erreur
[^] # Re: Sortie de GCC 3.3.1
Posté par linuxidable . Évalué à 1.
iteratorDeMaClasse = mapDeMaClasse.erase(iteratorDeMaClasse);
Le problème ce situe apparament sur la méthode erase qui retour un iterator sur l'objet suivant de la liste alors qu'avec la glibstdc++ elle ne retourne rien. En tout cas merci pour ton aide.
[^] # Re: Sortie de GCC 3.3.1
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
Page 491 of the standard gives three overloaded members 'erase' for
std:map:
void erase(iterator position);
size_type erase(const key_type& x);
void erase(iterator first, iterator last);
A map is an associative container, and page 466 gives requirements for
associative containers. There are three 'erase's, which are the same as
the above but ordered 2,1,3.
According to the text on page 490, a map also meets the requirements of a
container and of a reversible container (subclause 23.1) and "most
operations described in (23.1.2) for unique keys. This means that a map
supports the a_uniq operations but not the a_eq operations."
There is an erase member function that returns an iterator, but it is for
sequence containers (vector, list, deque, page 462, subclause 23.1.1),
not maps.
[^] # Re: Sortie de GCC 3.3.1
Posté par linuxidable . Évalué à 2.
donc, pour parcourir une map et y supprimer des éléments, je suis obligé de faire :
monTypeDeMap::iterator monIterator1;
monTypeDeMap::iterator monIterator2;
monIterator1 = maMap.begin();
while (monIterator1 != maMap.end()){
if (...){
monIterator2 = monIterator1++;
maMap.erase(monIterator2);
}
else
monIterator1++;
}
C'est un peu lourd :-(
[^] # Re: Sortie de GCC 3.3.1
Posté par Epsos . Évalué à 3.
Deux choses :
1- la STL sous windows n'est pas standard, donc lorsque tu fais un port tu peux t'apercevoir que tu as utilise des trucs pas standard : utilise une implementation standard des STL comme la STLport par exemple.
2 - evites de parcourir une map avec des iterateurs et de les effacer au fur et a mesure. En effet lorsque tu efface un iterateur d'un container, tu risques de modifier la structure du container, et donc tu invalides tes autres iterateurs : si tu fais des traitements avec des iterateurs non valide, tu vas voir apparaitre des bugs que tu auras du mal a localiser. (memoire corrompu entre autre)
Dans le cas qui t'interresse, il vaut mieux que tu construise une deuxieme map avec les elements que tu souhaites garder, en dupliquant tes enregistrements. Ensuite tu n'as plus qu'a detruire ta premiere map.
[^] # Re: Sortie de GCC 3.3.1
Posté par _ _ . Évalué à 1.
La STL founie avec Visual C++ vient en fait de DINKUMWARE. Pour citer leur page :
" Needless to say, the Dinkum C++ Library is the only completely conforming option today. It easily outdistances Libstdc++ from Project Gnu, STLport, and the latest releases of the Rogue Wave library."
Bon comme ça vient de leur site, on pourrait prendre ça pour de la pub, mais ça doit être vrai je pense car cette lib a bonne réputation.
utilise une implementation standard des STL comme la STLport par exemple.
Donc, en fait les problèmes de "standard compliance" ne viennent pas de la librarie directement mais plutôt du compilateur.
[^] # Re: Sortie de GCC 3.3.1
Posté par Guillaume Laurent (site web personnel) . Évalué à 5.
- Generic Programming and the STL. Matt Austern, ISBN 0201309564.
- The C++ Standard Library : A Tutorial and Reference. Nicolai M. Josuttis. ISBN 0201379260.
(plutôt le 2eme)
tu trouvera des exemples sur comment faire ce que tu veux.
C'est un peu lourd :-(
C'est la STL. Au début je trouvais l'abstraction iterateurs/conteneurs/algorithmes géniale, depuis j'en suis un peu revenu. Ça permet de faire des trucs très sioux, mais ça complexifie aussi beaucoup trop des choses qui devraient être simples (comme celle ci).
[^] # Re: Sortie de GCC 3.3.1
Posté par linuxidable . Évalué à 1.
monTypeDeMap::iterator monIterator;
monIterator = maMap.begin();
while (monIterator != maMap.end()){
if (...){
maMap.erase(monIterator);
}
monIterator++;
}
...mais à vous écouter ça n'a pas l'air d'être une bonne idée. J'ai testé sous windows et ça marche... autrement dit, ça ne m'inspire pas confiance du tout :o).
C'est la STL. Au début je trouvais l'abstraction iterateurs/conteneurs/algorithmes géniale, depuis j'en suis un peu revenu. Ça permet de faire des trucs très sioux, mais ça complexifie aussi beaucoup trop des choses qui devraient être simples (comme celle ci).
Je suis tout à fait d'accord, la STL c'est bien, en abuser ça craint.
[^] # Re: Sortie de GCC 3.3.1
Posté par Moby-Dik . Évalué à 0.
# Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: fortran 95
Posté par med . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.