{"thread":{"id":"9975","subject":"C++ *for Git*","startedAt":"2007-09-22T10:42:00Z","lastAt":"2007-09-24T10:46:03Z","messageCount":34,"participants":["Dmitry Kakurin","David Kastrup","Johannes Schindelin","Kyle Rose","Marco Costalba","Miles Bader","Martin Langhoff","Alex Unleashed","Frank Lichtenheld","David Brown","Pierre Habouzit","Nicolas Pitre","Linus Torvalds","Paul Franz","Dmitry Potapov","Reece Dunn","Robin Rosenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"53799","messageId":"ABE0ABE82AE84593A2B71B0281F4C814@ntdev.corp.microsoft.com","threadId":"9975","inReplyTo":null,"subject":"C++ *for Git*","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-09-22T10:42:00Z","receivedAt":"2007-09-22T10:42:00Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in \ngeneral*.\nIn no way I want to restart it. But *very specifically*, and *for Git*:\nWe already have strbuf \"class\" to do string/buffer manipulations.\nKudos to Pierre Habouzit for doing the refactoring work!\nNow, what I fail to understand is how this:\n\nstatic void write_global_extended_header(const unsigned char *sha1)\n{\n struct strbuf ext_header;\n\n strbuf_init(&ext_header, 0);\n strbuf_append_ext_header(&ext_header, \"comment\", sha1_to_hex(sha1), 40);\n write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);\n strbuf_release(&ext_header);\n}\n\nis better than this:\n\nstatic void write_global_extended_header(const unsigned char *sha1)\n{\n strbuf ext_header;\n\n ext_header.append_ext_header(\"comment\", sha1_to_hex(sha1), 40);\n write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);\n}\n\n?\nNote, there is no Boost/multiple inheritance/template \nmetaprogramming/std::string/whatever-else-scares-you-in-C++ in the second \npiece of code.\nJust a very straight-forward usage of only 3 C++ features:\n1. Constructors\n2. Destructors\n3. Better syntax (ext_header.append_ext_header vs. \nstrbuf_append_ext_header(&ext_header, )\n\nThe generated code will be exactly the same.\nYet the source code becomes more readable and MUCH less error prone. How is \nthis not a win?\n\nOne (sensible) argument that I've heard in the previous discussion was: you \nlet a little bit of C++ in and then it gets more and more complex and the \ncode quality decreases.\nThis problem is solved by having \"quality gates\".\nAgain, *for Git* these quality gates already exist: only few people have \n\"commit access\".\nIf/when somebody tries to be too fancy, what stops Junio from replying \"we \ndon't use Library-X/C++-feature-Y in Git, please change your code and \nresubmit\" and throwing that fix away? Nothing.\n\n- Dmitry\n"},{"id":"53801","messageId":"85lkazuf8o.fsf@lola.goethe.zz","threadId":"9975","inReplyTo":"ABE0ABE82AE84593A2B71B0281F4C814@ntdev.corp.microsoft.com","subject":"Re: C++ *for Git*","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-22T11:11:19Z","receivedAt":"2007-09-22T11:11:19Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Dmitry Kakurin writes:\n\n> We've had this theoretical (and IMHO pointless) discussion C vs. C++\n> *in general*.\n> In no way I want to restart it.\n\nThen don't.\n\n> Just a very straight-forward usage of only 3 C++ features:\n> 1. Constructors\n> 2. Destructors\n> 3. Better syntax (ext_header.append_ext_header\n> vs. strbuf_append_ext_header(&ext_header, )\n>\n> The generated code will be exactly the same.\n\nIt won't. It will _do_ exactly the same (modulo the tenfold\nlikelihood of compiler bugs) but hardly using the same code.\n\n> Yet the source code becomes more readable and MUCH less error\n> prone. How is this not a win?\n\nBecause it is just your claim that this is more readable.\n\n> One (sensible) argument that I've heard in the previous discussion\n> was: you let a little bit of C++ in and then it gets more and more\n> complex and the code quality decreases.\n> This problem is solved by having \"quality gates\".\n> Again, *for Git* these quality gates already exist: only few people\n> have \"commit access\".\n> If/when somebody tries to be too fancy, what stops Junio from replying\n> \"we don't use Library-X/C++-feature-Y in Git, please change your code\n> and resubmit\" and throwing that fix away? Nothing.\n\nWell, what stops him from replying \"we don't use C++ in Git, please\nchange your code and resubmit\"?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"53803","messageId":"Pine.LNX.4.64.0709221348180.28395@racer.site","threadId":"9975","inReplyTo":"ABE0ABE82AE84593A2B71B0281F4C814@ntdev.corp.microsoft.com","subject":"Re: C++ *for Git*","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-22T12:48:47Z","receivedAt":"2007-09-22T12:48:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 22 Sep 2007, Dmitry Kakurin wrote:\n\n> We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in\n> general*.\n\nI think \"pointless\" is more to the point.\n\nWe don't want C++. Why is that so hard to accept?\n\nCiao,\nDscho\n"},{"id":"53805","messageId":"46F5318A.4030103@krose.org","threadId":"9975","inReplyTo":"ABE0ABE82AE84593A2B71B0281F4C814@ntdev.corp.microsoft.com","subject":"Re: C++ *for Git*","fromName":"Kyle Rose","fromEmail":"krose@krose.org","sentAt":"2007-09-22T15:15:22Z","receivedAt":"2007-09-22T15:15:22Z","isPatch":false,"sender":{"key":"krose@krose.org","avatar":"https://gravatar.com/avatar/4e79b8d8d1ed762bf6d7c6bb575aa8a8b270948788d0d572f62ab2e90149026c?d=mp&s=160"},"body":"You know, git *is* free software. Feel free to fork it and add all the\nC++ code you want.\n\nFWIW, I am of the opinion that Python or Ruby (or god forbid, Perl)\nwould have been a better choice for something like git that does lots of\ntext processing... furthermore, I think the exception handling, garbage\ncollection, and implicit object destruction provided by those languages\n(and by C++, as overwrought as it is) makes any codebase easier to\nunderstand and maintain.\n\nBut that's irrelevant: git is written in C. That's the way it is, and\nyou should accept that or fork.\n\nKyle\n\nDmitry Kakurin wrote:\n> We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in\n> general*.\n> In no way I want to restart it.\n"},{"id":"53806","messageId":"e5bfff550709220823p241d04d1n370bda4fa0ef2733@mail.gmail.com","threadId":"9975","inReplyTo":"Pine.LNX.4.64.0709221348180.28395@racer.site","subject":"Re: C++ *for Git*","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-09-22T15:23:15Z","receivedAt":"2007-09-22T15:23:15Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 9/22/07, Johannes Schindelin wrote:\n>\n> We don't want C++. Why is that so hard to accept?\n>\n\nDmitry, I think what Johannes says in the above line is 100% the core\npoint of this (sad) discussion.\n\nYou cannot force/convince someone to use something he hates. That's\nit. And there's no point in trying to do this.\n\ngit developers were also kind enough to give explanations on 'why' C++\nis not a good language for them. Do you don't agree? do you find the\narguments not totally satisfying for you? That's not their problem.\n\nI like C++ (a my little git related GUI tool called qgit is done in\nC++) and at the same time I understand also much of the concerns that\nwhere expressed in the list.\n\nYour position will never be successful for a number of reasons, some\nclear expressed other less clear but at the same time, perhaps more\nimportant. So I really don't understand why you insist.\n\nThanks\nMarco\n\n\nP.S: The example you show is a pity for C++, it's like to advertise a\n1000cc 200Hp motorbike saying \"...and you will no have problems in\nparking in your box.\"\n"},{"id":"53809","messageId":"877imishdp.fsf@catnip.gol.com","threadId":"9975","inReplyTo":"46F5318A.4030103@krose.org","subject":"Re: C++ *for Git*","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2007-09-22T18:08:02Z","receivedAt":"2007-09-22T18:08:02Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Kyle Rose writes:\n> I think the exception handling, garbage collection, and implicit\n> object destruction provided by those languages (and by C++, as\n> overwrought as it is) makes any codebase easier to understand and\n> maintain.\n\nOf course, some of the most horrid unreadable source code I've ever seen\nis in one of git's competitors -- written in python....\n\n-Miles\n-- \n=====\n(^o^;\n(()))\n*This is the cute octopus virus, please copy it into your sig so it can spread.\n"},{"id":"53808","messageId":"46F55E03.2040404@krose.org","threadId":"9975","inReplyTo":"877imishdp.fsf@catnip.gol.com","subject":"[OT] Re: C++ *for Git*","fromName":"Kyle Rose","fromEmail":"krose@krose.org","sentAt":"2007-09-22T18:25:07Z","receivedAt":"2007-09-22T18:25:07Z","isPatch":false,"sender":{"key":"krose@krose.org","avatar":"https://gravatar.com/avatar/4e79b8d8d1ed762bf6d7c6bb575aa8a8b270948788d0d572f62ab2e90149026c?d=mp&s=160"},"body":"Miles Bader wrote:\n> Of course, some of the most horrid unreadable source code I've ever seen\n> is in one of git's competitors -- written in python....\n\nIndeed. :-)\n\nAt the office, people constantly badmouth Perl, which has some\nadmittedly evil syntax (especially around exception handling). My view\nis that good Perl programmers can produce good, readable, maintainable\nPerl programs, while bad Perl programmers can produce spaghetti the\nlikes of which can't be found outside Italy.\n\nOTOH, I think it is much harder to hang one's self with Python, though\nadmittedly possible, as it is when you combine a bad coder with *any*\nlanguage. Still, typical bad programmer + Perl is much worse than\ntypical bad programmer + Python.\n\nC++ is in the same category as Perl IMO: too easy to produce unreadable\ncode. I contend that C is pretty much just as bad, though in a\ndifferent way: while C lacks C++'s ability to bury code in multiple\nlayers of opaque abstractions, C makes up for it by providing absolutely\nno GC-type structures (i.e., I do this now, you clean it up later when\nI'm no longer interested in it). C is all explicit, which is nice when\nyou have a good handle on everything that is going on *or* an explicit\nsystem for remembering to do those types of cleanup tasks that is\nwell-understood by all developers involved.\n\nI like Ruby, except for the performance problems. Once they have those\nworked out, Ruby will be \"Perl done right.\" ;-)\n\nKyle\n"},{"id":"53810","messageId":"85bqbutszs.fsf@lola.goethe.zz","threadId":"9975","inReplyTo":"46F55E03.2040404@krose.org","subject":"Re: [OT] Re: C++ *for Git*","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-22T19:11:51Z","receivedAt":"2007-09-22T19:11:51Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Kyle Rose writes:\n\n> Miles Bader wrote:\n>> Of course, some of the most horrid unreadable source code I've ever seen\n>> is in one of git's competitors -- written in python....\n>\n> Indeed. :-)\n>\n> At the office, people constantly badmouth Perl, which has some\n> admittedly evil syntax (especially around exception handling).\n\nSince Perl has agglomerated pretty much _every_ syntax, it is not\nsurprising that evil syntax is included.\n\n> C++ is in the same category as Perl IMO: too easy to produce\n> unreadable code.\n\nNot quite. Perl gives you a hundred illegible ways to _say_ the same\nthing, C++ gives you a hundred illegible ways to _achieve_ the same\nthing, but using different means.\n\n> I like Ruby, except for the performance problems. Once they have\n> those worked out, Ruby will be \"Perl done right.\" ;-)\n\nRuby again is in the \"throw every syntactical idiom I can think of\ntogether\" ballpark. I find that a design mistake in Perl, a design\nmistake in Ruby, and even in C++ (Ada syntax for templates was just\nstupid, but at least there is no alternative syntax for it).\n\nThat's one of the things I like about Lua: its syntax fits on one page\nin the reference manual. And the reference manual has a paper size of\nabout A5. While the syntax for Lisp would probably fit in the margin,\nit does so at a cost in legibility.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"53814","messageId":"46a038f90709221524yf4900camf09c7870c09f8467@mail.gmail.com","threadId":"9975","inReplyTo":"46F5318A.4030103@krose.org","subject":"Re: C++ *for Git*","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-09-22T22:24:56Z","receivedAt":"2007-09-22T22:24:56Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 9/23/07, Kyle Rose wrote:\n> But that's irrelevant: git is written in C. That's the way it is, and\n> you should accept that or fork.\n\nOr - as Marco's done - write complementary bits to git. I'm a\nPerl-head, and I've ended up writing bits of Perl for git, some of\nthem have been reimplemented in C, some have stayed in Perl.\n\nArguing is a waste of time -- code! Help Marco, or write something new\nand glorious. Make it useful for people who don't care what it's\nwritten in, and beautiful so that the infidels are enlightened with\nhow elegant C++ can be.\n\nCodefest > Flamefest\n\ncheers,\n\n\n\nm\n"},{"id":"53815","messageId":"5e4707340709221550o6d0a6062qd51c16a278727c29@mail.gmail.com","threadId":"9975","inReplyTo":"46F55E03.2040404@krose.org","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Alex Unleashed","fromEmail":"alex@flawedcode.org","sentAt":"2007-09-22T22:50:00Z","receivedAt":"2007-09-22T22:50:00Z","isPatch":false,"sender":{"key":"alex@flawedcode.org","avatar":"https://gravatar.com/avatar/aae35e2f84230bfbc19c9b840ef8437fcb110f5316ea91197e3cd96c4bb4bf30?d=mp&s=160"},"body":"On 9/22/07, Kyle Rose wrote:\n> C++ is in the same category as Perl IMO: too easy to produce unreadable\n> code. I contend that C is pretty much just as bad, though in a\n> different way: while C lacks C++'s ability to bury code in multiple\n> layers of opaque abstractions, C makes up for it by providing absolutely\n> no GC-type structures (i.e., I do this now, you clean it up later when\n> I'm no longer interested in it). C is all explicit, which is nice when\n> you have a good handle on everything that is going on *or* an explicit\n> system for remembering to do those types of cleanup tasks that is\n> well-understood by all developers involved.\n\nI'd say being forced to be explicit is a good thing here, so that the\nprogrammer at least has some sort of good understanding of what is\ngoing on, and chances are that if he doesn't really know, things just\nwon't work out (quite unlike a lot of other languages where this\nprogrammer might actually end up with something half-assed that\n\"mostly\" works).\n\nFor some reason it seems to me a lot harder to find bad programmers\nsurviving using C than a lot of the other languages.\n\nAlex\n"},{"id":"53819","messageId":"20070923020951.GF24423@planck.djpig.de","threadId":"9975","inReplyTo":"5e4707340709221550o6d0a6062qd51c16a278727c29@mail.gmail.com","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Frank Lichtenheld","fromEmail":"frank@lichtenheld.de","sentAt":"2007-09-23T02:09:51Z","receivedAt":"2007-09-23T02:09:51Z","isPatch":false,"sender":{"key":"frank@lichtenheld.de","avatar":"https://gravatar.com/avatar/b9f1d4b120e138f157c9e480d0818197c474628923786adb98f30017cdb99c3c?d=mp&s=160"},"body":"On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:\n> I'd say being forced to be explicit is a good thing here, so that the\n> programmer at least has some sort of good understanding of what is\n> going on, and chances are that if he doesn't really know, things just\n> won't work out (quite unlike a lot of other languages where this\n> programmer might actually end up with something half-assed that\n> \"mostly\" works).\n> For some reason it seems to me a lot harder to find bad programmers\n> surviving using C than a lot of the other languages.\n\nIdiot-proofness-by-complexity is a myth IMHO. Idiots can be quite\npersistent...\n\nGruesse,\n-- \nFrank Lichtenheld \nwww: http://www.djpig.de/\n"},{"id":"53821","messageId":"a1bbc6950709222154m2b8d10fap7cebe70e2b352817@mail.gmail.com","threadId":"9975","inReplyTo":"e5bfff550709220823p241d04d1n370bda4fa0ef2733@mail.gmail.com","subject":"Re: C++ *for Git*","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-09-23T04:54:42Z","receivedAt":"2007-09-23T04:54:42Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"On 9/22/07, Marco Costalba wrote:\n> On 9/22/07, Johannes Schindelin wrote:\n> >\n> > We don't want C++. Why is that so hard to accept?\n> >\n>\n> Dmitry, I think what Johannes says in the above line is 100% the core\n> point of this (sad) discussion.\n\nActually after a couple of responses to this thread I had a BFO\n(Blinding Flash of Obvious). I cannot believe I was so naive :-). Now\nI have my answer.\n\nP.S. Mysteries like this could drive me crazy. Now I'm much happier.\n\n-- \n- Dmitry\n"},{"id":"53822","messageId":"20070923062527.GA8979@old.davidb.org","threadId":"9975","inReplyTo":"20070923020951.GF24423@planck.djpig.de","subject":"Re: [OT] Re: C++ *for Git*","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2007-09-23T06:25:27Z","receivedAt":"2007-09-23T06:25:27Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:\n>On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:\n>> I'd say being forced to be explicit is a good thing here, so that the\n>> programmer at least has some sort of good understanding of what is\n>> going on, and chances are that if he doesn't really know, things just\n>> won't work out (quite unlike a lot of other languages where this\n>> programmer might actually end up with something half-assed that\n>> \"mostly\" works).\n>> For some reason it seems to me a lot harder to find bad programmers\n>> surviving using C than a lot of the other languages.\n>\n>Idiot-proofness-by-complexity is a myth IMHO. Idiots can be quite\n>persistent...\n\nI work with plenty of them :-) It's all C. All of the same things happen,\nwith management looking for magic bullets to solve problems caused by bad\nprogrammers.\n\nDave\n"},{"id":"53823","messageId":"851wcpsv4z.fsf@lola.goethe.zz","threadId":"9975","inReplyTo":"20070923062527.GA8979@old.davidb.org","subject":"Re: [OT] Re: C++ *for Git*","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-23T07:23:08Z","receivedAt":"2007-09-23T07:23:08Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"David Brown writes:\n\n> On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:\n>>On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:\n>>> I'd say being forced to be explicit is a good thing here, so that the\n>>> programmer at least has some sort of good understanding of what is\n>>> going on, and chances are that if he doesn't really know, things just\n>>> won't work out (quite unlike a lot of other languages where this\n>>> programmer might actually end up with something half-assed that\n>>> \"mostly\" works).\n>>> For some reason it seems to me a lot harder to find bad programmers\n>>> surviving using C than a lot of the other languages.\n>>\n>>Idiot-proofness-by-complexity is a myth IMHO. Idiots can be quite\n>>persistent...\n>\n> I work with plenty of them :-) It's all C. All of the same things\n> happen, with management looking for magic bullets to solve problems\n> caused by bad programmers.\n\nC++ is good for creating black boxes. A black box that has been\nfitted into its environment and that has good innards is fine. A\nblack box with rotten innards, or not really being well-suited for the\njob at hand, isn't. For a project where people come and go, black\nboxes might hide a lot about bad design and implementation.\n\nIn particular, changing an algorithm to require different black boxes\nis something that is very unpleasant to do.\n\nHaving everything in the open is an advantage as long as the\ncomplexity to be managed is at a reasonable level.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"53826","messageId":"e5bfff550709230229t79004ce2j5ce8c2ae7744a7f2@mail.gmail.com","threadId":"9975","inReplyTo":"851wcpsv4z.fsf@lola.goethe.zz","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-09-23T09:29:45Z","receivedAt":"2007-09-23T09:29:45Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 9/23/07, David Kastrup wrote:\n> David Brown writes:\n>\n> > On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:\n> >>On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:\n> >>> I'd say being forced to be explicit is a good thing here, so that the\n> >>> programmer at least has some sort of good understanding of what is\n> >>> going on, and chances are that if he doesn't really know, things just\n> >>> won't work out (quite unlike a lot of other languages where this\n> >>> programmer might actually end up with something half-assed that\n> >>> \"mostly\" works).\n> >>> For some reason it seems to me a lot harder to find bad programmers\n> >>> surviving using C than a lot of the other languages.\n> >>\n\nWell, according to your reasoning assembly should be the gotha of\nelite programmers, only very disciplined and meticulous programmers\nsurvive, much more then in C.\n\nIs this a good way to measure a language?\n\n>\n> C++ is good for creating black boxes.\n\nObject oriented languages creates black boxes: that's the reason why\nobject oriented exsists and also the reason why Linus hates it ;-)\n\nDifference between C++ and other OO languages is mostly in the size of\nthe applications written in that language IMHO.\n\nC++ noramlly has the bigger code bases, so problem you mention are\nenanched and perhaps seem to depend on the language itself not on the\nsize of application. IOW a Python (Ruby) app probably does not have\nthe size of Firefox or Open Office, this _could_ induce the naive idea\nthat the python app is cleaner or easier to understand just becasue of\nPython vc C++.\n\nI really don't think so. I think this could be true for toy problems,\nbut for real, for big applications is the design of the appllcation,\nnot the language, that at 90% state the difference between clean and\ncrap.\n\n>A black box that has been\n> fitted into its environment and that has good innards is fine. A\n> black box with rotten innards, or not really being well-suited for the\n> job at hand, isn't.\n\nI really agree here. The biggset downside of OO is that for it to work\nyou should have a much deeper knowledge of the problem you want to\nhandle. OO force you to analyze more and know more because a bad\ndesign normally means throwing everything in the trash can and start\nagain.\n\nProcedural programming as C is more immune to this 'good problem\nanalysis' dependency.\n\nMarco\n"},{"id":"53827","messageId":"856421ra3l.fsf@lola.goethe.zz","threadId":"9975","inReplyTo":"e5bfff550709230229t79004ce2j5ce8c2ae7744a7f2@mail.gmail.com","subject":"Re: [OT] Re: C++ *for Git*","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-23T09:42:54Z","receivedAt":"2007-09-23T09:42:54Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Marco Costalba\" writes:\n\n> On 9/23/07, David Kastrup wrote:\n>> David Brown writes:\n>>\n>> > On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:\n>> >>On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:\n>> >>> I'd say being forced to be explicit is a good thing here, so that the\n>> >>> programmer at least has some sort of good understanding of what is\n>> >>> going on, and chances are that if he doesn't really know, things just\n>> >>> won't work out (quite unlike a lot of other languages where this\n>> >>> programmer might actually end up with something half-assed that\n>> >>> \"mostly\" works).\n>> >>> For some reason it seems to me a lot harder to find bad programmers\n>> >>> surviving using C than a lot of the other languages.\n>> >>\n>\n> Well, according to your reasoning\n\nWho is \"you\"? You are replying to a post of mine, yet commenting on\nAlex.\n\n> assembly should be the gotha of elite programmers, only very\n> disciplined and meticulous programmers survive, much more then in C.\n\nI am neither disciplined nor meticulous, yet have designed and\nprogrammed applications and complete systems in assembly language.\nProgrammers can easily survive assembly language without being\ndisciplined or meticulous. Their projects can't: they get tied to the\nprogrammers. Porting an assembly language application to a different\nprocessor might be easier than porting it to another programmer.\n\n> Is this a good way to measure a language?\n\nIt is a good way to measure programmers, at least concerning some\ninteresting metrics.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"53828","messageId":"e5bfff550709230250o78930a4dq6bafe53ab7a2d5a5@mail.gmail.com","threadId":"9975","inReplyTo":"856421ra3l.fsf@lola.goethe.zz","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-09-23T09:50:11Z","receivedAt":"2007-09-23T09:50:11Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 9/23/07, David Kastrup wrote:\n> >\n> > Well, according to your reasoning\n>\n> Who is \"you\"? You are replying to a post of mine, yet commenting on\n> Alex.\n>\n\nSorry, you are right, I'm not meticolus either ;-)\n\nMarco\n"},{"id":"53832","messageId":"20070923104525.GC7118@artemis.corp","threadId":"9975","inReplyTo":"e5bfff550709230229t79004ce2j5ce8c2ae7744a7f2@mail.gmail.com","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-09-23T10:45:25Z","receivedAt":"2007-09-23T10:45:25Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Sep 23, 2007 at 09:29:45AM +0000, Marco Costalba wrote:\n> On 9/23/07, David Kastrup wrote:\n> > David Brown writes:\n> >\n> > > On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:\n> > >>On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:\n> > >>> I'd say being forced to be explicit is a good thing here, so that the\n> > >>> programmer at least has some sort of good understanding of what is\n> > >>> going on, and chances are that if he doesn't really know, things just\n> > >>> won't work out (quite unlike a lot of other languages where this\n> > >>> programmer might actually end up with something half-assed that\n> > >>> \"mostly\" works).\n> > >>> For some reason it seems to me a lot harder to find bad programmers\n> > >>> surviving using C than a lot of the other languages.\n> > >>\n> \n> Well, according to your reasoning assembly should be the gotha of\n> elite programmers, only very disciplined and meticulous programmers\n> survive, much more then in C.\n\n This non argument was raised before in the recent thread we just had.\nCould we at least wait say, a month, before spawning the same trolls\nagain and again ?\n\n> > C++ is good for creating black boxes.\n> \n> Object oriented languages creates black boxes: that's the reason why\n> object oriented exsists and also the reason why Linus hates it ;-)\n\n This is just nonsense. This has been proved, though I can't find the\npaper about this anymore, than modules (or packages whichever name you\ngive them) plus abstract types are as good as OO languages at creating\nblack boxes. I mean it has been proved that it gives the exact same\namount of expressiveness. So please stop with this myth. And don't speak\nfor people, I would be very surprised that Linus would dislike \"black\nboxes\". Abstractions are good, when used wisely, and I would be much\nsurprised to see Linus pretend otherwise.\n\n The real problem with big applications, is not that they are written\nwith C, C++, D, APL or Perl, but that they are big. Most of the time,\nbig means that many people are not able to grok the big picture, and you\nend up with 102 implementations of base64, 10 string libraries, 4\ngeneral purpose buffers, and at least half of the common lisp\nfeatures[0]. And for the record git is _not_ big. It's around 100k\nslocs, which rougly the size of postfix or mutt.\n\n I for one do believe that bad programmers will write bad code\nwhichever language they use, and that what is wrong is to end with code\nbases in one monolithic thing like in [1]. OO design patterns and other\ncraps of the like helps you generate insane amount of codelines, and\nhide all the simplicity under huge loads of proxies and interfaces. In\nC, when your API suck, you usually need to refactor it under the\npressure of the huge amount of code you have to repeat each time you use\nthe API. in an OO language, you add a new class for that purpose. In C++\nit's even worse, you just hide it in a copy constructor, or an operator\nso that when you write:\n\n Foo a = b;\n\n Instead of a simple memcpy, you end up with an horrible pile of crap\nto be started and run behind your back. C++ is very good at hiding bad\ncode. At least in C, when someone writes bad code, it's obvious to any\nreader. C has many many quirks, I don't discuss that, but OO programming\nsolves none of them, and the problems OO addresses are not the one that\nmay interfere in the git development. I mean, the two really interesting\nthings in OO (that haven't a tremendous cost in return) are member\noverloading and inheritance. I see very few places where git would\nbenefit from that, and believe me, I looked at git's code with\nrefactoring in mind and only that.\n\n Can we go back to git now ?\n\n\n\n [0] http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule\n\n [1] http://www.ohloh.net/projects/29/analyses/latest\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"53833","messageId":"e5bfff550709230642v7fa5e837s7a5b9082b043672d@mail.gmail.com","threadId":"9975","inReplyTo":"20070923104525.GC7118@artemis.corp","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-09-23T13:42:05Z","receivedAt":"2007-09-23T13:42:05Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 9/23/07, Pierre Habouzit wrote:\n> >\n> > Object oriented languages creates black boxes: that's the reason why\n> > object oriented exsists and also the reason why Linus hates it ;-)\n>\n> This is just nonsense. This has been proved, though I can't find the\n> paper about this anymore, than modules (or packages whichever name you\n> give them) plus abstract types are as good as OO languages at creating\n> black boxes. I mean it has been proved that it gives the exact same\n> amount of expressiveness. So please stop with this myth. And don't speak\n> for people, I would be very surprised that Linus would dislike \"black\n> boxes\". Abstractions are good, when used wisely, and I would be much\n> surprised to see Linus pretend otherwise.\n>\n\n>From a Linus recent thread:\n\n> - inefficient abstracted programming models where two years down the road\n> you notice that some abstraction wasn't very efficient, but now all\n> your code depends on all the nice object models around it, and you\n> cannot fix it without rewriting your app.\n>\n>In other words, the only way to do good, efficient, and system-level and\n>portable C++ ends up to limit yourself to all the things that are\n>basically available in C. And limiting your project to C means that people\n>don't screw that up, and also means that you get a lot of programmers that\n>do actually understand low-level issues and don't screw things up with any\n>idiotic \"object model\" crap.\n\nPerhaps I have misunderstood, but the idea I got is that for Linus OO\nbrings in more problems than what it tries to fix.\n\n\n> The real problem with big applications, is not that they are written\n> with C, C++, D, APL or Perl, but that they are big.\n\nI have said exactly this, I don't understand where's your point in\nrepeating the same concept.\n\n> C has many many quirks, I don't discuss that, but OO programming\n> solves none of them, and the problems OO addresses are not the one that\n> may interfere in the git development.\n\nI really don't get how you made up your mind I'm advocating OO ? The\nonly comment I made on OO until now was to highlight one of its\ndownsides.\n\n\n> I mean, the two really interesting\n> things in OO (that haven't a tremendous cost in return) are member\n> overloading and inheritance.\n\nYou have listed two things that are a world apart one from each other.\n\nmember overload is just syntactic sugar for name mangling, while\ninheritance and the _strictly_ related virtual member functions (AKA\npolymorphism) is what opens the gates to all the stuff you have deeply\nblamed in your post.\n\n>I see very few places where git would\n> benefit from that\n\nInstead I see none. But probably you have looked at git code better then me.\n\n\n> Can we go back to git now ?\n>\n\nYou are not forced to follow this thread if this bores you.\n\nThanks\nMarco\n"},{"id":"53834","messageId":"alpine.LFD.0.9999.0709231018450.32185@xanadu.home","threadId":"9975","inReplyTo":"e5bfff550709230642v7fa5e837s7a5b9082b043672d@mail.gmail.com","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-09-23T14:23:47Z","receivedAt":"2007-09-23T14:23:47Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 23 Sep 2007, Marco Costalba wrote:\n\n> From a Linus recent thread:\n> \n> > - inefficient abstracted programming models where two years down the road\n> > you notice that some abstraction wasn't very efficient, but now all\n> > your code depends on all the nice object models around it, and you\n> > cannot fix it without rewriting your app.\n> >\n> >In other words, the only way to do good, efficient, and system-level and\n> >portable C++ ends up to limit yourself to all the things that are\n> >basically available in C. And limiting your project to C means that people\n> >don't screw that up, and also means that you get a lot of programmers that\n> >do actually understand low-level issues and don't screw things up with any\n> >idiotic \"object model\" crap.\n> \n> Perhaps I have misunderstood, but the idea I got is that for Linus OO\n> brings in more problems than what it tries to fix.\n\nYou must have misunderstood. Why? The linux kernel is itself very \nheavily \"object oriented\" already, even if it is written in C. You \ndon't need C++ for that.\n\n\nNicolas\n"},{"id":"53835","messageId":"85zlzdo3ch.fsf@lola.goethe.zz","threadId":"9975","inReplyTo":"e5bfff550709230642v7fa5e837s7a5b9082b043672d@mail.gmail.com","subject":"Re: [OT] Re: C++ *for Git*","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-23T14:37:02Z","receivedAt":"2007-09-23T14:37:02Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Marco Costalba\" writes:\n\n> On 9/23/07, Pierre Habouzit wrote:\n>> >\n>> > Object oriented languages creates black boxes: that's the reason\n>> > why object oriented exsists and also the reason why Linus hates\n>> > it ;-)\n\n>> So please stop with this myth. And don't speak for people, I would\n>> be very surprised that Linus would dislike \"black\n>> boxes\". Abstractions are good, when used wisely, and I would be\n>> much surprised to see Linus pretend otherwise.\n>\n> From a Linus recent thread:\n>\n>>In other words, the only way to do good, efficient, and system-level\n>>and portable C++ ends up to limit yourself to all the things that\n>>are basically available in C. And limiting your project to C means\n>>that people don't screw that up, and also means that you get a lot\n>>of programmers that do actually understand low-level issues and\n>>don't screw things up with any idiotic \"object model\" crap.\n>\n> Perhaps I have misunderstood, but the idea I got is that for Linus\n> OO brings in more problems than what it tries to fix.\n\nI read that as OO bringing in more programmers capable of creating\nproblems than those capable of fixing them.\n\nIt is not the fault of OO in itself, but it is the bottom line that\ncounts: if it draws the wrong audience for the wrong reasons, it\nbetter had great benefits to offset that. Not quite unsimilar with\ncommunism: the idea is great in principle, but the idea has no\nbuilt-in self-check. Capitalism, in contrast, is a distasteful idea\nat its heart, but it is rooted soundly in individual egoism. Which\ndoes not make it any less distasteful, but at least it tends to work.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"53837","messageId":"e5bfff550709230745m43ad32dh261edc6fc846602a@mail.gmail.com","threadId":"9975","inReplyTo":"alpine.LFD.0.9999.0709231018450.32185@xanadu.home","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-09-23T14:45:58Z","receivedAt":"2007-09-23T14:45:58Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 9/23/07, Nicolas Pitre wrote:\n> You must have misunderstood. Why? The linux kernel is itself very\n> heavily \"object oriented\" already, even if it is written in C. You\n> don't need C++ for that.\n>\n\nYes it's true, you don't need it. Object oriented in C is achived\nusing function pointers.\n\nIn C you fill a struct of function pointers with proper values instead\nof inherithing from an (abstract) base class as you would do in C++.\nThe results are more or less the same modulo some type safe.\n\n\nMarco\n"},{"id":"53838","messageId":"e5bfff550709230815r773a4ad2u47bf854cacc236b6@mail.gmail.com","threadId":"9975","inReplyTo":"85zlzdo3ch.fsf@lola.goethe.zz","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-09-23T15:15:40Z","receivedAt":"2007-09-23T15:15:40Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 9/23/07, David Kastrup wrote:\n> >\n> > Perhaps I have misunderstood, but the idea I got is that for Linus\n> > OO brings in more problems than what it tries to fix.\n>\n> I read that as OO bringing in more programmers capable of creating\n> problems than those capable of fixing them.\n>\n> It is not the fault of OO in itself, but it is the bottom line that\n> counts: if it draws the wrong audience for the wrong reasons, it\n> better had great benefits to offset that.\n\nPerhaps I'm wrong, but I think one of the advantages of big projects\nwritten in C vs comparable size projects in an OO language (read C++)\nit's exactly the opposite.\n\nBecause C lets a random developer to understand, quickly enough, and\ndo little local modifications also to big projects like Linux, it\nattracts a lot of developers that have the possibility to start with\nsome janitorial work or some little patch without incurring in the\nvery steep learning curve you have understanding the object hierarchy\nof a big C++ code base, an almost mandatory step, before to start\nhacking as example in Firefox.\n\nThis is, IMHO, a big advantage: fresh meat is always welcomed, the\ndamage it can potentially create is more then compensated by the long\nterm benefit of a large and live developer community.\n\n\nMarco\n"},{"id":"53839","messageId":"alpine.LFD.0.999.0709230911360.16478@woody.linux-foundation.org","threadId":"9975","inReplyTo":"e5bfff550709230642v7fa5e837s7a5b9082b043672d@mail.gmail.com","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-09-23T16:54:10Z","receivedAt":"2007-09-23T16:54:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 23 Sep 2007, Marco Costalba wrote:\n> \n> Perhaps I have misunderstood, but the idea I got is that for Linus OO\n> brings in more problems than what it tries to fix.\n\nNot really.\n\nI'm a huge believer in OO, and if you look at the kernel, for example, \nthere's just a ton of interfaces that are basically object-oriented. All \nthe VFS is, for example, is really just a object model around low-level \nfilesystems. The same largely goes for virtual memory mappings, or indeed \nfor things like the interrupt or DMA controller abstractions, the network \npacket filtering etc etc etc.\n\nBut I'm also a huge believer in *explicit*syntax*. People should see what \nis going on, and the abstraction should be explicit.\n\n[ Honesty in advertising: we do end up often hiding *some* abstractions. \n\n Sometimes it happens for historical reasons: if the code didn't have any \n indirection/abstraction initially, we may end up using macros and inline \n functions to hide the fact that it now is actually going through an \n indirect object-oriented interface.\n\n And sometimes it happens because the thing is *so* common or *so* \n obvious that making the indirection explicit is just syntactically too \n intrusive. ]\n\nAnd we do all of this in C. There is no need to go to C++ for any \"object \noriented principles\". It really is just a syntactic issue, and in many \nways the syntax \"advantage\" of C++ is actually a big *disadvantage*.\n\nI'm one of those people who think that interactions should be *locally* \nvisible. If you need to understand the \"big picture\" in order to \nunderstand what a line of code does, that's usually a bad idea. So \nsyntactic tricks that hide what is actually going on are bad.\n\nYou can see some of my opinions on C in the extensions I did for sparse. I \nthink the C type system is a bit too sloppy, and much of what sparse does \nis more totally static type checking. Things like being able to decorate \ntypes statically, and having to explicitly carry those decorations around \nis a *good* thing - because it does the opposite of hiding. Having to say\n\n\tstruct somestruct __user *p\n\nto explicitly say that it's a pointer to user space - and then having \nevery function that takes that pointer have to have that \"__user\" there is \na VERY GOOD THING.\n\nThat's very different from having \"accessor functions\" and making \"p\" an \nabstract type, and having the compiler automatically generate the right \nkind of access. That kind of stuff is TOTAL CRAP, and it's an example of \nhow C++ has a horrible design, where you carry around _implicit_ knowledge \ninstead of making the knowledge explicit and visible locally too.\n\n(And no, C doesn't do it very well. The C type system makes it too hard to \nadd explicit markers that get statically checked, and you generally have \nto do it by making the code unreadable by turning things into special \nstructures, one for each use, or something like that).\n\nThe same goes for things like memory allocation. Memory allocation issues \nare often some of the *biggest* performance issues, and that means that \nthey have to be explicit. I'm actually a big fan of GC, but most languages \nthat implement GC do it exactly the wrong way in my opinion: they make it \na fundamental thing that covers everything, and it all happens implicitly, \ninstead of making it explicit.\n\nI don't know how many people have noticed that git internally actually \ndoes do some garbage collection. It's just that we call it \"caches\", and \nwe do it explicitly. I'd love to have a language that helps me with that, \nbut I would *hate* to have a language that does it for everything. As it \nis, we *could* do garbage collection much more, but we don't, just because \nit's a bit too painful.\n\nIn practice, it means that I'm considering writing some helper routines in \nC, which actually would do exactly what I want them to do: make the \n(reasonably few) data structures that want to have a dynamic cache use \nthat dynamic cache explicitly, the way we now do for delta caching etc.\n\nThere are a few features of C++ that I really really like. For example, I \nthink the C preprocessor is absolutely horrid, and a preprocessor that is \nbuilt into the language - and integrates with the syntax - would be \nwonderful. And while C++ doesn't improve on that, at least templates are \nan example of something like that. Not perfect, but that's the kind of \nfeature that C really would like.\n\nIn the kernel, we (ab-)use the C preprocessor a lot for things like that. \nSome of our macros are really disgusting. I'm not proud, but it works \nwell, and together with gcc extensions like \"__typeof__\" and thigns like \n\"__builtin_constant_p()\" you can do some rather powerful things.\n\nBut other parts of C++ are just nasty. The whole OO layer seems designed \nto do a lot of things implicitly and in the wrong way. I also disagree \nwith exception handling, and the \"new\" keyword kind of exemplifies a lot \nof what is wrong in C++.\n\nSo in short:\n\n - the one big feature that I think really makes a huge difference to \n people, C++ does not have: garbage collection. Yes, there are GC \n modules, but let's face it, you can do that equally well in C too, it's \n just slightly different syntax.\n\n - the stuff C++ *does* have is usually nasty. Implicit initializers and \n destructors and the magic lifetime rules of objects etc are all just a \n piece of incredible bogosity. And that all comes from the OO stuff that \n is totally worthless, because it's really just syntactic fluff that can \n be done easily in C.\n\n - the C preprocessor really is horrible, and every single language beats \n C handily in this area. Except for C++, which didn't fix anything at \n all in that area.\n\n Even assemblers have macro languages that allow conditionals, \n repetition, nesting, etc etc. C and C++? Not so much. (Some languages \n don't need it, because the language itself is dynamic and you can do \n everything from within the language - ie you just evaluate an \n expression that you built up dynamically as in LISP etc).\n\n (And don't tell me about m4. It's a better preprocessor, but it's not \n syntactically integrated, and it's too complex, imho)\n\nThere are other problems in C. The implicit type conversions should at \nleast have some way to be disabled on a type-for-type basis.\n\n\t\tLinus\n"},{"id":"53841","messageId":"46F6A73A.3010203@comcast.net","threadId":"9975","inReplyTo":"85zlzdo3ch.fsf@lola.goethe.zz","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Paul Franz","fromEmail":"thefranz@comcast.net","sentAt":"2007-09-23T17:49:46Z","receivedAt":"2007-09-23T17:49:46Z","isPatch":false,"sender":{"key":"thefranz@comcast.net","avatar":null},"body":"To me the methods that an OO class defines is the same thing as an API. \nAnd you can screw up an API whether it is C++ or C. Both give you the \nsame opportunity to screw up the model and create code that needs to be \nre-written.\n\nPaul Franz\n\nDavid Kastrup wrote:\n> \"Marco Costalba\" writes:\n>\n> \n>> On 9/23/07, Pierre Habouzit wrote:\n>> \n>>>> Object oriented languages creates black boxes: that's the reason\n>>>> why object oriented exsists and also the reason why Linus hates\n>>>> it ;-)\n>>>> \n>\n> \n>>> So please stop with this myth. And don't speak for people, I would\n>>> be very surprised that Linus would dislike \"black\n>>> boxes\". Abstractions are good, when used wisely, and I would be\n>>> much surprised to see Linus pretend otherwise.\n>>> \n>> From a Linus recent thread:\n>>\n>> \n>>> In other words, the only way to do good, efficient, and system-level\n>>> and portable C++ ends up to limit yourself to all the things that\n>>> are basically available in C. And limiting your project to C means\n>>> that people don't screw that up, and also means that you get a lot\n>>> of programmers that do actually understand low-level issues and\n>>> don't screw things up with any idiotic \"object model\" crap.\n>>> \n>> Perhaps I have misunderstood, but the idea I got is that for Linus\n>> OO brings in more problems than what it tries to fix.\n>> \n>\n> I read that as OO bringing in more programmers capable of creating\n> problems than those capable of fixing them.\n>\n> It is not the fault of OO in itself, but it is the bottom line that\n> counts: if it draws the wrong audience for the wrong reasons, it\n> better had great benefits to offset that. Not quite unsimilar with\n> communism: the idea is great in principle, but the idea has no\n> built-in self-check. Capitalism, in contrast, is a distasteful idea\n> at its heart, but it is rooted soundly in individual egoism. Which\n> does not make it any less distasteful, but at least it tends to work.\n>\n> \n\n-- \n\n-------------------------------------------\n\nThere are seven sins in the world.\n Wealth without work.\n Pleasure without conscience.\n Knowledge without character.\n Commerce without morality.\n Science without humanity.\n Worship without sacrifice.\n Politics without principle.\n\n -- Mohandas Gandhi\n\n-------------------------------------------\n"},{"id":"53842","messageId":"e5bfff550709231105h94d08e2n9b1234e7c1a7e6a8@mail.gmail.com","threadId":"9975","inReplyTo":"alpine.LFD.0.999.0709230911360.16478@woody.linux-foundation.org","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-09-23T18:05:55Z","receivedAt":"2007-09-23T18:05:55Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 9/23/07, Linus Torvalds wrote:\n>\n> There are a few features of C++ that I really really like. For example, I\n> think the C preprocessor is absolutely horrid, and a preprocessor that is\n> built into the language - and integrates with the syntax - would be\n> wonderful. And while C++ doesn't improve on that, at least templates are\n> an example of something like that. Not perfect, but that's the kind of\n> feature that C really would like.\n>\n\nYes, I really agree. IMO templates are the thing that more resembles\nprocedural programming, a common way of using them is to split data\nstructures (containers) from functions that operates on them\n(algorithms). I find them very similar to the struct + functions\nclassical approach of C.\n\nAnd BTW\n\ntemplate \n\nis the thing in C++ that more remembers me of opaque pointers and\ntheir use in C, the difference is that the first is fully type\nchecked.\n\nMarco\n"},{"id":"53843","messageId":"85hcllmdzb.fsf@lola.goethe.zz","threadId":"9975","inReplyTo":"e5bfff550709231105h94d08e2n9b1234e7c1a7e6a8@mail.gmail.com","subject":"Re: [OT] Re: C++ *for Git*","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-23T18:30:16Z","receivedAt":"2007-09-23T18:30:16Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Marco Costalba\" writes:\n\n> On 9/23/07, Linus Torvalds wrote:\n>>\n>> There are a few features of C++ that I really really like. For example, I\n>> think the C preprocessor is absolutely horrid, and a preprocessor that is\n>> built into the language - and integrates with the syntax - would be\n>> wonderful. And while C++ doesn't improve on that, at least templates are\n>> an example of something like that. Not perfect, but that's the kind of\n>> feature that C really would like.\n>>\n>\n> Yes, I really agree. IMO templates are the thing that more resembles\n> procedural programming, a common way of using them is to split data\n> structures (containers) from functions that operates on them\n> (algorithms). I find them very similar to the struct + functions\n> classical approach of C.\n>\n> And BTW\n>\n> template \n>\n> is the thing in C++ that more remembers me of opaque pointers and\n> their use in C, the difference is that the first is fully type\n> checked.\n\nNot really. The difference is that the first generates new (and\noptimized) code for every type which is something you can only do\nusing macros in C. Class programming is similar to opaque pointers\n(in particular concerning the generated code) but templates are really\nmore like macros, as their instantiation generates specialized code,\nnot at all like the handling of opaque pointers.\n\nWhile I tend to agree that templates are probably the one thing\nactually worth having, it was stupid to lift the restrictions syntax\nalong with the concept of generics from the Ada shop. Borrowing\nsyntax along with features is such a Perlesque approach.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"53845","messageId":"e5bfff550709231143m7eb351bx4cf1c60d1247cc3d@mail.gmail.com","threadId":"9975","inReplyTo":"85hcllmdzb.fsf@lola.goethe.zz","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-09-23T18:43:25Z","receivedAt":"2007-09-23T18:43:25Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 9/23/07, David Kastrup wrote:\n> \"Marco Costalba\" writes:\n>\n> > On 9/23/07, Linus Torvalds wrote:\n> >>\n> >> There are a few features of C++ that I really really like. For example, I\n> >> think the C preprocessor is absolutely horrid, and a preprocessor that is\n> >> built into the language - and integrates with the syntax - would be\n> >> wonderful. And while C++ doesn't improve on that, at least templates are\n> >> an example of something like that. Not perfect, but that's the kind of\n> >> feature that C really would like.\n> >>\n> >\n> > Yes, I really agree. IMO templates are the thing that more resembles\n> > procedural programming, a common way of using them is to split data\n> > structures (containers) from functions that operates on them\n> > (algorithms). I find them very similar to the struct + functions\n> > classical approach of C.\n> >\n> > And BTW\n> >\n> > template \n> >\n> > is the thing in C++ that more remembers me of opaque pointers and\n> > their use in C, the difference is that the first is fully type\n> > checked.\n>\n> Not really. The difference is that the first generates new (and\n> optimized) code for every type which is something you can only do\n> using macros in C. Class programming is similar to opaque pointers\n> (in particular concerning the generated code) but templates are really\n> more like macros, as their instantiation generates specialized code,\n> not at all like the handling of opaque pointers.\n>\n\nProbably if I had written like this was more clear:\n\ntemplate int some_function(T* p);\n\nAnd regarding 'new' code for each type I would like to remember that\ntemplate instantations of different types can be removed by\ncompiler/linker when the instantations are the same (i.e. produce the\nsame binary instuctions), this could happen for function templates\nthat handle pointers, as example.\n\nMarco\n"},{"id":"53847","messageId":"857imhmc2l.fsf@lola.goethe.zz","threadId":"9975","inReplyTo":"e5bfff550709231143m7eb351bx4cf1c60d1247cc3d@mail.gmail.com","subject":"Re: [OT] Re: C++ *for Git*","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-23T19:11:30Z","receivedAt":"2007-09-23T19:11:30Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Marco Costalba\" writes:\n\n> On 9/23/07, David Kastrup wrote:\n>> \"Marco Costalba\" writes:\n>>\n>> > And BTW\n>> >\n>> > template \n>> >\n>> > is the thing in C++ that more remembers me of opaque pointers and\n>> > their use in C, the difference is that the first is fully type\n>> > checked.\n>>\n>> Not really. The difference is that the first generates new (and\n>> optimized) code for every type which is something you can only do\n>> using macros in C. Class programming is similar to opaque pointers\n>> (in particular concerning the generated code) but templates are really\n>> more like macros, as their instantiation generates specialized code,\n>> not at all like the handling of opaque pointers.\n>\n> Probably if I had written like this was more clear:\n>\n> template int some_function(T* p);\n\nHuh? How is this supposed to support your point? There is nothing\nlike an opaque pointer involved here. The point of opaque pointers is\nthat they can stand for a variety of types, whereas each template\ninstantiation can only substitute a single type.\n\n> And regarding 'new' code for each type I would like to remember that\n> template instantations of different types can be removed by\n> compiler/linker when the instantations are the same (i.e. produce\n> the same binary instuctions), this could happen for function\n> templates that handle pointers, as example.\n\nHardly. The type constraints/virtual function tables of any called\nfunction depending on T will be different. And if indeed nothing\ndepends on T at all inside of the template, it is pointless not to\ndeclare it as void *p in the first place: the type of *p will never be\nused then.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"53856","messageId":"20070923212239.GA7249@potapov","threadId":"9975","inReplyTo":"alpine.LFD.0.999.0709230911360.16478@woody.linux-foundation.org","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Dmitry Potapov","fromEmail":"dpotapov@nbs-eng.ru","sentAt":"2007-09-23T21:22:39Z","receivedAt":"2007-09-23T21:22:39Z","isPatch":false,"sender":{"key":"dpotapov@nbs-eng.ru","avatar":null},"body":"On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:\n> \n> And we do all of this in C. There is no need to go to C++ for any \"object \n> oriented principles\". It really is just a syntactic issue, and in many \n> ways the syntax \"advantage\" of C++ is actually a big *disadvantage*.\n\nCertainly, in this respect, C++ provides only syntactic sugar over C,\nand there is a real danger of abuse, which leads to horrible programs.\nThis is especially likely to happen to those who think that the evil\nof C++ is lying in templates, exceptions, or something other feature\nof C++, because they start to abuse the only \"good\" feature they know\nand inevitably end up with horrible code.\n\n> \tstruct somestruct __user *p\n> \n> to explicitly say that it's a pointer to user space - and then having \n> every function that takes that pointer have to have that \"__user\" there is \n> a VERY GOOD THING.\n\nuser_ptr p;\n\n> \n> That's very different from having \"accessor functions\" and making \"p\" an \n> abstract type, and having the compiler automatically generate the right \n> kind of access. That kind of stuff is TOTAL CRAP, and it's an example of \n> how C++ has a horrible design, where you carry around _implicit_ knowledge \n> instead of making the knowledge explicit and visible locally too.\n\nWhether it will convert to something or not depends entirely on the\ndefinition of user_ptr. So, it can be as explicit as you wish, or\ncompletely implicit. C++ does not impose anything on you here. So,\nthe problem is not in C++ but in the crappy mentality -- \"let's hide\neverything behind 'higher' abstraction\" or \"let's hide this thing too\nbecause we can\". Yes, these people end up with total crap. And yes,\nthose people tend to prefer C++ over C, just because C++ is better at\nhiding. But I don't think that C++ forces anyone to do that...\n\n> The same goes for things like memory allocation. Memory allocation issues \n> are often some of the *biggest* performance issues, and that means that \n> they have to be explicit. I'm actually a big fan of GC, but most languages \n> that implement GC do it exactly the wrong way in my opinion: they make it \n> a fundamental thing that covers everything, and it all happens implicitly, \n> instead of making it explicit.\n\nStroustrup was not a big fan of GC, so he made the language to be useful\nin absence of any GC, and it allows to manage memory and some other\nresources though not automatically, but with much less efforts than in C.\n\nMaybe, your idea of more explicit GC is better than what C++ offers. It\nis difficult for me to say without trying, but as you said most languages\nimplement GC in the wrong way in your opinion, so I don't think I will\nhave a chance to try any language that does it right. As to \"caches\" in\nGit, it works really nicely, but Git is not a programming language.\n\n> But other parts of C++ are just nasty. The whole OO layer seems designed \n> to do a lot of things implicitly and in the wrong way.\n\nIt could do a lot of things implicitly, but it does not force you,\nexcept calling destructor when the control leaves the scope of\ndeclaration, but I hardly can consider it as implicit.\n\n> I also disagree with exception handling,\n\nPerhaps, you look at it from the kernel point of view. Otherwise, I\nwould like to hear your arguments against it. In fact, I don't think\nit is possible to write generic algorithms without exceptions. Of\ncourse, if you write a program that can print an error to stderr and\nexit, there is no much need for them. So, it may depend on the task.\n\n> - the stuff C++ *does* have is usually nasty. Implicit initializers and \n> destructors and the magic lifetime rules of objects etc\n\nI am not sure what is wrong with initializers and destructors in C++,\nbut certainly there is no magic lifetime rules in C++, as it is fully\ndetermined by the scope. In fact, other high level languages that use\nGC have much more unpredictable lifetime rules for objects.\n\n\nDmitry Potapov\n\nPS Please, do not confuse me with Dmitry Kakurin, who started this\nthread, because my position is opposite to his. Though I like C++,\nI fully understand most of your consideration in choosing C for Git.\n"},{"id":"53857","messageId":"85ejgpkr13.fsf@lola.goethe.zz","threadId":"9975","inReplyTo":"20070923212239.GA7249@potapov","subject":"Re: [OT] Re: C++ *for Git*","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-23T21:31:20Z","receivedAt":"2007-09-23T21:31:20Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Dmitry Potapov writes:\n\n> On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:\n>\n>> - the stuff C++ *does* have is usually nasty. Implicit\n>> initializers and destructors and the magic lifetime rules of\n>> objects etc\n>\n> I am not sure what is wrong with initializers and destructors in\n> C++, but certainly there is no magic lifetime rules in C++, as it is\n> fully determined by the scope.\n\nIt has been some time since I last looked, but the lifetime of objects\nconstructed in return statements was a moving target through several\nstandards. The last standard I bothered looking at had the object\nsurvive until the statement with the function call expression ended:\nquite a strange synchronization point with regard to language design.\n\n> In fact, other high level languages that use GC have much more\n> unpredictable lifetime rules for objects.\n\nMostly objects are alive as long as you can refer to them. Not really\ncomplicated.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"53859","messageId":"3f4fd2640709231525q52a9865alc834ca46b85998fe@mail.gmail.com","threadId":"9975","inReplyTo":"20070923212239.GA7249@potapov","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Reece Dunn","fromEmail":"msclrhd@googlemail.com","sentAt":"2007-09-23T22:25:01Z","receivedAt":"2007-09-23T22:25:01Z","isPatch":false,"sender":{"key":"msclrhd@googlemail.com","avatar":null},"body":"On 23/09/2007, Dmitry Potapov wrote:\n> On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:\n> > The same goes for things like memory allocation. Memory allocation issues\n> > are often some of the *biggest* performance issues, and that means that\n> > they have to be explicit. I'm actually a big fan of GC, but most languages\n> > that implement GC do it exactly the wrong way in my opinion: they make it\n> > a fundamental thing that covers everything, and it all happens implicitly,\n> > instead of making it explicit.\n>\n> Stroustrup was not a big fan of GC, so he made the language to be useful\n> in absence of any GC, and it allows to manage memory and some other\n> resources though not automatically, but with much less efforts than in C.\n\nThe next version of C++ is going to have garbage collection that the\nuser can enable, disable or remain neutral about. However, this is\nprogram-wide and has many traps that you could fall into.\n\n> > But other parts of C++ are just nasty. The whole OO layer seems designed\n> > to do a lot of things implicitly and in the wrong way.\n>\n> It could do a lot of things implicitly, but it does not force you,\n> except calling destructor when the control leaves the scope of\n> declaration, but I hardly can consider it as implicit.\n\nYou have to add the explicit keyword to any constructor to prevent an\nautomatic conversion. Therefore, the constructors that are called are\nimplicit by default. If you have a conversion operator, this is always\nimplicitly called when there is a match by the compiler.\n\nI agree with Linus here, there are a lot of things that happen implicily.\n\n> > I also disagree with exception handling,\n>\n> Perhaps, you look at it from the kernel point of view. Otherwise, I\n> would like to hear your arguments against it. In fact, I don't think\n> it is possible to write generic algorithms without exceptions. Of\n> course, if you write a program that can print an error to stderr and\n> exit, there is no much need for them. So, it may depend on the task.\n\nThere are many issues with exceptions.\n\nFirstly, there is throwing an exception from a destructor, which is\nwarned against in any good C++ book, but does not prevent you from\ndoing so (even if it is inadvertantly)! If the program is in the\nprocess of handling an exception, the program is toast.\n\nMore importantly though, is the loss of contextual information.\nConsider throwing the same exception on all calls to API that return\nthe same error code type. The code that processes this may be anywhere\nin the system. This makes it impossible to do any sensible recovery\n(if possible), or error reporting. The exception can be rethrown or\ntranslated to another exception, making it impossible to find the\noriginator of the exception. This makes it harder, if not impossible,\nto track the exception back to the source when you are at a breakpoint\nin the exception handler.\n\nThen there is dealing with caller boundaries. That is, when a callback\nor interface function in the application will return to the operating\nsystem (e.g. when handling a draw request from X11), or another\nlanguage such as Python. Also, because different compiler vendors and\nversions handle exceptions differently, if you want to support\ndifferent compilers (and you have resolved the name mangling\nincompatibilities), you need to handle exceptions correctly in these\ncases, or risk having major problems that would be impossible to\ntrace. Not to mention that anywhere new, dynamic_cast and other\nlanguage features are used may throw exceptions.\n\n- Reece\n"},{"id":"53869","messageId":"200709240110.59680.robin.rosenberg.lists@dewire.com","threadId":"9975","inReplyTo":"85ejgpkr13.fsf@lola.goethe.zz","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-09-23T23:10:59Z","receivedAt":"2007-09-23T23:10:59Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 23 september 2007 skrev David Kastrup:\n> Dmitry Potapov writes:\n> \n> > On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:\n> >\n> >> - the stuff C++ *does* have is usually nasty. Implicit\n> >> initializers and destructors and the magic lifetime rules of\n> >> objects etc\n> >\n> > I am not sure what is wrong with initializers and destructors in\n> > C++, but certainly there is no magic lifetime rules in C++, as it is\n> > fully determined by the scope.\n> \n> It has been some time since I last looked, but the lifetime of objects\n> constructed in return statements was a moving target through several\n> standards. The last standard I bothered looking at had the object\n> survive until the statement with the function call expression ended:\n> quite a strange synchronization point with regard to language design.\n\nThe idea is that you should be able to use temporaries by reference and\ntrust them to be valid over function calls end even function returns, so \nyou can write efficient matrix math libraries that do not copy data much while\nretaining value semantics with overloaded operators. It is a purely practical\nmatter, what actually works and is efficient, not dogmatic language \"design\".\n\nEarlier versions failed to make up something useful here.\n\n> > In fact, other high level languages that use GC have much more\n> > unpredictable lifetime rules for objects.\n> \n> Mostly objects are alive as long as you can refer to them. Not really\n> complicated.\n\nWhat could be simpler, besides all static variables.\n\n-- robin\n"},{"id":"53906","messageId":"20070924104603.GB25435@potapov","threadId":"9975","inReplyTo":"3f4fd2640709231525q52a9865alc834ca46b85998fe@mail.gmail.com","subject":"Re: [OT] Re: C++ *for Git*","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2007-09-24T10:46:03Z","receivedAt":"2007-09-24T10:46:03Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, Sep 23, 2007 at 11:25:01PM +0100, Reece Dunn wrote:\n> The next version of C++ is going to have garbage collection that the\n> user can enable, disable or remain neutral about. However, this is\n> program-wide and has many traps that you could fall into.\n\nSure. C++ has not been design to be garbage collection friendly, in\nfact, even now, you can use some GC with C++, but it can be painful.\nI don't think that the new standard will change much in this respect.\n\n> > > But other parts of C++ are just nasty. The whole OO layer seems designed\n> > > to do a lot of things implicitly and in the wrong way.\n> >\n> > It could do a lot of things implicitly, but it does not force you,\n> > except calling destructor when the control leaves the scope of\n> > declaration, but I hardly can consider it as implicit.\n> \n> You have to add the explicit keyword to any constructor to prevent an\n> automatic conversion. Therefore, the constructors that are called are\n> implicit by default.\n\nYes, I would prefer if it were opposite by default, but it was an\ninitial mistake in design, and you cannot change it without breaking\na lot of people code.\n\n> If you have a conversion operator, this is always\n> implicitly called when there is a match by the compiler.\n\nConversation operator should be written only if you do want an implicit\nconversation, and that may be useful sometimes, albeit very rarely.\n\n> \n> I agree with Linus here, there are a lot of things that happen implicily.\n> \n> > > I also disagree with exception handling,\n> >\n> > Perhaps, you look at it from the kernel point of view. Otherwise, I\n> > would like to hear your arguments against it. In fact, I don't think\n> > it is possible to write generic algorithms without exceptions. Of\n> > course, if you write a program that can print an error to stderr and\n> > exit, there is no much need for them. So, it may depend on the task.\n> \n> There are many issues with exceptions.\n> \n> Firstly, there is throwing an exception from a destructor, which is\n> warned against in any good C++ book, but does not prevent you from\n> doing so (even if it is inadvertantly)!\n\nIn general, the compiler does not have all information to know whether\na destructor can or cannot throw an exception, and even less it knows\nabout your real intentions. There are many ways to write something\nthat will not work. You can create an infinite recursion, but I don't\nthink it is a good argument against recursion.\n\n> \n> More importantly though, is the loss of contextual information.\n\nDo you think that an error code contains much more contextual\ninformation?\n\n> Consider throwing the same exception on all calls to API that return\n> the same error code type. \n\nI did not mean that all error codes should be returned as an exception.\nException in C++ is something that should not normally happen, like\nfailure to allocate memory. So, you usually do not want to handle\nthis situation immediate.\n\n> The code that processes this may be anywhere\n> in the system. This makes it impossible to do any sensible recovery\n> (if possible), or error reporting. The exception can be rethrown or\n> translated to another exception, making it impossible to find the\n> originator of the exception. This makes it harder, if not impossible,\n> to track the exception back to the source when you are at a breakpoint\n> in the exception handler.\n\nIn gdb, you can catch all exception when thrown using \"catch throw\".\nAnd again, I don't see how it is better when a program returns an\nerror code, especially if this error code is recoded couple times\nin the process of returning. So the problem is not with exceptions,\nbut usually with bad design.\n\n> Then there is dealing with caller boundaries. That is, when a callback\n> or interface function in the application will return to the operating\n> system (e.g. when handling a draw request from X11), or another\n> language such as Python. Also, because different compiler vendors and\n> versions handle exceptions differently, if you want to support\n> different compilers (and you have resolved the name mangling\n> incompatibilities), you need to handle exceptions correctly in these\n> cases, or risk having major problems that would be impossible to\n> trace.\n\nYou named some interoperability issues with C++ (and there are many\nof them), but it is not an argument against exceptions per se.\n\n> Not to mention that anywhere new, dynamic_cast and other\n> language features are used may throw exceptions.\n\ndynamic_cast throws an exception only for references, but not for\npointers, and there is a good reason for that -- references should\nnot be NULL; and if you want to avoid bad_alloc exception, you can\nuse \"T* p = new (std::nothrow) T;\" but it is rarely needed.\n\n\nDmitry Potapov\n"}]}