#ifndef extc_h_ #define extc_h_ /*************************************************************************** * extc.h * * Tue Jul 26 22:17:20 2005 * Copyright 2005 James Scully- aka jtox * jtoxification@users.sourceforge.net ****************************************************************************/ /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU Library General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ int dbgmsg=0; /* #define DEBUG_EXTC */ #define DBGMSG(X) dbgmsg?\ printf("[ Extended C message ]--------------> [ "),\ printf X ,dbgmsg:dbgmsg; #define DBGALSO(X)dbgmsg?printf X ,dbgmsg:dbgmsg; #include "phase1.h" #include "phase2.h" /* Extended C's Phase Summary: Once again, yes, I do know about C++'s extern C {#include <INSERT NAME OF C HEADER>} Extended C Phase breakdown: /* Put this stuff into a separate file ! * / Phase 1: Syntax support: Object/Constructor/Destructor/method/readonly/macros Phase 2: support for *this/*self pointer access within member functions. and support for locally created Structs.(RE: Re-implement the object registries on a per-type basis rather than one global object db, and also keep in mind that we can only __directly__refer to the object once when calling a member function, even though we can apply as many unary operators upon that single direct call as we want. Thus, using only what we know so far we can only do two operations to aid us in finding out which object called the function: some_member_of_object++ and some_member_of_object & 1 which will allow us to check only even or odd memory addresses. Technically, according to straight-up computer science, this isn't really a speedup since it still runs in O(n), but getting down to the nitty-gritty of big-o, there are always sub-classes. Not to mention the object databases separated out speeds up the registry-lookup by an almost logarithmic factor.(But it's still O(n) in regards to the # of objects per type. Also use reader-writer database design for access to the registries. Phase 3: support for functions with duplicate names as member function names. Phase 4: support for private variables: apply these within the same context as the "*this" pointer, and hide their use in the same areas. Phase 5: thread-safe/process-safe version (self-monitoring objects following the Monitor design) Phase 6: traditional inheritance (eek.) Phase 7: cast-operator overloading (very very preliminary, and minimal) Phase 8: operator-overloading (Very, very, very minimal) assumed heavily-resource-intensive due to extent of database lookup and macro calls to nullify operator and call the underlying operator-function ) However, it seems array subscript notation can be overloaded at least for primitive values and other structs Phase 9: Function overloading. (nothing too fancy.) Phase 10: CUT DOWN ON REDUNDANCY. this may mean bringing back the idea of #define prototype(object, type, name) or even worse: using function arrays in order to remove the need of defining the structname_functions type */ #endif