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 -Received on Sun Jan 13 2008 - 18:20:27 MST
This archive was generated by hypermail pre-2.1.9 : Fri Feb 01 2008 - 12:00:04 MST