-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Programming |OT| C is better than C++! No, C++ is better than C
- Thread starter Kikarian
- Start date
Stumpokapow
listen to the mad man
I am storing some data for which I have legal liability. The data relates to human subjects research.
What's the current security best practice for storing web accessible personally identifying information (say, social or credit card or merchant token or billing address)? This is info that needs to be decrypted, not just hashed. I would guess AES is the best encryption option, but I have a few use case questions.
Say for ease of explanation I will be storing data in a flat file, with each line being (in practice this will be in an actual database, but for our conversation here say it's flat):
username | somethingsecret
What's the best practice?
1) Do I use one aes key for everyone, or separate aes keys? Assume the client can't store everything and I need to be able to do both encryption and decryption on the server.
2) What's a relatively future-proof key size currently?
3) If I need to implement, for example, a search on the encrypted field, is the best practice to temporarily decrypt the entire db, do the search, and then junk the decrypted copy? Privacy/security is more important than speed. Should I maybe do this on a ramdisk and then destroy the ramdisk? Yuck.
What's the current security best practice for storing web accessible personally identifying information (say, social or credit card or merchant token or billing address)? This is info that needs to be decrypted, not just hashed. I would guess AES is the best encryption option, but I have a few use case questions.
Say for ease of explanation I will be storing data in a flat file, with each line being (in practice this will be in an actual database, but for our conversation here say it's flat):
username | somethingsecret
What's the best practice?
1) Do I use one aes key for everyone, or separate aes keys? Assume the client can't store everything and I need to be able to do both encryption and decryption on the server.
2) What's a relatively future-proof key size currently?
3) If I need to implement, for example, a search on the encrypted field, is the best practice to temporarily decrypt the entire db, do the search, and then junk the decrypted copy? Privacy/security is more important than speed. Should I maybe do this on a ramdisk and then destroy the ramdisk? Yuck.
From when I did some research a few months ago AES seemed like the preferred solution for general encryption. Dunno about key sizes.
I'm not sure you gain much by having separate keys. If the key storage is compromised then it would seem all keys would be, the only benefit is if the storage location differed (ie the clients keep their own key). Since you need to decrypt on the server and programmatically varying storage locations is just a dumb obfuscation layer I'd say it probably doesn't matter.
As far as search goes I don't think you have any good options, private information is almost by definition not searchable. Your strategy seems reasonable but it opens holes as someone with access could grab your plain text database when it's created. It's not safe as much as it is "better than nothing." I think searching records one-by-one in the app and only decrypting the searched fields is about the safest way to do it but expect it to not be useful unless the database is small.
I'm not sure you gain much by having separate keys. If the key storage is compromised then it would seem all keys would be, the only benefit is if the storage location differed (ie the clients keep their own key). Since you need to decrypt on the server and programmatically varying storage locations is just a dumb obfuscation layer I'd say it probably doesn't matter.
As far as search goes I don't think you have any good options, private information is almost by definition not searchable. Your strategy seems reasonable but it opens holes as someone with access could grab your plain text database when it's created. It's not safe as much as it is "better than nothing." I think searching records one-by-one in the app and only decrypting the searched fields is about the safest way to do it but expect it to not be useful unless the database is small.
Stumpokapow
listen to the mad man
From when I did some research a few months ago AES seemed like the preferred solution for general encryption. Dunno about key sizes.
I'm not sure you gain much by having separate keys. If the key storage is compromised then it would seem all keys would be, the only benefit is if the storage location differed (ie the clients keep their own key). Since you need to decrypt on the server and programmatically varying storage locations is just a dumb obfuscation layer I'd say it probably doesn't matter.
As far as search goes I don't think you have any good options, private information is almost by definition not searchable. Your strategy seems reasonable but it opens holes as someone with access could grab your plain text database when it's created. It's not safe as much as it is "better than nothing." I think searching records one-by-one in the app and only decrypting the searched fields is about the safest way to do it but expect it to not be useful unless the database is small.
Okay sounds like my intuition is OK and there's nothing obvious I'm missing. Thanks.
Codeacious
Banned
That's up to you, but like Somnid said, you don't really gain too much from having multiple keys unless you want to individually distribute them to different storage locations/machines. With multiple keys, you do gain the advantage of not losing the entire database if you lose one key file, but it's probably best to back up any keys you make from this somewhere secure for safety anyway (say, a flash drive on your personal keychain that only ever gets used with your personal machine).1) Do I use one aes key for everyone, or separate aes keys? Assume the client can't store everything and I need to be able to do both encryption and decryption on the server.
AES-256 should be sufficient. Even the best published attacks I could find ([1], [2]) seem to only be marginally better than brute force. Given that CPU power has sort of hit a wall in the past few years, I'd imagine that it'll be future-proofed for some years to come (unless an attacker starts throwing massive amounts of distributed resources at your database). But how many years are you thinking of future proofing this for? If it's a long time, you might want to consider something even more powerful.2) What's a relatively future-proof key size currently?
If you're concerned about an attacker being able to read your memory, you'll have to be very careful not only how you handle the decrypted fields of the database, but the way the AES key itself is handled by whatever program is doing the actual decrypting (if they can identify and read the memory the AES key is loaded into, you're sunk, so it's important to know if there's side-channels in the decryption program you're using that would allow attackers to identify the key in memory), on top of whatever results you get from the database after the search. It's good practice to decrypt one row, write cryptographically generated random bytes to that memory, and then use a different, non-adjacent region of memory for the next row (if you use the same address for all rows, if an attacker identifies it early on and can read it, they'll get most of the database). Then, you can just write out the encrypted row(s) that match to a file, and then load it with a secure text editor that can use your AES key later (or, load it up on a machine you know is secure from attackers and decrypt it to plaintext there).3) If I need to implement, for example, a search on the encrypted field, is the best practice to temporarily decrypt the entire db, do the search, and then junk the decrypted copy? Privacy/security is more important than speed. Should I maybe do this on a ramdisk and then destroy the ramdisk? Yuck.
I am storing some data for which I have legal liability. The data relates to human subjects research.
What's the current security best practice for storing web accessible personally identifying information (say, social or credit card or merchant token or billing address)? This is info that needs to be decrypted, not just hashed. I would guess AES is the best encryption option, but I have a few use case questions.
Say for ease of explanation I will be storing data in a flat file, with each line being (in practice this will be in an actual database, but for our conversation here say it's flat):
username | somethingsecret
What's the best practice?
1) Do I use one aes key for everyone, or separate aes keys? Assume the client can't store everything and I need to be able to do both encryption and decryption on the server.
2) What's a relatively future-proof key size currently?
3) If I need to implement, for example, a search on the encrypted field, is the best practice to temporarily decrypt the entire db, do the search, and then junk the decrypted copy? Privacy/security is more important than speed. Should I maybe do this on a ramdisk and then destroy the ramdisk? Yuck.
Perhaps you've already carefully considered your design, but why use individually encrypted database fields? Are you giving this encrypted data to users who shouldn't be able to decrypt it? Why give it to them at all? If you're not giving it to them, why does it matter whether or not it's encrypted?
I'm not a security expert, and even if I were, I don't know enough about your application to actually assess it. It's not possible to design a secure system unless you know who and what you're securing it against.
There is a stack exchange dedicated to security. You may find this question relevent. You may wish to ask your own questions, too.
A few more interesting threads:
- https://news.ycombinator.com/item?id=6116243
- http://security.stackexchange.com/q/59580/93724
cpp_is_king
Member
I am storing some data for which I have legal liability. The data relates to human subjects research.
What's the current security best practice for storing web accessible personally identifying information (say, social or credit card or merchant token or billing address)? This is info that needs to be decrypted, not just hashed. I would guess AES is the best encryption option, but I have a few use case questions.
Say for ease of explanation I will be storing data in a flat file, with each line being (in practice this will be in an actual database, but for our conversation here say it's flat):
username | somethingsecret
What's the best practice?
1) Do I use one aes key for everyone, or separate aes keys? Assume the client can't store everything and I need to be able to do both encryption and decryption on the server.
2) What's a relatively future-proof key size currently?
3) If I need to implement, for example, a search on the encrypted field, is the best practice to temporarily decrypt the entire db, do the search, and then junk the decrypted copy? Privacy/security is more important than speed. Should I maybe do this on a ramdisk and then destroy the ramdisk? Yuck.
Best practice would be to not store it at all. Use an authorized payment vendor. If you're not collecting payment, then you shouldn't be storing the credit card number in the first place.
Do not re-invent this service yourself.
Stumpokapow
listen to the mad man
Best practice would be to not store it at all. Use an authorized payment vendor. If you're not collecting payment, then you shouldn't be storing the credit card number in the first place.
Do not re-invent this service yourself.
This has nothing to do with payment which is why I didn't mention payment in my post--it relates to human subjects research, which is why I did mention it in my post. I recognize that maybe using "merchant token" or "credit card" as examples of personally identifying information may have been confusing; I was just trying to clarify without giving details about the information I'm dealing with. This is not a task that has a pre-existing service. It's not commercial.
The confusion probably came from here:This has nothing to do with payment which is why I didn't mention payment in my post--it relates to human subjects research, which is why I did mention it in my post.
Stumpokapow said:What's the current security best practice for storing web accessible personally identifying information (say, social or credit card or merchant token or billing address)?
cpp_is_king
Member
This has nothing to do with payment which is why I didn't mention payment in my post--it relates to human subjects research, which is why I did mention it in my post. I recognize that maybe using "merchant token" or "credit card" as examples of personally identifying information may have been confusing; I was just trying to clarify without giving details about the information I'm dealing with. This is not a task that has a pre-existing service. It's not commercial.
Ahh you specifically mentioned billing addresses and credit card numbers.
Were those just generic examples and you're not actually storing those?
Are you worried about someone rooting your server or someone using the web interface to access other users data?
If it's the former, store the database on a different machine than the web server, open only 1 port for incoming database connections and only from the ip of the web server. Store it in AWS and block level encrypt the entire disk.
If it's the latter, encryption won't help anyway because the exploit would come in your application layer unless you use a key that only the user knows, such as one derived from their password but it would be quite slow probably, depending on how many QPS you anticipate
Perhaps a combination of the two. Run the server on appengine which talks to a database on a different machine with encrypted disk etc
Elfforkusu
Member
0. Make sure you don't implement any crypto yourself. Make sure you do understand how to use whatever implementation you go with.I am storing some data for which I have legal liability. The data relates to human subjects research.
What's the current security best practice for storing web accessible personally identifying information (say, social or credit card or merchant token or billing address)? This is info that needs to be decrypted, not just hashed. I would guess AES is the best encryption option, but I have a few use case questions.
Say for ease of explanation I will be storing data in a flat file, with each line being (in practice this will be in an actual database, but for our conversation here say it's flat):
username | somethingsecret
What's the best practice?
1) Do I use one aes key for everyone, or separate aes keys? Assume the client can't store everything and I need to be able to do both encryption and decryption on the server.
2) What's a relatively future-proof key size currently?
3) If I need to implement, for example, a search on the encrypted field, is the best practice to temporarily decrypt the entire db, do the search, and then junk the decrypted copy? Privacy/security is more important than speed. Should I maybe do this on a ramdisk and then destroy the ramdisk? Yuck.
0.a. I don't remember what the current state of the art AES mode is supposed to be. CTR? You want to encrypt-then-MAC. Again, you don't want to implement any of this yourself, but you should at least learn/understand what you're using.
0.b. For those reasons, it might be worth using NaCl::secret_box, which basically does the right thing has wrappers in many languages. e.g. ruby: https://github.com/cryptosphere/rbnacl/wiki/Secret-Key-Encryption
0.c. However, this is only if you have to roll some technology yourself. You want to roll as little as you can.
1. The question is really, "what's the attack vector?" If it's just to secure data at rest, something like a single password to encrypted the HDD/SSD in question is probably sufficient. Have a data center? Same deal, except now you have multiple machines to secure instead of one. You're not realistically going to be able to protect that data from a malicious process on the machine no matter what you do. If you have different users accessing the data who should only see their subset of it, you probably want additional controls (e.g. per user passwords and ACLs, or something of that sort) to enforce that user A can't see user B's data. But again, it depends on what the attack vectors are that you're trying to defend against.
2. For symmetric key crypto, 256 bits (i.e. AES256) should be sufficient for almost any use case.
3. The common approach for databases with PII that needs to be encrypted and yet still used is, AFAIK, to (A) encrypt the HDDs will full disk encryption, (B) secure the machines network wise (DMZ, separate application and data servers, etc), (C) secure the machines physically (locked, secure data center), (D) appeal to authority, i.e. what HIPAA does, and explain in writing with patient earnestness that you're doing everything you can whether that's true or not.
3.a. There's a decent amount of bleeding edge research on searching encrypted data in place (http://outsourcedbits.org/2013/10/06/how-to-search-on-encrypted-data-part-1/), but I don't know of any software database solutions that implement such things. But it's also true that I haven't looked into this seriously in a few years, and something may have changed.
3.b. ... but if said something hasn't made it into Postgres yet, it's probably not worth relying on. It's certainly not worth trying to code, unless you're angling for that PhD.
edit: if my little brain dump is confusing or unhelpful,
This is probably a good place to start.Perhaps a combination of the two. Run the server on appengine which talks to a database on a different machine with encrypted disk etc
Oh, cool, I just received an offer for a position as a tutor for one of the courses I completed last semester. It's five hours a week, so I obviously don't expect much pay. But it doesn't matter: It's a good opportunity to get to know some people from the institute, especially as I still don't have a clue what kind of Master's Thesis to choose.
The job involves helping students with their programming assignments and grade the assignments. Fortunately, the grading of the programming tasks is automated, so I'll just have to look at the theory questions which are part of the assignments.
The job involves helping students with their programming assignments and grade the assignments. Fortunately, the grading of the programming tasks is automated, so I'll just have to look at the theory questions which are part of the assignments.
Just a quick question; how do you guys deal with idiots who do not grasp the concept of abstraction, yet proclaim they do?
I guess I need to know the context.
Just a quick question; how do you guys deal with idiots who do not grasp the concept of abstraction, yet proclaim they do?
There is a difference between not getting "an abstraction" and not getting abstraction. Are you sure it's the later?
There is a difference between not getting "an abstraction" and not getting abstraction. Are you sure it's the later?
I guess I need to know the context.
We have several (6 now, but still growing) classes which all implement the same functionality x, some with a slight variation. I suggested we'd use an abstract class to implement the functionality, using overrides to accomodate the variations by setting parameters.
His argument to not use it is that it would result in a "chaotic code mess"...
It certainly can if your project becomes very large. Composition with interfaces is preferred over inheritance. I recommend using Strategy pattern.We have several (6 now, but still growing) classes which all implement the same functionality x, some with a slight variation. I suggested we'd use an abstract class to implement the functionality, using overrides to accomodate the variations by setting parameters.
His argument to not use it is that it would result in a "chaotic code mess"...
Unit tests I find to be a magical cure-all for common code problems. Mandatory unit tests are a great way to ensure people reuse code because it increases the tedium of non-reuse (even if they want to continue down that path you have something to check when refactoring). Same with overly long methods and methods with side effects, if you don't want immensely difficult tests to write you stop doing that.
It certainly can if your project becomes very large. Composition with interfaces is preferred over inheritance. I recommend using Strategy pattern.
That definitely sounds like the way to go in this case.
One question for the more experienced people with ORM's (or at least Hibernate): For some projects I work on we have pretty much all business logic in service methods. I'd like to refactor parts to get the business logic back into the domain model, but this seems to be quite difficult if you want to use a design pattern like strategy.
Usually strategies don't contain any data, so what's the correct way to store them in the database? Use an enumeration or something similar to describe what strategy is used, then store the enum value and set the strategy when the enum value is set by the ORM? Or are there better methods?
Example of my idea:
Code:
IE:
public class DbObject
{
private Strategy aStrategy;
public void setStrategy(StrategyEnum enum)
{
switch(enum) {
case 'aStrat':
aStrategy = new aStrategy();
break;
....
}
}
public StrategyEnum getStrategy() {
return aStrategy.getEnum();
}
}HammerOfThor
Member
So I just discovered the concept of a "quine", and I don't get it.
The goal is to output the source code, but all examples I see has the source code as a string. So its just outputting the string. Whats the point of this? It would be more interesting to read it's own files and output that text. I don't see the challenge in writing code, then putting the code in a string, then outputting it.
Or am I missing something?
The goal is to output the source code, but all examples I see has the source code as a string. So its just outputting the string. Whats the point of this? It would be more interesting to read it's own files and output that text. I don't see the challenge in writing code, then putting the code in a string, then outputting it.
Or am I missing something?
deltatheta
Member
So I just discovered the concept of a "quine", and I don't get it.
The goal is to output the source code, but all examples I see has the source code as a string. So its just outputting the string. Whats the point of this? It would be more interesting to read it's own files and output that text. I don't see the challenge in writing code, then putting the code in a string, then outputting it.
Or am I missing something?
Try writing one yourself and you'll find out quickly why that doesn't work.
HammerOfThor
Member
Try writing one yourself and you'll find out quickly why that doesn't work.
Ooohh, for some reason I was thinking the output doesn't output the string of code, but it does.
Yeah thats an interesting problem to solve.
cpp_is_king
Member
We have several (6 now, but still growing) classes which all implement the same functionality x, some with a slight variation. I suggested we'd use an abstract class to implement the functionality, using overrides to accomodate the variations by setting parameters.
His argument to not use it is that it would result in a "chaotic code mess"...
There's not enough detail there about what the functionality is, and what the variations are to conclude which (if either) of you are right. For example, if the parameters you're going to set are like a few booleans, then you could just have one class, store the few booleans as member,s and provide one method to set them, then just have all the functionality in the base class.
If entire algorithms need to change (like using a quick sort versus a merge sort) then something like a strategy pattern like Makai suggested might be better.
So yea, it's not obvious to me with this amount of information what the proper solution is.
There's been an absolute explosion of students enrolling in CS at my school. So much so that the CS department had to turn away hundreds of students. Something it had never needed to do before, because it could accommodate them with extra sections.
Even that's not enough now.
I'm mildly surprised. How many of these students will thrive? How many will barely scrap by? How many will altogether abandon when they realize they can't hack it?
It'd suck if you invested 4 years at school, and then realize in the workplace that your brain just ain't suited to problem-solving.
Even that's not enough now.
I'm mildly surprised. How many of these students will thrive? How many will barely scrap by? How many will altogether abandon when they realize they can't hack it?
It'd suck if you invested 4 years at school, and then realize in the workplace that your brain just ain't suited to problem-solving.
CornBurrito
Member
There's been an absolute explosion of students enrolling in CS at my school. So much so that the CS department had to turn away hundreds of students. Something it had never needed to do before, because it could accommodate them with extra sections.
Even that's not enough now.
I'm mildly surprised. How many of these students will thrive? How many will barely scrap by? How many will altogether abandon when they realize they can't hack it?
It'd suck if you invested 4 years at school, and then realize in the workplace that your brain just ain't suited to problem-solving.
From what I hear a lot of people end up switching majors.
Though there are horror stories of people who graduate from a 4 year program, with a CS degree, and yet can't even figure out for loops or Fizz Buzz level problems.
From what I hear a lot of people end up switching majors.
Though there are horror stories of people who graduate from a 4 year program, with a CS degree, and yet can't even figure out for loops or Fizz Buzz level problems.
My freshman year (granted this is over 10 years ago at this point) was two full (40ish) 201 classes, followed up by a single 202 class the next semester.
The following years were ~10-20 students per class.
I've seen people graduating from a 2+3 years program in CS and just hating anything related to computer (and, not surprisingly, having really poor understanding of anything CS-related). They mostly obtained their graduation from communication, humanities, etc.From what I hear a lot of people end up switching majors.
Though there are horror stories of people who graduate from a 4 year program, with a CS degree, and yet can't even figure out for loops or Fizz Buzz level problems.
When asked, they said they ended there because it was the highest rated school. I really find this sad. I'm really wondering what they're doing now.
CornBurrito
Member
I must be misunderstanding inheritance.
I have the Dice class.
Dice have a private member variable called sides.
It has the public member function setFaces(), with this syntax:
void setFaces(int faces)
{ sides = faces}
I have the FunnyDice class. It inherits from the Dice class.
It has the private member variable called sides.
I didn't rewrite the public member function because I thought it inherits that automatically.
In my main I declare two dice.
Dice d1
FunnyDice d2
d1.setFaces(6);
d2.setFaces(6);
However, the set function for d2 is NOT working. What's up?
I have the Dice class.
Dice have a private member variable called sides.
It has the public member function setFaces(), with this syntax:
void setFaces(int faces)
{ sides = faces}
I have the FunnyDice class. It inherits from the Dice class.
It has the private member variable called sides.
I didn't rewrite the public member function because I thought it inherits that automatically.
In my main I declare two dice.
Dice d1
FunnyDice d2
d1.setFaces(6);
d2.setFaces(6);
However, the set function for d2 is NOT working. What's up?
I must be misunderstanding inheritance.
I have the Dice class.
Dice have a private member variable called sides.
It has the public member function setFaces(), with this syntax:
void setFaces(int faces)
{ sides = faces}
I have the FunnyDice class. It inherits from the Dice class.
It has the private member variable called sides.
I didn't rewrite the public member function because I thought it inherits that automatically.
In my main I declare two dice.
Dice d1
FunnyDice d2
d1.setFaces(6);
d2.setFaces(6);
However, the set function for d2 is NOT working. What's up?
It doesn't override the private variable "sides", it still exists, you just can't touch it in FunnyDice (and thus can have a member of the same name). So when you call setFaces it uses Dice's version of the function which points to Dice's sides, FunnyDice's sides will never be set. You have to override the function or make the member visible to FunnyDice.
Could you post the class definition?I must be misunderstanding inheritance.
Are "sides" defined as private?
I may have not understood the problem, but you can't access anything private from a different class, even if it's an ancestor...
CornBurrito
Member
It doesn't override the private variable "sides", it still exists, you just can't touch it in FunnyDice (and thus can have a member of the same name). So when you call setFaces it uses Dice's version of the function which points to Dice's sides, FunnyDice's sides will never be set. You have to override the function or make the member visible to FunnyDice.
Huh, so any instance of an inherited class still needs its own getter/setter functions?
Actually... any function that would need to incorporate private member variables would need to be rewritten in the child class?
Could you post the class definition?
Are "sides" defined as private?
I may have not understood the problem, but you can't access anything private from a different class, even if it's an ancestor...
sides is indeed private.
cpp_is_king
Member
Huh, so any instance of an inherited class still needs its own getter/setter functions?
Actually... any function that would need to incorporate private member variables would need to be rewritten in the child class?
sides is indeed private.
No. Any inherited class automatically has all of the stuff from the base class. You don't have to add anything. public / private just means whether or not you're allowed to use it.
Code:
class Foo {
private:
int sides;
public:
int getsides() const { return sides; }
};
class Bar : public Foo {
int baz() const { return sides; }
int buzz() const { return getsides(); }
};Foo::getsides() can access sides because it's the same class.
Bar::baz() is a compiler error because sides is private, Bar can't access it.
Bar::buzz() is fine because getsides() is public, Bar can access it.
CornBurrito
Member
No. Any inherited class automatically has all of the stuff from the base class. public / private just means whether or not you're allowed to use it.
So then why wouldn't a function requiring access to private member variables not need to be rewritten in the child class case?
edit:
Ok but why bother writing buzz() when you can simply rewrite getsides() entirely in the child class?
I suppose this is better for longer functions? But I mean... you could copy/paste.
Depends... You can define nbsides as protected in the ancestor, and not define another nbside in the child. This way, the child will inherit nbsides, and will be able to access it.Huh, so any instance of an inherited class still needs its own getter/setter functions?
So the child as "two" nbsides: one from the ancestor, one from itself.sides is indeed private.
Quick'n dirty proof:
Code:
class dice {
private :
int nbsides;
public :
void setSides(int n) { nbsides = n; }
dice() {}
~dice() { printf("dice destructor: nbsides = %d\n", nbsides); }
};
class funny_dice : public dice {
private :
int nbsides;
public :
void setFunnySides(int n) { nbsides = n; }
funny_dice() {}
~funny_dice() { printf("funny_dice destructor: nbsides = %d\n", nbsides); }
};
int main(int argc, char* argv[]) {
funny_dice d;
d.setSides(2);
d.setFunnySides(1);
}outputs:
Code:
funny_dice destructor: nbsides = 1
dice destructor: nbsides = 2cpp_is_king
Member
So then why wouldn't a function requiring access to private member variables not need to be rewritten in the child class case?
Because the function is defined in the base class, which does have access. Member access specifiers only apply to single thing you're accessing (function, variable, etc) not all the stuff that might be referenced from within that function.
So then why wouldn't a function requiring access to private member variables not need to be rewritten in the child class case?
edit:
Ok but why bother writing buzz() when you can simply rewrite getsides() entirely in the child class?
I suppose this is better for longer functions? But I mean... you could copy/paste.
You wouldn't rewrite buzz, that ws just for the sake of illustration. But the code could be more complicated, you might implement buzz() as Sqrt[getsides() % 10] + 7 for example
Again though, nobody is "rewriting" getsides() anywhere. You write it one time, in the base class. The derived class does not rewrite it. The derived class can't rewrite it, because it requires access to a private member, which Bar doesn't have
You can use getsides() with an object of the child class, but you can't rewrite a getsides() methods in the child class without using the getsides() method from the ancestor class, since nbsides is only available in the ancestor class...Ok but why bother writing buzz() when you can simply rewrite getsides() entirely in the child class?
Or I don't understand the question...
CornBurrito
Member
Because the function is defined in the base class, which does have access. Member access specifiers only apply to single thing you're accessing (function, variable, etc) not all the stuff that might be referenced from within that function.
"So when you call setFaces it uses Dice's version of the function which points to Dice's sides, FunnyDice's sides will never be set. You have to override the function or make the member visible to FunnyDice."
I guess I don't get why this wouldn't be a problem with other functions.
Like if I had this function in the Dice class
int SizeOf()
{ return sides * 100 }
Isn't sides going to point to the sides in Dice, not funny Dice?
CornBurrito
Member
Again though, nobody is "rewriting" getsides() anywhere. You write it one time, in the base class. The derived class does not rewrite it. The derived class can't rewrite it, because it requires access to a private member, which Bar doesn't have
But in my case BOTH Die and FunnyDie have the private member variable, sides.
Hell, I just tested this. I was absolutely 100% able to simply copy and paste the setSides() function into the FunnyDie class. And it worked. Then I was able to set the sides of FunnyDie.
You can always put aAgain though, nobody is "rewriting" getsides() anywhere. You write it one time, in the base class. The derived class does not rewrite it. The derived class can't rewrite it, because it requires access to a private member, which Bar doesn't have
Code:
int getSides() { return dice::getSides(); }Makes no sense, but I've already seen it (from someone who thought he had to redifine all methods in the children so that it call the parents methods ^_^ )
Randolph Freelander
Member
But in my case BOTH Die and FunnyDie have the private member variable, sides.
The question is why does FunnyDie have a sides member. Why do you need it? Must it truly hold a different value than the base member?
CornBurrito
Member
The question is why does FunnyDie have a sides member. Why do you need it? Must it truly hold a different value than the base member?
Yes.
I need it to be the case that there can be a regular Die with 6 sides, and a LoadedDie with say... 4 sides.
cpp_is_king
Member
Right, which you don't need. Die already has sides. Don't copy it in FunnyDie. this is wrong.But in my case BOTH Die and FunnyDie have the private member variable, sides.
Hell, I just tested this. I was absolutely 100% able to simply copy and paste the setSides() function into the FunnyDie class. And it worked. Then I was able to set the sides of FunnyDie.
Yes, but now Die and Funny die (the same object) have 2 copies of sides which don't agree with each other. Take sides out of FunnyDie, put getSides() and setDies() in die, make them public.
Now I'm confused. What does "sides" mean in Die, and what does "sides" mean in FunnyDie?Yes.
Randolph Freelander
Member
Yes.
I need it to be the case that there can be a regular Die with 6 sides, and a LoadedDie with say... 4 sides.
At the same time?
Like, we get that sides is variable. But is there a reason for your instance of FunnyDie to literally have 2 simultaneous values in a member field called "sides."
CornBurrito
Member
Right, which you don't need. Die already has sides. Don't copy it in FunnyDie. this is wrong.
Yes, but now Die and Funny die (the same object) have 2 copies of sides which don't agree with each other. Take sides out of FunnyDie, put getSides() and setDies() in die, make them public.
Now I'm confused. What does "sides" mean in Die, and what does "sides" mean in FunnyDie?
Ok lets say I take sides out of FunnyDie. It doesn't need them. When I do setSides() in die (which was already public), and have a FunnyDie object try to use it, it won't be pointing at the wrong thing now? FunnyDie must be able to have a different number of sides than regular Die.
Sides means number of sides on the die. A D6 has six sides. A d20 twenty.
At the same time?
Like, we get that sides is variable. But is there a reason for your instance of FunnyDie to literally have 2 simultaneous values in a member field called "sides."
Ah I see what you mean. No.
It doesn't do what you think (I believe)...Hell, I just tested this. I was absolutely 100% able to simply copy and paste the setSides() function into the FunnyDie class. And it worked. Then I was able to set the sides of FunnyDie.
There's TWO "nbsides" in your FunnyDice class : one [labeled A], impossible to access directly, from the ancestor. A second [labeled B] one from the child class.
If you don't define a setSide() in FunnyDice, and call setSide() in a FunnyDice object, it calls the dice::setSide() method, which access nbsides[A].
If you define a setSide() in FunnyDice and call it, it access nbsides.
Redifining both a setSides() alongside a nbside in FunnyDice will obviously work, but I don't think that what you'll want (FunnyDice will have TWO nbsides and its setSide will replace the parent setSide)
Each dice (each instance of either class), be it Dice or FunnyDice, can have a different number of sides.Ok lets say I take sides out of FunnyDie. It doesn't need them. When I do setSides() in die (which was already public), and have a FunnyDie object try to use it, it won't be pointing at the wrong thing now? FunnyDie must be able to have a different number of sides than regular Die.
Sides means number of sides on the die. A D6 has six sides. A d20 twenty.
But what you're actually doing is defining two number of sides for the *same* dice.
CornBurrito
Member
Each dice (each instance of either class), be it Dice or FunnyDice, can have a different number of sides.
But what you're actually doing is defining two number of sides for the *same* dice.
Yeah I finally understand that. Wasn't thinking about it in the right way.
Ok so I got rid of the sides member variable in FunnyDie.
However, there is an error with trying to use setSides() with a FunnyDie. Because sides is a private member variable of the Die class. Even though setSides() is a public function of the die class.
Changing sides to a protected member variable fixed that I think.
Randolph Freelander
Member
Ah I see what you mean. No.
OK, good. Now we're getting somewhere again.
What you want to do is be sure your member in the base class has the right level of accessibility for derived classes, following whatever idiom is appropriate for your language of choice. That might be a different access modifier, or just consuming a getter method. You shouldn't need to redefine the member for your derived class.
cpp_is_king
Member
Ok lets say I take sides out of FunnyDie. It doesn't need them. When I do setSides() in die (which was already public), and have a FunnyDie object try to use it, it won't be pointing at the wrong thing now? FunnyDie must be able to have a different number of sides than regular Die.
Sides means number of sides on the die. A D6 has six sides. A d20 twenty.
Ah I see what you mean. No.
When you make these classes:
Code:
class Die {
private:
int sides;
public:
int getsides() const { return sides; }
void setsides(int s) { sides = s; }
};
class FunnyDie {
};And use them like this:
Code:
Die d;
FunnyDie f;
d.setsides(5);
f.setsides(3);This does exactly what you want it to do. d has 5 sides, and f has 3 sides.
Yeah I finally understand that. Wasn't thinking about it in the right way.
Ok so I got rid of the sides member variable in FunnyDie.
However, there is an error with trying to use setSides() with a FunnyDie. Because sides is a private member variable of the Die class. Even though setSides() is a public function of the die class.
Changing sides to a protected member variable fixed that I think.
Put setSides in Die, not in FunnyDie