Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

My OO...

Name: Anonymous 2011-12-13 3:19

...it's violated!

http://programmers.stackexchange.com/questions/17031/when-c-handles-pop-in-your-c-code-and-break-your-pretty-oo-design

Anime avatar. Passive-aggressive rant. Autismal as fuck. That's gotta be someone from /prague/, amirite?

Name: Cudder !MhMRSATORI!FBeUS42x4uM+kgp 2011-12-13 4:14

That is either a very good piece of satire or written by some idiot who has truly been brainwashed by OOP shit. I've seen so many of the latter that it's easy to tell at a glance.

http://www.codinghorror.com/blog/2004/09/why-objects-suck-revisited.html

 All you should be thinking about when designing/writing code is
1. Does it work?
2. Is it simple?
3. Is it efficient?

OOP was created as nothing more than a convenience for using structures and functions that operate on them. Anyone who does not understand that and worships it like it's some deity that provides enlightenment from all programming problems is a brainwashed idiot.

Name: Anonymous 2011-12-13 4:52

>>2

I think you're missing something

"is it safe?"

Say I'm writing a graphics library, and I don't want certain parts of my window class to be touched, as letting the user fuck around with them willy nilly will crash the program (however they need to be there). Things like, oh I don't know, the dimensions of the window. Sure you can ask for it, but changing what the program thinks is the dimensions and what is actually the dimensions would be just plain silly.

Here comes the OO programmer. He declares the dimensions of the window private, and creates getter functions in case the programmer needs to know what they are, but makes no possible way of changing them outside of the constructor function.

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-13 5:02

OOP can be always abstracted out: you can't do the same with functions.
The proper way to do it >>3 is to make window_class encapsulated into a function which maintains the window object via a standard API you define. The window Object itself should not be linked to the function: it would be decoupled from the object(which serves as data storage).

Name: Anonymous 2011-12-13 5:09

>>3
If your library is used by a drooling retard, it will crash anyway.

Private methods and variables are still just documentation that is to certain extent enforced by the compiler. By fiddling bits or manipulating headers that come with the library its user can do anything. Anything! With C libraries these things tend to be written in the comments if it's not evident from the header files what you're supposed to touch. Very often it is evident.

You can expect the user of your library can read and understand the code he's using. If he is not willing to, it's his own god damn fault.

Name: Cudder !MhMRSATORI!FBeUS42x4uM+kgp 2011-12-13 5:13

and I don't want certain parts of my window class to be touched, as letting the user fuck around with them willy nilly will crash the program
So what? If the user fucks up it's the user's fault.

Here comes the OO programmer. He declares the dimensions of the window private, and creates getter functions in case the programmer needs to know what they are, but makes no possible way of changing them outside of the constructor function.
*(((int*)pWindow)+2) = 9999;

Welcome to the real world.

Name: Anonymous 2011-12-13 5:17

Silly Cudder, puts a whitespace betwixt his name and the hash character.
That's not how you should trip on world4ch silly Cudder!

Name: Anonymous 2011-12-13 5:47

Filthy Cudder, puts a massive cock betwixt his buttocks.
That's not how you should trip on world4ch filthy Cudder!

Name: Anonymous 2011-12-13 6:11

>>2
JA;DR

Do you really think he is qualified to talk about the merits of OO, procedural programming?

Name: Anonymous 2011-12-13 9:43

This feels like a blog article, not a question. If you have a question, please make it more explicit and reduce the context to a minimum.

Name: Anonymous 2011-12-14 11:45

>>6
*(((int*)pWindow)+2) = 9999;
Weak typing is evil.

Name: Anonymous 2011-12-14 12:35

>>11
Weak typing is great.

Name: Anonymous 2011-12-14 12:39

pseudo-OOP : OpenGL

what

Name: Anonymous 2011-12-14 12:40

I have no strong feelings one way or another toward weak typing, but I can't wait for the 'weak typing is shit', 'if it's not weak typing, it's shit', 'jews invented weak typing' and other 'hax my weak typing'-type posts.

Name: Anonymous 2011-12-14 13:14

>>14
Only because you don't understand programming.

Name: Anonymous 2011-12-14 13:29

>>12
Yes, for non-programmers.

Name: Anonymous 2011-12-14 13:47

>>14
Here's how weak typing kills safety in your programs:

#include <iostream>
 
class Wallet {
        public:
                int money;
                Wallet() { money = 100; }
                void setMoney(int pounds) { money = pounds; }
};
 
class MyWallet : private Wallet {
        public:
                int getMoney() { return money; }
};
 
int main() {
        MyWallet *wallet = new MyWallet;
        reinterpret_cast<Wallet*>(wallet)->setMoney(9000);
        std::cout << wallet->getMoney(); // Output: 9000
        return 0;
}

Name: Anonymous 2011-12-14 14:19

>>17
You are implying that strong typing prevents this, but it doesn't. A malicious programmer (which is clearly what would be needed for your example) can directly modify application memory in any number of ways.

Name: Anonymous 2011-12-14 14:25

>>17,18
This is exactly the problem with strong typing.  It creates a false sense of "safety" without adding any safety at all.

Name: Anonymous 2011-12-14 14:25

static typing
http://img.0chan.ru/c/src/13238906183588.jpg

Name: Anonymous 2011-12-14 14:31

>>18
In your case it's not a language problem, it's problem of your OS which provides you direct access to the memory. Strong typing is also vulnerable to this kind of attacks (and it's very difficult to use them), but it eliminates problems like I showed above.

Name: Anonymous 2011-12-14 14:35

I read part of the URL as "when C handles poop in your code".
Do what you want with this information.

Name: Anonymous 2011-12-14 14:43

>>21
Strong typing
Fix: static typing

>>18,19
It'd be useful if you could provide examples of such tricks in a strongly typed language.

Name: Anonymous 2011-12-14 15:01

>>23
Of course strongly-typed languages for some weird reason tend to run in managed environments...

Name: Anonymous 2011-12-14 15:12

>>23
Trivially, http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-Ptr.html

If you start thinking about the kind of controls that would be needed to prevent this, it's inconceivable and won't be seen in our lifetimes.

Name: Anonymous 2011-12-14 15:20

>>25
I might add,

"You may want your programming language to be strongly typed. Just about every other force in the computer wants it weak."

Name: Anonymous 2011-12-14 18:07

>>25
It is part of the foreign function interface you massive faggot. Of course it is going to be unsafe.

Jesus CHRIST /prog/ is filled with fucking retards lately.

Name: Anonymous 2011-12-14 19:02

>>27
Wait, are you saying that strongly typed languages are safe?  You really need a counterexample?  Have you ever used C or C++ or C#?

/prog/ is filled with fucking retards lately.
Well, head back to /vp/ then.

Name: Anonymous 2011-12-14 19:12

>>27,28
... or are you doing that thing where you pretend like there's a difference between "strong" and "static" typing?  Yeah, there's a difference, but generally, when someone says "strongly typed," they mean the equivalent of statically typed.


int func(int a) { return a + 1; }

int main(int argc, char **argv)
{
    func("string");
    return 0;
}

error C2664: 'func' : cannot convert parameter 1 from 'const char *' to 'int'

That's what people usually mean by "strongly typed," and it doesn't make the world any safer.

Name: Anonymous 2011-12-14 19:29

The "safe" and "unsafe" distinctions are all bullshit anyway.

It's better to think of it as "making sure the program works as it should under all conditions of input" than "programming safely".

Part of the reason why computers are so powerful is because data is entirely dependent upon its interpretation, and we should respect that fact and not try to subvert it.

Name: Anonymous 2011-12-14 20:00

>>30
"making sure the program works as it should under all conditions of input"
But that's the whole point; static (or "strong") typing doesn't even do that.  Nothing does that.  It's equivalent to solving the halting problem.

Name: Anonymous 2011-12-14 20:49

>>28
C and C++ are not strongly typed languages.

Name: Anonymous 2011-12-14 22:14

its more like dynamically typed, where all the types coerce somehow to nonsense ints.

Name: Anonymous 2011-12-15 1:19

>>27
That's precisely my point. The idea that we should, for some reason, protect code from it's own developers is ludicrous. That people think strong typing will help effect such protections is at best comical, at worst incredibly dangerous.

Name: Anonymous 2011-12-15 1:22

>>34
Please die.

Name: Anonymous 2011-12-15 1:25

>>35
A well articulated argument!

Name: Anonymous 2011-12-15 1:27

>>36
It is all that strawman deserved.

Name: Anonymous 2011-12-15 2:09

>>34
So what danger does strong typing impose?

Name: Anonymous 2011-12-15 2:12

>>38
That some sepples programmer might write something that works and is maintainable, apparently.

Name: Anonymous 2011-12-15 5:15

>>38
Perhaps a false sense of security. With a dynamic language behavioural forces are exerted to rigorously test and that may end up quite comprehensive, whereas a program that gets types checked and an occasional runtime testing will not exert as much pressure to establish a test suite.
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -