*gngn* where was the original discussion at? (shouldn't it belong into programming in first place?)
fleeb, I get this:
gcc base_xx.cpp -o test1
In file included from /usr/include/c++/4.5/unordered_map:35:0,
from base_64.h:18,
from base_xx.cpp:5:
/usr/include/c++/4.5/bits/c++0x_warning.h:31:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
In file included from base_xx.cpp:5:0:
base_64.h:285:12: error: 'unordered_map' in namespace 'std' does not name a type
base_64.h:476:4: error: 'char_lookup_t' does not name a type
base_64.h: In member function 'int tvr::decode::base_64::decode_value(char)':
base_64.h:451:10: error: '_alphabet_map' was not declared in this scope
base_64.h:455:5: error: 'char_lookup_t' has not been declared
base_64.h:455:35: error: expected ';' before 'found'
base_64.h:456:10: error: 'found' was not declared in this scope
base_64.h:456:19: error: '_alphabet_map' was not declared in this scope
base_64.h: In member function 'void tvr::decode::base_64::build_map()':
base_64.h:470:6: error: '_alphabet_map' was not declared in this scope
and the other one... no main?
gcc cdecode.c -o test
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 0 has invalid symbol index 11
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 1 has invalid symbol index 12
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 2 has invalid symbol index 2
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 3 has invalid symbol index 2
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 4 has invalid symbol index 11
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 5 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 6 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 7 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 8 has invalid symbol index 2
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 9 has invalid symbol index 2
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 10 has invalid symbol index 12
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 11 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 12 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 13 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 14 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 15 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 16 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 17 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 18 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 19 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 20 has invalid symbol index 20
/usr/lib/gcc/x86_64-linux-gnu/4.5.3/../../../../lib/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
Wed Jun 01 2011 04:53:31 EDT from dothebart @ Uncensored Subject: Re:*gngn* where was the original discussion at? (shouldn't it belong into programming in first place?)
I got very, very angry in programming a while ago, and zForgot it. This was the next best place.
fleeb, I get this:
gcc base_xx.cpp -o test1
In file included from /usr/include/c++/4.5/unordered_map:35:0,
from base_64.h:18,
from base_xx.cpp:5:
/usr/include/c++/4.5/bits/c++0x_warning.h:31:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
Yeah, I pointed out earlier that you might have a problem with my use of 'unordered_map'. It is the one thing that was potentially difficult here, but I needed to use unordered_map for the hash table (faster than a binary table). I could maybe create another kind of lookup table that doesn't require this, though, but it would potentially waste space instead. If you have boost, change #include to <boost/unordered_map.hpp> (or whatever it is) and it should be just fine. If you have tr1, use that instead. Otherwise, try using -std=c++0x as the compiler suggests.
and the other one... no main?
I thought I got that... there's supposed to be a main in base_xx.cpp. The DevStudio IDE love to use a version of main that provides for TCHARs instead of chars. Just change whatever the IDE created to a normal main and it should be fine (I'm not using any command line arguments anyway).
Maybe your code is small enough that it remains inside the data and
code buffers of the cpu, too?
I was thinking something like this. Perhaps more spinning variables end up in registers your way.
Well, the updated archive (with base32 and base16, not to mention some bugfixes) is on http://www.fleeb.com/base_xx if you're interested. It corrects the weird TCHAR main thing, but I'm still using unordered_map (at least until I can find something else that's fast but more available).
On a semi-related note, I found Tom Duff's comment on Duff's Device
amusing:
The only problem with duff's device is that it really isn't all that useful. It's very cute, but that's about it.
Well... it is useful in a very, very specific way. You can implement coroutines in C/C++ with them. So the problems solved best by co-routines are best solved with Duff's Device.
The way I heard it the first time was that duffs device allows you to jump into the middle of a loop so you don't have to handle a start/end case pile of code before or after the loop.
That sounds great from a pretty programming point of view, but duffs device isn't terribly pretty to look at, and what really matters is what it compiles into, which I haven't actually seen, so maybe it's a better deal.
Seems to me an optimizer would detect a copy of some code handling the after-loop case and end up with the same result as if you had written duffs device.
Wed Jun 01 2011 16:17:32 EDT from Spell Binder @ UncensoredIn a way, the case's in a switch statement are essentially go-to labels, so any situation that might require the flexibility of a label could probably be made somewhat more organized by using a switch statement instead.
For me, though, the more bizarre part is the way it continues within the loop... it's like jumping to the middle of the loop without even looking at the 'while' or 'for' statement, yet still working within the loop. While I know better, my mind kind of feels like the evaluation is 'set up' at the beginning, and must be viewed before working within the loop's block.
Which is why, IIRC, the loop in duff's device is usually a do {} while ();
I think Duff actually mentions that some optimizing compilers may be
able to recognize what a rolled-up loop structure is doing and pick the
gcc -O3 -funroll-loops/-funroll-all-loops
I think Duff actually mentions that some optimizing compilers may be
able to recognize what a rolled-up loop structure is doing and pick the
fastest assembly code. In which case, using his technique may not get
you any performance gains.
Also keep in mind duff wrote that in 1988 or something, and optimizing compilers have come a long way in 23 years.
So I started reading that.
my god. I'm old.
Jun 1 2011 3:38pm from fleeb @uncnsrd
Well... it is useful in a very, very specific way. You can
implement coroutines in C/C++ with them. So the problems solved
best by co-routines are best solved with Duff's Device.
co-routines, at least in the context of the Simon Tatham link mentioned previousluy, appear equivalent to the generators construct in languages like Python, Scala and Erlang.
Far preferable to have first-class language support for that sort of thing.
I definitely agree with that. Explicit language support for any particular comp-sci technique is far preferable to trickery.
(LS's favorite State Machine poem is included herein by reference.)
This allows one to write lazy iterators using an unusual, but comprehensible idiom:
public final class Generator
extends HateMachine<Integer>
{
private int i;
@Override
protected void generate()
{
for (; i <= 3; i++ )
{
yield( i );
}
}
}
yield() is internally implemented, in base class HateMachine, as
protected final void yield( T value )
{
throw new YieldException( value );
}
... the rest of the base class is simple enough, yet totally revolting, and therefore left as an exercise to the reader.