Valhalla Legends Archive

Quote from: Kp on June 11, 2003, 12:15 AM

Quote from: Camel on June 10, 2003, 05:36 PM
+1 to iago for the irrelivant privates comment

consider:

Code Select Expand

struct privates iagos_privates;
in the former, anybody can say "extern struct privates iagos_privates;" and then play with iago's privates freely. in the latter, one cannot even look at iago's privates; it's sort of like wearing steel underpants.

Just do this:

Code Select Expand

static struct privates iagos_privates;Now the symbol isn't exported, so the linker won't be able to match up other people's references to it.  It doesn't protect against other accesses from the same file, but you trust the code in the same file as you - right?

I sure as hell don't.. I never know when I'm going to be attempting to screw myself up :-/

Quote from: Kp on June 11, 2003, 12:15 AMJust do this:

Code Select Expand

static struct privates iagos_privates;Now the symbol isn't exported, so the linker won't be able to match up other people's references to it.  It doesn't protect against other accesses from the same file, but you trust the code in the same file as you - right?

that isn't the point. the idea is to not allow joe shmoe to modify the data direcly without going through some function that can check the validity of the data. perhaps one wants to pass a string (for the sake of argument, a char array pointer) to the function. rather than just modifying the data directly, one must call the function. the function can  check, for example, if the pointer is set to NULL. this way, one need not check if the pointer is null every time he wants to modify the data. this makes for 1) more consise and easier to read code, 2) a little bit of security, 3) a lot less code to change when you decide to convert your char* to an std::string (or simmilar)
the only time where this would be a truely unfavorable approach is when an application becomes so time critical that one should be considering looks into asm to handle one's loops

Quote from: Camel on June 13, 2003, 07:39 AM

Quote from: Kp on June 11, 2003, 12:15 AMJust do this:

Code Select Expand

static struct privates iagos_privates;Now the symbol isn't exported, so the linker won't be able to match up other people's references to it.  It doesn't protect against other accesses from the same file, but you trust the code in the same file as you - right?

that isn't the point. the idea is to not allow joe shmoe to modify the data direcly without going through some function that can check the validity of the data.

Unless you make a habit of letting joe shmoe write code in your source file, my solution enforces that.  From another file, he *cannot* directly access iagos_privates because its name was never exported (thus he would get a linker error if he tried).  If you follow "good" design in laying out your functions, only the accessors/mutators for iagos_privates (I'll let someone else fill in the mutator jokes...) will be in a position to locate that name.  Good is, of course, a highly relative idea.  IMO, it means (at the least) separating your code across file divisions that help enforce meaning.  For instance, putting your GUI code and configuration file reading code in separate files because they have such radically different purposes.

once again you've missed the point. it's not all about security -- in fact, security would be the least of my worries. read my previous post again and comment on more than just the second sentance, plz.
i agree, the first step to making code readable to one's self is to seperate the code, but this can certainly backfire. unless your code looks like:
void main()
{
   class myBot;
   myBot.GetInfo;
   mybot.CreateMainWindow();
   myBot.ShowMainWindow();
   myBot.BNCS_Connect("useast.battle.net", 6112);
}
then it is almost always intimidating for outsiders seeing the code for the first time. IMO, the most important skill of a good programmer is to be able to write code that's extremely intuitive -- code that doesn't need comments because it explains itself.

Quote from: Camel on June 13, 2003, 04:40 PM
once again you've missed the point. it's not all about security -- in fact, security would be the least of my worries. read my previous post again and comment on more than just the second sentance, plz.

From what I can see, there's nothing in your post that the use of static on the  variable declarations would not solve. It could even be solved by just putting a "don't touch" sign on the variables. (i.e. not documenting them as you do the functions)

Besides, no matter what you do, the variables can be modified by joe shmoe if he really wants to.

how many times do i have to say it's not all about security? perhaps i just want to check that i'm not setting some string to null, but i dont want to code it in a billion places. that ALONE is enough reason to use a class.

Now you're just being pissy.  What did joe schmoe do to deserve this outburst of attitude?






j/k

Quote from: Camel on June 14, 2003, 07:56 PM
how many times do i have to say it's not all about security? perhaps i just want to check that i'm not setting some string to null, but i dont want to code it in a billion places. that ALONE is enough reason to use a class.

No, it's not. You can use a function to set your variables whether you put them in a class or not.

Camel, not a flame, but FYI:

I don't think you realise the collective experience of the programmers you're arguing with. You're making yourself look pretty stupid.

Especially with that avatar.

i'm not trying to make a blanket statement that it's always best to use a class, i'm just saying that in most cases where there is pooled code, it's a good idea because it allows more control in one centralized place. i know i wouldnt want to go searching through 50 pages of someone else's code who didnt understand how my struct was *supposed* to be used.

If Joe Shmoe screws something up, that's great.  Atleast it's not running on your computer.  I say if he isn't smart enough to follow some type of "protocol", then he needs to go back to elementary school.  You should not have to put in place extra code to check for stupidity.

Quote from: Camel on June 16, 2003, 09:23 PM
i'm not trying to make a blanket statement that it's always best to use a class, i'm just saying that in most cases where there is pooled code, it's a good idea because it allows more control in one centralized place. i know i wouldnt want to go searching through 50 pages of someone else's code who didnt understand how my struct was *supposed* to be used.

Actually, either you don't have to be searching through 50 pages of someone else's code either way, or you do. If the user is being nice, you don't have to look through the code, because he's using your functions. If the user isn't being nice, he's poking data straight into your classes no matter what you try. And it's probably easier to poke data straight into a class than into a static variable in another file.

adron, you're assuming joe shmoe has malicious intent. maby he just accidently sets some pointer to NULL because he didn't check its value first. then it would be favorable to check if said pointer is NULL not to restrict access (as i said, it has nothing to do with security) but for reliablility (through redundancy)

Frankly, camel is at least partially right here. When you're building a program, unless you are the absolute only one ever using it (and it's rare that you can actually be sure of that), it's best to assume that the potential user of your code is going to do something wrong. The user is a moron: if there's something that can be screwed up, they'll find it, so you'd better make sure there isn't.

On the other hand camel, a lot of your arguments don't really have anything to do with the necessity of using classes. Well-constructed procedural code can accomplish the same thing if you really want it to.