So, everybody would be using boost, right?

Well, no… You see, boost is a BIG library. It installs 64Mb worth of header files alone, 24Mb of libraries, and takes 20 minutes to compile on my machine, an average dual-core.

Now suppose I have a simple C++ program, a few files long, that uses some boost to parse the commandline. that would build in some seconds… why would i wait for 20 minutes for the code to arrive to simply parse the commandline? I’m not very happy that parsing the commandline this way requires you to redistribute a 300K+ .dll file.

GNU getopt on the other hand, compiles to less than 5K of code that you link in directly, so no .dll needed.

And they both do more or less the same thing. Sure, boost.program_options does a lot more, but it just is too excessive. And that’s why boost is impractical. You want a sip, but you get a bucketload shoved down your throat


// list all operators and functions used in the
// template 'add_t' (below) into concept AddType.
concept AddType<typename T>
{
T::T(const T&);
T operator+(const T&,const T&);
}

return result;
}
As you can see, all this is just a complicated way of writing 1+2, so if you optimize properly, all this boils down to: int main() { return 3; } as it should.

template<class T> struct foo { T data; foo() { data = 0; } };

I could define an operator ‘+’ on it using complicated syntax, but say I have done that, and I want to test that it works. (And, say, you want T is ’std::complex<float>’ and ‘float’, for example.) Okay:

template<class T>
struct foo_test
{
inline foo_test() /* here we test the whole 'foo' class on syntax */
{
foo<T> x,y,z;
z = x + y;
}
};
inline void foo_test_instantiate() /* here we instantiate *the test* for our supported types */
{
foo_test<float> tmp1;
foo_test<std ::complex<float> > tmp2;
foo_test<std::complex<long double> > tmp3;
/* done testing supported types */
}

I suppose you can place this kind of syntax checking right into the header file, as it has zero code overhead, if it wasn’t for the fact that those get too big as it is, and testing doesn’t belong there anyway.

This is pretty awesome stuff:

” During our session, AMD was quick to point out the inherent benefits of their “Direct Connect” architecture, which is brought to the system via serial HyperTransport links.

In the architecture Memory, CPUs and certain IO subsystems are all directly connected to each other via HT and it affords AMD a huge advantage in scalability. So much so that they’re already speaking of octal core implementations. In addition, it’s our early estimation that this is the single most important advantage that a quad-core AMD architecture has over Intel’s Kentsfield CPU that is soon to be launched.

(…) The board has no less that 48 lanes of PCI Express connectivity brought out to its four full-length X16 PCIe slots. This will provide a ton of room for expansion for not only graphics but other technologies like PCI Express RAID cards for example. Also note the 12 X 3G SATA ports — holy RAID Batman.

(…) Specifically the machines had two instances of City of Heroes running, two HD video streams playing, including a Battlefield 2142 trailer, and a video conversion going on, all at the same time. In this case all four cores are pegged at 100% utilization but in fact there is plenty of horsepower left to navigate around Windows XP and launch other applications. AMD is citing that more than 20 mutli-threaded game titles are targeted for release in 2007. We’d offer that is even perhaps a bit conservative, as without question the world has now officially gone multi-core, whether you consider the developer or end user community.”

So. That’s a shitload of horsepower. Do I need it? Sometimes, but surely not all the time. Right now all what i’m doing is typing this blog entry. I could do some video conversion in the background, but I’m probably done coverting that few video’s pretty soon.

(slashdot link)

C/C++ compilers generate great assembly code, but sometimes you want to get down to the metal and do every instruction yourself. Under the x86 architecture, this usually means you want to do specific MMX/SSE stuff in your application.

compiler code generation

To support modern architectures, you basically need to recompile. x86-64 issues are handled by recompile for that architecture, sse2 stuff requires your compiler to be very good at vectorizing code, and multi-core is handled by using multithreaded coding (Boost.Threads, for example).

x86-64

Most issues are straightforward, but there are a few big differences. First of all, the x87 floating point is not supported under amd64. You must use sse2. Secondly, the 64bit version of MSDEV does not support inline asm anymore. gcc however obviously supports inline asm. In either case, you can use fasm for 64-bit asm modules.