| |
| |
| |
|
Page: 1 2 3 4 5
Comments:
<0> he waited a whole 3 minutes
<0> and you bastards didn't respond
<1> if only I knew more than jack about Windows IPC ;P
<0> http://techdirt.com/articles/20060303/0140223.shtml
<2> does anyone here serviced by bell south or live in that region has long distance calling?
<3> Bell net or bell south?
<4> I thought everbody had long distance calls
<2> well there is no long distance calling in all of south texas right now
<3> if you have ADSL it depends on the distance to the exchange
<4> Blame Lucent (har har har)
<3> what are charges there for an 2megabit connection?
<3> in the US
<2> in this region its 5mbit and its 45 a month i think
<3> any download limit?
<2> no
<5> Is anyone here employed as a Network Administrator? If so, please send me a message :)
<6> does anyone have a good article explaining that stl is good ?
<7> you don't need an article :P
<6> it's not for me
<7> list<int> vs. some big buggy code you wrote
<7> and whoever you want to convince is convinced
<6> my friend needs to convince his bosses to move away from home-grown containers
<1> it is good when you can use it
<6> strings, etc
<7> you won't have to deal with memory leaks, it's already written for speed
<7> I would point some of this stuff and they should agree
<6> thank you for telling me that - I need it written in a compact format, preferably at some respectful site
<6> respectable, that is
<1> what is your friend's reason for not using it?
<1> er your friend's bosses' reason
<6> cn28h : I'm not lagged, I was eating :)
<1> ah ;P
<6> let's see... that the employees aren't used to it - so it will take them time to learn it
<6> that std::list uses dynamic allocation - and will cause memory fragmentation, while their list allocates a big chunk and manages it
<6> and mostly, prejudice - back in 90's stl wasn't good enough
<6> no really good reason, of course
<1> I don't see how the STL will cause memory fragmentation, you will have the same fragmentation problems with allocating a big buffer and handing out chunks yourself
<1> this is how malloc()/new are generally implemented anyway
<1> grab a big hunk of memory from the OS and hand out chunks from that
<6> not quite, if you have a list and keep adding nodes - it will allocate nodes, but if you know that your algorithm is going to add 20 members in a row - you can allocate an array of 20 nodes, and add links
<6> maybe you can p*** an allocator to std::list to achieve the same result, though
<1> if it's a list who cares if it's fragmented?
<1> you can't do random access anyway
<6> fragmentation is not about random access, it's about wasting more memory that you actually use
<6> there is no point in conviencing me - I only need a good article on the subject
<1> is their algorithm smart enough to coalesce freed blocks?
<6> dunno
<1> generally malloc()/new is
<6> for every specific case you can write a better implementation than stl's - but for vast majority of the cases, their implementation is good enough, and is more robust and stable than anything you can write
<0> unless you're me
<0> then, you can beat the STL 100% of the time
<0> but, you still don't bother because you're lazy.
<8> it's not useful to make algorithms that already exists. Reinventing the wheel with square blocks is not very useful excersize..
<1> it is a useful exercise, but in practice it's not the most efficient way to get things done
<0> programming isn't exercise cn28h.
<1> if you are learning, it can be
<0> I don't know, even with frequent trips to the bookstore, it's still not really exercise.
<0> you should get outside and get some real exercise.
<1> I do, haha
<1> I'm at work
<3> ATL's are one of the most beautiful things
<0> did MS ever have a competing template library with the STL?
<9> <dribling> :)))
<9> <dribling> asa ca care o kopie il dau in judecata:D
<9> <dribling> :)))
<9> <9> mei
<9> <9> ce sa fac
<9> <dribling> da
<9> <9> nush
<9> <dribling> nici eu
<9> <9> mmmmmmmmmm
<6> Noidea: CArray/CList/etc crap, and ATL
<10> 'lo
<11> ol'
<10> dumb question
<11> sounds like it
<11> dumb answer coming right up
<10> :P
<10> why does (4.32809e-11 - 0)/4.32809e-11 ... give me an answer of "infinity" instead of 1?
<12> because it should
<11> probably becuase it causes an overflow
<11> or underflow?
<12> learn how floating point works and it might make sense
<11> obviously it looks innocent, which means it isn't
<10> oic, so its normal?
<12> floating point sort of works like scientific notation, but what's happening is that the 4.32809e-11 - 0 is getting essentially rounded to 0
<12> then when you do 0/4.32809e-11 the 0 is much larger in terms of the exponents
<10> but if it recognizes 4.32809e-11 as 4.32809e-11 initially ... why does it recognize it differently later on?
<11> can 4.32809e-11 be stored in a double?
<12> it desnt
<12> it always recognizes it the same
<10> then why does the division get messed up?
<1> it should fit in a double
<12> the problem si that #1 you have no clue how floating point numbers work and #2 4.32809e-11 - 0 = 0
<10> oic...
<10> but then the answer should be 0, not infinity :)
<12> go read up on IEEE 754
<10> alrighty ... one more question...
<12> no, it should be infinity because the exponent of 0 is out of bounds of e-11
<10> oic.
<12> e-11 is getting rounded to 0 as well
<12> this might help http://en.wikipedia.org/wiki/IEEE_floating-point_standard
<10> if I have like ... (<really small number 1> - <really small number 2>)/ <really small number 1> ...could I have an answer of "NaN"?
<11> Try it.
Return to
#c++
or
Go to some related
logs:
#linux
mazilix
#linux
#london
#chatzone
#linuxhelp
spf iowait
#linux
#linux
#gentoo
|
|