| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11
Comments:
<0> there's no room for philosophy in C++
<1> no... it is :). This one
<0> either somehting works the way you want it to, or it does not
<2> Now lets do something useful... I need a function that will help me to count objects that fullfill some requirement. Thus, I have objects of some type T. I run over all of them and determine if they fullfill this requirement, if they do - then I add them to a set<T> - if the object was already added, then I increment a counter... hmm, where is the counter? I better add it therefore to a set<Count<T> > I guess.
<0> std::map<T, int>
<0> there's the counter
<2> Or that
<2> What would be a good interface to this algorithm?
<0> hmm, it's like std::foreach or something
<0> http://www.cppreference.com/cppalgorithm/for_each.html
<0> send your list through and a function. the function will check the items of the list and then it can add them to another list
<1> can you advice me good resources about localization?
<0> WhiteVoid http://rudbek.com/books.html the last book
<1> jsaacmk locales?
<0> yes
<3> Run: Couldn't you jsut sue the Count algorithm on your set?
<3> Or check it's size?
<2> I guess I'll create a std::map<T, int> foobar; first.
<2> What would be a good name instead of foobar? Hmm.
<4> size_t
<2> count_map?
<0> histogram
<5> bazbletch
<2> Ashe: I use int for counting.
<4> Why?
<2> Why not/
<4> Because you'll never have a negative count?
<2> So?
<4> So why waste half the values?
<4> Why do you think std:: uses size_t everywhere?
<4> Why do you think size_type is unsigned?
<4> Oh yeah, cause the ones who made it were bored and felt like typing longer types
<2> When the size of an int becomes a problem down to the last bit of it, then I'm doing something serious wrong.
<2> I use 'int' when the size that I need is fuzzy: it should be large enough.
<4> It's still dumb
<2> If it's not large enough, then I use long long, or int128_t :p
<4> Which just proves it's completely stupid
<0> is there an int128_t ?
<2> It's not dumb, it took me 10 years to realize that using int makes more sense. I used size_t too in the past.
<4> Amazing you're the only one who figured it out
<4> While everybody else figured it out the other way
<4> You must be that much special
<2> 'int' means "an integer" in the mathematical sense of the word: they run from minus infinity to infinity. Whenever I'm not concerned with the virtual limit of a computers 32 bits, then I use an int when I need an integer.
<4> Your value can't be negative, so using a signed value is dumb
<4> No matter how you look at it
<2> Whatever
<4> But it's not the first time, so I guess it's normal
<2> Or no, I'll bother explaining why it isn't stupid.
<5> it's unnecessary, but it usually doesn't matter
<4> Great, show me the wonderful advantages of using int instead of unsigned int to store a size ;)
<4> (and then go rewrite all the STL cl***es, cause you know better)
<5> show me where it's necessarily a disadvantage?
<0> what's the population of the world?
<4> It's -2^31 people, of course
<5> it's clear it's not a bad idea to use unsigned int where you need to make sure the number isn't negative
<2> I use size_t for _sizes_. As a bonus for doing it my way, I get compiler errors when I compare sizes with integers (like counters), or when I overload a function that uses a size_t and an int or whatever. It makes my code more robust because the compiler gives more often compile errors when I make mistakes.
<2> In other words, I reserve 'size_t' for sizes (in bytes).
<4> If you used size_t for counters it wouldn't happen
<4> But that must be too much obvious
<2> Exactly
<5> but in most of my code it won't happen *anyway*
<4> Because of course a reference count can be negative
<2> And then I would think it worked because it compiled..
<2> jottinger: on the contrary
<4> Now I understand why you often ask dumb C++ questions
<2> If you know your number cannot be negative, it is stupid to use an unsigned it.
<2> int
<4> Still many things to learn
<2> Because that way you'll never detect if it DOES become negative by accident.
<2> Using an 'int' is more robust.
<0> If you know your number cannot be negative, it is stupid to use an unsigned it. that makes sense to use an unsigned int in that case
<4> So you make dumb things because you know you'll do OTHER dumb things
<4> Hahah
<4> You ****
<2> At least I'm not getting personal. I know by experience that using 'int' where you mean 'integer' in the mathematical sense of the word (and that includes counting objects) makes your code more robust against mistakes. If you disagree, fine. Don't call me names.
<4> I'm not calling you names, I'm saying you're stupid and just do more stupid things to compensate for the first ones
<4> And I'm sure you check if your ints are negative each time you use them ;)
<6> is boost.org down ?
<2> I'm not the only one being stupid I guess.
<4> Well, cppreference is certainly known for being THE reference</sarcasm>
<4> But the STL, on the other hand
<4> They were plain stupid
<2> I suppose you always write: for(unsigned int i = 0; i < N; i++ )
<4> Using unsigned types everywhere
<2> lol
<5> Ashe: nobody's saying they were being stupid
<4> Of course they were, they didn't use ints
<5> it's not a matter of me saying "everyone should use int, because I don't care if I use int in cases where it doesn't matter"
<5> okay, fine, infer meaning nobody else has implied
<7> Hiya, with chess, how would you check if the game is over (the king cant move anymore)
<7> How would you check if there's no move the player can do
<0> but if you ever help anyone with C++ and use an int for a count, you teach them incorrectly
<2> It clearly doesn't matter in the case you DON'T make programming mistakes: don't tell me you EVER have to count 2147483648 objects!
<4> Icewolf: think I told you that few days ago
<4> Run: I do, I work on machines with 32 GB of RAM
<7> Ashe: I'm kinda trying to find the best way, if anyone is really smart with some easy, but yet powerful way
<4> But the ints are 64-bit anyway
<2> But IF you make a mistake, then it HELPS when it can become negative too: -1 is a LOT closer to the values you really use than 2147483648.
<4> Icewolf: try to move the king to each possible location, then test if any of the opponent's pieces can take it
<3> Icewolf: There aren'T dozen of ways. You do it jsut like you'd do it in a real-life chess game. Try to mvoe the king to all possible positions, and see if he's still in check.
<4> (for each possible location)
<7> But there's another thing
<4> Run: sorry, I don't make completely ridiculous mistakes like that
<4> But now I know why you had to make a debugging lib
<7> Hmm let me think about this for a while
<7> thanks
<5> Ashe: I haven't had to debug rollover values for a long, long, long time
<4> So it doesn't help you to have a -1
<5> but in 99.9% of the cases, it doesn't HURT you to have a -1
<7> But what if he can't move to any tile, BUT another piece can block the enemy from checkmating
<7> That would be a complicated way to check
<2> <4> But the ints are 64-bit anyway <-- and then you tell me I'm stupid to waste half of the values of an int by not typing 'unsigned' all over the place, or abusing the size_t type that is NOT meant for counting (being unsigned or not). The main feature of size_t is that its name says that it is for sizes, not that it is unsigned. The only reason where it being unsigned REALLY comes into play (especially if its 64 bits) is in compiler warnings where you try to comp
<2> are signed with unsigned. ONLY using unsigned won't help a lot there.
<3> I like to make values I know won't be negative unsigned because... Well, then jsut seeing the "unsigned" makes you know they can'T be negative! It's got greater semantic significance.
<4> Run: you know, no matter how you look at it, it'll make no difference, unsigned value makes more sense
<8> here's what I think (since nobody asked me)
<4> (and if you don't want to "compare a size with a counter" (why would you do that anyway) just have a cl*** for it)
<8> #1: As a general rule, it's stupid to *rely* on signed/unsigned to make your code mess-up faster and help you find bugs. ***ERT is a much, much better tool.
<2> Ashe: I already said: once the program works, it makes no difference. But while you're still working on it, it helps to distingish unsigned sizes from signed counters.
<8> #2: code what you MEAN. if a value isn't SUPPOSED to ever be negative, make it UNSIGNED, so that if someone reads over your code later, they can use that fact to find inconsistencies and bugs.
<4> Which just means you make stupid mistakes and do stupid things to fix them
<8> there. I think I'm done. :)
<2> Every programmer makes mistakes, that isn't stupid - it's a fact. If they didn't then there would exist a guy somewhere who always wrote programs that immediately worked after he wrote it.
<8> actually.
<8> there are ways to limit those mistakes.
<4> Not every programmer does mistakes only newbies who've been doing C++ for 2 weeks do
<2> lol
<8> relying heavily on ***ERT and unit testing is a way to severely limit bugs to begin with.
<2> ok, I'm going to write my algorithm (using int for the counter ;) :p
<0> so sad
<4> Not like anyone will use your algorithm, so who cares ;)
<9> string.h doesnt have strupr and strlwr ?
<4> std::transform with toupper/tolower
<5> wabbitcode: ask #C
<9> Thanks Ashe
<8> hmm. I spose a good code-coverage tool might help at some point
<9> jottinger, why there ? i'm doing C++
<9> besides i like it in here, i'm fine in here, why change enviroment ? :P
<4> Swish: there's a nice one in devpartner
<5> "string.h"
<9> oh, okay.
<8> ashe, is that the one that's overpriced?
<8> or was that glowcode
<5> should be cstring
<4> Dunno, it was like $2000 iirc
<4> With boundchecker and such
Return to
#c++
or
Go to some related
logs:
rc.local run activemq
#chatzone
#linux
#AllNiteCafe
#c++
#AllNiteCafe
#AllNiteCafe
chrooting apache php slackware
#windows
yum Scite + no match for argument
|
|