From owner-freebsd-chat Wed Mar 6 12:37:31 2002 Delivered-To: freebsd-chat@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 3CB0637B41A for ; Wed, 6 Mar 2002 12:37:26 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA04816; Wed, 6 Mar 2002 13:36:39 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g26Kacf36720; Wed, 6 Mar 2002 13:36:38 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.32214.569624.572704@caddis.yogotech.com> Date: Wed, 6 Mar 2002 13:36:38 -0700 To: Raymond Wiker Cc: nate@yogotech.com (Nate Williams), Giorgos Keramidas , Terry Lambert , "Steve B." , freebsd-chat@FreeBSD.ORG Subject: Re: C vs C++ In-Reply-To: <15494.29430.907768.151847@raw.grenland.fast.no> References: <20020305132457.A4700-100000@alpha.yumyumyum.org> <001701c1c481$d0d5eab0$f642d9cf@DROID> <20020305231252.GC5328@hades.hell.gr> <3C8568E0.76415D99@mindspring.com> <20020306032029.GA7926@hades.hell.gr> <15494.13878.219807.949085@raw.grenland.fast.no> <15494.20631.682803.383406@caddis.yogotech.com> <15494.22039.581536.624619@raw.grenland.fast.no> <15494.23822.972400.759310@caddis.yogotech.com> <15494.29430.907768.151847@raw.grenland.fast.no> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > class FP > > { > > public: > > FP() { _value = 0.0; } > > FP(double v) { _value = v; } > > > > float getValue() { return _value; } > > > > private: > > float _value; > > } > > > > int > > main() > > { > > FP f(1.0); > > > > printf("Value = %3.2f\n", f.getValue()); > > > > return 1; > > } > > #include > #include > > std::cout << setw(3) << setiosflags(ios::fixed) << setprecision(2) > << f.getValue() << std::endl; Do you mind if I throwup now? > How would you go about extending printf et al so that you can > use printf to print a description of an object? With iostreams, this > is trivial. It can be done trivially in an object as well. class Name { public: Name(String name) { objname = new String(name); } ~Name() { delete objname; } private: String objname; } Obviously, this can be combined with the above to get the desired behavior. > > Try using it on HP/UX. Try using it on AIX. Try using standard > > containers and see how they behave differently on different releases of > > Solaris. > > Have you actually _seen_ this sort of behaviour recently? No, but most C++ code was written before it was possible. Now, there are (IMO) better languages than C++ to perform solutions, so finally years later when C++ can be used, it's been overtaken by events. > > > Further, if you don't use the advanced features of C++, you may just > > > as well stick to to C. > > > > Naw, it's still C++. All versions of C++ support inheritance, scoping > > protection, object initialization and teardown, as well as > > function/operator overloading. Of the above described features, only > > operator overloading tends to cause strange problems. > > I haven't even seen problems with operator overloading. I > think. It is entirely possible that I may remember something > later :-) Unintended creation/deletion/leaking of objects when doing using operator overloading is very common. Most of the Meyers book discuss these sorts of problems. Avoiding these kinds of problems causes the resulting code to be totally incomprehensible to all but the most clued developers. > > > > Safer? The intracacies of printf/scanf are *well* known, so I wouldn't > > > > say that it's any more/less safe. At least with the above functions, > > > > you *know* ahead of time the issues, vs. some random implementation of a > > > > class you don't want to look at. > > > > > > The intricacies of print/scanf may be *well* known, as you > > > say, but *not* to the average C programmer > > > > This I disagree with. Back when I learned C in college (late 80s), it > > wasn't as well known as it is now. However, even back then we discussed > > some of the pitfalls of scanf. With printf/scanf, at least you have > > only *one* set of routines to deal with. With streams, you have a bunch > > of different pitfalls that may vary from class to class. Simple *is* > > better. > > Only insofar as it isn't a source of errors. How do you > protect against anyone doing something like > > const char *s = "http://this/is/a/strange/url?%23strange"; > > printf(s); > > I've just seen something very similar to this; not involving > printf, but a non-standard string class :-) Stupid things can be done with *any* function. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message