|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On March 18 2013 09:17 CecilSunkure wrote:Show nested quote +On March 18 2013 09:00 MiyaviTeddy wrote:Thanks alot Abductedonut & Morfildur  The last few topics I'm still really confused about is: -Inheritance -Virtual functions -Pure virtual -Abstract classes any examples or primers would be greatly appreciated! and this is helping me towards finishing my assignment. These are all related to one another quite heavily. Inheritance lets you stick one object inside of another completely. Here's a slideshow I made talking about inheritance in C. This is almost exactly like what happens in C++, but it's important to know how to do it (and actually do it yourself) in C first, in my opinion. Read the pdf to understand: what inheritance is, and why it's useful. The pdf also covers virtual functions and how to implement them. A pure virtual is a function that must be overridden when a class derives from a type. The compiler will complain if you don't. That's all. This is good for enforcing interfaces. An abstract class is type that is designed to only be used as a base for derivation. Again, a good example (the only good one I know) is for interfaces. If you're confused on what an interface is: it is just a set of functions to call. If I employ an interface, then other objects can treat me as if I employ this interface. For example say we make an object to resemble a duck. We have an interface for quacking and swimming. Other code portions can call my quack and swim functions upon me, without knowing about the rest of what I am so long as I employ the duck interface. This is actually referred to as "duck-typing".
That's not the definition of duck typing. Duck typing refers to a style of type system that derives its type information from the interface an object exposes rather than from a inheritance tree that was explicitly laid out. It is common in dynamic languages (Javascript, Ruby, Python, PHP) but can also exist in statically typed languages (Go uses a form of duck typing, for instance). What you described is simply 'polymorphism'.
Also, I don't think understanding how to implement inheritance in C is at all necessary and most definitely overkill for understanding how inheritance, virtual functions, and abstract classes work. The vast majority of programmers likely have no idea how vtables work (and there are very few times where knowing such information will actually matter). Telling someone who is having their first foray into OO to learn all of that stuff is bordering on sadistic.
|
On March 18 2013 09:35 tec27 wrote:Show nested quote +On March 18 2013 09:17 CecilSunkure wrote:On March 18 2013 09:00 MiyaviTeddy wrote:Thanks alot Abductedonut & Morfildur The last few topics I'm still really confused about is: -Inheritance -Virtual functions -Pure virtual -Abstract classes any examples or primers would be greatly appreciated! and this is helping me towards finishing my assignment. These are all related to one another quite heavily. Inheritance lets you stick one object inside of another completely. Here's a slideshow I made talking about inheritance in C. This is almost exactly like what happens in C++, but it's important to know how to do it (and actually do it yourself) in C first, in my opinion. Read the pdf to understand: what inheritance is, and why it's useful. The pdf also covers virtual functions and how to implement them. A pure virtual is a function that must be overridden when a class derives from a type. The compiler will complain if you don't. That's all. This is good for enforcing interfaces. An abstract class is type that is designed to only be used as a base for derivation. Again, a good example (the only good one I know) is for interfaces. If you're confused on what an interface is: it is just a set of functions to call. If I employ an interface, then other objects can treat me as if I employ this interface. For example say we make an object to resemble a duck. We have an interface for quacking and swimming. Other code portions can call my quack and swim functions upon me, without knowing about the rest of what I am so long as I employ the duck interface. This is actually referred to as "duck-typing". That's not the definition of duck typing. Duck typing refers to a style of type system that derives its type information from the interface an object exposes rather than from a inheritance tree that was explicitly laid out. It is common in dynamic languages (Javascript, Ruby, Python, PHP) but can also exist in statically typed languages (Go uses a form of duck typing, for instance). What you described is simply 'polymorphism'. Also, I don't think understanding how to implement inheritance in C is at all necessary and most definitely overkill for understanding how inheritance, virtual functions, and abstract classes work. The vast majority of programmers likely have no idea how vtables work (and there are very few times where knowing such information will actually matter). Telling someone who is having their first foray into OO to learn all of that stuff is bordering on sadistic.
Well he said he's learning this for school, and when I went to school I learned all that stuff. I still stand by all I said except the duck typing thing.
|
It is in no way important to know how to do inheritance in C. Just like it's not important to know how a CPU works. It can be fun to learn for those of us who are sadistic, but it's not important or useful. Encouraging learning is good, but you gotta be realistic about it.
If every programmer was made to go through the physics of transistors, low level processor and memory architecture, assembly, all the way up... we'd have a lot less programmers. You could argue that the ones remaining would be better somehow (debatable), but we need way more programmers than we have already. Unless you have a solution to the H1-B deficiency problem :\
|
I agree. Every programmer should learn to write a bit of assembly and have at least a basic idea of how transistor logic works, and maybe even learn how to write OO code in C. That's not where you point a beginner, though. A beginner should start somewhere in the middle, learning to write basic programs a high-level programming language, and then work their way down into low-level stuff and up into the world of operating system APIs and network code and threading. Teaching someone OO by making them do it in C is dumping too much complexity on their heads all at once, it's much better to let them learn the concept (which is complicated enough if you're new to it) and then later learn how the concept is actually implemented at a low level.
Also, CecilSunkure, you wrote that the only case you know for an abstract class is in writing an interface. There's a subtle difference between the two concepts, though. An interface is just a communication contract - implementing an interface is basically promising to present a defined set of public methods. An abstract class is a class that isn't intended to be instantiated, but only to be inherited from. The difference is that an interface doesn't provide implementation, but an abstract class can. I have an abstract class in a project I'm working on right now called Link, for example, which represents a link, which can be of type internal, external or download. The base Link class implements a render() method and defines the abstract getUrl() method, which is implemented by each of the three derived classes. If Link were an interface rather than an abstract class, all of the classes implementing it would have to have their own implementation of render().
|
On March 18 2013 16:16 AmericanUmlaut wrote:
I agree. Every programmer should learn to write a bit of assembly and have at least a basic idea of how transistor logic works, and maybe even learn how to write OO code in C. That's not where you point a beginner, though. A beginner should start somewhere in the middle, learning to write basic programs a high-level programming language, and then work their way down into low-level stuff and up into the world of operating system APIs and network code and threading. Teaching someone OO by making them do it in C is dumping too much complexity on their heads all at once, it's much better to let them learn the concept (which is complicated enough if you're new to it) and then later learn how the concept is actually implemented at a low level.
Also, CecilSunkure, you wrote that the only case you know for an abstract class is in writing an interface. There's a subtle difference between the two concepts, though. An interface is just a communication contract - implementing an interface is basically promising to present a defined set of public methods. An abstract class is a class that isn't intended to be instantiated, but only to be inherited from. The difference is that an interface doesn't provide implementation, but an abstract class can. I have an abstract class in a project I'm working on right now called Link, for example, which represents a link, which can be of type internal, external or download. The base Link class implements a render() method and defines the abstract getUrl() method, which is implemented by each of the three derived classes. If Link were an interface rather than an abstract class, all of the classes implementing it would have to have their own implementation of render().
Well I'm not here to argue, though I myself learned C, then learned OO in C, then moved to C++. It's in my opinion that others would do wise to do the same and that's why I recommend it.
And thanks for the clarification on abstract classes! I believe the reason I didn't make a clear distinction is because I use template mixins to avoid run-time costs of polymorphism. So I don't really think of CRTP mixins as "abstract classes" since I don't have the = 0 pure specifier 
|
On March 18 2013 17:14 CecilSunkure wrote:Show nested quote +On March 18 2013 16:16 AmericanUmlaut wrote:
I agree. Every programmer should learn to write a bit of assembly and have at least a basic idea of how transistor logic works, and maybe even learn how to write OO code in C. That's not where you point a beginner, though. A beginner should start somewhere in the middle, learning to write basic programs a high-level programming language, and then work their way down into low-level stuff and up into the world of operating system APIs and network code and threading. Teaching someone OO by making them do it in C is dumping too much complexity on their heads all at once, it's much better to let them learn the concept (which is complicated enough if you're new to it) and then later learn how the concept is actually implemented at a low level.
Also, CecilSunkure, you wrote that the only case you know for an abstract class is in writing an interface. There's a subtle difference between the two concepts, though. An interface is just a communication contract - implementing an interface is basically promising to present a defined set of public methods. An abstract class is a class that isn't intended to be instantiated, but only to be inherited from. The difference is that an interface doesn't provide implementation, but an abstract class can. I have an abstract class in a project I'm working on right now called Link, for example, which represents a link, which can be of type internal, external or download. The base Link class implements a render() method and defines the abstract getUrl() method, which is implemented by each of the three derived classes. If Link were an interface rather than an abstract class, all of the classes implementing it would have to have their own implementation of render(). Well I'm not here to argue, though I myself learned C, then learned OO in C, then moved to C++. It's in my opinion that others would do wise to do the same and that's why I recommend it. And thanks for the clarification on abstract classes! I believe the reason I didn't make a clear distinction is because I use template mixins to avoid run-time costs of polymorphism. So I don't really think of CRTP mixins as "abstract classes" since I don't have the = 0 pure specifier
CRTP is f.ex used for static polymorphism. the base class would be your abstract class providing an interface, the functions in which it calls derived member functions would be like pure virtual functions. you can very much so think of the CRTP base class as an abstract class.
i don't think (pure) virtual functions and abstract class even makes sense besides as analogues in a CRTP context.
|
On March 16 2013 12:33 tec27 wrote:Show nested quote +On March 16 2013 01:46 mcc wrote:On March 16 2013 00:04 AmericanUmlaut wrote:
Types in JS are a bloody nightmare.
typeof(NaN) => "Number"
Yay Javascript. Yep, JS type design is terrible shit. Empty string is equivalent to false, who knew  Caused me some wasted time yesterday. Empty string does not equal false, it is merely a falsy value. Falsy values are very useful, and greatly increase the expressiveness of the language imo. I've programmed in JS a lot, and I can tell you that if you're actually checking if a variable equals or does not equal a falsy value, you are generally not doing the right thing anyway. But just in case, I'd recommend running your code through http://jshint.com (there's a command-line version as well if you'd like to lint through your editor/console) and it'll catch cases where you compare against falsy values without using !== or ===. JS has some weird idiosyncracies, but its type system isn't one of them and makes for a very expressive and useful language.
I was checking old code for a bug and it looked ok on the first glance, I found the issue later once I understood what the code was exactly doing. In more strict language I would have found this error in small fraction of a time. Which brings me to a point, "very expressive" is not a good property of a language in 90% of cases as it mostly means it gives you slightly faster coding time, but sacrifices maintainability. So for short programs that need to be quickly done they are ok-ish, for anything else they just complicate bugfixing and extending the program.
To expand on it a bit more I will start by saying that "people should code well" is not a proper argument as there will always be bad code created by bad (or even good) programmers for multitude of reasons. Thus a language that cuts off some part of those bad possibilities by force will more than offset any lack of expressiveness in development that is measured in more than weeks.
To make it short I see absolutely no gain in the JS type system that is not more than offset by issues it causes. I am not saying it does not have some inner sense, but so have many things that are in practice terrible.
|
This may seem out of topic but I am curious as to what others think:
I was in a library studying near a bathroom entrance. Two lads ran into each other in the bathroom and started talking. Long story short they were discussing about software engineering/comp sci majors. One of the lad proceeded to discuss how it is a terrible major and it will "fall" and soon become useless. His reasoning was that it was too "easy" to have the jobs outsourced to "India or Pakistan."
This is something that quite a lot of people believe in actually and I am a bit disturbed. I personally think this is a load of horse crap considering how much money different companies (google and microsoft) and countries (Middle east and Europe like UK) are pumping into this field as we speak. Hell, even legislation in the US are discussing about making programming a recommended elective to HS for graduation. With so many signs and pleading by companies asking for more certified programmers I fail to see how this is a failing crap degree (to put it lightly). Maybe he mixed his definition up with offshoring perhaps?
I don't know. Maybe I am delusional but anyone here care to take a jab and strengthen or destroy my belief (and perhaps inspire or discourage others to take this major)?
|
On March 19 2013 01:30 heroyi wrote:
This may seem out of topic but I am curious as to what others think:
I was in a library studying near a bathroom entrance. Two lads ran into each other in the bathroom and started talking. Long story short they were discussing about software engineering/comp sci majors. One of the lad proceeded to discuss how it is a terrible major and it will "fall" and soon become useless. His reasoning was that it was too "easy" to have the jobs outsourced to "India or Pakistan."
This is something that quite a lot of people believe in actually and I am a bit disturbed. I personally think this is a load of horse crap considering how much money different companies (google and microsoft) and countries (Middle east and Europe like UK) are being pumped into this field as we speak. Hell, even legislation in the US are discussing about making programming a core class(elective) to graduate. With so many signs and pleading by companies asking for more certified programmers I fail to see how this is a failing crap degree (to put it lightly).
I don't know. Maybe I am delusional but anyone here care to take a jab and strengthen or destroy my belief (and perhaps inspire or discourage others to take this major)?
I think my company is trying to outsource our old products to India but keep our new ones in shore. It's kinda dumb since the people in India are so smart, but it's a very nice deal for us if this works. I think the reasoning is that the communication is better.
That said, no one knows what the future holds. People are bad at predicting things, like the recession. You sometimes have to take the risk.
Universities try to teach you things that can't be outsourced like really specialized energy systems, robotics, communications, electrical jobs.
|
On March 19 2013 01:33 obesechicken13 wrote:Show nested quote +On March 19 2013 01:30 heroyi wrote:
This may seem out of topic but I am curious as to what others think:
I was in a library studying near a bathroom entrance. Two lads ran into each other in the bathroom and started talking. Long story short they were discussing about software engineering/comp sci majors. One of the lad proceeded to discuss how it is a terrible major and it will "fall" and soon become useless. His reasoning was that it was too "easy" to have the jobs outsourced to "India or Pakistan."
This is something that quite a lot of people believe in actually and I am a bit disturbed. I personally think this is a load of horse crap considering how much money different companies (google and microsoft) and countries (Middle east and Europe like UK) are being pumped into this field as we speak. Hell, even legislation in the US are discussing about making programming a core class(elective) to graduate. With so many signs and pleading by companies asking for more certified programmers I fail to see how this is a failing crap degree (to put it lightly).
I don't know. Maybe I am delusional but anyone here care to take a jab and strengthen or destroy my belief (and perhaps inspire or discourage others to take this major)? I think my company is trying to outsource our old products to India but keep our new ones in shore. It's kinda dumb since the people in India are so smart, but it's a very nice deal for us if this works. I think the reasoning is that the communication is better.
But you are outsourcing the old products while keeping new in. That isn't new at all to the business model.
The guys argument comes in that the outsourced country can pump out softwares out quickly and as many as possible while being cheap. However, he doesn't take into the account the quality of a coding and we all know how costly bugged codes can be.
|
On March 18 2013 17:14 CecilSunkure wrote:Show nested quote +On March 18 2013 16:16 AmericanUmlaut wrote:
I agree. Every programmer should learn to write a bit of assembly and have at least a basic idea of how transistor logic works, and maybe even learn how to write OO code in C. That's not where you point a beginner, though. A beginner should start somewhere in the middle, learning to write basic programs a high-level programming language, and then work their way down into low-level stuff and up into the world of operating system APIs and network code and threading. Teaching someone OO by making them do it in C is dumping too much complexity on their heads all at once, it's much better to let them learn the concept (which is complicated enough if you're new to it) and then later learn how the concept is actually implemented at a low level.
Also, CecilSunkure, you wrote that the only case you know for an abstract class is in writing an interface. There's a subtle difference between the two concepts, though. An interface is just a communication contract - implementing an interface is basically promising to present a defined set of public methods. An abstract class is a class that isn't intended to be instantiated, but only to be inherited from. The difference is that an interface doesn't provide implementation, but an abstract class can. I have an abstract class in a project I'm working on right now called Link, for example, which represents a link, which can be of type internal, external or download. The base Link class implements a render() method and defines the abstract getUrl() method, which is implemented by each of the three derived classes. If Link were an interface rather than an abstract class, all of the classes implementing it would have to have their own implementation of render(). Well I'm not here to argue, though I myself learned C, then learned OO in C, then moved to C++. It's in my opinion that others would do wise to do the same and that's why I recommend it. And thanks for the clarification on abstract classes! I believe the reason I didn't make a clear distinction is because I use template mixins to avoid run-time costs of polymorphism. So I don't really think of CRTP mixins as "abstract classes" since I don't have the = 0 pure specifier
How do you learn OO in C? C isn't an object-oriented language unless you mean C++/Objective C here.
|
On March 19 2013 02:22 darkness wrote:Show nested quote +On March 18 2013 17:14 CecilSunkure wrote:On March 18 2013 16:16 AmericanUmlaut wrote:
I agree. Every programmer should learn to write a bit of assembly and have at least a basic idea of how transistor logic works, and maybe even learn how to write OO code in C. That's not where you point a beginner, though. A beginner should start somewhere in the middle, learning to write basic programs a high-level programming language, and then work their way down into low-level stuff and up into the world of operating system APIs and network code and threading. Teaching someone OO by making them do it in C is dumping too much complexity on their heads all at once, it's much better to let them learn the concept (which is complicated enough if you're new to it) and then later learn how the concept is actually implemented at a low level.
Also, CecilSunkure, you wrote that the only case you know for an abstract class is in writing an interface. There's a subtle difference between the two concepts, though. An interface is just a communication contract - implementing an interface is basically promising to present a defined set of public methods. An abstract class is a class that isn't intended to be instantiated, but only to be inherited from. The difference is that an interface doesn't provide implementation, but an abstract class can. I have an abstract class in a project I'm working on right now called Link, for example, which represents a link, which can be of type internal, external or download. The base Link class implements a render() method and defines the abstract getUrl() method, which is implemented by each of the three derived classes. If Link were an interface rather than an abstract class, all of the classes implementing it would have to have their own implementation of render(). Well I'm not here to argue, though I myself learned C, then learned OO in C, then moved to C++. It's in my opinion that others would do wise to do the same and that's why I recommend it. And thanks for the clarification on abstract classes! I believe the reason I didn't make a clear distinction is because I use template mixins to avoid run-time costs of polymorphism. So I don't really think of CRTP mixins as "abstract classes" since I don't have the = 0 pure specifier How do you learn OO in C? C isn't an object-oriented language unless you mean C++/Objective C here.
C has structures, which is analogous to an object in that each copy of the structure can have its own variables, functions, and purpose. It just isn't done for you the way C++/Java do it, you have to manually setup the functions and call them. Its actually very good practice for understanding how higher level languages organize objects in memory, and how garbage collection works.
There isn't inheritance, but it's got polymorphism (weak static types) and encapsulation (structures).
From StackOverflow:
typedef struct {
int (*open)(void *self, char *fspec);
int (*close)(void *self);
int (*read)(void *self, void *buff, size_t max_sz, size_t *p_act_sz);
int (*write)(void *self, void *buff, size_t max_sz, size_t *p_act_sz);
// And data goes here.
} tCommClass;
tCommClass commRs232;
commRs232.open = &rs232Open;
: :
commRs232.write = &rs232Write;
tCommClass commTcp;
commTcp.open = &tcpOpen;
: :
commTcp.write = &tcpWrite;
In a personal note, I see this pattern used very extensively in the operating system I work on. The BSD file system is basically an enormous example of OO practices in C, so this isn't some niche feature of the language.
|
On March 19 2013 01:37 heroyi wrote:Show nested quote +On March 19 2013 01:33 obesechicken13 wrote:On March 19 2013 01:30 heroyi wrote:
This may seem out of topic but I am curious as to what others think:
I was in a library studying near a bathroom entrance. Two lads ran into each other in the bathroom and started talking. Long story short they were discussing about software engineering/comp sci majors. One of the lad proceeded to discuss how it is a terrible major and it will "fall" and soon become useless. His reasoning was that it was too "easy" to have the jobs outsourced to "India or Pakistan."
This is something that quite a lot of people believe in actually and I am a bit disturbed. I personally think this is a load of horse crap considering how much money different companies (google and microsoft) and countries (Middle east and Europe like UK) are being pumped into this field as we speak. Hell, even legislation in the US are discussing about making programming a core class(elective) to graduate. With so many signs and pleading by companies asking for more certified programmers I fail to see how this is a failing crap degree (to put it lightly).
I don't know. Maybe I am delusional but anyone here care to take a jab and strengthen or destroy my belief (and perhaps inspire or discourage others to take this major)? I think my company is trying to outsource our old products to India but keep our new ones in shore. It's kinda dumb since the people in India are so smart, but it's a very nice deal for us if this works. I think the reasoning is that the communication is better. But you are outsourcing the old products while keeping new in. That isn't new at all to the business model. The guys argument comes in that the outsourced country can pump out softwares out quickly and as many as possible while being cheap. However, he doesn't take into the account the quality of a coding and we all know how costly bugged codes can be.
It also does not take into account that there are risks in outsourcing. A retailer who wants to make a website does not really risk much by outsourcing it as the software is not really a core part of their business, but if the software IS the business, then it could be much harder to keep critical parts of it secret. In manufacturing there are cases where the people who run a factory in china take what they learned and start competing with the original company.
There will also always be critical systems that require US citizens to fill for people like government/defense contractors.
|
On March 19 2013 02:59 RoyGBiv_13 wrote:C has structures, which is analogous to an object in that each copy of the structure can have its own variables, functions, and purpose. It just isn't done for you the way C++/Java do it, you have to manually setup the functions and call them. Its actually very good practice for understanding how higher level languages organize objects in memory, and how garbage collection works. There isn't inheritance, but it's got polymorphism (weak static types) and encapsulation (structures). From StackOverflow:
typedef struct {
int (*open)(void *self, char *fspec);
int (*close)(void *self);
int (*read)(void *self, void *buff, size_t max_sz, size_t *p_act_sz);
int (*write)(void *self, void *buff, size_t max_sz, size_t *p_act_sz);
// And data goes here.
} tCommClass;
tCommClass commRs232;
commRs232.open = &rs232Open;
: :
commRs232.write = &rs232Write;
tCommClass commTcp;
commTcp.open = &tcpOpen;
: :
commTcp.write = &tcpWrite;
In a personal note, I see this pattern used very extensively in the operating system I work on. The BSD file system is basically an enormous example of OO practices in C, so this isn't some niche feature of the language.
I can not decide whether that is brilliantly beautiful or sickeningly disgusting.
It is certainly a clever hack, but it simply can not compete with languages natively supporting inheritance, polymorphism and multiple levels of encapsulation. Lack of "automated" features simply cut into your useful development time.
|
Agreed - coding OOP in C is like coding lambda abstractions in Java - might be fun or useful as an exercise, but in both cases there are simply languages better suited for the job.
|
On March 19 2013 04:49 Frigo wrote:Show nested quote +On March 19 2013 02:59 RoyGBiv_13 wrote:C has structures, which is analogous to an object in that each copy of the structure can have its own variables, functions, and purpose. It just isn't done for you the way C++/Java do it, you have to manually setup the functions and call them. Its actually very good practice for understanding how higher level languages organize objects in memory, and how garbage collection works. There isn't inheritance, but it's got polymorphism (weak static types) and encapsulation (structures). From StackOverflow:
typedef struct {
int (*open)(void *self, char *fspec);
int (*close)(void *self);
int (*read)(void *self, void *buff, size_t max_sz, size_t *p_act_sz);
int (*write)(void *self, void *buff, size_t max_sz, size_t *p_act_sz);
// And data goes here.
} tCommClass;
tCommClass commRs232;
commRs232.open = &rs232Open;
: :
commRs232.write = &rs232Write;
tCommClass commTcp;
commTcp.open = &tcpOpen;
: :
commTcp.write = &tcpWrite;
In a personal note, I see this pattern used very extensively in the operating system I work on. The BSD file system is basically an enormous example of OO practices in C, so this isn't some niche feature of the language. I can not decide whether that is brilliantly beautiful or sickeningly disgusting. It is certainly a clever hack, but it simply can not compete with languages natively supporting inheritance, polymorphism and multiple levels of encapsulation. Lack of "automated" features simply cut into your useful development time.
But what you gain in development time you loose in performance. Not every system can use C# or Java but C is in the house and you might want to use OO then. Or you are in an environment where C is the only programming language which can do the stuff you want (operating systems a prime example of this) where if you dont use such schemes you will die a horrible death of code complexity.
Also the described method for OO in C is more or less how C++ classes are implemented, just that instead of fields holding the refererences to functions there is a vtable holding the references to the virtual methods.
|
On March 19 2013 05:26 Ilintar wrote:
Agreed - coding OOP in C is like coding lambda abstractions in Java - might be fun or useful as an exercise, but in both cases there are simply languages better suited for the job.
No some times C is the right language for the job and if the job requeres it OO in C is a useful and important programming scheme to know. The method is highly used in operating systems. The whole driver model in Linux uses it, and it is really easy straitforward to use and program to.
|
On March 19 2013 05:26 Ilintar wrote:
Agreed - coding OOP in C is like coding lambda abstractions in Java - might be fun or useful as an exercise, but in both cases there are simply languages better suited for the job.
OOP in C was actually the language of choice for a lot of GBA games. But again the point isn't to learn it professionally, but just to have a solid understanding of how what you're using in C++ works. Using function pointers and typecasting in C for OOP isn't as difficult or tedious as you guys seem to think it is.
On a different topic, if I could I'd code everything in C instead of C++. I really like C. It's just that templating in C++ is so useful, and there are some very nice C++11 features coming around. Whenever someone codes something in C it's almost always completely obvious as to what they are trying to do. With C++ though there are a lot of ways to hide a lot of things. Auto-generated code, things can be run in non-intuitive ways. It's a big problem when a poor C++ programmer is writing code within a team. Of course the solution isn't "lets all code in C", it's just to use C++ appropriately. Even at my school though it's hard to find solid programmers to work with. I can't imagine how hard it would be to find a fit for a team that works primarily with C++ out in the world. Perhaps if more people started "hitting the ground running" in C things would be different?
|
Hi guys!
#include <iostream>
using namespace std;
struct A {
virtual void f() { cout << "Class A" << endl; }
};
struct B: A {
void f(int) { cout << "Class B" << endl; }
};
struct C: B {
void f() { cout << "Class C" << endl; }
};
int main() {
B b; C c;
A* pa1 = &b;
A* pa2 = &c;
// b.f();
pa1->f();
pa2->f();
}
So I'm looking through the example and I need some clarification.
I think I get what is going on with
B b; C c;
But after that, I have no idea what is going at that point.
|
On March 19 2013 07:15 MiyaviTeddy wrote:
... snip ...
You should look up inheritance and polymorphism, along with pointers and typecasting.
If you know these then you can see A is treated as a base for other derived cases. The derived cases override a base function being called from A base pointers.
|
|
|
|
|
|
EPT
