|
There's nothing going on with that. Literally nothing. Why would the presence of a derived class affect the compilation of base class methods?
|
#
?
Apr 6, 2010 05:08
|
|
|
|
| # ? May 14, 2024 04:09 |
|
|
Mr.Hotkeys posted:Right, but everything works fine. Huh? Did you read "does" as "doesn't"?
|
|
#
?
Apr 6, 2010 05:11
|
|
|
shrughes posted:Huh? Did you read "does" as "doesn't"? Apparently  So if a base class has a private field, derived classes inherit them even though they can't use them? If I have a base class with 60 private fields and derive a class from that with 10 private fields, it will separate enough space in memory for 70 fields when I initialize an instance of the derived class? Sorry if I'm being dumb guys, I'm having a real hard time wrapping my head around this for some reason.
|
|
#
?
Apr 6, 2010 05:14
|
|
|
Mr.Hotkeys posted:So if a base class has a private field, derived classes inherit them even though they can't use them? If I have a base class with 60 private fields and derive a class from that with 10 private fields, it will separate enough space in memory for 70 fields when I initialize an instance of the derived class? Yep, that's what happens. private, protected, and public just affect the visibility of the fields. The purpose of marking something private in a base class is because you think subclass implementors have no business touching that thing directly. You can take anything that's private and make it protected, or take anything protected and make it public, and it won't change the behavior of the running code. (Except that the reflection API will naturally treat them as public or protected, depending on whatever they are, and also, maybe you'll create some naming conflicts).
|
|
#
?
Apr 6, 2010 05:20
|
|
|
Beautiful, that clears it up a bunch, thanks.
|
|
#
?
Apr 6, 2010 05:23
|
|
|
I'm looking around for C++ jobs, and many are in the financial sector. Given that the job listings are so vague, could anyone tell me what kind of software it is that I'd be working on if I went for that? Data analysis/visualisation apps (I know nothing about finance)?
|
|
#
?
Apr 6, 2010 13:21
|
|
|
Avenging Dentist posted:There's nothing going on with that. Literally nothing. Why would the presence of a derived class affect the compilation of base class methods?
|
|
#
?
Apr 6, 2010 13:30
|
|
|
ultra-inquisitor posted:I'm looking around for C++ jobs, and many are in the financial sector. Given that the job listings are so vague, could anyone tell me what kind of software it is that I'd be working on if I went for that? Data analysis/visualisation apps (I know nothing about finance)?
|
|
#
?
Apr 6, 2010 13:46
|
|
|
What does this warning mean? I'm using the pgf90 compiler to compile a fortran program:code:code:
|
|
#
?
Apr 6, 2010 20:45
|
|
|
I think the min function usually takes single precision inputs and you are passing in a double precision number. The compiler is warning you that it has to recast the datatype to get min to work and you may see some loss of precision as a result. It's been years since I've written a single line of FORTRAN so do your own fact checking.
|
|
#
?
Apr 6, 2010 21:56
|
|
|
I'd like to have a loop that is basically a while (true) {} but I want an integer to oscillate linearly between 20 and -20. I can't for the life of me figure out what logic to use exactly. Googling has failed me, but maybe I'm not searching for the right thing. How can I write a infinite loop that oscillates an integer back and forth indefinitely?
|
|
#
?
Apr 7, 2010 01:47
|
|
|
code:
|
|
#
?
Apr 7, 2010 01:56
|
|
|
if (i == 20) i = -20; else i = 20; // Rest of loop Or do you mean that the values between the two (-5, 0, 9, etc) be included? You could do something like this: s = 1 while (true) { if (i % 20 == 0) s = -s; i += s; // Rest of loop } e: Beaten
|
|
#
?
Apr 7, 2010 01:57
|
|
|
sonic bed head posted:I'd like to have a loop that is basically a while (true) {} but I want an integer to oscillate linearly between 20 and -20. I can't for the life of me figure out what logic to use exactly. Googling has failed me, but maybe I'm not searching for the right thing. How can I write a infinite loop that oscillates an integer back and forth indefinitely? Or, where round rounds a number to the nearest integer: code:
|
|
#
?
Apr 7, 2010 01:58
|
|
|
 Thank you all. Had a complete brain problem with that one. I thought about it for a full 10 minutes before deciding that I had to resort to google. It makes perfect sense. I don't know why I forgot about abs();
|
|
#
?
Apr 7, 2010 02:09
|
|
|
shrughes posted:Or, where round rounds a number to the nearest integer: This is the best.
|
|
#
?
Apr 7, 2010 03:29
|
|
|
shrughes posted:Use a variable. Use two variables. This has some weird aliasing issues, not to mention it uses two relatively expensive calls and is hard to immediately follow what it is doing. You might be better off just manually doing the oscillation. code:litghost fucked around with this message at 03:49 on Apr 7, 2010 |
|
#
?
Apr 7, 2010 03:47
|
|
|
litghost posted:This has some weird aliasing issues, not to mention it uses two relatively expensive calls and is hard to immediately follow what it is doing. You might be better off just manually doing the oscillation. whooosh!
|
|
#
?
Apr 7, 2010 04:26
|
|
|
Write an iterator for it. 
|
|
#
?
Apr 7, 2010 04:33
|
|
|
floWenoL posted:whooosh! Indeed  . Wow, I cannot believe I missed the responses below it as well.
|
|
#
?
Apr 7, 2010 05:27
|
|
|
Is there a simple way in batch (DOS\CommandPrompt) to convert files in a folder with no extensions to have a .txt extension? Simplfied example: I have: Folder1 Folder1\asdf1 Folder1\asff2 Folder1\assf3 Folder1\asgf4 Folder1\asef5 Folder1\asaf6 I want to have: Folder1 Folder1\asdf1.txt Folder1\asff2.txt Folder1\assf3.txt Folder1\asgf4.txt Folder1\asef5.txt Folder1\asaf6.txt
|
|
#
?
Apr 7, 2010 19:58
|
|
|
madebz posted:Is there a simple way in batch (DOS\CommandPrompt) to convert files in a folder with no extensions to have a .txt extension? I think REN * *.txt would work. Or maybe REN *. *.txt Or maybe use FORFILES. I don't really know.
|
|
#
?
Apr 7, 2010 21:48
|
|
|
madebz posted:Is there a simple way in batch (DOS\CommandPrompt) to convert files in a folder with no extensions to have a .txt extension? Do you want to do this to every file in the folder, or only files without extensions (e.g. no extension mixed with extension in the same folder)? The dir mask is *. but that'll pick up A)directories and B)files with extensions but no names. If you can guarantee that no subfolders will be in there you could probably do 'ren *. *.txt' if you wanted to gamble.
|
|
#
?
Apr 7, 2010 21:57
|
|
|
Scaramouche posted:Do you want to do this to every file in the folder, or only files without extensions (e.g. no extension mixed with extension in the same folder)? The dir mask is *. but that'll pick up A)directories and B)files with extensions but no names. All files in folder have no extensions and there is no subfolders. I will try ren. Thanks guys EDIT: WORKED!! hell ya
|
|
#
?
Apr 7, 2010 21:59
|
|
|
I am starting a new project and I am trying to figure out the best way to structure the different classes before I get started. I've never really used interfaces before and I feel like this is the kind of situation where they should be used but gently caress if I can figure out how best to do this. The app is a Dungeons and Dragons encounter manager. So the first kinds of objects I need are Monsters and Player Characters. They share mostly the same set of stats, so I figure they should both be subclasses of a "Combatant" parent. Combatant ├ Monster └ Player Character When you set up an encounter to run, it can have a bunch of monsters and a bunch of PCs so I figure it'll just be its own Encounter object with an array of Combatants or something. This next part is the part that eludes me. When you actually go to run the encounter, you will have initiative values of each Combatant, be able to damage Combatants, apply status effects to them, and all sorts of other things. I know implementing all of that poo poo in the Combatant class is the wrong way to do it but I am not sure what the best way to do it is. I feel like an interface should be used for the instances of a Combatant, which provides methods for doing status effects, adjusting current HP, etc. But then now do I implement that in the Combatants? Do I have an entirely new class called CombatantInstance that implements the interface? I would then need to also have a MonsterInstance and PCInstance too? Ugh this is where my understanding of how to do this falls apart and reveals that I don't know as much about programming as I sometimes think I do.
|
|
#
?
Apr 8, 2010 00:47
|
|
|
OverloadUT posted:I know implementing all of that poo poo in the Combatant class is the wrong way to do it... Why is that?
|
|
#
?
Apr 8, 2010 01:41
|
|
|
Because you shouldn't have a whole bunch of properties and methods that are only used in a specific context and will be ignored all other times. I should have explained it a little further. The Combatants are permanent objects. You can import monsters and PCs from XML files exported by other tools. You will have a database of PCs and Monsters that you can add to an encounter template before you "run" it. Combatants can be modified and exported and sent to friends or whatever. In all of those times, the "during combat" properties are not relevant. The Combatant is like a "prototype" of what will actually be in a running encounter. I hope that explains it well enough.
|
|
#
?
Apr 8, 2010 01:46
|
|
|
OverloadUT posted:Because you shouldn't have a whole bunch of properties and methods that are only used in a specific context and will be ignored all other times. 
|
|
#
?
Apr 8, 2010 02:04
|
|
|
How about simply having a CombatantInstance and using composition to contain the Combatant involved and then adding whatever you need to store for a specific instance to that (such as status effects, initiative, ...)
|
|
#
?
Apr 8, 2010 02:07
|
|
|
OverloadUT posted:Because you shouldn't have a whole bunch of properties and methods that are only used in a specific context and will be ignored all other times. I don't think you've really thought this design through. D&D monsters do not (generally) persist across encounters, whereas PCs do. The monster data (in your config file) is closer to a character class than an actual character: i.e. a template to create a character. Basically, you are trying to conflate two different things. The PCs' information absolutely should persist, since any items used, etc. will be gone in the next encounter as well. What you need is something to spawn monsters for the encounter based on monster "classes". You could probably use the factory pattern for this, though I am loathe to recommend design patterns (but even more loathe to write more than I have, so...).
|
|
#
?
Apr 8, 2010 02:45
|
|
|
OverloadUT posted:They share mostly the same set of stats, so I figure they should both be subclasses of a "Combatant" parent. Does not follow.
|
|
#
?
Apr 8, 2010 02:50
|
|
|
Avenging Dentist posted:I don't think you've really thought this design through. D&D monsters do not (generally) persist across encounters, whereas PCs do. floWenoL posted:Does not follow. Monsters have a compendium URL, monster class, group type, etc. PCs have a player class, player name, iPlay4e character token, etc. In short, PCs have properties that monsters do not, and monsters have properties that PCs do not. But they share a lot of properties as well. If that's not a case for using inheritance I don't know what is. Dijkstracula posted:I don't know what this means. You're saying that initiative rolls, status effects, etc, are common between monsters and PCs, so why wouldn't they be fields in the parent class? I'm saying that in well-structured code you shouldn't have just one gigantic class with a billion properties for every single thing that monster might be used for. My app will deal with "monsters" outside the scope of combat where initiative, status effects, and currentHP are all concepts that do not exist. Therefore those properties should not be in the base Monster class.
|
|
#
?
Apr 8, 2010 07:55
|
|
|
Avenging Dentist posted:What you need is something to spawn monsters for the encounter based on monster "classes". You could probably use the factory pattern for this, though I am loathe to recommend design patterns (but even more loathe to write more than I have, so...). Yes this is the basic idea but I agree the factory pattern is not the way to go. A MonsterInstance will be created from a "MonsterTemplate" or "MonsterPrototype" or something like that. But what I am trying to figure out is how best to get the only-during-combat properties and methods in to that MonsterInstance in a clean way, considering the PlayerInstance will need the same thing.
|
|
#
?
Apr 8, 2010 07:57
|
|
|
OverloadUT posted:I'm saying that in well-structured code you shouldn't have just one gigantic class with a billion properties for every single thing that monster might be used for. My app will deal with "monsters" outside the scope of combat where initiative, status effects, and currentHP are all concepts that do not exist. Therefore those properties should not be in the base Monster class. This argument is tenuous at best. (Especially since I can't see why you'd store initiative with the character anyway, as opposed to the key into a sorted dictionary that you iterate over for the round.) Other status effects absolutely do exist outside of combat rounds. (Ok, this is in 3.5, but if you use 4e, then  )Also I'm pretty sure D&D monsters don't even really have non-combat stats since they're, you know, monsters. OverloadUT posted:Yes this is the basic idea but I agree the factory pattern is not the way to go. A MonsterInstance will be created from a "MonsterTemplate" or "MonsterPrototype" or something like that. A rose by any other name EDIT: here is some slightly more specific advice: 1) You are overdesigning your idea (and I'm going to presume underimplementing, since it doesn't sound like you have a proof-of-concept yet), though this is perhaps fitting given the D&D rules set's tendency to do the same. 2) There's nothing that says you have to serialize all the combat data back to the source file for the character (and you probably don't have to serialize any of it for monsters, unless they're persistent, in which case they're basically characters). 3) You're worrying about the complexity of adding a few members for HP and the like while seemingly ignoring the complexity of all sorts of other general-purpose rules necessary for characters (inventory management, XP, skills, to name a few). 4) If you're hell-bent on keeping HP out of the Character class, why not put it in the Encounter class and have characters act as controllers (and buckets of stats) with combat changes occurring in the Encounter's data? 5) I question the purpose of this in the first place, since how would the DM cheat on his dice rolls if the game were computer-assisted? Avenging Dentist fucked around with this message at 08:31 on Apr 8, 2010 |
|
#
?
Apr 8, 2010 08:07
|
|
|
Avenging Dentist posted:1) You are overdesigning your idea (and I'm going to presume underimplementing, since it doesn't sound like you have a proof-of-concept yet), though this is perhaps fitting given the D&D rules set's tendency to do the same. 
|
|
#
?
Apr 8, 2010 09:27
|
|
|
OverloadUT posted:In short, PCs have properties that monsters do not, and monsters have properties that PCs do not. But they share a lot of properties as well. If that's not a case for using inheritance I don't know what is. Rectangular prisms and cars have a length, width, and height. Does that mean rectangles and cars should both inherit from a LengthWidthAndHeight class? Point masses and photons have both a position and velocity. Does that mean they should both inherit from a HasLocationAndVelocity class? And should that inherit from the HasVelocity class? (Non-point masses can't be quite said to have a single location, but they can still have a velocity.) What would the implementation look like? code:code:Anyway, you might say, "Hey, all kinds of masses have these certain kinds of information so we should just ..." code:Is that good? What is inheritance anyway? What is inheritance, anyway? When something of type X inherits from type Y, that means there exists a conversion function convert_X_to_Y which takes a parameter of type X and returns a parameter of type Y. That's all it means! Depending on the language you're using, these parameters might be passed and returned by reference, or things are always references, or pointers. The conversion operator might be implicit. There is nothing different or more or less poweful between having X inherit from Y and defining a function of type X -> Y. And so instead of having some class like this: code:code:You can also have something like this: code:code:If you have a bunch of common properties, you might just want to use hold a reference to something that holds those common properties, as shown above. Or you could forget about generality at all -- and just manually rewrite the same property names with the same types. This is fine too. You won't die from this. In fact, you have the benefit of the classes not being entangled with one another. If you are having things inherit from things just because they share some properties, this tends to grow into some horrible mess of inheritance with stuff having different properties. Things never neatly align themselves into some inheritance hierarchy, and when you try to force them into one, you end up affecting the evenhandedness with which you should make design decisions. You end up designing things in ways that unnaturally fit into the existing inheritance hierarchy. Inheritance can be nice with the way it lets you write less explicit code, but composition does too. Also, as things grow, you tend to get an ugly mixture of inheritance and composition and interfaces and wrappers strewn all about. If you just want to avoid rewriting properties, go with composition. If you want the generalization that comes with inheritance, you're out of luck because as described above, inheritance doesn't give you any generalization. It just gives you an implicit conversion operator. Premature generalization is the root of OOP.
|
|
#
?
Apr 8, 2010 09:45
|
|
|
I've been trying to read on the concept of zippers lately. I don't fully grasp the concept of continuations (or their whole power) yet and most examples I've read seem to focus on their use. For the sake of the question, let's use a binary search tree as the structure being used. I am wondering what do zippers have that can't be done by defining a new data structure holding a stack/list of the previously visited nodes and implementing operations that way. It seems to me both concepts would be equivalent: O(1) access to the previous node, left or right if there is any (go to the previous node, then the other child?), O(log n) updates (update every element of the stack to take the value of the previous one, assumes sharing of unchanged elements), etc. There must be something I'm missing here. I think some of it might be the generality of the zipping implementation, but I'm not too sure. Any idea, tip, or good reading?
|
|
#
?
Apr 8, 2010 14:47
|
|
|
I'm working on implementing a log based file system for a file as a class project. I have a good amount of it working on my 64 bit OS X laptop, but when I try to run the code on the CS department's 32 bit linux machines, I get a seg fault. The API we're given allows writing DISK_SECTOR_SIZE (512) bytes at a time. Our log record consists of the 512 bytes the user wants to write as well as some metadata (which sector he wants to write to, the type of operation, etc). All in all, the size of the "record" object is 528 bytes, which means each log record spans 2 sectors on the disk. The first record writes 0-512 on sector 0, and 0-15 on sector 1. The second record writes 16-512 on sector 1, and 0-31 on sector 2. The third record writes 32-512 on sector 2, and 0-47 on sector 3. ETC. So what I do is read the two sectors I'll be modifying into 2 freshly allocated buffers, copy starting at record into buf1+the calculated offset for 512-offset bytes. This works correctly on both machines. However, the second memcpy fails. Specifically, "record+DISK_SECTOR_SIZE-offset" in the below code segfaults, but only on the linux machine. Running some random tests, it gets more curious. The linux machine reports sizeof(Record) to be 528. Therefore, if I tried to memcpy from record+500 into buf for 1 byte, it shouldn't have a problem. In fact, the biggest offset I can get from record is 254. That is, memcpy(buf1, record+254, 1) works, but memcpy(buf1, record+255, 1) segfaults. Does anyone know what I'm missing? code:ndrz fucked around with this message at 19:15 on Apr 8, 2010 |
|
#
?
Apr 8, 2010 18:40
|
|
|
Sup mate! If you have a binary tree and a list like [Left,Right,Left,Left,Left] that tells you where you are in the tree i.e. the current node, and you want to modify it, you have to traverse the whole list before getting to your desired node and modifying it, so that's O(n) (or O(log n) if you consider n to be the number of elements in the tree and the tree is balanced). If you want to move around the tree a lot, you have to start from the root for each movement and traverse that list of Left and Right, so you'll be doing a lot of O(n) operations. If you have a zipper, moving around is O(1) and so is modifying the element under focus. Instead of explaining zippers, I'll point to this excellent article about them: http://www.haskell.org/haskellwiki/Zipper also this new blog post about them is cool too: http://blog.ezyang.com/2010/04/you-could-have-invented-zippers/
|
|
#
?
Apr 8, 2010 18:44
|
|
|
|
| # ? May 14, 2024 04:09 |
|
|
I was writing a program to strip data from XML files, and give me [tagname, data] pairs. Of course I ran into problems with nested tags. Would a linked list be a good way to keep track of which tag I am in? <rss> -- <channel> -- <item> </item> -- </channel> -- </rss> Thoughts?
|
|
#
?
Apr 8, 2010 19:08
|
|
