The decision was made a while ago to not use the STL for various reasons. These mostly included portability and bugs in the compiler and STL libraries. I'm guessing that these have mostly been fixed. Thing is, the STL is "great" until you need to optimise for performance, then you need to know a bit more about them then was preached :) For example, if you don't preallocate a size for an array template (I forget the details, I stopped playing with the STL) then every time you add an item to the array it'll actually allocate a new array, copy constructor the objects into the new array, and then dereference/destroy the old array. This makes for bad performance until you fire up a profiler and debugger. :) Thats why the Boost library exists. Its basically the STL done sensibly and portably, with all the extra types that make C++ development shiny. You can still make poor decisions using Boost, and I dare say if all you know is Boost/C++ then you may try shoehorning -everything- into what those tools provide you, but at least they provide the potential for portable, high performance, efficient C++ development. shared_ptr for example seems extraordinarily nifty. Personally, I think the biggest problem with the Squid project to date is the lack of coherent architecture and direction. I admit to being a dissenting voice since shortly after the C++ effort began, but I'd like to think its been with reason. (Eg: the Squid-2.5 + $LARGE_PATCH_SET debacle which resulted in me forking off to a seperate side release for a while, which eventually kicked the other developers into releasing Squid-2.6.) I'm not going to jump on the Squid-3 bandwagon. I'll stick to developing "C Squid" because thats what I'm interested in doing, and the only thing that'll sway me is people ceasing to use "C Squid". :) In fact, I don't -strictly- have anything against C++. If this means that I'll have to take what I'm doing into a new project and leave the "Squid" path to be Squid-3 and make their lives easier then so be it. No, Squid-2.7 doesn't support all of HTTP/1.1. Squid-2 is just starting to grow the internal restructuring that will make HTTP/1.1 compliance easier to achieve without massive shoehorning and sledgehammering of the required concepts. It at least decodes chunked encoded responses from HTTP servers which shouldn't be responding with it to a HTTP/1.0 request. Adrian On Sun, Jan 13, 2008, Matt Benjamin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Well. > > I've had squid-3 in production doing ssl reverse-proxy custom stuff > since 2 years ago. Shame on me, for believing the squid developers when > they said, expect a squid-3 release rsn. > > On the c++ front, I submitted code trivially using STL <list> and was > informed, that's not allowed. Not allowed? Sorry, Squid-3 is not (or > was not) using c++. > > I'm happy to see forward movement in any direction. However, I think > it's strongly in the interest of all Squid developers and users to get > together and structure a single road-map to a future that is really > delivered, with frequent incremental delivery of new code. > > By the way Adrian, what does it mean to improve HTTP/1.1 compliance? > Does Squid 2.7 really support HTTP/1.1? > > Matt > > Adrian Chadd wrote: > | On Sat, Jan 12, 2008, Marcus Kool wrote: > ~ integrated ICAP support; Amos has ipv6 support included in 3.HEAD. > | > | 2.x: functional cyclic filesystem (COSS), some of my recent work > | (store URL rewriting to allow CDN type content to be cached with > | appropriate administrator intervention; my logging helper framework > | to make logging lightweight again and allow other logging > destinations > | to be easily written, like UDP, MySQL, etc), performance > improvements, > | HTTP/1.1 compliance improvements. > | > > > > - -- > > Matt Benjamin > > The Linux Box > 206 South Fifth Ave. Suite 150 > Ann Arbor, MI 48104 > > http://linuxbox.com > > tel. 734-761-4689 > fax. 734-769-8938 > cel. 734-216-5309 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHirZZJiSUUSaRdSURCMkpAJsGztPJdn06U/fmrAf73diHLClgbgCgj3mh > L1jIaUZr58CNB++wQ7yyDQ0= > =U0Ss > -----END PGP SIGNATURE----- -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
