Page 2 of 3

Posted: Sun Aug 19, 2007 3:07 am
by binutils
pcmattman wrote: In this time, Mattise has been switched from a monolithic design to a microkernel design.
Is this c++ class-type side-effect? or irrelevant?

Posted: Sun Aug 19, 2007 3:15 am
by pcmattman
binutils wrote:
pcmattman wrote: In this time, Mattise has been switched from a monolithic design to a microkernel design.
Is this c++ class-type side-effect? or irrelevant?
Irrelevant. I work better under an OOP environment, that's all. Linked lists are so much easier when you can use a template class instead of rewriting code for every new type.

Posted: Sun Aug 19, 2007 3:26 am
by binutils

Posted: Sun Aug 19, 2007 3:32 am
by pcmattman
No, but I have used Boost for other programs I've written (under Windows). Doesn't Boost require the STL?

Posted: Sun Aug 19, 2007 3:34 am
by binutils
pcmattman wrote:Doesn't Boost require the STL?
I heard that Both(with or without) is possible, i compiled and installed it on windows and linux without STL.

Posted: Sun Aug 19, 2007 7:15 pm
by jerryleecooper
Personally I don't like much C++. I have this impression the designer consider the language adherents like children. For exemple, the whole public/private thing. To have a class accessing private members of another class you make a friend of it. Why not instead have some kind of permission map, having some variables of a class that are publicly readable, but not writable, and inversely? You can do that by overloading the = operator? And there's this thing they teach in the C++ books I have, make a variable private, but with a function to read it's value public, and a function to set its value, also public. And they're also saying you're supposed to do that to EVERY variable. Crazy.

Posted: Mon Aug 20, 2007 12:18 am
by os64dev
jerryleecooper wrote:For exemple, the whole public/private thing. To have a class accessing private members of another class you make a friend of it. Why not instead have some kind of permission map, having some variables of a class that are publicly readable, but not writable, and inversely? You can do that by overloading the = operator?
And you then ofcourse need a permission map for each different type of access talk about efficient memory usage. Friends are only needed when you wish to hide implementation details for all other classes. And the operator = is related to the whole class not only its members. Personally i don't use friend classes.
jerryleecooper wrote:And there's this thing they teach in the C++ books I have, make a variable private, but with a function to read it's value public, and a function to set its value, also public. And they're also saying you're supposed to do that to EVERY variable. Crazy.
Not every variable just the ones you need to expose in the interface. Think of an old analog clock. You could have the hour minute and second as private member variables and set_clock or get_clock as the public functions (set_hour/get_hour etc can also be done). That the interface of the clock. However the whole innerworkings of the wheels and the number of teeth per wheel how they are connected and everything is all done in private space and don't need to be exposed. Thus don't need the access functions.

If you think in objects it makes sense.
1) public members define how a user of the object can change how the object works and can get and set state information.
2) protected members are methods that are shared between similar types of objects (hence inheritance). An object inherits the behaviour of another object.
3) private mebers are methods only available to the object itself. The contain the implementation of the objects behaviour so no one outside can manipulate it and the objects behaviour is guaranteed.

Posted: Mon Aug 20, 2007 1:49 am
by JamesM
jerryleecooper: If you can't see the merits of seperating the interface and implementation of an abstract data type by a great big concrete wall then you obviously haven't tried to change the implementation of a widely used package. (Example I'm thinking of is to change the implementation of a Map ADT from a hashtable to a binary search tree.). Relying on the implementation of a module is a recipe for disaster.

Posted: Mon Aug 20, 2007 2:19 am
by jerryleecooper
Yes I see it's good to separate the interface from the implementation. Well, there's probably a couple of things I don't know about C++, I need to check my knowledges about it. Anyway, I have my own ideas of what makes a good language, and until I make my own compiler (a project, like my own operating system) I will not discuss further about C++ being a language for children. My new language will be C with a bit of C++, but no template, operator overloading and friend classes. Instead, well, that will be for another thread.

Posted: Mon Aug 20, 2007 2:25 am
by jerryleecooper
os64dev wrote:Think of an old analog clock. You could have the hour minute and second as private member variables and set_clock or get_clock as the public functions (set_hour/get_hour etc can also be done). That the interface of the clock. However the whole innerworkings of the wheels and the number of teeth per wheel how they are connected and everything is all done in private space and don't need to be exposed. Thus don't need the access functions..
OK, so I put some formating into the set_hour function, instead of relying on each place in my code where I want to set the hour.

I think C++ is like GUI for programmers.

Posted: Mon Aug 20, 2007 2:33 am
by AJ
jerryleecooper wrote: I think C++ is like GUI for programmers.
So if you don't like it, don't use it :roll:

Posted: Mon Aug 20, 2007 6:53 am
by jerryleecooper
AJ wrote: So if you don't like it, don't use it :roll:
Im using it when im programming in windows, and it's a joy. But I don't use the features I don't like.

Posted: Mon Aug 20, 2007 3:18 pm
by pcmattman
jerryleecooper wrote:
AJ wrote: So if you don't like it, don't use it :roll:
Im using it when im programming in windows, and it's a joy. But I don't use the features I don't like.
MFC will put anyone off C++.

Posted: Tue Aug 21, 2007 12:13 am
by os64dev
what does MFC got to do with C++ ?

Posted: Tue Aug 21, 2007 12:44 am
by AndrewAPrice
pcmattman wrote:
jerryleecooper wrote:
AJ wrote: So if you don't like it, don't use it :roll:
Im using it when im programming in windows, and it's a joy. But I don't use the features I don't like.
MFC will put anyone off C++.
Then don't use MFC. You can use the C-headers of the Win32 SDK if you want.

I always hear people saying "MFC is evil". I haven't used MFC yet, but after looking at a few source examples, it doesn't really seem any worse than any other C++ GUI library?

You create an object, set it's position, add the control to a parent control (the window), and add an action to call when you click it. How much simpler could you have it?