From: Alexandre M. <am...@ib...> - 2001-12-05 20:23:03
|
Hello, I am starting my adventures at Firebird 2´s tree. I would like to know if there is something somewhere that says what the patterns, goals, etc. are. Cheers, Alexandre Magno IBSuper (www.ibsuper.net) |
From: John B. <bel...@cs...> - 2001-12-05 23:11:20
|
Alexandre, On Wednesday, December 5, 2001, at 01:25 PM, Alexandre Magno wrote: > Hello, > I am starting my adventures at Firebird 2=B4s tree. I would like to = know=20 > if > there is something somewhere that says what the patterns, goals, etc.=20= > are. I don't think there is a list of goals for FB2 anywhere. Some that I am=20= aware of are: convert to c++ (almost complete), use exceptions instead=20= of setjmp/longjmp, SMP, redesigned authentication system, better IB6=20 compatibility, and more. The list is not in any particular order. I=20 currently have a large number of outstanding changes that I haven't=20 committed. I've been working on (with the help of Mike Nordell and Ann=20= H.) overhauling the memory management in FB2 to use c++ constructs=20 instead of c constructs. -John |
From: <pa...@no...> - 2001-12-29 21:02:30
|
bel...@cs... (John Bellardo) wrote: >I don't think there is a list of goals for FB2 anywhere. Some that I am >aware of are: convert to c++ (almost complete), What compiler(s) will FB be compiled with on a) W32? and b) Linux? c) FreeBSD? Paul... >-John -- moc.oohay@nahenilp If you think this email address will work, you've go me all backwards. |
From: Mike N. <ta...@al...> - 2001-12-29 22:29:02
|
pa...@no... wrote: > What compiler(s) will FB be compiled with on For all supported systems, FB2 will be compilable by any reasonably conforming C++ compiler. Actually, since it's to be compilable by the MSVC6 compiler you can assume even compilers with quite bad C++ conformance will handle the code. What to look out for is obsolete C++ libraries, such as the one included with most GCC 2.95.x distros. Alternatives might be e.g. the GNU std C++ lib. 3(.x) or STLPort. Basically: The compiler needs to be able to handle basic template usage, exceptions and know what "bool" is. The library needs to be post C++ standard. No fancy stuff at all, and that's how we're going to try to keep it. /Mike |
From: Mark O'D. <mar...@lu...> - 2001-12-31 05:03:52
|
Mike Nordell wrote: >pa...@no... wrote: > >>What compiler(s) will FB be compiled with on >> > >For all supported systems, FB2 will be compilable by any reasonably >conforming C++ compiler. Actually, since it's to be compilable by the MSVC6 >compiler you can assume even compilers with quite bad C++ conformance will >handle the code. > >What to look out for is obsolete C++ libraries, such as the one included >with most GCC 2.95.x distros. Alternatives might be e.g. the GNU std C++ >lib. 3(.x) or STLPort. > Im trying the gcc 3.0.1 compiler, I needed to add the following two throw() clauses, In include/fb_exception.h changed: virtual ~status_exception() {} virtual const char* what() const to: virtual ~status_exception() throw() {} virtual const char* what() const throw() When I last did c++, stl was a pup. As I find from reading the manual, the above restricts the exceptions thrown in the methods to those in the throws(..) list, which in this case is none. So no exception can be thrown by these methods. Is that a problem for you (John/Mike) if I put these in? And, I know this meant to be part of the joys of debugging templates/namespaces under c++, but how do I fix the following. The error is: ../../src/jrd/gds.cpp:2463: instantiated from here /usr/include/g++-v3/bits/basic_string.h:169: passing `const Firebird::allocator<char>' as `this' argument of `bool Firebird::allocator<T>::operator==(const Firebird::allocator<T>&) [with T = char]' discards qualifiers Obviously it's to do with declaration of string in fb_string.h : namespace Firebird { typedef std::basic_string<char, std::char_traits<char>, Firebird::allocator<char> > string; }; and usage in gds.cpp : const Firebird::string regPrefix = FirebirdConfig::getSysString("RootDirectory"); and the const beign discarded somehow - but how do I fix it? Yours sincerely perplexed exjava programmer. Cheers Mark -- Your database needs YOU! http://www.firebirdSQL.org |
From: Claudio V. C. <cv...@us...> - 2001-12-31 07:02:25
|
> -----Original Message----- > From: fir...@li... > [mailto:fir...@li...]On Behalf Of Mark > O'Donohue > Sent: Lunes 31 de Diciembre de 2001 1:04 > To: Mike Nordell > > Im trying the gcc 3.0.1 compiler, > I needed to add the following two throw() clauses, > In include/fb_exception.h Here comes the Java-powered aussie to see if he can get his teeth on Mike's work before Mike finishes polishing the thing. :-) > changed: > > virtual ~status_exception() {} > virtual const char* what() const > > to: > > virtual ~status_exception() throw() {} > virtual const char* what() const throw() When you can't compile, you add a couple of reserved words like const, mutable, explicit, virtual, throw(), "&" to mean reference, a template and keep trying until either you or the compiler give up. :-) :-) :-) > When I last did c++, stl was a pup. But the issue here is that the STL was adapted to the features and restrictions of the language. > As I find from reading the manual, > the above restricts the exceptions thrown in the methods to those in the > throws(..) list, which in this case is none. So no exception can be > thrown by these methods. Let's see what is said straight from the horse's mouth, [Stroustrup 2000] in this case: Section 14.6.1: «A virtual function may be overridden only by a function that has an exception-specification at least as restrictive as its own (explicit or implicit) exception-specification.» Section 14.10 defines the root of the standard exceptions: class exception { public: exception() throw(); exception(const exception&) throw(); virtual ~exception() throw(); virtual const char* what() const throw(); Those declarations should be katakana for a pure-Pascal programmer. Had the designers been even more wicked, they could have enacted instead: virtual const char *const what() const throw(); that would have been funnier. :-) Since status_exception and the other two exceptions come from std::exception (why not creating a base class for FB exceptions?), it can't offer a function that's less restrictive than the original and since the original functions say "we don't throw any exception", there's no other alternative for the overriden functions. I think Mike used the redundant "virtual" keyword for documentation purposes, since it should be harmless (the base functions are already virtual). > Is that a problem for you (John/Mike) if I put these in? At least for Mike, no, since the MSVC compiler DOESN'T CARE about the exception-specification part, it will simply ignore that declaration. The Borland compiler cares and obviously, gcc does care. > And, I know this meant to be part of the joys of debugging > templates/namespaces under c++, but how do I fix the following. The > error is: > > ../../src/jrd/gds.cpp:2463: instantiated from here > /usr/include/g++-v3/bits/basic_string.h:169: passing `const > Firebird::allocator<char>' as `this' argument of `bool > Firebird::allocator<T>::operator==(const Firebird::allocator<T>&) > [with T = > char]' discards qualifiers It seems related to the constant literal string used there: > const Firebird::string regPrefix = > FirebirdConfig::getSysString("RootDirectory"); Do you get a warning or an error? C. --------- Claudio Valderrama C. Ingeniero en Informática - Consultor independiente http://www.cvalde.com - http://www.firebirdSQL.org |
From: Mike N. <ta...@al...> - 2001-12-31 12:22:50
|
Mark O'Donohue wrote: > I needed to add the following two throw() clauses, Thanks. [...] > Is that a problem for you (John/Mike) if I put these in? Absolutely not. It was an obvious oversight you corrected. > And, I know this meant to be part of the joys of debugging > templates/namespaces under c++, but how do I fix the following. The > error is: > > ../../src/jrd/gds.cpp:2463: instantiated from here > /usr/include/g++-v3/bits/basic_string.h:169: passing `const > Firebird::allocator<char>' as `this' argument of `bool > Firebird::allocator<T>::operator==(const Firebird::allocator<T>&) > [with T = > char]' discards qualifiers The compiler teels you that the operator== of Firebird::allocator<T> has a problem. It expects a non-const "this" pointer, but is used with a const "this" pointer. Change that line in common/memory/allocator.h to read bool operator==(const allocator<T>& rhs) const (it missed the const function declaration). /Mike |
From: Mark O'D. <mar...@lu...> - 2002-01-01 09:47:10
|
Hi Mike Nordell wrote: > >The compiler teels you that the operator== of Firebird::allocator<T> has a >problem. It expects a non-const "this" pointer, but is used with a const >"this" pointer. Change that line in common/memory/allocator.h to read > bool operator==(const allocator<T>& rhs) const > >(it missed the const function declaration). > Ok, that's what I did, But for your comment, previously I had added the following code in the Firebird namespace, (it came from the std namespace allocator, in gcc implementation, and when added it worked, but I wasn't so sure of the default 'return true' return false' as being enough - perhaps std only has only one allocator?. template <class _T1, class _T2> inline bool operator==(const allocator<_T1>&, const allocator<_T2>&) { return true; } template <class _T1, class _T2> inline bool operator!=(const allocator<_T1>&, const allocator<_T2>&) { return false; } Cheers Mark -- Your database needs YOU! http://www.firebirdSQL.org |
From: Mike N. <ta...@al...> - 2002-01-01 10:45:15
|
Mark O'Donohue wrote: > But for your comment, previously I had added the following code in the > Firebird namespace, (it came from the std namespace allocator, in gcc > implementation, and when added it worked, but I wasn't so sure of the > default 'return true' return false' as being enough - perhaps std only > has only one allocator?. > > template <class _T1, class _T2> > inline bool operator==(const allocator<_T1>&, const allocator<_T2>&) [snipped body and op!= ] AFAIK we don't copy any of our containers, therefore we shouldn't need any comparison operators for our allocator class template. Could you please post an error message of what and where it fails if these two are left undefined. /Mike |
From: Mark O'D. <mar...@lu...> - 2002-01-01 13:19:31
|
Hi Mike Mike Nordell wrote: >Mark O'Donohue wrote: > >AFAIK we don't copy any of our containers, therefore we shouldn't need any >comparison operators for our allocator class template. Could you please post >an error message of what and where it fails if these two are left undefined. > It's ok, when I change the method to const, it resolved fine, it was just something that seemed strange after looking though the g++ stl implementation code for answers.: Mind you I'd tried it originally but const in java usually goes in the front but const bool operator==(const allocator<T>& rhs) means something entirely different :-). So, now next compile problem :-). blb.cpp:2191 Another concise STL error message :-). ../../src/jrd/jrd.h: In member function `T* vec_base<T, TYPE>::memPtr() [with T = SLONG, short unsigned int TYPE = 11]': ../../src/jrd/blb.cpp:2191: instantiated from here ../../src/jrd/jrd.h:635: cannot convert `vec_base<T, TYPE>::begin [with T = SLONG, short unsigned int TYPE = 11]()' from type `std::__normal_iterator<SLONG*, std::vector<SLONG, Firebird::allocator<SLONG> > >' to type `SLONG*' where: blb.cpp:2191 MOVE_FASTER(vector->memPtr(), page->blp_page, page->blp_length); move faster is defined in common.h : #define MOVE_FASTER(from,to,length) memcpy (to, from, (int) (length)) and jrd is the vector definition : jrd.h:635 T* memPtr() { return (T*)begin(); } So as a working solution (to get through the compile and after quite a few failures) my solution was : T* memPtr() { T& a = vector[0]; return &a; } but there should be something better (and Im likely to be wrong :-) Yours sincerely waiting for a better answer. Mark PS: I've got past building gpre_boot, Cheers Mark -- Your database needs YOU! http://www.firebirdSQL.org |
From: Mark O'D. <mar...@lu...> - 2002-01-01 14:56:34
|
Mark O'Donohue wrote: > where: > > > MOVE_FASTER(vector->memPtr(), page->blp_page, page->blp_length); > > T* memPtr() { return (T*)begin(); } Looks like this might be a problem. Im also getting similar errors for cmp.cpp: csb_repeat* tail = csb->csb_rpt.begin(); csb_repeat* end = tail + csb->csb_n_stream; So hunting up on the web about it (and g++ in particular) I eventually come across the following: http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#5_1 5.1 string::iterator is not char*; vector<T>::iterator is not T* If you have code that depends on container<T> iterators being implemented as pointer-to-T, your code is broken. While there are arguments for iterators to be implemented in that manner, A) they aren't very good ones in the long term, and B) they were never guaranteed by the Standard anyway. The type-safety achieved by making iterators a real class rather than a typedef for T* outweighs nearly all opposing arguments. Code which does assume that a vector iterator i is a pointer can often be fixed by changing i in certain expressions to &*i . Future revisions of the Standard are expected to bless this usage for vector<> (but not for basic_string<>). So that makes the correct answer to : T* memPtr() { return (T*)begin(); } as : T* memPtr() { return (T*) &*(begin()); } And code such as : csb_repeat* tail = csb->csb_rpt.begin(); should now become : csb_repeat* tail = &*(csb->csb_rpt.begin()); (This is of course a question, which I hope to get an answer for :-). Cheers Mark -- Your database needs YOU! http://www.firebirdSQL.org |
From: Mike N. <ta...@al...> - 2002-01-01 15:44:44
|
Mark O'Donohue wrote: > Im also getting similar errors for cmp.cpp: > > csb_repeat* tail = csb->csb_rpt.begin(); > csb_repeat* end = tail + csb->csb_n_stream; > > > So hunting up on the web about it (and g++ in particular) I eventually > come across the following: > > http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#5_1 > > > 5.1 string::iterator is not char*; vector<T>::iterator is not T* That one's obvious. [...] > So that makes the correct answer to : > > T* memPtr() { return (T*)begin(); } > > as : > T* memPtr() { return (T*) &*(begin()); } I fail to see the reason for the C-style cast to T*, but this is basically correct. > And code such as : > > csb_repeat* tail = csb->csb_rpt.begin(); > > should now become : > > csb_repeat* tail = &*(csb->csb_rpt.begin()); Iff (two f intended) we have a bunch of csb_repeat in contigous memory (i.e. in a vector) that would take care of it. /Mike |
From: Mark O'D. <mar...@lu...> - 2002-01-01 16:57:15
|
Hi Mike Mike Nordell wrote: >Mark O'Donohue wrote: > >> >>as : >> T* memPtr() { return (T*) &*(begin()); } >> > >I fail to see the reason for the C-style cast to T*, but this is basically >correct. > Ok so it should be T* memPtr() { return &*(begin()); } > >>And code such as : >> >> csb_repeat* tail = csb->csb_rpt.begin(); >> >>should now become : >> >> csb_repeat* tail = &*(csb->csb_rpt.begin()); >> > >Iff (two f intended) we have a bunch of csb_repeat in contigous memory (i.e. >in a vector) that would take care of it. > Yep thats the case, either the original code wanted to copy a raw array, (as in the original one I sent) or more commonly it wants to pass a pointer to the object to a child function that accepts a pointer. But heres one that was slightly different, so to be sure in vio.cpp : for (rec_ptr = vector->begin(), end = vector->end(); rec_ptr != end; ++rec_ptr) if ((record = *(REC*) &*rec_ptr) && !(record->rec_flags & REC_gc_active)) { the: if ((record = *(REC*) rec_ptr) && !(record->rec_flags & REC_gc_active)) { should it become: if ((record = *rec_ptr) && !(record->rec_flags & REC_gc_active)) { (just after a 2nd opinion) And some other things: 1) It seems that some of the debug .cpp files (for linux basically ) # DEBUG_Sources= grammar.c dbg.cpp dbt.cpp dmp.cpp (in particular dbg.cpp) will not compile, since it uses HNK and stuff, are these now obsolete, or do they need to be looked at again. 2) Im missing something basic here, in array.cpp (and a few other files in dsql as well) the only changes were for gds__status, gds__trans -> gds_status and gds_trans. The original fb2 ones had #defines such as: array.cpp:#define gds__status isc_status array.cpp:#define gds__status2 isc_status2 but the new ones dont, so it gives errors. Anyway Im off to bed for now, if it strikes you as something you remember what happens, tell us. Cheers Mark -- Your database needs YOU! http://www.firebirdSQL.org |
From: Mike N. <ta...@al...> - 2002-01-01 21:35:26
|
Mark O'Donohue wrote: > Mike Nordell wrote: > > >I fail to see the reason for the C-style cast to T*, but this is > >basically correct. > > > Ok so it should be > > T* memPtr() { return &*(begin()); } Yes. > But heres one that was slightly different, so to be sure in vio.cpp : > > for (rec_ptr = vector->begin(), end = > vector->end(); rec_ptr != end; ++rec_ptr) > if ((record = *(REC*) &*rec_ptr) && !(record->rec_flags & > REC_gc_active)) { > > the: > if ((record = *(REC*) rec_ptr) && !(record->rec_flags & > REC_gc_active)) { > > should it become: > > if ((record = *rec_ptr) && !(record->rec_flags & REC_gc_active)) { > > (just after a 2nd opinion) I haven't got a clue. But if it works, sure. Whatever. That code should probably be rewritten anyway so that rel::rel_gc_rec is a Firebird::vector<REC>*, and that function (VIO_gc_record) should be rewritten a bit. If you look at the end of it, the code goes through a whole lot of trouble for an operation as simple as vector->push_back(record); > And some other things: > > 1) > It seems that some of the debug .cpp files (for linux basically ) > > # DEBUG_Sources= grammar.c dbg.cpp dbt.cpp dmp.cpp > > (in particular dbg.cpp) will not compile, since it uses HNK and stuff, > are these now obsolete, or do they need to be looked at again. 1) It's not only Linux, they don't work for Win32 either (or anything for that matter). 2) I don't think they are sceduled for removal. It was John Bellardo that did the memory pool design and implementation, which IMHO was a rather large and important task, and I don't know if/when he planned to bring that code up to speed. For now, just compile with nodebug.cpp. > 2) > > Im missing something basic here, in array.cpp (and a few other files in > dsql as well) the only changes were for gds__status, gds__trans -> > gds_status and gds_trans. Yes, you are. Two consecutive underscores are reserved for the implementatio n. The wording from C++ CD1 17.3.3.1.3 was Each name having two consecutive underscores (2.8) is reserved to the implementation for use as a name with both extern "C" and extern "C++" linkage. Even that the final wording perhaps is a bit different, the spirit is the same. (I know, we can't obey by the rules with gds__free et.al. but we'll have to do the best we can) > The original fb2 ones had #defines such as: > > array.cpp:#define gds__status isc_status > array.cpp:#define gds__status2 isc_status2 > > but the new ones dont, so it gives errors. ??? The array.cpp generated for dsql should contain #define gds_status isc_status and never should gds__status be mentioned. Are you perhaps using an obsolete gpre? /Mike |
From: Mark O'D. <mar...@lu...> - 2002-01-02 01:54:11
|
Mike Nordell wrote: > >>2) In array.epp >> >>Im missing something basic here, in array.cpp (and a few other files in >>dsql as well) the only changes were for gds__status, gds__trans -> >>gds_status and gds_trans. >> > >Yes, you are. Two consecutive underscores are reserved for the implementatio >n. The wording from C++ CD1 17.3.3.1.3 was > Each name having two consecutive underscores (2.8) is > reserved to the implementation for use as a name with > both extern "C" and extern "C++" linkage. > >Even that the final wording perhaps is a bit different, the spirit is the >same. >(I know, we can't obey by the rules with gds__free et.al. but we'll have to >do the best we can) > In other places in the code gds_ and gds__ prefixes are used to distingish c and c++ constants (some moved to src/include/gen/codes.h). I don't know but my impression was that the reserved usage of underscores for implementation and system stuff was confined to leading underscores ie: __gds_status and _gds_status, and wasn't concerned with those within the variable name. > >>The original fb2 ones had #defines such as: >> >>array.cpp:#define gds__status isc_status >>array.cpp:#define gds__status2 isc_status2 >> >>but the new ones dont, so it gives errors. >> > >??? The array.cpp generated for dsql should contain > >#define gds_status isc_status > >and never should gds__status be mentioned. > >Are you perhaps using an obsolete gpre? > The lines array.cpp:#define gds__status isc_status array.cpp:#define gds__status2 isc_status2 are added by gpre, to the .epp file, I assume (from what you've said) you've changed what gpre generates. Im using gpre_boot, so there may be some work todo there, but a quick grep through the gpre code brings up lots of gds__status references. I'll need to look a little further. Cheers Mark -- Your database needs YOU! http://www.firebirdSQL.org |
From: Mike N. <ta...@al...> - 2002-01-02 12:30:05
|
Mark O'Donohue wrote: > Mike Nordell wrote: > > > The wording from C++ CD1 17.3.3.1.3 was > > Each name having two consecutive underscores (2.8) is > > reserved to the implementation for use as a name with > > both extern "C" and extern "C++" linkage. I've now digged a little bit deeper, and the wording in CD2 (2.10.2) was "In addition, identifiers containing a double underscore (__) or beginning with an underscore and an upper-case letter are reserved for use by C++ implementations and standard libraries and shall not be used otherwise; no diagnostic is required.". > In other places in the code gds_ and gds__ prefixes are used to > distingish c and c++ constants (some moved to src/include/gen/codes.h). Right. Two consecutive underscores are reserved for the implementation in C++, but are not in C. /Mike |
From: Mark O'D. <mar...@lu...> - 2002-01-02 06:51:43
|
Hi Mike Mike Nordell wrote: > >>The original fb2 ones had #defines such as: >> >>array.cpp:#define gds__status isc_status >>array.cpp:#define gds__status2 isc_status2 >> >>but the new ones dont, so it gives errors. >> > >??? The array.cpp generated for dsql should contain > >#define gds_status isc_status > >and never should gds__status be mentioned. > >Are you perhaps using an obsolete gpre? > Ok found it. gds__status vs gds_status In gpre_meta_boot.cpp -lang_internal flag is used, This allows compilaton without reference to a database, used mainly in building gpre_boot. lang internal was based on c rather than c++ base so it generates gds__status references in the c_cxx.cpp file, now all the lang_internal stuff is really cpp and no longer c in fb2: There was also a lot of code tests for sw_language == lang_c or sw_language == lang_cxx mainly this is skipping comments parsing etc (about 10 references in gpre directory). Now lang_internal would not have matched either of these. I've changed all the sw_language == lang_cxx to isLangCpp(sw_language) an inline function. inline bool isLangCpp(LANG_T lang) { if (lang == lang_cxx || lang == lang_internal) { return true; } return false; } And some other issues I worked through after that. 13) g++ really requires brackets around arrays of substructures to make initialisation of arrays work. remote/allr.cpp remote/inet.cpp static const p_cnct::p_cnct_repeat protocols_to_try1[] = { {PROTOCOL_VERSION8, arch_generic, ptype_rpc, MAX_PTYPE, 2}, 14) as above with {} structures, for remote/allr.cpp but assume last "," should be deleted, or was this something special to add an extra one? .... {type_MIN, 0, 0}, } removed last comma. 15) Problem with some of the macros in src/make.new/configure/autoconf.h.in grp.h wasn't there, and I reordered the rest to match configure.in file. wait.h is no longer checked for so I removed from .h file (sys/wait.h is there). 16) in alice/alice.cpp unknown LPSTR type - now I wonder who introduced this :-), static inline void translate_cp(LPSTR sz) changed to : static inline void translate_cp(TEXT* sz) 17) A lot more initialised arrays of structures without the { } groupings. These are needed as under certain circumstances a runtime error will be generated by g++ (it's logged as an issue but not yet fixed). So wherever you have ../../src/jrd/par.cpp:79: warning: aggregate has a partly bracketed initializer it's an even chance it will cause an error. 18) Related to the above the file include/gen/codetext.h should be the one generated from the jrd/codes.epp program - which will put the brackets in for these (and the other header files that it generates) correctly. It hasn't changed from the original checkin so it will need updating. 19) The intl stuff needs to be worked through these still are .c files, and they don't parse some of the c++ stuff in dsc.h (and other files) at all. 20) The I wonder if there is a problem having an object called ld.o? Cheers Mark -- Your database needs YOU! http://www.firebirdSQL.org |
From: Claudio V. C. <cv...@us...> - 2002-01-02 07:22:39
|
> -----Original Message----- > From: fir...@li... > [mailto:fir...@li...]On Behalf Of Mark > O'Donohue > Sent: Miércoles 2 de Enero de 2002 2:52 > > 14) > as above with {} structures, for remote/allr.cpp but assume last "," > should be > deleted, or was this something special to add an extra one? > > .... > {type_MIN, 0, 0}, > } > > removed last comma. To my knowledge, required in no other place. I'm still wondering what's exactly the meaning of this phrase: THIS MODULE HAS SEVERAL KISSING COUSINS; IF YOU SHOULD CHANGE ONE OF THE MODULES IN THE FOLLOWING LIST, PLEASE BE SURE TO CHECK THE OTHERS FOR SIMILAR CHANGES: > > 18) > Related to the above the file include/gen/codetext.h should be the one > generated > from the jrd/codes.epp program - which will put the brackets in for these > (and the other header files that it generates) correctly. It hasn't > changed from the > original checkin so it will need updating. Beware that you don't waste your time by accident on files that are generated by some utilities in the msgs dir, for example. > 19) > The intl stuff needs to be worked through these still are .c > files, and they > don't parse some of the c++ stuff in dsc.h (and other files) at all. One of these days I'm gonna put my paws in dsc.h again to make some changes to the cpp version used in FB2... ;-) Seriously speaking, I think that dsc can become a struct (not a class yet) with some helper inline methods. This would help cure the need for some ugly & silly macros. For example, there's a macro to decode the charset and collation from a dsc... God forbids you from applying it by mistake to a blob, because you won't get the charset that you expect. C. |
From: Mark O'D. <mar...@lu...> - 2002-01-02 12:40:45
|
Hi Claudio Claudio Valderrama C. wrote: >>-----Original Message----- >>From: fir...@li... >>[mailto:fir...@li...]On Behalf Of Mark >>O'Donohue >>Sent: Miércoles 2 de Enero de 2002 2:52 >> >>14) >>as above with {} structures, for remote/allr.cpp but assume last "," >>should be >>deleted, or was this something special to add an extra one? >> >>.... >> {type_MIN, 0, 0}, >>} >> >>removed last comma. >> > >To my knowledge, required in no other place. I'm still wondering what's >exactly the meaning of this phrase: > >THIS MODULE HAS SEVERAL KISSING COUSINS; IF YOU > SHOULD CHANGE ONE OF THE MODULES IN THE FOLLOWING > LIST, PLEASE BE SURE TO CHECK THE OTHERS FOR > SIMILAR CHANGES: > These would be the allocate files. alice/all.cpp dsql/alld.cpp ipserver/alli.cpp jrd/all.cpp jrd/all_old.cpp pipe/allp.cpp qli/all.cpp remote/allr.cpp All very similar in design and purpose but one for ea module, perhaps function decomposition would have pointed towards having one, but as I understand the complexity also varies between them. But (and Im not sure if Im entirely right here), part of what John/Mike are doing is to replace them all with a single set. > >>18) >>Related to the above the file include/gen/codetext.h should be the one >>generated >>from the jrd/codes.epp program - which will put the brackets in for these >>(and the other header files that it generates) correctly. It hasn't >>changed from the >>original checkin so it will need updating. >> > >Beware that you don't waste your time by accident on files that are >generated by some utilities in the msgs dir, for example. > No chance of that happening :-). It's just that I modified the codes.epp program to output the correct codetext.h format about 4mths ago, I must have just never run it (or more likely forgot to check in the new output). > >>19) >>The intl stuff needs to be worked through these still are .c >>files, and they >>don't parse some of the c++ stuff in dsc.h (and other files) at all. >> > >One of these days I'm gonna put my paws in dsc.h again to make some changes >to the cpp version used in FB2... >;-) >Seriously speaking, I think that dsc can become a struct (not a class yet) >with some helper inline methods. This would help cure the need for some ugly >& silly macros. For example, there's a macro to decode the charset and >collation from a dsc... God forbids you from applying it by mistake to a >blob, because you won't get the charset that you expect. > I don't know enough about it as yet, however from my last trip through intl it was fairly simple in strucutre, and perhaps ld.c could also be upgraded to .cpp. BTW: I've got classic built, it falls over dead, building the examples ISQL Version: LI-T2.0.0.35 Firebird2 Dev1 InterBase/linux Intel (access method), version "LI-T2.0.0.35 Firebird2 Dev1" on disk structure version 10.0 SQL warning code = 301 -DATE data type is now called TIMESTAMP SQL warning code = 301 -DATE data type is now called TIMESTAMP SQL warning code = 301 -DATE data type is now called TIMESTAMP -SQL warning code = 301 -DATE data type is now called TIMESTAMP -SQL warning code = 301 SQL warning code = 301 -DATE data type is now called TIMESTAMP ** DSQL error: INTERNAL: Assertion failure: Unexpected memory block type File: ../../src/dsql/pass1.cpp Line: 3957 so I want to compare with Mike et al, to see if this is related to the changes I've made on the way through - it looks like it could easily be related to the memory allocation routines. Otherwise Im stepping through the debugger having a look to see if anything obvious catches my eye. Cheers Mark -- Your database needs YOU! http://www.firebirdSQL.org |
From: Mike N. <ta...@al...> - 2002-01-02 12:30:06
|
Mark O'Donohue wrote: > Mike Nordell wrote: > > >Are you perhaps using an obsolete gpre? > > Ok found it. Good to know. > g++ really requires brackets around arrays of substructures to make > initialisation of > arrays work. remote/allr.cpp remote/inet.cpp If my memory serves me, it is required by the standard. > as above with {} structures, for remote/allr.cpp but assume last "," > should be > deleted, or was this something special to add an extra one? > > .... > {type_MIN, 0, 0}, > } No, that one was/is an extension provided by many compilers (to allow for sloppy programming practices). > 16) > in alice/alice.cpp unknown LPSTR type - now I wonder who introduced this > :-), > > static inline void translate_cp(LPSTR sz) > changed to : > static inline void translate_cp(TEXT* sz) Ehhh *blush*, sorry? :-) I was changing a macro to an inline function, and since it's only for Win32 it does that mapping... > The I wonder if there is a problem having an object called ld.o? LOL Even if it doesn't mess with ld(1) the obvious problem is: That name says nothing about the contents of the file. Even worse, for any *nix dude/dudette a file named ld.c would obviously be the source code for ld. Right? So why is it inside a dir named "intl"? /Mike |
From: Claudio V. C. <cv...@us...> - 2002-01-01 22:13:32
|
> -----Original Message----- > From: fir...@li... > [mailto:fir...@li...]On Behalf Of Mike > Nordell > Sent: Martes 1 de Enero de 2002 11:43 > > Mark O'Donohue wrote: > > > [...] > > So that makes the correct answer to : > > > > T* memPtr() { return (T*)begin(); } > > > > as : > > T* memPtr() { return (T*) &*(begin()); } > > I fail to see the reason for the C-style cast to T*, but this is basically > correct. Isn't there an even uglier form? I could try to find one! :-) Sincerely speaking, is there a possibility to write those lines in a more pleasant way? It makes me remember some horrible code that exists in FB1. Isn't there a way to get a pointer to the internal element from the operator? Ah, don't tell me, the way to get this is by means of the "*" to mean "dereferencing", so Mark's solution is okay. But I would prefer some method that does the same than the "*" operator, so we could write instead return (T*) &begin()->internal_element(); instead. Since there's no such method, at least with vectors we could try &vector[0] The so-called intelligent pointer can't be used alone, hence it's not possible to write begin()->() :-) A question for a Byzantine discussion: the "*" op is said to return a reference to the element, right? Then why do we need (T*) in front of it? The address of a reference to type T should be a pointer to T already. For me, T* memPtr() { return &*(begin()); } should work, now tell me what's wrong with my idea. Since C++ uses strong typing, things that can't be converted won't be allowed, so no need for an explicit cast if the conversion is already legit. > > And code such as : > > > > csb_repeat* tail = csb->csb_rpt.begin(); > > > > should now become : > > > > csb_repeat* tail = &*(csb->csb_rpt.begin()); > > Iff (two f intended) we have a bunch of csb_repeat in contigous > memory (i.e. > in a vector) that would take care of it. Assuming the code didn't change meaning when converted to the STL, it should work. Ideally, we would have "tail" to be an iterator instead. The old C code assumes the compiler scratch block has a repeating structure at the tail. Only the first member of the array is inside the struct, so when the old code allocated memory for the CSB with N "repeats", it would get a full contiguous chunk where the CSB plus N-1 additional csb_repeat structs would fit. Now, is this compatible with the current layout of a vector or is there some gap between the 0th csb_repeat and the next? C. |
From: Mark O'D. <mar...@lu...> - 2002-01-02 02:13:29
|
Hi Claudio Claudio Valderrama C. wrote: >>> >>>as : >>> T* memPtr() { return (T*) &*(begin()); } >>> >>I fail to see the reason for the C-style cast to T*, but this is basically >>correct. >> > >Isn't there an even uglier form? I could try to find one! >:-) > [..snip...] >so we could write instead >return (T*) &begin()->internal_element(); > I agree, but I might wait till John has a look since it's basically his code, so he's likely to know the best thing to do here. [...snip...] > >For me, >T* memPtr() { return &*(begin()); } >should work, . > Yep - done, I just prefer to go causiously until I know what Im doing :-). > > >>>And code such as : >>> >>> csb_repeat* tail = csb->csb_rpt.begin(); >>> >>>should now become : >>> >>> csb_repeat* tail = &*(csb->csb_rpt.begin()); >>> >>Iff (two f intended) we have a bunch of csb_repeat in contigous >>memory (i.e. >>in a vector) that would take care of it. >> > >Assuming the code didn't change meaning when converted to the STL, it should >work. Ideally, we would have "tail" to be an iterator instead. The old C >code assumes the compiler scratch block has a repeating structure at the >tail. Only the first member of the array is inside the struct, so when the >old code allocated memory for the CSB with N "repeats", it would get a full >contiguous chunk where the CSB plus N-1 additional csb_repeat structs would >fit. Now, is this compatible with the current layout of a vector or is there >some gap between the 0th csb_repeat and the next? > I've left the ones like: csb_repeat* tail = &*(csb->csb_rpt.begin()); Perhaps it means looking at each usage, as Mike suggests, but Im just skipping though and don't want to change too much at the moment, till at least John thinks of something. The ones I've looked at seem fine, in that the stl is a map over a contiguious block, and in win32 (from my small prior stl experience) I've seen this sort of thing done fairly often with mapping over allocated memory blocks. Cheers Mark -- Your database needs YOU! http://www.firebirdSQL.org |
From: Claudio V. C. <cv...@us...> - 2002-01-02 02:22:07
|
> -----Original Message----- > From: fir...@li... > [mailto:fir...@li...]On Behalf Of Mark > O'Donohue > Sent: Martes 1 de Enero de 2002 22:13 > > >so we could write instead > >return (T*) &begin()->internal_element(); > > > I agree, but I might wait till John has a look since it's basically his > code, so he's likely to know the best thing to do here. This is only a dream, Mark. Such construction doesn't exist, if it didn't become clear. This is why I said in the next line that you wiped out: > Since there's no such method, at least with vectors we could try > &vector[0] So we have to stick with the "*" for dereferencing the iterator. C. |
From: Mark O'D. <mar...@lu...> - 2002-01-02 06:37:27
|
Claudio Valderrama C. wrote: >This is only a dream, Mark. Such construction doesn't exist, if it didn't >become clear. This is why I said in the next line that you wiped out: > True but for the case above with definiton of GetPtr() we can do what we want, I also guess we could create a templated function to do the conversion for the general case. template<T> T* getRawPointer(iterator<T> iter) { return &*(iter); } rather than doing a ZZ* fred = &*(vector->begin()) everywhere, which looks a little dumb. but like I said, Im guessing as to the syntax :-). Cheers Mark -- Your database needs YOU! http://www.firebirdSQL.org |
From: Mike N. <ta...@al...> - 2002-01-02 12:30:06
|
Mark O'Donohue wrote: [...] > I also guess we could create a templated function to do the > conversion for the general case. > > template<T> T* getRawPointer(iterator<T> iter) { > return &*(iter); > } Please don't. This is starting to look like an entry for IOCCC. Even if, there's no need for the parens around "iter". It's not a macro we're dealing with. :-) Also, the name should probably have been more like getEntryPtr or something like it. But since we're not going to use this function template, how's the weather? :-) > rather than doing a > > ZZ* fred = &*(vector->begin()) > > everywhere, which looks a little dumb. If you need a pointer to the first entry of a vector, you do &vector[0]; This can also be used for index 'n' like &vector[n]; It's of course more ugly when you only have a _pointer_ to a vector, but I don't think there are that many places in the code where we really _need_ a pointer to a vector. If you need to get an entry from an iterator, why not something like ZZ& fred = * vector->begin(); If there really is a function that needs a ZZ*, foo_func(&fred); /Mike |