| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> Er... what the hell does npad do?
<0> Anyway, you appear to be wrong about VC not reusing stack space.
<0> It does in release mode.
<0> Yup. It does, unless you involve writes to volatile storage.
<1> Hmm, I was sure it didn't in something I was looking at yesterday.
<1> Oh, wait...
<1> I know what I was doing.
<0> Let me post my test case.
<1> I was doing something like: res = fn( fn( fn( fn( fn( in )))); And in that case it didn't reuse the stack space, even though it could quite easily.
<1> But I guess that's not a problem really. :)
<0> Def: http://cpp.enisoc.com/pastebin/6988
<0> You see that only big1 is kept on the stack, because I use it at the end of the function. Everything else stays.
<0> Er, goes.
<0> In debug mode, there's a stack overflow, obviously.
<0> I fail to see how your example is an argument for using ***ignments though.
<0> I wouldn't expect it to reuse the stack in that case.
<1> No, it doesn't. It should be free to though.
<0> Well, it's still not an argument to use ***ignment.
<1> That's really strange code the compiler generated there.
<1> It's slowly walking down the stack for each successive instance
<0> No it isn't... the cdecl calling convention pops the numbers for the calls.
<0> I mean, it's not the caller's responsibility to do that.
<1> No, but even with that it's walking 32 bytes each line.
<1> If it were really reusing the stack all the address offsets would be identical.
<1> It partially reuses, but seems to get confused. Big15 is in the same space as Big8 for example, but 9-14 are offset slightly.
<0> Er, you're right. I observed that it didn't crash, and looked at the stuff at the top of the segment, where supposedly each _big gets the same address.
<0> Ah: the reason is that the caller /does/ clean up the parameters (thus supporting varargs but generating larger executables).
<0> VC just seems to be saving a bunch of those cleanups until the end.
<1> Hmm
<0> ...hence the occasional "add esp, 68" or whatever.
<0> Still quite an odd way of doing things.
<1> It kinda makes sense. I mean that will be faster than cleaning up after every call.
<1> Probably.
<1> The size of the objects will probably hurt the cache as much as anything else anyway, so you probably wont be losing anything there.
<0> What's odd is that it doesn't leave all the cleanup until the function exit.
<0> Well, it was intended just to prove that the compiler works the way I expect it to... it wasn't supposed to be finely tuned code :)
<1> It might be trying to be clever and limit the clean up to a cache line. (64 bytes.)
<1> But it's clearly failing. :D
<0> Did you see this post, by the way? http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=424931&SiteID=1
<0> Optimiser bug that makes things 3 to 5 times slower under VS2005.
<1> yeah
<1> Isn't it great...
<1> Another half-finished product release to hit the Dec 31 deadline.
<1> I specially like the way it just ****s up 64-bit code sometimes.
<1> especially*
<1> There's a bug report on that in there somewhere too.
<0> Just ****s it up?
<1> Yeah, let me find the report
<1> http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=303761e8-c8b5-4cba-9ee4-cdd7a9f8ae59
<1> Hmm, I'd not enountered it in VC2003. I noticed it several days after installing 2005 though.
<0> I was just thinking that.
<0> Nice that there's going to be an SP1 though.
<0> I keep hearing that; Herb has promised some things.
<1> It needs it
<1> And an SP2, and maybe a 3 too. :D
<0> It's not that bad, is it?
<1> Are you kidding?
<1> There's so much wrong with it...
<1> meeting time... biab
<0> Bah, cock****er.
<0> Anything that's a serious defect or regression?
<2> :q
<2> oops
<0> Lame!
<0> Dabs have changed to use Amtrack... which reliably informs me that they have my consignment, but give no indication of when they might deliver it.
<0> Wheee... security update for lynx :)
<2> elinks > lynx!
<2> :>
<0> emacs is teh ****.
<0> Actually, I'm just not smart enough to use it.
<0> So I stick to nano. I only ever log into that machine to update it, anyway.
<1> erm..
<1> hiding build/platform config when building or debugging is really ****ing annoying.
<1> solution explorer not showing the selection when editing project/file properties.
<1> Configuration manager not being able to make more than a couple of changes at a time
<0> Hiding the what? When?
<1> single stepping over source lines in the debugger reverting to dis***embly view if you've viewed it before
<0> ...but yeah, devenv ****s.
<0> That's caused by you not knowing the difference between toggle dis***embly and go to dis***embly.
<1> The toolbar configuration dropdown for selecting build configuration and target platform. When you're building or debugging they're just blank boxes.
<0> Add the extra button to your toolbar, and never be miserable again.
<1> It's different behaviour, which doesn't seem to be needed.
<1> Intellisense constantly rebuilding itself all the ****ing time
<0> Yeah, I don't think 2005 is an improvement over 2003.
<1> slowly and badly.
<1> It's not. It's ****ing terrible.
<1> It's a lot slower to use.
<1> I think they've just added Sleep( 100 ) to the end of every line in the source code.
<1> The whole IDE locks up for minutes (literally) at a time.
<1> The really annoying thing is we were forced to upgrade due to the vista psdk not supporting 2003.
<1> Oh that retarded ctrl-tab window. Fortunately you can disable it...
<1> The god-awful syntax colouring for commented out blocks.
<1> Nice idea. Just doesn't work.
<0> You mean #ifdef'd blocks?
<0> That's the only bit of IntelliSense which does work, for me.
<1> It worked for me for about 2 days. And now it just comments out huge chunks of code seemingly at random.
<1> I can think of two things which are better in 2005.
<0> ...and it took you a while!
<1> The fact you can scroll past the end of the file, so you're not stuck editing the end of the file at the arse end of the screen.
<1> And the expandable tooltips in the debugger.
<0> Oh, you could always do that with the mouse.
<1> ?
<1> Should *= return a reference or an object? It shouldn't matter should it?
<0> A reference, typically.
<0> ...but only nasty code would be affected by it.
<1> Yeah.
<3> yeah what ?
<3> wel nuffin i have an ***ignment and its due and i'm fkd up so i really need some1 to help me with
<3> that all
<1> Just yeah
<3> i'm honest and simple
<3> see
<3> so can u help
<3> me ?
<0> Well, you've proven the simple part.
<3> yeah i know but the ****ty part is the ***ignment !
<0> If you ask a specific question, we will help.
<3> beautifull zn
<3> okay wel i have an external file txt
<3> how can i read the data from it
<3> 3435344 A 2005/02/22/08:22:41 << like this
<3> i just wonna read for example the id then A and add them in another file
<0> Hm. Well, I've never seen that happen before.
<0> six?
<2> ye?
<3> yeah sorry fkin dc
<0> Why does ChanServ do that?
<2> err, real kills *never* have Quit: before them
<2> everything that starts with Quit: was written by the user
<2> i.e. he typed /quit Killed (ChanServ (You've been online too long))
<0> Oh, yeah.
<3> i didn't write that
<2> well your silly script did or whatever
<2> anyway, it was not a dalnet-initiated thing
<3> yeah probably whatever
<3> i know it ma ****ty connection
<3> next time ill get damn oc12 one
<0> twiste911: Anyway, you probably learnt iostreams in cl***.
<3> yeah mate
<0> So, use an ifstream to read from the file. Simple as that.
<3> ok
<3> yeah but the problem is not here
<3> wel the ***ignment is we have 2 read from a file
<3> where all these data are located
<3> then put each id number tht return to a customer to a new txt file
<3> its like an invoice
<3> or statement
<3> so how can i read for example 2919929 A, 82882:2882 how can i read the first numbers before the A
<3> so wara ya think ?
<1> I think your English needs some work. ;)
<4> yeah i know i'm tryin 2
Return to
#c++
or
Go to some related
logs:
error: Failed dependencies libcrypto.so.6
ah bu neh
#chat-world
#unixer
lazepe
#india
#chat-world
t
#india
linkin park howold?
|
|