Sto cercando di compilare un pacchetto software C++ che è stato scritto nel 2007 e sto ottenendo questo errore:'uint32_t' non citarne tipo
error: ‘uint32_t’ does not name a type
Questo sta accadendo a 64 bit Ubuntu che usa g ++ 4.5.2. Compila bene su CentOS a 64 bit usando g ++ 4.1.2.
C'è un #include o un flag di compilatore che mi manca? Oppure, dovrei usare typedef per assegnare uint32_t a size_t o forse a unsigned int?
è necessario includere stdint.h
#include <stdint.h>
L'intestazione C++ "corretta" sarebbe 'cstdint'. – paxdiablo
Nota, nel mio caso il problema era in realtà che l'inclusione' boost/cstdint.hpp' non è stata trovata. boost-devel' risolto il mio caso – snooze92
@paxdiablo non dovrebbe il cstdint.h essere incluso in un extern "C" {} blocco? – StarShine
È necessario #include <cstdint>, ma potrebbe non funzionare sempre.
Il problema è che alcuni compilatori spesso esportano automaticamente i nomi definiti in varie intestazioni o tipi forniti prima che tali standard fossero in vigore.
Ora, ho detto "potrebbe non funzionare sempre". Questo perché l'intestazione cstdint fa parte dello standard C++ 11 e non è sempre disponibile sui compilatori C++ correnti (ma spesso lo è). L'intestazione stdint.h è l'equivalente C e fa parte di C99.
Per la massima portabilità, è consigliabile utilizzare l'intestazione di Boost boost/cstdint.hpp, se si desidera utilizzare boost. Altrimenti, probabilmente sarai in grado di farla franca con # include'ing <cstdint>.
Questo mi ha dato '#error Questo file richiede il supporto di compilatori e librerie per il prossimo standard ISO C++, C++ 0x. Questo supporto è attualmente sperimentale e deve essere abilitato con le opzioni del compilatore -std = C++ 0x o -std = gnu ++ 0x. – rmtheis
Destra, come si dice, cstdint fa parte del nuovo standard C++ (che è stato chiamato C++ 0x ma non è, ufficialmente, C++ 11. Quindi, per usare quell'intestazione, devi abilitare il nuovo standard in g ++. Come ho detto, il modo migliore per ottenere questi tipi è usare Boost o qualche altro intestazione equivalente, piuttosto che fare affidamento sul supporto del compilatore – plasma
Le altre risposte presuppongono che il compilatore è C++ 11 compliant. Va bene, se lo è. Ma cosa succede se si utilizza un compilatore più vecchio?
Ho raccolto il seguente trucco da qualche parte sulla rete. Funziona abbastanza bene per me:
#if defined __UINT32_MAX__ or UINT32_MAX
#include <inttypes.h>
#else
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned long uint32_t;
typedef unsigned long long uint64_t;
#endif
Non è portatile, ovviamente. Ma potrebbe funzionare per il tuo compilatore.
Aggiungere quanto segue nel file base.mk. Il seguente terza linea è importante -include $(TOP)/defs.mk
CFLAGS=$(DEBUG) -Wall -W -Wwrite-strings
CFLAGS_C=-Wmissing-prototypes
CFLAGS_CXX=-std=c++0x
LDFLAGS=
LIBS=
per evitare il #error Questo file richiede il supporto del compilatore e la biblioteca per il moderno standard ISO C++, C++ 0x. Questo supporto è attualmente sperimentale e deve essere abilitato con -std = C++ 0x o -std = gnu ++ 0x opzioni del compilatore
La domanda non dice se Make è in uso. Una risposta più portabile dovrebbe solo dire quali flag passare al compilatore (e quale compilatore sei un ssuming). –
Ho anche riscontrato lo stesso problema su Mac OSX 10.6.8 e purtroppo aggiungo #include <stdint.h> o <cstdint.h> nel file corrispondente non ha risolto il mio problema. Tuttavia, dopo ulteriori ricerche, ho trovato questa soluzione che consigliava di aggiungere #include <sys/types.h> che ha funzionato bene per me!
se è successo quando si include l'intestazione opencv.
Vorrei raccomandare che cambi l'ordine delle intestazioni.
posiziona le intestazioni opencv appena sotto l'intestazione standard del C++.
come questo:
#include<iostream>
#include<opencv2/core/core.hpp>
#include<opencv2/highgui/highgui.hpp>
ho avuto tha stesso problema cercando di compilare un lib ho scaricato da internet. Nel mio caso, c'era già uno #include <cstdint> nel codice. Ho risolto il problema aggiungendo:
using std::uint32_t;
@Daniel È ancora necessario "# includere" l'intestazione corretta prima di poter accedere al tipo. – cubrr
Sì, è necessario "# include". Non ho detto che non lo è. Ma poiché nel mio caso si trattava di un "#include
Aggiungere quanto segue nel file base.mk. La seguente terza riga è importante -include $ (TOP) /defs.mk
CXXFLAGS = -g -std=c++11 -O3 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long $(THREADSCXXFLAGS)
Cerca intestazioni stdint.h o. Quel tipo è (a quanto ho capito) parte di C99 ma non è stato convertito in C++. –
Hai '#include'? Sembra un possibile bug su Ubuntu 64 bit. Inoltre, hai un '-std = C++ 98' o qualche opzione della riga di comando per gcc? Se è così, puoi controllare se compila bene se usi '-std = gnu ++ 98'? –
dirkgently
@dirkgently Ho controllato il Makefile e non c'erano opzioni 'std'. – rmtheis