| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9
Comments:
<0> but scul is right.. the beauty of c++ (opposed to java, for eg) is that you can only use the language features you see fit.
<1> stl throus exceptions non-optionally
<1> AaronWL: wrong
<2> Quite true AaronWL, I'm never against C++ when it's properly used for the task at hand
<1> c++ std lib throws exceptions at you
<1> it has no other way or reporting errors
<3> anyway, exceptions are better whan setjmp/longjmp
<4> Aeon-_: it throws bad_alloc if it can't allocate ****.
<0> the only significant one is std::bad_alloc, which you don't have to catch, if you are fine with the default behavior
<4> Aeon-_: what's wrong with that?
<0> you can use the non-throwing new, if you like.
<0> Aeon-_, that doesn't work because constructors don't return values.
<0> constructors are the reason c++ has exceptions
<4> Aeon-_: that doesn't even work in the case of malloc().
<1> AaronWL: tnhat's why C++ is stupid
<3> constructor can be dangerous when it comes to exceptions
<0> Aeon-_, so you're opposed to any language with true user-defined types.
<1> i'm againast exceptions
<0> any real user-defined type has the potiential for failure on construction, or various other weird times, when return values are unavailible.
<0> you need some other, out-of-line, failure reporting mechanism.
<4> Aeon-_: i don't understand why.
<0> in C, its mainly errno
<0> or other misc hacks that ****
<4> checking return codes is a huge pain in the ***. exceptions are less of a pain in the ***.
<1> evilgeek: because using stl and writing largesize c++ code in C++ is pain in the ***
<0> i think writing exception-safe code is easy.. but it is not intuitive.. you must be trained to do it.
<1> evilgeek: because i was in the project that needed to convert
<0> stl does not generate exceptions....
<1> exception-unsafe code into code that handles badalloc
<1> and that painfully failed
<4> AaronWL: bad_alloc
<0> well, the stl itself does not generate bad_alloc
<0> it just p***es it through
<4> and, er, i think there are one or two more that are called in a couple of random cases. like vector::at() and so forth.
<1> evilgeek: because too many c++ programmers just write exception-unsafe code by default
<0> oh, at(), good point
<0> but if you're using at(), its because you specifically want exceptions
<0> fwiw, i really like at()
<4> aye.
<4> Aeon-_: and there's nothing wrong with that.
<0> at() is great for reading untrusted data files or similar when you dont want to have a million error-handling paths everywhere
<0> Aeon-_, i agree its a problem, but i think the only solution is training.
<3> in 10 yrs compiler will be able to report 'your coding style ****s' error :)
<0> other languages have the same problem, even if they manifest the problem differently.
<4> scul: then i will not use that compiler.
<0> still, you can solve 90% of exception safety issues by using RAII properly, and never using a bare pointer.
<4> oh god, a four letter acronym.
<0> eg, you shouldn't have code like: my_nontrivial_type *p = something;
<4> what does it mean?
<3> :)
<1> did smalltalk have exceptions ?
<0> RAII = resource acquisition is initialisation
<0> std::fstream, for example, is an example of RAII
<0> when the fstream is initialized, it acquires the file and manages the low-level resource. when fstream dies, the file handle is freed.
<0> these sorts of objects are great, because they know how to clean up after themselves.
<0> the big hole is pointers, which don't know this. so, you never use bare pointers.
<0> or if you do, you need to have a try{} somewhere nearby.
<2> This can get a problem if performance matters
<0> one of the worst offenders, among programmers who should know better, is cl*** constructors. often they don't handle the case where an exception occurs during object construction (even on the compiler side of things, this is a painful case to get right)
<0> Maloeran, auto_ptr, the solution to most of these cases, is free in terms of performance and storage efficiency.
<1> i think c++ lib ****s for not having shared_ptr
<0> yeah
<0> but, shared_ptr is no replacement to auto_ptr. i think shared_ptr's are way overused.
<0> shared_ptr also has a significant performance penalty
<0> particularly in multithreaded apps
<4> AaronWL: the reason why auto_ptr is "free" in terms of speed and storage is that there's a huge amount of extra crap thrown into every stack frame in a C++ application. at least with old versions of gcc.
<0> well, thats just a compiler artifact. auto_ptr is just a thin wrapper over a pointer.
<4> it's not just a compiler artefact. you're just doing the accounting differently.
<2> The way C++'s cl***es are structured and used, it's often inappropriate when performance matters
<0> with optimisation on, the main case you're going to see 'bloat' from it is in the exception tables, which will be slightly larger (but on microcomputer operating systems, exception tables are not normally paged in, so this just wastes disk space)
<0> let me do a test though, to see how auto_ptr does today
<0> hm, right, i forgot, there is an extra layer of indirection
<0> bujt
<2> The whole thing is just plain inefficient to me :p
<2> That doesn't always matters, but it matters for what I do
<3> again, you can use c style pointer, if you wish
<0> right Maloeran, but are you sure this isn't just fear, uncertainty, and doubt?
<1> AaronWL hhhm. so yuo're saying C++ = fear, uncertainty, and doubt?
<1> well if you say so
<2> AaronWL, I might not have studied GCC's C++ output as well as I did for its C, but no, I think I understand quite well
<0> if you are only interested in performance, you know, you can just write the performance-critical bits without using any c++ features you feel are slow, possibly yielding code equivilent to C
<0> still doing some tests re auto_ptr
<2> *nods* But these parts work together. I'm using Lisp when performance is not a concern anyway
<1> Aaron: where does extrac level of indirection come from ?
<1> isn't auto_ptr just a pointer wrapped into cl*** ?
<0> still analyzing
<5> AaronWL, I'd be interested to hear what the performance penalty for shared_ptr was.
<1> x zillion
<5> yeah, a lot
<1> but i'd like to hear comprehensive auto_ptr perf results first
<0> im just interested in auto_ptr. shared_ptr performance, for boost, is documented in the manual in detail
<5> oh, is it?
<5> speaking of hungry, for 75000 packets on full debugging I generate 420mb of log.
<0> there seems to be a failure of the ssa optimiser here
<1> packets of what ? of food ?
<5> of 6 byte basic chunks
<5> http://www.boost.org/libs/smart_ptr/smarttests.htm for anyone else who looks interested.
<0> hm, the exception-handling bits create additional complications
<0> making this difficult to test understandibly
<0> realistically, i should say
<1> AaronWL: what are you comparing >? code size ? code speed ? data size ?
<0> i am comparing raw pointer use to auto_ptr use, in common usage
<1> that i undersdtand
<0> unfortunately, evilgeek is right.. additional cruft is generated
<1> i'm asking, do you compute differences in code size ? code speed ? data size ?
<1> ah, yuo're just lookinf as ***embly
<1> i see
<2> C++ really is not that clean, AaronWL, even when "properly used"... if you do use the C++ features
<1> @Gambit-: looks like they compare various implementations of smartptr among themselves , but never against C pointer
<0> in terms of object size, they are the same, obviously
<1> ... and never against auto_ptr
<5> Aeon-_, iirc that's what a "raw" pointer is, at the bottom.
<0> there are two problems i am seeing.
<5> they're also using really old compilers
<0> the first is a general failure of the optimiser to turn struct {char *p;}; into char *p;
<5> and I can't quite figure out what their test actually does, the whole descriptions a little ambiguous.
<0> eg, it insists on loading things onto the stack that have no earthly purpose being there.
<1> Gamb: ah right
<0> this causes various spurious stack activity
<1> AaronWL: i never saw auto_ptr somehow used in real projects by real programmers
<0> but only manifests itself when they are p***ed around
<0> or right at allocation, or other places which, imo, aren't that important
<0> (p***ing an auto_ptr is different from p***ing an ordinary pointer in that it implies a change of ownership)
<2> That "raw" pointer can't be a C pointer... I mean, initialisation would be a single mov instruction
<0> so, this part does not concern me, and while it does generate crap, it really doesnt matter.
<0> the second part is the exception-handling part.
<1> HOw come that in 3rd table, raw pointers come out the slowest ?
<0> with real code, where inter-procedural information is not availible, there are considerable complications in handling auto_ptr
<0> not just exception tables, as i predicted.. but various stack activity due to providing landing pads and safety code for exceptions that are p***ing by
<2> There's something really wrong with their tests, whatever it was
<1> AaronWL: let's say you write a function that accepts pointer to T and works on the object never deallocating it
<2> Anyway, I rest my case : C++ typically ends up slower
<1> why would you need auto_ptr() in such a function ?]
<1> T* is good enough, and auto_ptr would be pure overhead
<1> so, it folows that you don't want to p*** auto_ptr() around
<0> Aeon-_, in that case, it doesn't, and stylistically, i would prefer to p*** it a T &
<1> which makes them of little use
<0> auto_ptr is not designed for this case
<0> auto_ptr is designed to be used by the person who is actually managing a bit of heap storage
<1> the biggest difficulty if in handling exceptions in constructors and around constructors
<0> for example, cl*** mycl*** { /*...*/ private: T* one, *two; };'
<1> the solution is not always auto_ptr
<0> for the safety of the ctor, this should be replaced with: cl*** mycl*** { auto_ptr<T> one, two;};
<1> i suspect auto_ptr is very very rarely the solution
Return to
#c
or
Go to some related
logs:
#gentoo
#mirc
uranus is ours
#networking
#gentoo
#nhl
#politics
#politics
#debian
#wtf
|
|