C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  automatically const cast ? Goto page 1, 2, 3 ... 159, 160, 161  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message server Guest Posted: Fri Jan 27, 2006 6:39 am    Post subject: automatically const cast ? message unavailable Back to top Axter Guest Posted: Fri Jan 27, 2006 6:39 am    Post subject: Re: automatically const cast ? Buster wrote: Quote: Bob Hairgrove wrote: You should overload operator-> on const, e.g.: template<typename T class SmartPtr { T* ptr; public: SmartPtr(T* pt) : ptr(pt) {} T* operatr->() { return ptr; } T const * operatr->() const { return ptr; } // etc. }; I had tried that and it didn't work. It looked to me like the const version would only be called if the SmartPtr itself was const. Have I got something wrong ? No, you don't have it wrong. I also tried the same thing you're trying, so-as to help me make a Copy-On-Write smart poitner: http://code.axter.com/cow_ptr.h But ran into the same problem. The const version of operator-> only gets called if the smart poitner itself is constant. Otherwise the non-const version is called. No easy way to tell if the pointee is getting mutated or not. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jack Klein Guest Posted: Fri Jan 27, 2006 6:41 am    Post subject: Re: Swapping the sign of doubles On 26 Jan 2006 12:49:08 -0500, "hans.dewinter (AT) silicos (DOT) com" <hans.dewinter (AT) silicos (DOT) com> wrote in comp.lang.c++.moderated: Quote: I have a series of double variables which I need to multiply with either -1 or +1. Since multiplication of two doubles is an 'expensive' operation, I am looking for an alternative method. I was thinking in the direction of bitwise operators. This is perfectly possible in the case of integers, where a bitwise exclusive 'or' (^) operation may be performed between the variable and (1 >> 0). Is someting similar also possible for a double variable? Multiplication of two doubles is not nearly as 'expensive' as it used to be. Depending on your platform and its internal binary format for doubles, you could possibly put together some code that uses type punning of one sort or another and toggles a single bit in the memory pattern of a double. The result is undefined behavior under the C++ standard, and can be hideously non-portable if you ever need to move the application to a different platform. It would help if you provided more context, and perhaps some sample code. Depending on how the code is structured, it should be possible to replace the multiply with something like: (some_ver) ? my_double[x] : -my_double[x]; Negating the sign of a floating point value is very inexpensive on the floating point hardware of most current desktop and work station platforms. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alberto Ganesh Barbati Guest Posted: Fri Jan 27, 2006 6:42 am    Post subject: Re: C++ template base class' nested typedefs not visible in Alberto Ganesh Barbati ha scritto: Quote: mikehcox (AT) gmail (DOT) com ha scritto: Below is a file I'm getting compile errors on (CASEs 1 and 2). I think both 1 and 2 should be legal C++. Visual C++ Expres 2005 agrees with me. Compiling using Cygwin's GNU 3.4.4 has the shown error messages. Which compiler is right and what C++ standard clause would cover this situation? Visual C++ is right. The others seems to allows a relaxed syntax which is actually incorrect. Ops. I'm sorry. It's the other way round. Case 1 and 2 are not legal C++ and should not compile. Ganesh [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Wu Yongwei Guest Posted: Fri Jan 27, 2006 6:45 am    Post subject: Re: iostream/ostream Dietmar Kuehl wrote: Quote: Attila Feher wrote: and now I see (here and other places) that people keep writing: #include <iostream #include <ostream where we have originally have only written #include <iostream I observed in 1998 that the standard does not mandate inclusion of either <istream> or <ostream> from <iostream>. For the implementation of <iostream> it would be sufficient to merely declare the necessary stream types but to omit their actual definition. At the time of my observation, only Nathan Myers commented on the issue and he considered it to be a bug in the implementation as I did, too. I'm not aware of any standard library implementation which does not include <istream> and <ostream> from <iostream> although my own implementation is prepared to simply remove these two headers. Thus, I think it is actually a non-issue some people like to point out. They are formally right but actually distract from the issues actually under consideration. Good argument. Now on some practical issues. I always use just <iostream>, since one of the old compilers I use (old, but still decent enough to recognize namespaces and templates, and can build my code very well) has not a header named <ostream> at all. Although in my own environment, I add an <ostream> to just include <iostream>, it does not make other people using the same compiler compile the code. I do not think this issue is reason enough to encourage people to `upgrade' to a version that is really completely different. The only compiler that I heard people say that requires <ostream> to be included is Comeau. Of course it is (or should be) a decent compiler, but since I have never used it offline I really do not care much.... And #ifdef on this seems ugly and overkilling. Best regards, Yongwei [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ted Guest Posted: Fri Jan 27, 2006 2:31 pm    Post subject: Re: Definition of POD <Michiel.Salters (AT) tomtom (DOT) com> wrote in message news:1138189510.118100.11110 (AT) g44g2000cwa (DOT) googlegroups.com... Quote: Ted wrote: What exactly is a POD (plain old datatype) in C++? Defined in the standard, from memory: a type without virtual functions, virtual inheritance, non-POD members or bases, or non-trivial constructors. What then is a "trivial" constructor? (One that does nothing?). Ted [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ketan Guest Posted: Fri Jan 27, 2006 2:32 pm    Post subject: Re: C++ design - encapsulation for large data Hi Niek, Thanks for the inputs and sorry for non-standard format ( using google-groups via web interface) "Design Patterns" (http://www.amazon.com/gp/product/0201633612/) is an -> Yes, I have this and been refering it. Seriously consider rolling your own iterators. They provide a powerful abstraction for traversing over your dataset. Rather than tossing around references to your data structure, simply hand algorithms a begin/end pair of iterators. This helps keep your algorithms more generic, making them easier to reuse in the future. Furthermore, with -> I agree about generic solution but currently I am not sure how to store -> and abstract my data. I will look into it more. custom iterators you can do tricks like lazy loading/generation of the datasets you are returning upon dereferencing. -> Can you explain more what do you mean by above ? architecture. There are also plenty of classical computer science techniques which come in to play: algorithms computing variance in a single pass, sorts optimized for data on secondary storage, etc. -> OK, will get back and read again :) -> Thanks again for inputs. bye ketan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Walter Bright Guest Posted: Fri Jan 27, 2006 2:32 pm    Post subject: Re: Swapping the sign of doubles <hans.dewinter (AT) silicos (DOT) com> wrote in message news:1138295502.272962.58020 (AT) g47g2000cwa (DOT) googlegroups.com... Quote: I have a series of double variables which I need to multiply with either -1 or +1. Since multiplication of two doubles is an 'expensive' operation, I am looking for an alternative method. I was thinking in the direction of bitwise operators. This is perfectly possible in the case of integers, where a bitwise exclusive 'or' (^) operation may be performed between the variable and (1 >> 0). Is someting similar also possible for a double variable? If the doubles are stored in IEEE 754 format, xoring the sign bit of the floating point value with 1 will change the sign of the floating point value. Of course, this isn't portable. And, of course, some compilers do a pretty good job generating floating point code. I'd first try: d = -d; and compile with optimization on and then disassemble the output. There may not be much profit in taking it any further. -Walter Bright www.digitalmars.com C, C++, D programming language compilers [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ted Guest Posted: Fri Jan 27, 2006 2:37 pm    Post subject: Re: Backgrounder on C++/CLI "Dilip" <rdilipk (AT) lycos (DOT) com> wrote in message news:1138289910.706588.162930 (AT) z14g2000cwz (DOT) googlegroups.com... Quote: I don't know how useful or on-topic this article is going to be for this NG, but considering there are many more discussion that are likely to spawned once C++/CLI gets accepted into the mainstream, I thought the C++ community might want to spend a few minutes looking into the design and ISO C++ compatibility goals as presented by Stan Lippman in this piece: http://msdn.microsoft.com/msdnmag/issues/06/00/PureC/default.aspx Apologies to the moderator in advance if this is considered OT. What comes to mind immediately after reading the material at the above link is that if you are one of those developers who uses multiple languages to create applications and systems, than your life is a lot more complex than those that use only C++. MS has always been on that track, probably because of Gate's love of VB. The article mentions things like GC and "managed code" (whatever the heck that is) like they are fundamental well-known, desireable and appropriate things to use going forward rather than special-case or proprietary things. CLI is a way to get you to buy into the proprietary .NET technology. C++ will evolve (is evolving slowly, but maybe that is good since it requires more competence to engineer foundational software), but C++ should not succumb to the smoke and mirrors of presentations that try to influence opinion that multi-language programming is the future or even desireable (IMO it's to be avoided at all costs). The article IMO, looks like propaganda that tries to make MS's problems everyone's problems. I find C++ quite adequate for now and in the foreseeable future and what's not "in there" I write myself or find an existing library to modify: if I want GC, I'll build it or absorb the Boehm GC; if I need something COM-like or .NET-like, I'll build that too. I don't want my software dependent on loads-O-proprietary technology pieces (that's why I use C++!). I use English to speak. Similarly, I use C++ to build software. Both are more than adequate for my needs. (Or maybe the article is an attempt to make C++ syntax ugly (uglier?) and get followers onboard the high-level-XML-flavor-of-the-month-point- and-click development tool game? Fat chance!) OK, I got a bit soapy. I feel better now though. :) Ted [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Le Chaud Lapin Guest Posted: Fri Jan 27, 2006 2:37 pm    Post subject: Re: Commercial programs written in C/C++? Seungbeom Kim wrote: Quote: I don't think the mere existence of a standard library will force users to use it; only if it's good and useful enough. A standard GUI library will not force anyone to stop using proprietary GUI libraries that have been in use, unless he/she and others feel that there's a significant gain in switching to the standard one (including the portability, readability, maintainability and whatever else a standard may give). So, having something that's not good enough is not that worse than not having anything at all. What happens when you have 5 managers in a board room trying to decide how to solve the cross-platform GUI problem, and someone mentions that there is already a "standard" GUI library provided by the language itself? Unless the managers are able to objectively evaluate the virtue of the standard, there will be a strong collective urge to issue a manadate that everyone should use it. Why? Because it's standard. Microsoft, for example, is shrewdly exploiting this peculiar defect in human decision-making by calling their tainted C++ enviroment (CLI/CLR) "managed" whereas pure C++ is unmanaged, which, course, means that pure C++ is inferior to CLI/C++ because any idiot knows that something that is managed is better than something that is not - we can't have all that code running wild, now can we? I could rattle off a long list of technologies that were brain-dead at birth, but were forcibly prescribed by management because management was highly interested in "doing things by the book", as it relieved them of sorting through the conflicting information that they were being given by their lieutenants and making a decision that required deep insight. The resulting cost of having thousands of skilled workers being forced to use a technology is defunct at birth is simply enormous. -Le Chaud Lapin- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze Guest Posted: Fri Jan 27, 2006 8:11 pm    Post subject: Re: iostream/ostream Wu Yongwei wrote: Quote: Dietmar Kuehl wrote: Attila Feher wrote: and now I see (here and other places) that people keep writing: #include <iostream #include <ostream where we have originally have only written #include <iostream I observed in 1998 that the standard does not mandate inclusion of either <istream> or <ostream> from <iostream>. For the implementation of <iostream> it would be sufficient to merely declare the necessary stream types but to omit their actual definition. At the time of my observation, only Nathan Myers commented on the issue and he considered it to be a bug in the implementation as I did, too. I'm not aware of any standard library implementation which does not include <istream> and <ostream> from <iostream> although my own implementation is prepared to simply remove these two headers. Thus, I think it is actually a non-issue some people like to point out. They are formally right but actually distract from the issues actually under consideration. Good argument. Now on some practical issues. I always use just <iostream>, since one of the old compilers I use (old, but still decent enough to recognize namespaces and templates, and can build my code very well) has not a header named <ostream> at all. Hmmm. The only compiler I've ever seen that had <iostream> but not <ostream> was g++ 2.95.x. And it didn't really have <iostream>; it had a file with that name which had nothing to do with the standard iostreams, but was rather an alias for <iostream.h>. (It also had special handling for namespace's, so that std:: and :: were synonyms.) The standard iostream and the classical iostream are two different beasts. If you have to support both, deciding whether to include <iostream.h> or <iostream>, <ostream>, etc. is the least of your worries. When I still had to support both, I had my own header files corresponding to each header in the standard, <iostream.hh>, <ostream.hh>, etc.; my header not only included the appropriate library header (<iostream.h> in every case for the classical iostreams), but also defined a number of portability macros, so that I didn't have to clutter my code with #ifdef's every few lines. Quote: Although in my own environment, I add an <ostream> to just include <iostream>, it does not make other people using the same compiler compile the code. I do not think this issue is reason enough to encourage people to `upgrade' to a version that is really completely different. If you're comparing the classical iostreams with the standard, the versions really are completely different. Some things are minor (the initial formatting state is different, for example); others are more important (you can't do binary IO without correctly imbue'ing the streambuf with a transparent locale, for example, and some commonly used functions in streambuf changed names). Quote: The only compiler that I heard people say that requires ostream> to be included is Comeau. Of course it is (or should be) a decent compiler, but since I have never used it offline I really do not care much.... Unless things have changed since I got my copy, Comean is just the compiler, not the library. I have heard somewhere of an implementation which implemented <iostream> in a minimal fashion, but I forget where, it was some time ago, and it's quite possible that they've changed since then. I do have a modification of the g++ library which uses the minimal implementation. It's handy for verifying that my code is conform in this respect. Quote: And #ifdef on this seems ugly and overkilling. I never used an #ifdef in my code. But if you have to support both the classical iostream and the standard one, you do need to take a number of differences into account. Not just the name of the header(s). -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Earl Purple Guest Posted: Fri Jan 27, 2006 8:12 pm    Post subject: Re: Definition of POD Ted wrote: Quote: Michiel.Salters (AT) tomtom (DOT) com> wrote in message news:1138189510.118100.11110 (AT) g44g2000cwa (DOT) googlegroups.com... Ted wrote: What exactly is a POD (plain old datatype) in C++? Defined in the standard, from memory: a type without virtual functions, virtual inheritance, non-POD members or bases, or non-trivial constructors. What then is a "trivial" constructor? (One that does nothing?). struct A { int x; double y; A() : x( 0 ), y( 0.0 ) { } A( int xx, double yy ) : x( xx ), y (yy ) { } }; I guess those constructors are trivial although this would be non-compatible with C You would initialise in C as A a = { 5, 3.3 }; [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze Guest Posted: Fri Jan 27, 2006 8:13 pm    Post subject: Re: Definition of POD Fuz wrote: Quote: kanze wrote: The only real guarantee concerning POD's is that memcpy works on them, although in practice, they must also be compatible with C structs. Note that the presence of a constructor generally means that memcpy will not work; at any rate, it cannot be guaranteed to work. Prove it. :-) I've had this conversation with Howard Hinnant before: http://groups.google.co.uk/group/comp.lang.c++.moderated/msg/f7a6bb4beb234d04 We couldn't find any reference to anything in the Standard which says that only PODs are copyable by memcpy. A trivial copy constructor should be enough, but again, that's not specified either. I'd say that the shoe is on the other foot. What makes you think that any object can be copied by memcpy? The only guarantee I see concerning this is §3.9/2: "For any complete POD object type T, whether or not the object holds a valid value of type T, the underlying bytes making up the object can be copied into an array of char or unsigned char. If the content of the array of char or unsigned char is copied back into the object, the object shall subsequently hold its original value." Of course, that's rather vague -- one can presumably ask what it means to "hold its original value". std::string s ; unsigned char tmp[ sizeof( s ) ] ; memcpy( tmp, &s, sizeof( s ) ) ; s = "abcde" ; memcpy( &s, tmp, sizeof( s ) ) ; I don't think anyone here expects that to get us anything but trouble. Now consider a class that is exactly like std::string, except that 1) it doesn't have constructors, a destructor or an assignment operator, but member functions init, destruct and assign, which have to be called explicitly, and 2) all of its members are public. This makes it a POD, but: ThisClass s ; s.init() ; unsigned char tmp[ sizeof( s ) ] ; memcpy( tmp, &s, sizeof( s ) ) ; s.assign( "abcde" ) ; memcpy( &s, tmp, sizeof( s ) ) ; s.destruct() isn't going to work any better that the first example. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Dervish Guest Posted: Fri Jan 27, 2006 8:13 pm    Post subject: Re: Coding skills: const vs mutable Quote: const AMAP::const_iterator& it = aMap.find(s); Idea around this option was performance optimization. In case of local variable copy constructor of iterator is called. Const reference should remove this call. Quote: One thing does bother me about your code, however. GetString is synthetic example. Real signature is: const SomeClass* GetSomeClass(const SomeKey& key); In which by default return value is 0. By the way I found in Stroustrup's TC++PL that he uses mutable to overcome const (for caching) in case of single potentially mutable variable. But for more complex case he creates member pointer to other class. That other class can be simply changed, since pointer is not changed. Looks like hack. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze Guest Posted: Fri Jan 27, 2006 8:13 pm    Post subject: Re: Definition of POD Ted wrote: Quote: Michiel.Salters (AT) tomtom (DOT) com> wrote in message news:1138189510.118100.11110 (AT) g44g2000cwa (DOT) googlegroups.com... Ted wrote: What exactly is a POD (plain old datatype) in C++? Defined in the standard, from memory: a type without virtual functions, virtual inheritance, non-POD members or bases, or non-trivial constructors. What then is a "trivial" constructor? (One that does nothing?). More or less, with the added requirement that it be generated by the compiler -- no constructor you write is ever trivial, even if it does nothing. This, of course, means that only default constructors and copy constructors can be trivial. Formally, a constructor is trivial if: -- the class has no virtual functions and no virtual bases, -- all of its direct base classes of its class have trivial constructors of the same type (copy or default), and -- all of its nonstatic data members that are of class type (or array thereof) have trivial constructors of the same type. Similar definitions exist for trivial assignment operator and trivial destructor. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2, 3 ... 159, 160, 161  Next Page 1 of 161   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.