and you need to choose one for your project and stick with it.
if you do choose a C style paradigm (a paradigm easily available in C, that is)... why not add to that some of the Better C in C++? Like polymorphic functions, default arguments, generic functions, better static typing, all of which introduce no inefficiencies (at least no more than making efficiency mistakes in regular C does).
Even simple classes as structures with constructors and destructors are easy to use such that they don't introduce inefficient or "hidden" code.
computer science has a way of not only creating new words, but then using them for different things.
a funny one I've watched over the years is polymorphism, so often people think they know what it refers to but the bigger picture is it's used to mean many things.
polymorphism where functions taking different arguments are different forms... but also the idea of using classes as ancestor classes, and a few more, all coming down to the general natural language meaning of anything that takes multiple forms.
"template" is not really the right term these days, the unifying term is "generic programming".
but what I said is still true. That sort of thing has been kept for a minimum.
It's legit to say "not minimum enough" and my OOPers would happilly say compatibility is "way too minumumly broken", but there is no doubt that there has been a very real attempt to keep it as minimal as possible.
You can use pointers. But you can also adopt a standard where you do not have to use pointers (generally you will manipulate pointers at lower levels, say in class libraries you make or purchase). You can't adopt a "pointerless paradigm" for an application project, and then go use pointers.
You can use printf style string building and stream style, but it's better to choose one and use it.
RTTI: yes... and if you grant that some projects really do need/want RTTI, then this is a conflict with the possible paradigm of relying only on compile time type checking.
You can have a paradigm where constructors cannot fail... i.e. you can set defaults and prepare your class, but you might avoid mallocing or attaching to streams, etc., in your constructor, instead putting that into an "init" type function. That's legit, it's also legit to do it in constructors (assuming you don't mind using exceptions to handle errors in the constructor), but doing both in one project is not a clear approach. Goto is available in C++... and you might use an old fashioned error handling system using goto:, exceptions are probably better, but the former is still legal C++ and if used for whatever reason, should not be mixed also with using exceptions sometimes, and goto at others.
All of this comes from the fact that C++ is designed to give options to the programmer. And many of these options are contradictory, if not literally incoherent when used together, use of them together shows a lack of design, show that there is no design, or at least that there is a mixed and therefore unclear standard at use in the code.
>Yup. Trouble is that they are slow, but so are virtual functions. (In my book this is because because C++, like Java, isn't a true OO language, but some macro hack)
C++ isn't supposed to be a true OO language. Stroustrup doesn't like telling people what idiom to use and doesn't believe in one paradigm to rule them all.
>I have an impression that references are in C++ due to a necessity rather than clarity, something to do with operator overloading etc.
you got that right
>>templates etc.
>You can do incredible things with #include/#define;)
I didn't know until recently that this was exactly how templates came about... from the experience of using CPP macros to do generic programming. The only part of C that Stroustrup is really against (but by no means has the C++ standards committee been as against), is the C preprocessor. Still, I think templates are nothing but macros on steroids. Of course, it's nice that the compiler is doing this which yields a lot of advantages.
>The problem with C++ with stuff like kernels is that it forces its own way of implementing things. Sometimes it just doesn't meet the needs. For example, what if you needed to refer to object data and vtable with a pair of pointers instead of storing the latter in the object?
I don't get this. Why couldn't you do that if you need to? You would have two data structures. Obviously you would manipulate the vtable yourself... because you chose to, so you would not use C++ syntax to invoke those functions... except that with your class definition you could still create very convienient and efficient syntax for calling these functions.
In the end, the fallback is that C-style code is a part of C++... C++ is not some pure language trying to stop you from writing C-style when that's the best thing. Quite the contrary, C++ has bent over backward to secure and guarantee you could do just that!
>(with the premise that const_cast and mutable variables aren't used in abundance, which is bad programming practice anyway)
a lot of people object to the fact that you can break the rules at all.
>(with the premise that const_cast and mutable variables aren't used in abundance, which is bad programming practice anyway)
yep... I'll admit I've often been lazy about using const (and get called on it) becuase it takes care to use and not get screwed this time or that time yada yada (peanut gallery: shut up, I admitted it was lazy... it's not hard)... but the point is, doing it makes it easier for the user of your code... it's part of the contract with the user right there in the declarations, with a compiler to help enforce it.
you have a good point. I think references are probably best left to operator overloading, usually, and not library or function calls in which it would be better to request a pointer and be more obvious to the user/caller how you will handle the object.
function polymorphism is one of the main advantages to writing C-style in C++. It's nice to share the name of the function but have versions that take different arguments.
Stroustrup et al took great care to make sure the C++ be able to solve all the same problems as C, even to the degree that C code compiles pretty much unaltered (a couple exceptions, generally regarding typing issues).
C-style is ONE OF THE PARADIGMS available in C++, and if you use it, you get no "C++" overhead. That's by design. Please note all the other languages that DON'T take that approach. It wasn't an accident.
I like the forumlation that it throws C in an OOP direction, except that the STL isn't oop, and strong typing isn't OOP, although it's realated.
Seriously, read History of C++ and you will understand the lengths gone to to make C++ C v2.0 compared with... Objective C, etc. etc. etc.
None of this means the C++ IS Cv2.0, it's not (that would be ANSI C), and maybe there are even better languages that could be C v3.0... but I won't hold my breath waiting for you to create it.
Slashdot Mirror
well, when I was young... oh fuck it.
damn. here it is, I don't want you to miss it.
/etc/init.d/httpd start
#!/bin/bash
let's protect them!
I wrote it in bash.
/etc/init.d/httpd start
#!/bin/bash
now I can use that money to pay my rent.
Netcraft confirms this study is dieing!?
... absolutely nothing about UCB or just very very little?
and you need to choose one for your project and stick with it.
if you do choose a C style paradigm (a paradigm easily available in C, that is)... why not add to that some of the Better C in C++? Like polymorphic functions, default arguments, generic functions, better static typing, all of which introduce no inefficiencies (at least no more than making efficiency mistakes in regular C does).
Even simple classes as structures with constructors and destructors are easy to use such that they don't introduce inefficient or "hidden" code.
but C++ isn't an OOP language.
it's a language with OOP idioms available.
bit difference, just ask any C++ hater of the OOP Purist School.
it's a natural language meaning.
computer science has a way of not only creating new words, but then using them for different things.
a funny one I've watched over the years is polymorphism, so often people think they know what it refers to but the bigger picture is it's used to mean many things.
polymorphism where functions taking different arguments are different forms... but also the idea of using classes as ancestor classes, and a few more, all coming down to the general natural language meaning of anything that takes multiple forms.
"template" is not really the right term these days, the unifying term is "generic programming".
or maybe it was a different set of mistakes!
a continuation of it is ideal
it is evolution which has been drivien
but what I said is still true. That sort of thing has been kept for a minimum.
It's legit to say "not minimum enough" and my OOPers would happilly say compatibility is "way too minumumly broken", but there is no doubt that there has been a very real attempt to keep it as minimal as possible.
it's true.
C++ is multiparadigmed.
You can use pointers. But you can also adopt a standard where you do not have to use pointers (generally you will manipulate pointers at lower levels, say in class libraries you make or purchase). You can't adopt a "pointerless paradigm" for an application project, and then go use pointers.
You can use printf style string building and stream style, but it's better to choose one and use it.
RTTI: yes... and if you grant that some projects really do need/want RTTI, then this is a conflict with the possible paradigm of relying only on compile time type checking.
You can have a paradigm where constructors cannot fail... i.e. you can set defaults and prepare your class, but you might avoid mallocing or attaching to streams, etc., in your constructor, instead putting that into an "init" type function. That's legit, it's also legit to do it in constructors (assuming you don't mind using exceptions to handle errors in the constructor), but doing both in one project is not a clear approach. Goto is available in C++... and you might use an old fashioned error handling system using goto:, exceptions are probably better, but the former is still legal C++ and if used for whatever reason, should not be mixed also with using exceptions sometimes, and goto at others.
All of this comes from the fact that C++ is designed to give options to the programmer. And many of these options are contradictory, if not literally incoherent when used together, use of them together shows a lack of design, show that there is no design, or at least that there is a mixed and therefore unclear standard at use in the code.
you just lowered my blood pressure. :)
C++ is a multiparadigmed language, one of the paradigms is the set of paradigms available in C.
That's according to Stroustrup. Believe me when I say I don't want to apply to work there. Next Coward plz.
I assume there is some terminological collision here.
"templates" in C++ refers to it's typesafe generic programming...
to each his own.
frankly... minimal C++ use to me is C with the class construct, constructors and destructors... which of course is not just as better C.
>Yup. Trouble is that they are slow, but so are virtual functions. (In my book this is because because C++, like Java, isn't a true OO language, but some macro hack)
;)
C++ isn't supposed to be a true OO language. Stroustrup doesn't like telling people what idiom to use and doesn't believe in one paradigm to rule them all.
>I have an impression that references are in C++ due to a necessity rather than clarity, something to do with operator overloading etc.
you got that right
>>templates etc.
>You can do incredible things with #include/#define
I didn't know until recently that this was exactly how templates came about... from the experience of using CPP macros to do generic programming. The only part of C that Stroustrup is really against (but by no means has the C++ standards committee been as against), is the C preprocessor. Still, I think templates are nothing but macros on steroids. Of course, it's nice that the compiler is doing this which yields a lot of advantages.
>The problem with C++ with stuff like kernels is that it forces its own way of implementing things. Sometimes it just doesn't meet the needs. For example, what if you needed to refer to object data and vtable with a pair of pointers instead of storing the latter in the object?
I don't get this. Why couldn't you do that if you need to? You would have two data structures. Obviously you would manipulate the vtable yourself... because you chose to, so you would not use C++ syntax to invoke those functions... except that with your class definition you could still create very convienient and efficient syntax for calling these functions.
In the end, the fallback is that C-style code is a part of C++... C++ is not some pure language trying to stop you from writing C-style when that's the best thing. Quite the contrary, C++ has bent over backward to secure and guarantee you could do just that!
>(with the premise that const_cast and mutable variables aren't used in abundance, which is bad programming practice anyway)
a lot of people object to the fact that you can break the rules at all.
>(with the premise that const_cast and mutable variables aren't used in abundance, which is bad programming practice anyway)
yep... I'll admit I've often been lazy about using const (and get called on it) becuase it takes care to use and not get screwed this time or that time yada yada (peanut gallery: shut up, I admitted it was lazy... it's not hard)... but the point is, doing it makes it easier for the user of your code... it's part of the contract with the user right there in the declarations, with a compiler to help enforce it.
you have a good point. I think references are probably best left to operator overloading, usually, and not library or function calls in which it would be better to request a pointer and be more obvious to the user/caller how you will handle the object.
and why did these C++ features keep making it back into C?
The answers have been available in print for more than ten years.
sorry, that other guy got me worked up.
meaning without the OOP stuff.
function polymorphism is one of the main advantages to writing C-style in C++. It's nice to share the name of the function but have versions that take different arguments.
Stroustrup et al took great care to make sure the C++ be able to solve all the same problems as C, even to the degree that C code compiles pretty much unaltered (a couple exceptions, generally regarding typing issues).
C-style is ONE OF THE PARADIGMS available in C++, and if you use it, you get no "C++" overhead. That's by design. Please note all the other languages that DON'T take that approach. It wasn't an accident.
I like the forumlation that it throws C in an OOP direction, except that the STL isn't oop, and strong typing isn't OOP, although it's realated.
Seriously, read History of C++ and you will understand the lengths gone to to make C++ C v2.0 compared with... Objective C, etc. etc. etc.
None of this means the C++ IS Cv2.0, it's not (that would be ANSI C), and maybe there are even better languages that could be C v3.0... but I won't hold my breath waiting for you to create it.
I happen to have been reading Stroustrup on the History of C++ recently, and he is the one that paints C++ this way.
so fuck you unread bigot.
did I mention fuck you?
C++ is an improved C, choke on it. read a book.