Problem with gr-error-correcting-codes/src/lib/libecc

I’m getting a compile time error with gr-error-correcting-codes in
libecc:

code_convolutional_trellis.cc:293: error: no match for ‘operator=’ in
‘t_fb_generators_soai =
((code_convolutional_trellis*)this)->code_convolutional_trellis::d_code_feedback’
/usr/lib/gcc/i486-linux-gnu/4.0.3/…/…/…/…/include/c++/4.0.3/bits/vector.tcc:133:
note: candidates are: std::vector<_Tp, _Alloc>& std::vector<_Tp,
_Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = unsigned
int, _Alloc = std::allocator]
code_convolutional_trellis.cc:353: error: no match for ‘operator=’ in
‘((code_convolutional_trellis*)this)->code_convolutional_trellis::d_code_feedback
= t_fb_generators_soai’
/usr/lib/gcc/i486-linux-gnu/4.0.3/…/…/…/…/include/c++/4.0.3/bits/vector.tcc:133:
note: candidates are: std::vector<_Tp, _Alloc>& std::vector<_Tp,
_Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = long
unsigned int, _Alloc = std::allocator]

Then there are several more like this:

code_convolutional_trellis.cc: In member function ‘void
code_convolutional_trellis::create_trellis()’:
code_convolutional_trellis.cc:573: error: call of overloaded
‘n2bs(memory_t&, size_t&)’ is ambiguous
./mld/n2bs.h:27: note: candidates are: std::string n2bs(char, size_t)
./mld/n2bs.h:28: note: std::string n2bs(int, size_t)
./mld/n2bs.h:29: note: std::string n2bs(long int,
size_t)
./mld/n2bs.h:30: note: std::string n2bs(size_t, size_t)
./mld/n2bs.h:31: note: std::string n2bs(long long int,
size_t)

If I ‘make -k’ it will continue and successfully compile and link
everything else in libecc directory (encoder.o, decoder.o, and
code_metrics.o all show up in .libs).

This is with latest CVS but it looks like the file date is July 20.

Might this be a problem with GCC 4.0.3?

-Johnathan

(1) gr-ecc is a work in progress and really doesn’t do anything yet.
The encoder seems to work (passes the basic QA tests), and is hooked
into a gr_block (soon to be called
“ecc_streams_encode_convolutional”), but none of the decoder stuff
has been verified to function yet. I’m working on it as quickly as
time allows, and I -will- have this stuff operational in a couple of
weeks. Stay tuned.

(2) The error you get is when copying a std::vector into another via
“=”, instead of copying individual elements. Before the copy I do a
vector.resize(old_vector.size()), to make sure there’s storage space,
and this seems to work for me (OSX 10.4.7, XCode 2.3, gcc 4.0.1). I
think it’s been working for Eric too, once I (via his help)
determined that I wasn’t doing the “resize” and I added that code.
vectors are still a bit of a mystery to me, but they work really well
once you get them going.

What OS are you trying the compile under?

(3) I’ve just checked in the latest version (decoder stuff still
doesn’t work, but the rest is starting to take over the duties of the
decoder slowly but surely). I was on vacation from July 21 to 29,
but I did some good work during that time. Could you try updating
the code & recompiling it?

If there are still errors, I can certainly move to copying individual
elements instead of the “=”, but it’s so much cleaner this way. - MLD

Michael D. wrote:

(2) The error you get is when copying a std::vector into another via
“=”, instead of copying individual elements.

I’m not familiar enough with the standard library to know whether this
is “proper”; it looks like it would be very convenient.

What OS are you trying the compile under?

This is Ubuntu Linux 6.06, using gcc 4.0.3.

(3) I’ve just checked in the latest version (decoder stuff still doesn’t
work, but the rest is starting to take over the duties of the decoder
slowly but surely). I was on vacation from July 21 to 29, but I did
some good work during that time. Could you try updating the code &
recompiling it?

Will do.

If there are still errors, I can certainly move to copying individual
elements instead of the “=”, but it’s so much cleaner this way. - MLD

My gut still thinks there is some compiler related issue as I’d be
surprised something would work under 4.0.1 but not work in 4.0.3. I’ll
let you know how it goes with the new code.

-Johnathan

Johnathan C. wrote:

Michael D. wrote:

(3) I’ve just checked in the latest version (decoder stuff still doesn’t
work, but the rest is starting to take over the duties of the decoder
slowly but surely). I was on vacation from July 21 to 29, but I did
Could you try updating the code & recompiling it?

Will do.

Unfortunately, even with a cvs update of the stuff you just checked in,
it fails in the identical way–what compiled successfully before still
does, and the failure messages are the same.

-Johnathan

On Tue, Aug 01, 2006 at 11:41:10AM -0700, Johnathan C. wrote:

'((code_convolutional_trellis*)this)->code_convolutional_trellis::d_code_feedback
code_convolutional_trellis.cc:573: error: call of overloaded
everything else in libecc directory (encoder.o, decoder.o, and
code_metrics.o all show up in .libs).

This is with latest CVS but it looks like the file date is July 20.

Might this be a problem with GCC 4.0.3?

Don’t think so. I get the same problem with gcc 4.0.2 on x86.
It does work for me on x86-64 with g++ 3.3.5, but it’s 64-bit. The
ambiguity may be being caused by different widths for the different
types under different architectures.

Eric

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs