| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12
Comments:
<0> look in #winprog or #win32
<1> threat: http://pastebin.com/534955 whats wrong with this? i get errors
<2> do you know the difference between = and == ?
<1> oo right right, got it
<2> plus, you cant use == to compare a cstring
<2> it wont work
<2> you can either ***ign argv[3] to a std::string or you will need to #include <cstring> and use strcmp();
<2> the former is probably a better idea
<2> may use more resources, but thats all good :)
<1> hmm how would i ***ign it to a string
<2> std::string string_name; string_name = argv[2]; or std::string string_name = argv[2];
<2> I would recommend you define all variables at the start of main()
<3> yay i got my **** to work
<1> once i ***ign argv[3], can use the ==?
<2> yes
<3> wait
<3> what?
<2> tehkevn, I was talking to CptPotato
<1> i still get errors. when i type "square" as the last argument, it returns my error "shape must be..."
<1> threat: http://pastebin.com/534969
<2> CptPotato, also, before you jump into the code liek you have already done, try and plan it out first, write out on a piece of paper (or in your text editor or choice) how you would go around doing the objectives stated in the question sheet
<1> well ya, i planned it out, and then thats when i needed to figure out how to separate the strings in the inputFile
<2> and how you would split the program up into functions , etc
<2> CptPotato, easy, string str; int i; inFile >> str; inFile >> i;
<1> ok, so with that, how would i display the third string (__Hi!__)
<4> Note to ops: guest3895 posts porn links. I just banned him from #c. It may be a good idea to do the same here.
<5> does anyone know MFC?
<2> who?
<2> CptPotato, ?
<2> CptPotato, inFile >> str;
<1> yes?
<1> hold on a sec
<2> >> delimiters are ' ' and \n
<2> although I am not sure if you need to inFile.ignore() the ' ' and '\n'
<2> I personally use getline instead of >>
<2> getline(inFile, str1, ' '); getline(inFile, str2, '\n');
<2> however since you have an int, I gues you would have to use >> on that
<1> threat: we were never taught getline so im ***uming we cant use it
<1> where would i paste these entries?
<6> CptPotato: comparing char pointers with == only compares the pointers themselves and not the pointed-to values, so your tests will never be true
<6> std::string shape = argv[3]; if ( shape == "square" ) {} // std::string is properly overloaded for == to allow comparison
<6> or even std::string const shape = argv[3]; if you won't be changing it
<6> good code otherwise, except for your indentation style :P
<2> CptPotato, hmmm have you been taught about the enum type?
<1> ive been working on this for hours haha, it seems like a such a simple pr0g too..
<1> nope
<2> I did this --> if((shape_type = strToShape((string)argv[3])) == INVALID) {
<6> ick
<2> where shape_type is an enum {INVALID = -1. SQUARE, RIGHT_TRI, ISO_TRI};
<2> :)
<2> Kniht, indeed :)
<1> ick what?? and we were never taught enum, yet
<2> Kniht, I like to compact code, I guess thats kind of bad since it makes readable less
<2> hehe oh ok
<2> what have you been taught then ?
<2> std::string?
<1> yes
<6> ick to threat's code
<2> Kniht, I know :)
<6> side effects in a conditional and a bad cast
<7> string(argv[3]) is a better style
<7> and it's simply not required, because string has an implicit cast from char*
<2> is this bvetter? --> if((string)argv[3] == "square")
<1> ahh!! haha you're all losing me..
<2> is this bvetter? --> if(string(argv[3]) == "square")
<2> :)
<7> somewhat better
<1> yes! do i need to declare anything or anything else
<6> threat: if ( std::string( argv[3] ) == "square" )
<2> exception, so would you cast the cstring to a std::string and compare? or would you create a std:;string tmp_str = argv[3]; and then test the tmp_str?
<2> you like to what spaces there?
<2> what = put
<2> isnt that a java style?
<6> don't put the spaces if you like, personal preference, but the cast isn't needed, construction is preferred
<7> threat : and if you don't need a temp variable, don't use one
<6> threat: I had just mentioned how to do this above your code :P
<2> Kniht, good idea :)
<2> Kniht, what about int shape_type; string shape = argv[3]; if(shape == "square") shape_type = 0; else if(shape == "right_triangle") shape_type = 1; and so on?
<2> then switch(shape_type) { 0: printSquare(str, size); break; 1: printRightTri(str, size); break; and so on ? :)
<2> CptPotato, oh do you know what a switch statement is? ;)
<6> threat: sure, but use an enum
<1> threat, kniht, the if statements work now, thanks :).. now i need to separate the strings..
<2> Kniht, yeah I was, but CptPotato doesnt know what one is :)
<1> no i dont
<6> then use named int constants
<1> i wasnt following your little dialogue, i was just adding the if statements
<2> Kniht, oh so const int SQUARE = 0; ?
<2> Kniht, good idea :)
<2> CptPotato, do you know what a switch statement is ?
<6> int const triangle = 1; int const square = 2; ... int type; std::string const shape = argv[3]; if ( shape == "triangle" ) type = triangle;
<2> althoug h I guess you can just use if statements
<1> threat, u saw the ***ignment.. is it even necessary to split apart the infile into separate variables or no? and no i dont know a switch statement
<2> Kniht, yes but if CptPotato hasnt learnt switch statement then using named constants is kind of pointless
<2> may as well use std::string
<1> how though
<6> no, it's not
<3> nice
<6> an enum is just named constants anyway, if you can't use an enum for whatever reason that's not justification to sprinkle magic numbers through the source
<2> CptPotato, does the input file only have one pair of string, int? or can it have multiple string, int paris?
<2> pairs even
<2> Kniht, ok :)
<2> Kniht, in prototyping a function do you include the name of the varibles? or just the datatypes?
<1> the input file is a string of random characters, a space, and an positive integer... and any number of lines of that
<6> depends, do I feel like duplicating documentation that the parameter names represent? do I want the maintenance h***le when something changes?
<2> Kniht, true
<1> like this one: http://cptpotato.dnsalias.org/in_patterns.txt
<1> the first string is the ascii to be repeated in the shape, and the number is the height of the shape
<1> output with the 'square' argument http://cptpotato.dnsalias.org/out_square.txt
<1> i want to separate the lines, and then get the first string and set that to a variable, and then the second string, following the first by a space, and ***ign that to a variable
<6> two stage parsing like that requires storage for the full line, you can do that with std::getline and feed your line into a std::istringstream to read the individual fields from it
<6> however, for this project, it seems like that's not needed
<1> earlier (like 2 hours ago haha) i think threat mentioned vectors, how would i go about using those in this case
<2> Kniht, I have it figured out now :P
<2> CptPotato, no dont use vector :)
<2> CptPotato, you dont need it
<1> threat u have the code? ;)
<2> CptPotato, this is what I have done so far http://pastebin.com/535010
<2> Kniht, if you would like to chgeck that out too :) it would be appreciated, I have been on holidays for 3 months and a bit rusty :P
<6> threat: why change the way inFile and outFile were initialized in potato's code? why move all the variable definitions to the top of main?
<2> Kniht, easily able to see what variables are used in the function
<2> instead of defining them half way through the code
<2> or in other random places
<6> it's easier to put the variables closest to where they are used
<6> it's less confusing and more readable
<6> by putting them all at the top, you not only have to remember how they're used, but also where they're used
<6> by putting them where they're used, one piece of that information is documented explicitly
<6> err, implicitly :P
<2> Kniht, although if you define a variable, and use it on line 740, and its not right up the top of the function its harder to locate where I have defined it
<6> it also allows things like making them const, which further documents use and prevents some mistakes
<2> or corse you could use CTRL+F or / however if you need to print the code out for a marker to mark, then its easier if the vairables are defined at the top
<6> if it's first used on line 740 and defined on line 739, it's *easier* to find where it's defined and what initial value it's given
<2> yes but if its defined on line 54 its harder
<6> and it doesn't take you away from where it's used to find where it's defined, less searching
<6> I didn't say line 54, I said line 739
<6> and any function that's 740 lines needs to be refactored
<2> yes but I said line 54 :) there is no point defining variables like that other wise they will only go out of scope when the program exits, defining at the top you can reuse variables
<6> reusing them is even more confusing, and no faster
<6> in fact, it can be slower, if you happen to get a cache miss in your 740 line function
<2> Kniht, creates an efficient program
<6> I just said it's no more efficient, and can be less efficient
<2> cache miss?
<2> who?
<6> on the code
<6> unlikely, but possible
<2> I guess its a case of ppl have different coding styles :)
<6> I'd look into refactoring any function that has more than 2 or 3 variables whose entire lifetime exceeds a screen size
<6> !open = Prefer { ifstream file(filename); } over { ifstream file; file.open(filename); }. It's shorter and also conforms to the RAII (`calc raii`) principle.
<2> oh lol I didnt ***ign anything to shape_type :P
<8> Also keeps you from wasting an initialization that's immediately replaced by an ***ignment.
<6> errors like that are harder to catch your style
<2> I see
Return to
#c++
or
Go to some related
logs:
#c++
#networking
#linux
poiuy_qwert
#linux
#chatzone
aoyama kun
sikiyom
#linuxhelp
#linuxhelp
|
|