stl::vector - Page 1

Quand j'utilise pas stl, je me fais engueuler. Alors j'ai décidé de l'utiliser.
Sauf que là, je vois pas qui alloue quoi et quand. Je vais devoir préferer à coder les trucs de base moi même. Sauf si vous m'aidez

Je veux faire une classe qui contien un vector, c'est pas compliqué... normalement.

); }

Dans void GraphLoc::generateInstance(){
vector<IloBoolVarIndexe > xEdgeArr;
vector<IloBoolVarIndexe > xVertArr;
...
xEdgeArr.push_back(x_aux

je veux que les deux vector soient des membres de ma classe GraphLoc (pour que je puisse les utiliser dans les autres fonctions membre de la classe). Alors je les mets en attribut dans la définition de la classe dans le .hpp. Ca compile. Mais dès que j'execute xEdgeArr.push_back(x_aux); ca SegFault.

Explication?

ps: J'ai aussi essayé pas mal de bidouillage avec des new meme si logiquement je devrais pas avoir besoin... mais bon je vois pas ce qui se passe là, qui est pointeur, qui l'est pas.. Qu'est-ce qu'un vector "vide" crée juste avec la déclaration comme ca..

Ok c'est gcc qui pue.
make clean, make
et ca marche (y)

et vive microsoft! (qui eux savent faire un vrai compilo)

c koi le rapport avec gcc ?

ça link sans broncher des vieux fichiers... faudrait au moins des warnings.
Mais c'est vrai que c'est plus un pb d'IDE.

c'est peut etre un probleme de make, j'ai un bon makefile.

J'ai jamais eu ce genre de probleme sous Visual Studio. Là on atteint le ridicule franchement.

Tu as peut être rien codé de plus 3 lignes avec Visual Studio?

lol, si si

Il manque des dépendances dans ton makefile (les fichiers .o ne doivent dépendre pas seulement du .cpp correspondant, mais aussi de tous les .hpp que ce .cpp inclut). La manière la plus simple de réaliser ça est la règle simple (qui est aussi celle de TIGCC IDE): tous les .o dépendent de tous les .h/.hpp. Mais tu peux faire plus fin (mais plus difficile à maintenir) si tu vérifies exactement quels .cpp incluent quels .hpp.

il n'existe aucun outil de calcul de dépendances?

makefile?

automake aussi.

qmake aussi, et c'est plus facile à utiliser.

Si tu veux oui. Mais je préfère automake qui s'intégre mieux avec autoconf, libtool et autolibs. (et autoreconf, j'allais l'oublié)

Sinon pour ./6, c'est parce que Visual Studio génère à la volée le bon Makefile.
Mais tu me diras qu'un bon Makefile peut se mettre à jour à la volée automatiquement aussi. Par exemple (de tête, je me rappelle plus comment c'était exactement) :

.depend:
      gcc -M *.c > .depend
include .depend

Je sais bien. C'est pas magique, y a bien quelque chose qui regarde les dépendances et les modifications un moment ou un autre. Mais pourquoi c'est un bordel monstre sous linux? Et pourquoi ca marche mal?? Ca m'enerve qu'on critique MS à tout bout de champ alors qu'il faut rendre à César ce qui est à César.

Je vous posterai le makefile lundi.

Bah, c'est parce que tu n'utilises pas les bons outils, c'est extrèmement facile avec qmake, tu lui donnes une liste de tes sources et une liste de tes headers et ça t'autogénère un makefile avec les bonnes dépendances partout.

onur (./17) :
Mais pourquoi c'est un bordel monstre sous linux? Et pourquoi ca marche mal??

Parce que linux a pris le parti de laisser à l'utilisateur la liberté d'utiliser l'outil qu'il souhaite pour créer son makefile.
Sous Win tu es contraint d'utiliser le générateur automatique de visual studio.

Enfin, il n'est pas vraiment contraint, qmake marche très bien sous Window$ par exemple.

Bien sûr, mais on retombe sur les mêmes problèmes : plus l'outil qu'on utilise fait de chose à notre place, moins on peut faire de choses différentes avec.
Autrement dit, on perd en flexibilité.

onur (./17) :
Je sais bien. C'est pas magique, y a bien quelque chose qui regarde les dépendances et les modifications un moment ou un autre. Mais pourquoi c'est un bordel monstre sous linux? Et pourquoi ca marche mal?? Ca m'enerve qu'on critique MS à tout bout de champ alors qu'il faut rendre à César ce qui est à César.

Parce que sous Linux on préfère utilise un outil pour chaque chose et les combiner ensemble plutôt qu'un outil centralisé.
C'est essentiellement ca.

Et si tu veux du "tout fait pour toi", on a aussi des solutions pour ça, genre KDevelop.

onur (./6) :
J'ai jamais eu ce genre de probleme sous Visual Studio. Là on atteint le ridicule franchement.

Ce que je ne comprends pas trop c'est pourquoi tu t'embêtes à utiliser des outils que tu ne maîtrises pas alors que tu peux le faire avec vs que tu sembles maîtriser ? Si c'est le côté logiciels libres, je comprends, mais alors fais l'effort de lire les manuels de tes outils... (ou au moins des tutos, car là c'est la base quand même).

Soit dit en passant, VS fait exactement la même chose. Il génère un makefile (au format propriétaire nmake, mais globalement ça fonctionne pareil).
Btw, KDevelop fait la même chose, il te génère tes makefiles automatiquement avec toutes les dépendances.

Autre différence: L'un marche, l'autre pas.

c'est quoi la flexibité dont vous parlez? Sous vs, tu peux aussi choisir tes options comme un grand si tu t'y connais.

Ben tu trouves aussi des outils équivalents sous linux.
Mais en général, plus un outil fait de choses à ta place, moins tu peux les paramétrer (sinon tu passes ton temps à le paramétrer et ça gave).

Ok. Il se trouve que là j'avais pas spécialement le choix (je fais tout ca dans le cadre d'un stage).

Voici le makefile dont vous aviez toujours revé :P

SYSTEM     = x86_rhel4.0_3.4
LIBFORMAT  = static_pic

CPLEXDIR      = /usr/local/cplex-10.0
CONCERTDIR    = /usr/local/concert-2.2

CCC = g++
LD = $(CCC)

#CPPFLAGS= -g -DNDEBUG -O3 -funroll-loops -Wall $(INCLUDES_PATH)
CPPFLAGS= -g  $(INCLUDES_PATH) -Wno-deprecated -DILOUSESTL -DIL_STD -ILOSTRINGSTL

CPLEXLIBDIR   = $(CPLEXDIR)/lib/$(SYSTEM)/$(LIBFORMAT)
CONCERTLIBDIR = $(CONCERTDIR)/lib/$(SYSTEM)/$(LIBFORMAT)
LIBIO_DIR     := /export/shop/stow/libIo-1.4.8
BOOST_DIR     := /export/shop/stow/boost-1.32.0
GETTEXT_DIR   := /export/shop/stow/gettext-0.14.5

LIBS_PATHS     := -L$(LIBIO_DIR)/i686-pc-linux-gnu/g++-4.0.2/lib \
-Wl,-rpath=$(LIBIO_DIR)/i686-pc-linux-gnu/g++-4.0.2/lib \
-L$(CPLEXLIBDIR) \
-L$(CONCERTLIBDIR) \
-L$(GETTEXT_DIR)/i686-pc-linux-gnu/lib \
-Wl,-rpath=$(GETTEXT_DIR)/i686-pc-linux-gnu/lib
LIBS    = -lintl -lIo -lz -lbz2 -lilocplex -lcplex -lconcert -lm -lpthread -lz -lbz2 -lilocplex -lcplex -lconcert -lm -lpthread -lIo -lintl

INCLUDES_PATH  := -I$(LIBIO_DIR)/i686-pc-linux-gnu/include \
-I$(CPLEXDIR)/include \
-I$(CONCERTDIR)/include \
-I$(BOOST_DIR)/include/boost \
-I$(GETTEXT_DIR)/include

SRC := main.cpp GraphLoc.cpp IloBoolVarIndexe.cpp IloIntVarIndexe.cpp IloNumVarIndexe.cpp CoverCut.cpp

OBJS := $(patsubst %.cpp,%.o,$(SRC))

localiz: $(OBJS)
	$(LD) -o $@ $(LIBS_PATHS) $(OBJS)  $(LIBS)

%.o: %.cpp
	$(CCC) -c $(CPPFLAGS) $<

clean:
	rm -f localiz $(OBJS)

En utilisant automake/autoconf, ton Makefile.am devient ça :

bin_PROGRAMS = localiz
localiz_SOURCES = main.cpp GraphLoc.cpp IloBoolVarIndexe.cpp IloIntVarIndexe.cpp IloNumVarIndexe.cpp CoverCut.cpp

Et éventuellement la ligne suivante à ajouter, ça dépend de comment ta lib se paramètre :
localiz_CPPFLAGS = -DILOUSESTL -DIL_STD -ILOSTRINGSTL

Mais tu n'as pas mis le configure.ac de 1000 lignes qui va avec.

Plus sérieusement, il faut au minimum des entrées dans configure.ac et/ou Makefile.am pour chacune des 5 libs qu'il utilise, sinon ça ne va pas marcher. Et il y a aussi quelques lignes minimum que tout configure.ac utilisable avec automake doit avoir.