More C++ BS:

Post #80,594 by admin 2/10/03 11:39:30 AM Reply	More C++ BS: \ntemplate <class T,const int COUNT,const int SIZE = -1>\nclass CBDCachedAllocator\n{\n...\n\ttypedef T & reference; // C\n...\n}\n\n\nclass CINIFile \n{\npublic:\n...\n\tclass Section; // A\n...\n\ttypedef CBDCachedAllocator<Section,256> SectionAllocator; // B\n...\n\tclass Section : public stringnc\n\t{\n...\n\t\tfriend class std::list<Section,SectionAllocator>;\n...\n}\n BDAlloc.h(132): error: reference to void is not allowed \ttypedef T & reference; \t ^ detected during: instantiation of class "CBDCachedAllocator<T, COUNT, SIZE> [with T=void, COUNT=1024, SIZE=-1]" at line 17 of "/opt/intel/compiler70/ia32/include/list" instantiation of class "std::_List_nod<_Ty, _Alloc> [with _Ty=CINIFile::Field, _Alloc=CINIFile::FieldAllocator]" at line 46 of "/opt/intel/compiler70/ia32/include/list" instantiation of class "std::_List_ptr<_Ty, _Alloc> [with _Ty=CINIFile::Field, _Alloc=CINIFile::FieldAllocator]" at line 66 of "/opt/intel/compiler70/ia32/include/list" instantiation of class "std::_List_val<_Ty, _Alloc> [with _Ty=CINIFile::Field, _Alloc=CINIFile::FieldAllocator]" at line 83 of "/opt/intel/compiler70/ia32/include/list" instantiation of class "std::list<_Ty, _Ax> [with _Ty=CINIFile::Field, _Ax=CINIFile::FieldAllocator]" at line 75 of "INIFile.h" Apparently the forward declaration of Section at 'A' is carried forward as 'void' until the full declaration. Unfortunately the code needs it before then when it uses the CBDCachedAllocator template at 'B;, which has a nifty 'T & reference' thinger in it at 'C'. No references to void allowed, so boom. Wheee! I heart C++! Goddamned byzantine garbage. MSVC like, gcc like, Intel no like. Pah. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #80,691 by jb4 2/10/03 4:57:58 PM Reply	OK, the problem here is the implementation, not the language Apparently the forward declaration of Section at 'A' is carried forward as 'void' until the full declaration. I would agree, but that's not the fault of C++. A forward reference in C++ has the type of the reference (which is undefined); assigning the forward reference the "temporary" type of void is a trick that particular compiler uses...and it results in a typically misleading error message when you trip over it. The compiler is at fault here, not the language; the correct error message would be something along the lines of "attempt to resolve incomplete type" or "attempt to resolve forward reference to incomplete type 'Section'" or something like that. jb4 "They lead. They don't manage. The carrot always wins over the stick. Ask your horse. You can lead your horse to water, but you can't manage him to drink." Richard Kerr, United Technologies Corporation, 1990
Post #80,694 by CRConrad 2/10/03 5:08:53 PM Reply	Oh, come the heck on! Yes, it IS the language! If a language is so fucking hard to implement that shit like that happens regularly -- and Scott's shown examples from pretty much every implementation, hasn't he? -- then, yes, there IS a problem with the LANGUAGE. Now stop trying to defend the luster of that parrot's plumage, Burnsy. [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link\|http://z.iwethey.org/forums/render/content/show?contentid=71575\|Ashton Brown]
Post #80,703 by jb4 2/10/03 5:35:53 PM Reply	C'mon Christian... What's "so fucking hard" is the ability for an implementation to render a correct error message for this (and several other related) scenarios. gcc is the worst. Micros~1 is only slightly better. Borland C++ Builder is quite a bit better, and will actually get the message more-or-less the way I described it (YMMV). Never having tried the Intel compiler, I don't know how it handles it, but from Scott's description, it appears to be in gcc-land as far as this is concerned. 4 different implementations. 4 different handlings of the issue. Same language. And you claim that it's the language's fault?!? C'mon Christian...who you crappin? jb4 "They lead. They don't manage. The carrot always wins over the stick. Ask your horse. You can lead your horse to water, but you can't manage him to drink." Richard Kerr, United Technologies Corporation, 1990
Post #80,704 by admin 2/10/03 5:37:42 PM Reply	Not that big a stretch... The C++ language is too complex for compiler writers to get right with any amount of certainty... ;-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #80,706 by CRConrad 2/10/03 5:42:23 PM Reply	So, it's a great language, if your definition... ...of "great" includes "impossible to implement". Yeah, OK, I reckon I could agree to that, if you insist. To the rest of us, that's called "sucks". This issue is a Norwegian Blue. [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link\|http://z.iwethey.org/forums/render/content/show?contentid=71575\|Ashton Brown]
Post #80,718 by jb4 2/10/03 5:58:08 PM Reply	NO, that's NOT what I said. [link\|http://z.iwethey.org/forums/render/content/show?contentid=79320\|What I said was:] C++ ain't the greatest thing ever evented in the name of computer science, but it ain't the devil's spawn either. I stand by that statement, not any that you might try to place in my mouth. jb4 "They lead. They don't manage. The carrot always wins over the stick. Ask your horse. You can lead your horse to water, but you can't manage him to drink." Richard Kerr, United Technologies Corporation, 1990
Post #80,723 by tuberculosis 2/10/03 6:05:26 PM Reply	Yeah, its the language The language is how many years old and nobody can write a good compiler for it? The grammar is a nightmare. Many language "features" come out of fantasy land. If the compiler writers are having trouble agreeing on what something means - what are the chances an author in the language is going to be able to express himself in it? I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customer got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more. --Alan Perlis
Post #80,741 by jb4 2/10/03 6:33:34 PM Reply	Re: Yeah, its the language The language is how many years old and nobody can write a good compiler for it? The grammar is a nightmare. Many language "features" come out of fantasy land. If the compiler writers are having trouble agreeing on what something means - what are the chances an author in the language is going to be able to express himself in it? Are you describing C++ or APL? (or Visual Basic, for that matter?) jb4 "They lead. They don't manage. The carrot always wins over the stick. Ask your horse. You can lead your horse to water, but you can't manage him to drink." Richard Kerr, United Technologies Corporation, 1990
Post #80,754 by inthane-chan 2/10/03 7:19:07 PM Reply	Yes.
Post #80,702 by admin 2/10/03 5:35:08 PM Reply	Advocacy aside: Is the code as presented correct, or has the developer done something that can only be expected to work in certain implementations (gcc 2.95.2, 2.95.4, 3.2.1, and MSVC 6, in this case)? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #80,711 by jb4 2/10/03 5:50:57 PM Reply	My understanding is: A reference should be forward reference-able. That is, one should be able to create a reference to a class that is forward referenced. I think the "problem" here is the template. In order to create an object of a templated type, many compilers want to know the innards of the passed-in type(s) (i.e. the template types). What I suspect has happened here is that your Intel compiler has attempted to early-resolve the type T in the 'CBDCachedAllocator' type, and finding it forward-referenced short cut the process by (perhpas temporarily?) resolving it as void. This dodge might actually work most of the time...until you try to create a reference to the type, at which point the more sane part of the compiler rises up and smites you. A proper template implementation would attempt to forward-ref the templated type until class T could be resolved. So in answer to your question, the construct as presented shoupd be syntactically correct (so long as the full definition of 'Section' is visible before the end of the compilation unit). jb4 "They lead. They don't manage. The carrot always wins over the stick. Ask your horse. You can lead your horse to water, but you can't manage him to drink." Richard Kerr, United Technologies Corporation, 1990
Post #80,732 by admin 2/10/03 6:13:45 PM Reply	Update: test code: try the fun on YOUR c++ compiler! Fun for the whole ANSI committee! This is the minimal code needed to duplicate the test case: \n// file test.cpp\n\n#include <string>\n#include <list>\n\ntemplate <class T>\nclass CTestAlloc\n{\npublic:\n\ttypedef T value_type;\n\ttypedef size_t size_type;\n\ttypedef ptrdiff_t difference_type;\n\ttypedef T * pointer;\n\ttypedef const T * const_pointer;\n\ttypedef T & reference;\n\ttypedef const T & const_reference;\n\n\ttemplate <class U>\n\tstruct rebind { typedef CTestAlloc<U> other; };\n};\n\n\nclass CTest \n{\n\ttypedef std::string string;\n\npublic:\n\tclass Field;\n\tclass Field_iter;\n\n\ttypedef CTestAlloc<Field> FieldAllocator;\n\n\ttypedef std::list<Field,FieldAllocator> Fields_t;\n\n\tclass Field : public string\n\t{\n\t};\n\n\tclass Field_iter : public Fields_t::iterator\n\t{\n\t};\n\npublic:\n\tCTest();\n\tvirtual ~CTest();\n};\n 'gcc -o test.o -c test.cpp' (2.95.4) compiles. 'icc -o test.o -c test.cpp' (7.0) does not. Same code will compile in MSVC 6.0 and gcc 3.2.1 as well. So, is it a compiler error or an stl implementation error? And how do you put up with this shit? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #80,742 by jb4 2/10/03 6:41:17 PM Reply	Borland C++ Builder 6 Pro compiles w/o error As I would expect, as Borland tends to be the most ANSI compliant of the compilers with which I am familiar. (And I'm sure that brings some warmth to Sir Cyclic's heart...). jb4 "They lead. They don't manage. The carrot always wins over the stick. Ask your horse. You can lead your horse to water, but you can't manage him to drink." Richard Kerr, United Technologies Corporation, 1990
Post #80,743 by admin 2/10/03 6:42:07 PM Reply	Nifty for Windows users, eh? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #80,750 by jb4 2/10/03 6:57:08 PM 2/10/03 6:57:42 PM Reply	In Linux-land, try Kylix... Same compiler, targets Linux. It really really works! jb4 "They lead. They don't manage. The carrot always wins over the stick. Ask your horse. You can lead your horse to water, but you can't manage him to drink." Richard Kerr, United Technologies Corporation, 1990 Edited by jb4 Feb. 10, 2003, 06:57:42 PM EST Expand All History
Post #80,753 by admin 2/10/03 7:15:22 PM Reply	I'll take a look then. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #80,769 by tjsinclair 2/10/03 8:09:40 PM Reply	GCC on Jaguar (3.1) works okay Tom Sinclair "Everybody is someone else's weirdo." - E. Dijkstra
Post #80,748 by admin 2/10/03 6:52:39 PM Reply	Update: what I did to workaround this I used STLPort instead of the built-in Intel STL implementation. Seems to compile OK now that I have an Intel version of the STLPort library as well. Wish me luck. :-P Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #80,751 by jb4 2/10/03 6:58:30 PM Reply	LUCK!!! ;-) jb4 "They lead. They don't manage. The carrot always wins over the stick. Ask your horse. You can lead your horse to water, but you can't manage him to drink." Richard Kerr, United Technologies Corporation, 1990
Post #80,983 by Arkadiy 2/11/03 5:45:33 PM 2/11/03 5:45:54 PM Reply	OT: gcc 2.95 native STL is very bad Remind me again, why you don't want to switch to 3.2? -- We have only 2 things to worry about: That things will never get back to normal, and that they already have. Edited by Arkadiy Feb. 11, 2003, 05:45:54 PM EST Expand All History
Post #81,012 by admin 2/11/03 8:19:14 PM Reply	I'm not using native 2.95 STL. We're using STLport. 3.2 has it's own issues... code portability for one (I don't have much time to finish this port) and several bugs that I came across. The Intel port is going quite well, so hopefully that will be the last compiler I have to attempt. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."

Welcome to IWETHEY!