- Why should a "c" programmer learn c++ ? (V2_a) - 3 Updates
| Anton Shepelev <anton.txt@gmail.com>: Sep 15 01:33AM +0300 Olcott to Anton Shepelev: > > would not be classes otherwise. So you use classes with > > methods but without inheritcance? -- interesting. > http://wiki.c2.com/?InheritanceBreaksEncapsulation Of course. Inheritance means dependencies going down and branching through layers upon layers of the class hierarchy. It is for this reason that McConnel argued against it in "Code Complete", and I agree with him. But classes without inheritance leave so very little of the whole object- oriented paradigm that switching to a simpler, procedural language seems only natural. Why stick to a huge object- oriented language to use 1% of its capabilities? Classes without inheritance are very easy to do in C, and so are dynamic arrays and sensible, (Borland)Pascal strings. > > classes help to avoid. > If every function depends on the same global data pool > changes to one function can break other functions. I understand what side effects are, but I am not familiar with the term "global data pool". If you mean global variables, then one can use them in procedural and object- oriented languages as easily as avoid them! C does not force you to use or abuse global variables... On the other hand, the fields of classes -- their hidden state -- are global with respect to methods because they are not syntatically passed in as parameters, and produce on class level exactly the same problem as global variables do on module level in procedural languages. The big difference, however, is that procedural programming lets you avoid global varialbes whereas classes make no sense without fields. > [...] > I did not pay much attention because std::vector is > already perfect. The subject of this thread being "Why should a "c" programmer learn c++ ?", I expected you to pay equal attention to solving your problems in both C and C++... > > So do my C dynamic arrays, although the factor is > > constant. > With a constant growth size is prioritized over time. I said constant factor, not constant increment. `factor' implies multiplication, not addition. > I did try using std::list once yet the benchmarks proved > that std::vector is much more efficient even for most > linked list things. A sensible approach once you have dynamic arrays. What do you do in situtaions where you store pointers or indices into a vector and have to compress it to release free space in between used elements? -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived] |
| olcott <NoOne@NoWhere.com>: Sep 14 05:58PM -0500 On 9/14/2020 5:33 PM, Anton Shepelev wrote: > oriented language to use 1% of its capabilities? Classes > without inheritance are very easy to do in C, and so are > dynamic arrays and sensible, (Borland)Pascal strings. Classes with their own member functions not only dive the complexity of system design by putting functionality and data in the same place it used properly can utterly eliminate data dependencies and side effects. > with the term "global data pool". If you mean global > variables, then one can use them in procedural and object- > oriented languages as easily as avoid them! C does not force A std::vector can hold many classes comprised of other classes and stored in a local variable. We can create a dozen of these in main() and have a very sophisticated and powerful system with no thought ever given to dynamic memory allocation, or pointers. main() can pass combinations of these sophisticated classes to its own functions as references. >> With a constant growth size is prioritized over time. > I said constant factor, not constant increment. `factor' > implies multiplication, not addition. I found that increasing size by double is generally the best tradeoff between space and time. > you do in situtaions where you store pointers or indices > into a vector and have to compress it to release free space > in between used elements? I never use pointers and whenever I need indexes they are only used in the member functions that needs them. -- Copyright 2020 Pete Olcott |
| Anton Shepelev <anton.txt@gmail.com>: Sep 15 02:15AM +0300 Juha Nieminen to Anton Shepelev: > If the length of the language definition were everything > that's needed to know whether a programming language is > "simple" to use or not, -> Of cousre, it is not. The length of the standard is related to what I should call the mathematical simplicity of a language, its simplicity in itself, with no regard to ease of use by mortals. In that sense, RedCode, BainFuck, and the Turing machine are all by magnitudes simpler than both C and C++. > language specification can be written in one page, and > talk about the "simplicity" of that language and how it > makes it better than C++. Not at all, because neither of those languages is a near subset of C++, which has all the complexity of C and tons more to boot. > correlate to the simplicity of use or understanding the > language. The esoteric programming languages are a perfect > proof of this. You are not quite correct. With the other conditions equal, the larger language is harder and longer to learn, forces the programmer to rember more stuff and to spend more time thinking which thing to use when, because large languages tend to offer not merely two, but often three, four, &c ways defur the same feline. The length of the standard, charaterising the outward size of the language, *is* one measure of both its mathematical and human complexities. > C is a very complicated language compared to many others, > both in terms of fully understanding it, as well as using > it. Yes. I should say it is certainly more complicated than Modula and Pascal. > for decades, still remember by heart the syntax of, for > example, "a pointer to a 2-dimensional array where the > second dimension is 100". The declaration of an array has nothing do to with pointer arithmetic, which *is* simple in C. I do not remeber having to do it, but here is my attempt, which did not come quite from the tips of my fingers: int **p[100]; OK, the syntax of C declarations is counterintuituve until one learns its logic, and even then it reamains at a considerable angle with human intuition. But is not this syntax the same in C++? > Heck, some such programmers might not even know such a > thing is possible at all! Even though they may have been > programming in C (or C++) for decades. I kid you not. Not to know that a language supports such a basic data structure? I don't know... One way to avoid the problem is to declare one thing at a time instead of putting all on one line, as many like to do. > declarations that hare extraordinarly hard to decipher. > Certainly not something you can decipher at a quick > glance. It is bad enough that C allows such complex declarations, but I consider it part of it mathematical simplicity. Yet I never ever write anything like Ian Collins's example: > void (*signal(int sig, void (*disp)(int)))(int); I do it one step at a time to keep my brain inside my skull: typedef void ( *f_disp )( int ); typedef void ( *f_signal)( int sig, f_disp disp ); And again, as far as I know, this declaration syntax is as essential part of C++ as it is of C. Why mention it? > intimate with the newer versions of the C standard, even > though they add relatively little to the language. > [...] I don't see how it bears on the subject, but I like lower volatility of the C standard. It help the programmer stay sane and focus on the real work instead of learning heaps of new features every several years. I absolutely adore the commitment of PDOS to C90. > language. I have witnessed first-hand how exasperating it > can be to write complicated several levels deep dynamic > data structures in C. Yes the basic model is very simple, but it takes discipline to use it correctly. Using indices into dynamic arrays instead of ad-hoc pointers helps a lot. > data structures. His final conclusion after the course > was, essentially, "C is not for me" and he moved to > Javascript, Haxe and C#.) Memory management in C# is so much more complicated than it is in C once you look into how it works instead of just using it lamer-like, without a notion of what is going on under the hood. > C is *not* a simple language. Not in the sense of being > simple to understand and use. May be "simple" in the same > sense as when that word is used to describe a person. I consider this adjective more true of people whose first programming language is Python or Java. They import and use high-level libraries and all the complicated language features with nary a glimpse of the super compicated machinery that makes it possible. They miss what programming is all about. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived] |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment