Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #13209 > unrolled thread
| Started by | AD <isquat@gmail.com> |
|---|---|
| First post | 2012-01-10 04:35 -0800 |
| Last post | 2012-01-17 02:31 -0800 |
| Articles | 20 on this page of 81 — 24 participants |
Back to article view | Back to comp.lang.c++
Oozing poison AD <isquat@gmail.com> - 2012-01-10 04:35 -0800
Re: Oozing poison Leigh Johnston <leigh@i42.co.uk> - 2012-01-10 15:19 +0000
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-11 00:43 -0800
Re: Oozing poison "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-11 10:01 +0100
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-11 22:09 +1300
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-11 01:42 -0800
Re: Oozing poison Leigh Johnston <leigh@i42.co.uk> - 2012-01-11 13:36 +0000
Re: Oozing poison John Bokma <john@castleamber.com> - 2012-01-11 10:08 -0600
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-12 06:08 -0800
Re: Oozing poison Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 14:13 +0000
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:08 -0800
Re: Oozing poison Henrik Faber <hfaber@invalid.net> - 2012-01-17 12:50 +0100
Re: Oozing poison Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-13 02:18 -0800
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:24 -0800
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-11 16:50 +0000
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-12 06:04 -0800
Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-12 10:13 -0500
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:19 -0800
Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-17 08:04 -0500
Re: Oozing poison Miles Bader <miles@gnu.org> - 2012-01-18 13:51 +0900
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-21 04:40 -0800
Re: Oozing poison Quint Rankid <qbr567@gmail.com> - 2012-01-21 09:05 -0800
Re: Oozing poison Wil Evers <bouncer@dev.null> - 2012-01-21 18:52 +0000
Re: Oozing poison Quint Rankid <qbr567@gmail.com> - 2012-01-21 11:33 -0800
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-25 02:23 -0800
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-25 02:07 -0800
Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-25 07:59 -0500
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-26 07:54 +1300
Re: Oozing poison Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-01-21 22:43 -0500
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-22 21:05 +1300
Re: Oozing poison Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-01-22 18:21 -0500
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-23 15:55 +0000
Re: Oozing poison gwowen <gwowen@gmail.com> - 2012-01-23 08:37 -0800
Re: Oozing poison Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-01-24 22:48 -0500
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-25 19:44 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-26 08:56 +1300
Re: Oozing poison 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-25 23:04 -0800
Re: Oozing poison Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:24 -0800
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 19:13 +0000
Re: Oozing poison Brian Drummond <brian@shapes.demon.co.uk> - 2012-01-27 00:12 +0000
Re: Oozing poison "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-26 22:44 -0600
Re: Oozing poison 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 14:25 -0800
Re: Oozing poison Robert Miles <milesrf@Usenet-News.net> - 2012-02-26 22:16 -0600
Re: Oozing poison "Gernot Frisch" <me@privacy.net> - 2012-01-24 18:21 +0100
Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-24 12:41 -0500
Re: Oozing poison Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:25 -0800
Re: Oozing poison Rui Maciel <rui.maciel@gmail.com> - 2012-01-25 19:44 +0000
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-26 09:44 +0000
Re: Oozing poison Rui Maciel <rui.maciel@gmail.com> - 2012-01-26 10:36 +0000
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 19:18 +0000
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-26 20:42 +0000
Re: Oozing poison Juha Nieminen <nospam@thanks.invalid> - 2012-01-26 16:30 +0000
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 19:24 +0000
Re: Oozing poison Cholo Lennon <chololennon@hotmail.com> - 2012-01-26 17:13 -0300
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 20:55 +0000
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-26 22:08 +0000
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 00:32 +0000
Re: Oozing poison Dombo <dombo@disposable.invalid> - 2012-01-28 12:59 +0100
Re: Oozing poison Cholo Lennon <chololennon@hotmail.com> - 2012-01-27 18:28 -0300
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-29 18:02 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-27 20:18 +1300
Re: Oozing poison Miles Bader <miles@gnu.org> - 2012-01-27 18:09 +0900
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 20:29 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 10:06 +1300
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 21:26 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 12:22 +1300
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-28 04:18 +0000
Re: Oozing poison Miles Bader <miles@gnu.org> - 2012-01-28 13:44 +0900
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-28 21:31 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-29 11:32 +1300
Re: Oozing poison 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 14:55 -0800
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-29 11:59 +1300
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-30 17:08 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 18:06 +1300
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-28 22:49 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-29 12:22 +1300
Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 20:16 +0000
Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 10:01 +1300
Re: Oozing poison Juha Nieminen <nospam@thanks.invalid> - 2012-01-28 16:00 +0000
Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-10 21:42 +0000
Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:31 -0800
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | "MikeWhy" <boat042-nospam@yahoo.com> |
|---|---|
| Date | 2012-01-26 22:44 -0600 |
| Message-ID | <jfta2i$hcu$1@dont-email.me> |
| In reply to | #13602 |
"Brian Drummond" <brian@shapes.demon.co.uk> wrote in message
news:jfsq5m$q7i$1@dont-email.me...
> On Thu, 26 Jan 2012 03:24:11 -0800, Nick Keighley wrote:
>
>> On Jan 26, 7:04Â am, 88888 Dihedral <dihedral88...@googlemail.com> wrote:
>>
>>> Programming in C++ code costs more to maintain.
>>
>> I've seen some pretty nasty C
>
> They are both pretty bad.
>
>>> and the famous non-checking for array boundaries in any read/write. The
>>> vetctor part just covers up some traps but it slows down as expected.
>>
>> what language avoids this? If you do array bound checking it costs. If
>> you don't then you run a risk. Are there languages that can prove array
>> bounds won't be breeched?
>
> There certainly are.
> But array bound checks rarely cost anything. If your compiler can't prove
> and eliminate the bulk of them at compile time, get a better compiler.
> Help it by defining a new integer type restricted to the size of the
> array (even where the array size is only known at runtime) and using that
> type for the index.
> The remaining few checks cost, but you would have to write the same
> checks by hand in C, so they don't cost extra, they just save programmer
> time.
template <typename DataT, size_t LenT>
void Foo(DataT (& foo)[LenT])
{
...
}
> Anyone with even a little sympathy for "AD"'s position, or interest in
> writing readable, maintainable, safe code would find it worthwhile to try
> Ada 2005.
Surely, this is even more absurd than the OP claim. ;)
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2012-01-28 14:25 -0800 |
| Message-ID | <14453264.313.1327789537673.JavaMail.geo-discussion-forums@prie27> |
| In reply to | #13590 |
在 2012年1月26日星期四UTC+8下午7时24分11秒，Nick Keighley写道： > On Jan 26, 7:04 am, 88888 Dihedral <dihedr...@googlemail.com> > wrote: > > > Programming in C++ code costs more to maintain. > > I've seen some pretty nasty C > > > Maybe this is good for offering > > more programming positions for the employees. Also problems in C are inherited > > in C++ such as the non-closure integer arithmetics and the lousy sort trap > > the what? > > > and the famous non-checking for array boundaries in any read/write. > > The vetctor part just covers up some traps but it slows down as expected. > > what language avoids this? If you do array bound checking it costs. If > you don't then you run a risk. Are there languages that can prove > array bounds won't be breeched? > > > The operator reloading and the copy constructor part of derived classes introduce > > more problems in any operation that needs a new object in the RHS to be > > assigned to the LHS. > > could you expand on that; I didn't quite follow you. I don't recall > encountering a problem in this area. > I classify methods according to A. those just modify pass in objects and use temprorary variables on the stack or static allocated buffers on the heap before invoked by messages. This class is safe for run-time polymorphism. B. those have to generate any new non-temporary object to be assigned to some objects in return, somewhat like the heap hog eater in this calss. If any method in this class calls a method in this class, then it becomes a memrory hog very easily especially in the recursive way. > > Of course there are people using C++ without deriving > > new classses and just use those libraries in trivial programs. > > Then in this cas C++ is easy to mantain. > > ...and isn't really C++
[toc] | [prev] | [next] | [standalone]
| From | Robert Miles <milesrf@Usenet-News.net> |
|---|---|
| Date | 2012-02-26 22:16 -0600 |
| Message-ID | <4f4b038f$0$27617$882e7ee2@usenet-news.net> |
| In reply to | #13532 |
On 1/21/2012 6:40 AM, AD wrote: > On Jan 18, 6:51 am, Miles Bader<mi...@gnu.org> wrote: >> AD<isq...@gmail.com> writes: >>>> So, you're not coding in C++, and you come to a C++ community hangout to >>>> complain about C++ being difficult to comprehend, and you expect what, >>>> sympathy?<shrug> >> >>> I'm not coding in C++ ANYMORE >>> I could not possibly see how it can be used to write robust code >> >> You expect us to trust your judgement? >> >> [I've found C++ _much_ easier to write robust code in compared to C. >> It is clearly no proof against incompetent coders (nothing is), but it >> does offer some really good tools to help competent ones...] >> > Well, objective-c (and it's inherent to all c based languages, unless > you start ripping out pointers, etc) is prone to allowing a single fly- > idiot > poisoning the whole barrel, and java like languages > were designed precisely to keep idiots at bay, but c++ seems to be > especially > susceptible to providing morons with tools to automate > writing some crap code. Looks like you've been fired from a programming management job for incompetence in choosing which programmers you hired, but weren't fired fast enough to keep you from becoming familiar with those incompetent programmers.
[toc] | [prev] | [next] | [standalone]
| From | "Gernot Frisch" <me@privacy.net> |
|---|---|
| Date | 2012-01-24 18:21 +0100 |
| Message-ID | <9o87laF9tlU1@mid.individual.net> |
| In reply to | #13432 |
> I could not possibly see how it can be used to write robust code Am I feeding a troll now? :S You can write perfectly robust code in C++ if you don't use pointers at all. There's usually no need to do this, as other languages don't even have them. Use references if you pass byref, and use containers if you want to allocate to be safe.
[toc] | [prev] | [next] | [standalone]
| From | Victor Bazarov <v.bazarov@comcast.invalid> |
|---|---|
| Date | 2012-01-24 12:41 -0500 |
| Message-ID | <jfmqgi$4sn$1@dont-email.me> |
| In reply to | #13562 |
On 1/24/2012 12:21 PM, Gernot Frisch wrote: > >> I could not possibly see how it can be used to write robust code > > Am I feeding a troll now? :S > [..] You are. Please don't. Thanks. V -- I do not respond to top-posted replies, please don't ask
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-01-26 03:25 -0800 |
| Message-ID | <baae7a0a-9010-4f96-8622-1b7d88460df5@s18g2000vby.googlegroups.com> |
| In reply to | #13562 |
On Jan 24, 5:21 pm, "Gernot Frisch" <m...@privacy.net> wrote: > > I could not possibly see how it can be used to write robust code > > Am I feeding a troll now? :S > > You can write perfectly robust code in C++ if you don't use pointers at all. > There's usually no need to do this, as other languages don't even have them. how do I build complex structures? Eg.trees. How do I do runtime polymorphism? > Use references if you pass byref, and use containers if you want to allocate > to be safe. Containers of pointers?
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-01-25 19:44 +0000 |
| Message-ID | <jfpm34$91j$1@speranza.aioe.org> |
| In reply to | #13432 |
AD wrote: > I'm not coding in C++ ANYMORE > I could not possibly see how it can be used to write robust code I could not possibly see how matter can consist of arrangements of a dozen types of sub-atomic particles. Then again, I'm no particle physicist. So that explains it. > linux kernel developers at one point tried (and failed), > primirily because of the buggy g++ frontend to gcc > and you can really count on your palm c++ compilers that work okay. Taken from the linux kernel mailing list FAQ: Why don't we rewrite the Linux kernel in C++? http://www.tux.org/lkml/#s15-3 They didn't actually failed to write the linux kernel with C++. They only opted to discontinue to write code that compiled under g++ due to performance issues. If you take the time to discover the reasons behind the decision by the linux kernel team not to use C++ to write kernel code, you will notice that every single reason they point out is related to the use of C++ to write kernel code. The keyword here is "kernel code". Having said that, I'll point out what they state regarding the C++ programming language: <quote> My personal view is that C++ has its merits, and makes object-oriented programming easier. However, it is a more complex language and is less mature than C. The greatest danger with C++ is in fact its power. It seduces the programmer, making it much easier to write bloatware. The kernel is a critical piece of code, and must be lean and fast. We cannot afford bloat. I think it is fair to say that it takes more skill to write efficient C++ code than C code. Not every contributer to the linux kernel is an uber-guru, and thus will not know the various tricks and traps for producing efficient C++ code. </quote> Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2012-01-26 09:44 +0000 |
| Message-ID | <slrnji2839.1ls.grahn+nntp@frailea.sa.invalid> |
| In reply to | #13584 |
On Wed, 2012-01-25, Rui Maciel wrote: > AD wrote: ... >> linux kernel developers at one point tried (and failed), >> primirily because of the buggy g++ frontend to gcc >> and you can really count on your palm c++ compilers that work okay. ... > Having said that, I'll point out what they state regarding the C++ > programming language: > > <quote> > My personal view is that C++ has its merits, and makes object-oriented > programming easier. However, it is a more complex language and is less > mature than C. The greatest danger with C++ is in fact its power. It seduces > the programmer, making it much easier to write bloatware. The kernel is a > critical piece of code, and must be lean and fast. We cannot afford bloat. I > think it is fair to say that it takes more skill to write efficient C++ code > than C code. Not every contributer to the linux kernel is an uber-guru, and > thus will not know the various tricks and traps for producing efficient C++ > code. > </quote> That's what the LKLM FAQ maintainer wrote. When /Linus/ writes about C++, he sounds almost exactly like "AD". That's probably the the first thing that prevents C++ in the Linux kernel. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-01-26 10:36 +0000 |
| Message-ID | <jfrab7$i9t$1@speranza.aioe.org> |
| In reply to | #13588 |
Jorgen Grahn wrote: > That's what the LKLM FAQ maintainer wrote. When Linus writes about > C++, he sounds almost exactly like "AD". That's probably the the first > thing that prevents C++ in the Linux kernel. You can read for yourself what Linus Torvalds had to say about C++: http://lkml.org/lkml/2004/1/20/20 And again, it was about using C++ on kernel code, not C++ in general. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2012-01-26 19:18 +0000 |
| Message-ID | <pGhUq.10760$Jp3.8519@news.usenetserver.com> |
| In reply to | #13589 |
Rui Maciel <rui.maciel@gmail.com> writes: >Jorgen Grahn wrote: > >> That's what the LKLM FAQ maintainer wrote. When Linus writes about >> C++, he sounds almost exactly like "AD". That's probably the the first >> thing that prevents C++ in the Linux kernel. > >You can read for yourself what Linus Torvalds had to say about C++: > >http://lkml.org/lkml/2004/1/20/20 > He misses the point, in that article. I disagreed with him then, and still do now. Just because C++ has a feature (e.g. exceptions), doesn't mean you have to use it. Having written two operating systems and a hypervisor in a dialect of C++ (no exceptions, no run-time typing, no templates), the features you can use (data encapsulation using classes) are quite useful. He seems to miss the fact that one can overload not only the new operator on a per-class basis, but indeed, can overload it on a global basis in a kernel. scott
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2012-01-26 20:42 +0000 |
| Message-ID | <slrnji3emh.1ls.grahn+nntp@frailea.sa.invalid> |
| In reply to | #13589 |
On Thu, 2012-01-26, Rui Maciel wrote: > Jorgen Grahn wrote: > >> That's what the LKLM FAQ maintainer wrote. When Linus writes about >> C++, he sounds almost exactly like "AD". That's probably the the first >> thing that prevents C++ in the Linux kernel. > > You can read for yourself what Linus Torvalds had to say about C++: > > http://lkml.org/lkml/2004/1/20/20 I did; it was quoted in the LKML FAQ. If it's supposed to disprove what I wrote, I fail to see how. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-01-26 16:30 +0000 |
| Message-ID | <4f217fc2$0$4387$7b1e8fa0@news.nbl.fi> |
| In reply to | #13584 |
Rui Maciel <rui.maciel@gmail.com> wrote: > <quote> > My personal view is that C++ has its merits, and makes object-oriented > programming easier. However, it is a more complex language and is less > mature than C. The greatest danger with C++ is in fact its power. It seduces > the programmer, making it much easier to write bloatware. The kernel is a > critical piece of code, and must be lean and fast. We cannot afford bloat. I > think it is fair to say that it takes more skill to write efficient C++ code > than C code. Not every contributer to the linux kernel is an uber-guru, and > thus will not know the various tricks and traps for producing efficient C++ > code. > </quote> One of the most common misconceptions among advocate C hackers is that programming in C somehow automatically makes your program more efficient and have "less bloat" than, for example, when programming C++, which requires more care to be as efficient and small. (And I'm discounting here the bunch that believes that C++ *always* produces less efficient and larger code than C.) Linus Torvalds, in addition to that, also has this completely weird notion that programming in C also automatically makes your code easier to understand and maintain (while C++ is the exact opposite). Of course practical examples tell a completely different story. There are plenty of C programs out there that are absolutely horrendous, inefficient, and almost completely impossible to maintain. And many of these are not just some obscure one-man projects, but large and popular ones. (For example much of mplayer was like this last time I checked. Granted, this was many years ago, so it's theoretically possible that they have done a complete refactoring of the entire code. I find it unlikely, though.) That's not to say that you cannot create horrendous programs in C++. Of course you can. And probably over half of the C++ programs out there are horrendous. OTOH, also probably over half of C programs out there are likewise horrendous. The difference is, however, that C++ offers you tools that C doesn't, tools to make your code safer and easier to understand and maintain, while still being as efficient as an equivalent C program would.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2012-01-26 19:24 +0000 |
| Message-ID | <ILhUq.10761$Jp3.1129@news.usenetserver.com> |
| In reply to | #13592 |
Juha Nieminen <nospam@thanks.invalid> writes: > That's not to say that you cannot create horrendous programs in C++. >Of course you can. And probably over half of the C++ programs out there >are horrendous. OTOH, also probably over half of C programs out there >are likewise horrendous. The readability of C++ seems to get worse with each new version of the standard. Once the <XXX> elements (static/dynamic casts, templates) were added to the language, it became worse than perl for readability. Java has a similar problem; after 1.5, they just started adding language elements willy-nilly (but at least the syntax isn't quite so obtuse as the C++ stuff). C++ prior to templates (Version 2.1, granted much closer to C) can be quite elegent. And, of course, readability is in the eye of the beholder :-) scott
[toc] | [prev] | [next] | [standalone]
| From | Cholo Lennon <chololennon@hotmail.com> |
|---|---|
| Date | 2012-01-26 17:13 -0300 |
| Message-ID | <jfsc2b$bkp$1@speranza.aioe.org> |
| In reply to | #13595 |
On 26/01/2012 16:24, Scott Lurndal wrote: > The readability of C++ seems to get worse with each new version of the > standard. Once the<XXX> elements (static/dynamic casts, templates) were added > to the language, it became worse than perl for readability. Really? Do you think C++ cast operators go against readability? For me is the opposite: At glance, for example, they give you more information than the traditional C cast and, as a result, they are (IMHO) more readable. -- Cholo Lennon Bs.As. ARG
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2012-01-26 20:55 +0000 |
| Message-ID | <T4jUq.10763$Jp3.2627@news.usenetserver.com> |
| In reply to | #13596 |
Cholo Lennon <chololennon@hotmail.com> writes: >On 26/01/2012 16:24, Scott Lurndal wrote: >> The readability of C++ seems to get worse with each new version of the >> standard. Once the<XXX> elements (static/dynamic casts, templates) were added >> to the language, it became worse than perl for readability. > >Really? Do you think C++ cast operators go against readability? For me >is the opposite: At glance, for example, they give you more information >than the traditional C cast and, as a result, they are (IMHO) more readable. > Buenas, I think they may provide better _maintainability_ at the expense of _readability_. It may also be that for someone coming from a C background (starting in 1978), the dynamic/static cast syntax just looks alien and out of place. Templates and exceptions on the other hand, have a distinct impact on code size (thus icache footprint, thus performance). Could be worse, I suppose (see below) scott 004400 PROGRAM-ID. ENV 004500 ENVT01. ENV 004600* WHERE T = TEST SYSTEM NUMBER. ENV 004700 AUTHOR. ENV 004900 ADC-DPS N0044 005000 ATLANTA. ENV 005100 DATE-COMPILED. ENV 005200 ENVIRONMENT DIVISION. ENV 005300 CONFIGURATION SECTION. ENV 005400 SOURCE-COMPUTER. ENV 005500 NOT-DOCUMENTED. N0221 005600 OBJECT-COMPUTER. ENV 005700 V-300, N4556 005800 STACK SIZE IS 1, ENV 005900 SEGMENT-LIMIT IS 1. ENV 006000/ ENV 006100 INPUT-OUTPUT SECTION. ENV 006200 FILE-CONTROL. ... 822000 VALIDATE-ADVICE-LOOP. N1812 822100 IF NOT-KEY NOT = 0 N1812 822200 PERFORM SEND-NOTICE THRU SEND-NOTICE-EXIT. N1812 822300 PERFORM RECEIVE-SCREEN THRU RECEIVE-SCREEN-EXIT. N1812 822400 MOVE Y TO POSITION-CURSOR. N1812 822500 IF S216-CUST-DR-RT NOT NUMERIC N1812 822600 MOVE 19 TO NOT-KEY N1812 822700 MOVE ERROR-CHAR TO S216-CUST-DR-RT N1812 822800 GO TO VALIDATE-ADVICE-LOOP. N1812 822900 IF S216-CUST-DR-TC NOT NUMERIC N1812 823000 MOVE 19 TO NOT-KEY N1812 823100 MOVE ERROR-CHAR TO S216-CUST-DR-TC N1812 823200 GO TO VALIDATE-ADVICE-LOOP. N1812
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2012-01-26 22:08 +0000 |
| Message-ID | <slrnji3jng.1ls.grahn+nntp@frailea.sa.invalid> |
| In reply to | #13598 |
On Thu, 2012-01-26, Scott Lurndal wrote: > Cholo Lennon <chololennon@hotmail.com> writes: >>On 26/01/2012 16:24, Scott Lurndal wrote: >>> The readability of C++ seems to get worse with each new version of the >>> standard. Once the<XXX> elements (static/dynamic casts, templates) >>> were added >>> to the language, it became worse than perl for readability. >> >>Really? Do you think C++ cast operators go against readability? For me >>is the opposite: At glance, for example, they give you more information >>than the traditional C cast and, as a result, they are (IMHO) more readable. > > I think they may provide better _maintainability_ at the expense of > _readability_. Keep in mind, both of you, that the best way to deal with casting is to avoid doing it! Or isolating it to a few places. C++ provides better tools for that than C. ... > Templates and exceptions on the other hand, have a distinct impact > on code size (thus icache footprint, thus performance). I can't comment on exceptions, but how do templates, in general, increase code size? Note that templates do not imply function inlining. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2012-01-27 00:32 +0000 |
| Message-ID | <jgmUq.16032$5g.8866@news.usenetserver.com> |
| In reply to | #13599 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >On Thu, 2012-01-26, Scott Lurndal wrote: >> Cholo Lennon <chololennon@hotmail.com> writes: >>>On 26/01/2012 16:24, Scott Lurndal wrote: >>>> The readability of C++ seems to get worse with each new version of the >>>> standard. Once the<XXX> elements (static/dynamic casts, templates) >>>> were added >>>> to the language, it became worse than perl for readability. >>> >>>Really? Do you think C++ cast operators go against readability? For me >>>is the opposite: At glance, for example, they give you more information >>>than the traditional C cast and, as a result, they are (IMHO) more readable. >> >> I think they may provide better _maintainability_ at the expense of >> _readability_. > >Keep in mind, both of you, that the best way to deal with casting is >to avoid doing it! Or isolating it to a few places. C++ provides >better tools for that than C. > >... >> Templates and exceptions on the other hand, have a distinct impact >> on code size (thus icache footprint, thus performance). > >I can't comment on exceptions, but how do templates, in general, >increase code size? Note that templates do not imply function >inlining. With g++, each specialization of a template results in replication of each referenced non-inline member function. So for each unique <type>::member_function, a separate body of code will generated. For only one or two specializations, it may not be a significant performance impact, but consider a template for a linked list, which is specialized by several hundred different types in an operating system; the amount of added code can be considerable. While not typesafe, a simple double-linked list base class from which all those types derive, is much more efficient from a icache footprint standpoint and fairly simple iterators can be built to iterate over the list (using casts). In this case efficiency wins for OS and hypervisor implementations where every page used by the OS can't be given to the application or guest. s
[toc] | [prev] | [next] | [standalone]
| From | Dombo <dombo@disposable.invalid> |
|---|---|
| Date | 2012-01-28 12:59 +0100 |
| Message-ID | <4f23e2e9$0$14710$5fc3050@news.tiscali.nl> |
| In reply to | #13600 |
Op 27-Jan-12 1:32, Scott Lurndal schreef: > Jorgen Grahn<grahn+nntp@snipabacken.se> writes: >> On Thu, 2012-01-26, Scott Lurndal wrote: >>> Cholo Lennon<chololennon@hotmail.com> writes: >>>> On 26/01/2012 16:24, Scott Lurndal wrote: >>>>> The readability of C++ seems to get worse with each new version of the >>>>> standard. Once the<XXX> elements (static/dynamic casts, templates) >>>>> were added >>>>> to the language, it became worse than perl for readability. >>>> >>>> Really? Do you think C++ cast operators go against readability? For me >>>> is the opposite: At glance, for example, they give you more information >>>> than the traditional C cast and, as a result, they are (IMHO) more readable. >>> >>> I think they may provide better _maintainability_ at the expense of >>> _readability_. >> >> Keep in mind, both of you, that the best way to deal with casting is >> to avoid doing it! Or isolating it to a few places. C++ provides >> better tools for that than C. >> >> ... >>> Templates and exceptions on the other hand, have a distinct impact >>> on code size (thus icache footprint, thus performance). >> >> I can't comment on exceptions, but how do templates, in general, >> increase code size? Note that templates do not imply function >> inlining. > > With g++, each specialization of a template results in replication of each > referenced non-inline member function. So for each unique<type>::member_function, > a separate body of code will generated. For only one or two specializations, it > may not be a significant performance impact, but consider a template for a linked > list, which is specialized by several hundred different types in an operating system; > the amount of added code can be considerable. > > While not typesafe, a simple double-linked list base class from which all those > types derive, is much more efficient from a icache footprint standpoint and fairly > simple iterators can be built to iterate over the list (using casts). With judicious use of templates you can have both in C++; type-safe linked lists without code duplication using the technique explained in the chapter about template specializations in the book "The C++ programming Language" written by Bjarne Stroustrup. Yes, with this technique there are a few casts in the template code, but that is a hell of a lot better than sprinkling casts all over the place. IMO seeing a lot of casts in C++ code is a bad sign. With a good design you rarely, if ever, need to cast. That C++ casts stand out more clearly (and can be easily grepped) than C style cast is a good thing as far as I am concerned.
[toc] | [prev] | [next] | [standalone]
| From | Cholo Lennon <chololennon@hotmail.com> |
|---|---|
| Date | 2012-01-27 18:28 -0300 |
| Message-ID | <jfv4ri$k6s$1@speranza.aioe.org> |
| In reply to | #13599 |
On 26/01/2012 19:08, Jorgen Grahn wrote: > Keep in mind, both of you, that the best way to deal with casting is > to avoid doing it! Or isolating it to a few places. C++ provides > better tools for that than C. > I agree, of course, but when you have to deal with legacy C or low level code casting appears (and I have to say that there is a lot of legacy C code) -- Cholo Lennon Bs.As. ARG
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2012-01-29 18:02 +0000 |
| Message-ID | <slrnjib2e4.1ls.grahn+nntp@frailea.sa.invalid> |
| In reply to | #13614 |
On Fri, 2012-01-27, Cholo Lennon wrote: > On 26/01/2012 19:08, Jorgen Grahn wrote: >> Keep in mind, both of you, that the best way to deal with casting is >> to avoid doing it! Or isolating it to a few places. C++ provides >> better tools for that than C. >> > > I agree, of course, but when you have to deal with legacy C or low level > code casting appears (and I have to say that there is a lot of legacy C > code) Yes, and I think part of what I was trying to say was: When you have a chance to rewrite such code, it pays to first check if you can eliminate the cast in some other way (e.g. with a wrapper function which does the casting) rather than replace the C-style cast with the best C++ cast. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web