#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