| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Comments:
<0> Ibiwan having them create a collection, simply so you can copy it to yours seems folly
<1> Actually that's what's asked, not my decision this time...
<0> wrap it with a cl*** that ONLY can do push(node)
<2> Clickers: but i fail to see any logical reasoning for even wanting to do that
<1> i agree
<3> I thought letting the user touch my private data structures was folly
<3> k
<3> I can see that
<0> that's not "touching" it
<3> lemme ponder a bit
<1> lol nacitar, hence my confusion why it would matter
<2> Clickers: im hoping whoever told you to doesnt think it makes reverse engineering more difficult... because the variables are "lost" in compilation
<0> you've got it guarded...all they can do is push
<1> i told him that, he didn't care
<1> go figure
<1> oh well
<1> :P
<0> or give them an output_iterator<node>&
<2> Clickers: tell him he's an idiot and you wont waste your time.
<1> I wish i could... 2 more mo and then a new job :)
<4> If it's a job, I'm not sure why any project manager would care about how you name variable
<1> don't ask -- this dude is nutz... i just do my job :(
<1> he was contracted, and we're stuck w/ him
<4> Well, tell him it's impossible because the language (or compiler) won't let you
<1> hehe... i'd like to see the look on his face
<2> you might ask him for a clear explanation of why he things this is needed
<3> vaw, so I would p*** a vector::output_iterator<node>& as one of the function parameters?
<2> thinks*
<1> yeah, that'll happen nacitar :P
<4> output_iterator is not part of vector
<5> Ibiwan stop making things up, nobody said vector::output_iterator
<3> well container:: is where I've seen iterators come from before
<0> Ibiwan not really, no... but I don't thnk that priority_queue has one
<3> I'm sorry I have to work from previous experience, but it's pretty much impossible for me to do otherwise, by definition
<0> nacitar I've looked
<2> vawjrwrk: didnt see anything?
<3> so let's say I call that iterator itr
<3> does the function then use itr.push(somenode); ?
<2> vawjrwrk: thanks for looking btw. :)
<0> no, *itr++=somenode
<6> nice work investors
<0> IF it's doable
<3> ++=?
<3> I gotta look that one up
<0> no no
<3> oh nm
<3> got it
<0> no, *itr++ =somenode
<3> yeah
<3> sorry
<6> high expectations always lead to market instability
<3> got that one just barely too late :)
<6> GE releases lower than expected (still good) earnings
<6> SELL SELL SELL
<5> heh
<2> i detest how you cant do ++it
<0> peterhu it's in the best interest of all brokes to have "volume"
<3> but I need to use the priority queue as such, so I need to use its built-in "add and arrange" function instead of just taking it on to the end
<0> nacitar huh ??
<6> indeed
<2> vawjrwrk, in my .net 2k3 implementation it complains if i preincrement an iterator
<2> only post works.
<2> (complains as in, operator not found)
<7> that's not supposed to happen
<5> what kind of iterartor is it?
<7> it should work
<0> Ibiwan have you looked to see if there is an insert iterator for priority_queue
<0> nacitar did you write the iterator?
<2> rdragon, like, a vector<int> even
<3> "insert"? I know the "add and arrange" is push()
<5> vector<int>::iterator iter = vec.begin(); ++iter; //works fine
<2> vawjrwrk, nope
<2> i think its something wrong with the implementation
<0> nacitar that's crap, I've both pre and post increment for vector<blah>
<5> i never had a problem with 2003
<0> nor I
<5> not even vc6
<2> me either
<0> it's blah* for crying out loud
<3> k, it's only got top() push() and pop()
<2> when i say its something wrong with the implementation, i mean it's something weird at work
<0> I don't have my docs here
<0> nacitar what are they using?
<3> alright, so if I'm not worried about users messing with my data structures, can I just p*** the address of the queue and let them push() there?
<3> and forget all the vector-return crap
<2> vawjrwrk, its .net 2k3.. but they might have added some other stl port
<5> can't you return a reference to it? (I haven't been paying attention, not sure what you're doing)
<0> Ibiwan there's a difference between handing off the entire queue, and a way to only push into it
<2> i havent investigated.
<2> but now i know for certain that it _should_ work.
<3> okay, you mentioned the wrapper cl***
<2> so i shall.
<3> but I'm still making the user add to my data structure... that doesn't fit the program outline they want us to code to
<0> rdragon he calls something that needs to create a bunch of things that he's gonna push into his priority queue as soon as the thing returns
<3> *mutters*
<0> it's an obcious optimization
<0> err, obvious
<3> sure, but it loses reusability
<5> Ibiwan - who is 'they' ?
<3> me, later :)
<0> Ibiwan not really
<3> oh
<5> job or school?
<3> that "they"
<3> cl***
<5> mmm
<3> school
<3> I understand the topics actually covered just fine
<3> it's implementation I'm having one issue with -- actually came in here on a syntax question
<1> lol he's so pissed
<0> if one is creating a "collection" of things (in this case, expand() ) haveing an output iterator is one of the nicest reusable things
<1> you'd love it nacitar
<0> Ibiwan if you want to return a vector, find.... std::vector<node> succ(expand(n));
<3> succ() and expand() are synonyms
<0> I was referring to line 12
<0> they'd better NOT be synonyms
<3> oh
<3> heh
<3> I see what you mean
<3> use the return as the constructor parameter?
<0> yeah, make it quite explicit
<0> though std::vector<node> succ = expand(n); means the same thing
<3> k
<0> <sigh> neither queue nor priority_queue have an output_iterator to put things in them, nor an input_iterator to take them out
<0> looks like an extreme oversight on the committee's part
<3> heh
<3> well I'll just copy the objects, I'm only worried about big-o processing time on this thing
<3> and I'm already processing them once each, so a copy doesn't add anything
<0> back_insert would work, but the fools use push for queues instead of push_back
<5> yeah, i was just looking at back_insert
<0> they really really really seem to think that syntax determines method and I've ****ing tired of it
<0> if they used push_back inside back_insert then we could use it for things like std::copy
<3> alright, I'll mess with this for a while
<3> thanks for the help
<3> be back in later, I'm sure
<5> http://www.noidea128.org/sourcefiles/15848.html
<5> what a lousy amount of work to change push_back to push
<8> so speaking of iterators
<8> once I have my vector back from the function, I want to iterate through it
<8> and I'm trying to declare my iterator with: vector<T>::iterator iter;
<8> if I change T to, say, double.. it works fine
<8> but as is, compiling chokes with "expected ';' before "iter""
<5> well you have to give it a real T
<5> depending on what kind of vector you want it to iterate over
<0> node in this case
<8> I don't know what T is going to be, that's defined externally to this cl***
<0> ibiwan how can it be defined externally?
<8> vector<T> succ(expand(n)); works fine on the previous line
<8> vaw, I just mean T isn't defined until someone instantiates this cl***
<5> is the cl*** a template cl***?
Return to
#c++
or
Go to some related
logs:
livecd mount sata drive raid
#chatzone
dewd undernet
moskeja
#london
#AllNiteCafe
#chatzone
language of swizertland
#php
#squid
|
|