Also if export templates are supported, the compilation process
becomes slightly more complicated.
http://www.comeaucomputing.com/4.0/docs/userman/export.html
Comeau C++ Export Overview
The export templates supported since 2003 on Comeau C++ compiler, the
first and foremost standard compiler except for sometimes the KAI
front end
The export templates, they generate templates and then save them to a
file and are compiled around the functions.
You can redefine the templates to compile them, then generate a stage
wait and write them.
http://www.pgroup.com/products/workpgcc.htm
The Portland Group
Portland group makes C++ compilers. Ah, they are using the CHARMM API
on their parallel functions, it is a parallel programming API which
IBM solved in the 90s.
KAI compiler.
http://www.fnal.gov/docs/products/kai/
How do you put the ref trait on the?
oh, just the type, put the ref trait on the type
&this is a pointer, it's the pointer to this, which is a pointer.
The export templates are generating templates, imagine off the
reference. They can generate the reference actually to a file with
translation and then its later executed. That helps as a convention
for using the system filename expansions to parameterize the command
line flow because if the file is loaded into the standard tools
semantics are free.
That's about, where the template files are generated on the
compilation step, then a file can be included several times. Then,
the idea is to find the plain old data strings that have standard C++
strings instead of or any combination of references and pointer
indirection with the reference chain on the stack, to strings, and
built-in types, also flat reference types through name resolution over
the compiled template generation, redefining and canceling their types
to the built-in types. Also that technique exhausts the loop-free
generation of the resolution of typedefs to built-in types.
Then, in a later compilation step, the template files that were
emitted are sitting there with the templates defined in the other
files that were canceled on compilation.
Imagine this, for example. The C++ stack is automatic about the
objects, you can add to the object's interface and pass them through
the standard APIs with the object's interface when they are allocated
naturally on the stack with the stack layout of the object
accomodating, particularly with source translation, where all the
object's sizes are the same. Then, it's nice where the programming
interfaces can be programmed directly in the C++ in a portable and
standard way. Then, passing the objects to binary incompatible APIs
simply truncates them. The templates would be generating the source
modifiers where then there is function prolog / epilog then some
consideration of the composable actuators with the hand source
activation over feature groups, with typing shift 1.
About calling them, they are instrumented when they enter and leave
the standard APIs, the keys, so the idea is to carry over the template
logic and function descriptor, the argument types, without
instrumenting, canceling the templates. Basically, it is just this,
the object in the code is on the stack with its function pointers
right under the object pointer. Then it's class fields are under
that. The static fields and functions are in the object pointer, with
static variables. For example the 32-bit integer is the natural or
word type on the 32-bit processor. So the default int is four bytes
because sizeof char is 1, of course in the standard C++, the int type
is only guaranteed sizeof(int) >= sizeof(char). (Of course, sizeof
has various semantics, sizeof(1), sizeof 1, etcetera, or does it not,
in C++? It does, but, I don't think it's being overloadable, it's
evaluated as a keyword and a built-in function.)
Then, the explore templates don't necessarily resolve to some string
in the export template file like #ifdef #define, writing include files
out of the preprocessed template output. Hmm... now I wonder how to
have the export template mechanism generate include files for
compilation steps. No, that would be abuse of the template generation
mechanism. How about template logic reading macros?
All seemingly supported in C++.
The export templates then I wonder how to have other compilation units
in the module not wait on, on recompiles. The other compilation units
should use the modules whose definition is satisfied link-time of the
template, so if there's only one pass to generate all the templates,
they should be generated before are generated the other files that
will use them in their environment. The idea is that the attributed
types are used to automatically generate the convention matching data
structures off of the primitive and object types, and having them
share a memory allocator. That way, the user code has automatic
semantics, for example it works well with copy-constructable and other
concepts, as in concepts, or a suitable function can be generated out
of the definition of the categories of types and then observing static
typing of objects in and out of interfaces. Yet, consider where the
templates were unsatisfied, for example generating incompatible data
formats for the API functions. That is where, a char* or C++
std::string is used as a pointer to the beginning of a string, which
is a string of numbers, letters, other values including spaces,
invisible characters, well maybe not those, the C language standard
string as used by its standard string API operates on the pointer as a
local variable of the function. To find the end of the C string, look
at each next character until it is zero, then return the count.
That's among reasons why often algorithms on strings process the
characters before reaching the end. The ownership by functions that
is the content of the strings here is considered around redefinition
of C and C++ types, yet templates can't overload some semantics of
built-in scalar types, and redefining keywords is undefined.
Then the C++ export templates don't even need this
What is the point of this? Here the idea is how to have the in-place
allocator, basically it is around final classes because it's
convenient for the in-place allocator to be simply nesting on the
addition of the nestings over the template compilation levels, so they
can themselves be final classes in their layout. Then, in seems that
this is quite clear and I must implement some of these templates and
discover support.
"Exported templates are templates declared with the keyword export.
Exporting a class template is equivalent to exporting each of its
static data members and each of its non-inline member functions. "
Oh, sometimes the const references should be returned, other
times, .... never return a reference to a local variable, what unless
it's a leaf because the caller keeps it? How about on the stack with
the nested class bodies on the general class layout compositor. What
is that supposed to mean, class layout compositor? It is about
maintaining the types together, they're related types, and passing
into the API the core of the class body, figuring where class
definitions would be interleaved and deinterleaved in API call chains
to pass small vectors of primitives from embodied types.
(One thing I wonder is, how to I use sizeof and offsetof using indices
instead of identifiers?)
Then, build conditions, that are correctedon the recompiles that
maintain canceling the build cancel on maintaining the satisfaction of
selectively-compile time large template generators that are automatic
off of the structure definition in source code so by including the
header file with the struct is objectified with cross pointers in
compositional and behavioral inheritance. Sometimes it's more
convenient to have the object be a state machine and have its type
change as its state changes. It's also convenient where the types are
identical to multiple APIs, ie, types maintaining multiple semantics,
in their natural layout where the object allocator and in-place build
of the functions and the fields doesn't prevent .
Make a program, watch a file, each time it's accessed.
Anyways this is to be about making some lean templates that help to
accomplish the automatic input stream compositor. So, am wanting an
object layou in a class definition of new for an extension to istream
that I want to use with the standard library APIs with the native
objects.
template <class C> class extender()
{
operator new(size_t s); // allocate this objects with setting up the
references
// this object doesn't have a body yet, it is just the class
{
}
operator new(size_t s, void* place) // I want automatic placement
operators for the extenders of the standard class
{
}
// operator new[]
// operator new[] ...
operator delete(extender<C>* pC);
operator delete(extender<C>* pC);
// layout the extended C and re-seat references to the
private C member;
C& operator(){} // type converter narrows type
}
Those new and delete functions have both local and global ones, so
then they can be called in scope, and sometimes use more compile-time
features.
Sometimes the definition of new and delete would be better in the
inline constructor file, other times its body is better outside the
constructor.
Then, how can the object extended<C> be exactly the same object for
it's call to be typeconverted to C, and used in-place like a C.
Overload the type converter, then the compiler will pick up the
template .
Now, the type can be used with standard APIs with simply extending the
type. Also it can be used with standard functions that use the type,
where the iterators don't go over the pointers. That is basically
about how to use with them standard containers that have fixed widths
on the sizes of the elements. Here there is source availability of
the interchange types, but only binary access to the fixed-sized
record handling standard algorithm. Lots of functions take const
references, then where goes the copy in multiplying the type? It's
kind of pointless to worry when the subclass can be written to go
through, idea here is to transparently pass extenders and extensions
not just through source libraries without modifying the code, but also
to binary libraries.
Thats about then functions that use it preserve its layout, where it
can be inferred that the object is not copied around, i.e. exactly in
const reference chains. Also, it's kind of focused on a particular
nested layout. That's where, I have, for example, that works on
iostreams, or any functional interface, and I want to automatically
generate code within software projects that generates code and helps
convert software projects to using standard libraries with standard
APIs.
What's the point about input and input stream? It is that I want to
use expressive types like specification and have it do what, exactly,
that isn't available right from with standard C++ inheritance of
function from the base class and simply pass the derived class,
maintained in its body, and when the functions are done on the object
it's still a perfectly serviceable extension object. It might just
have addended fields in the definition, yet when an object is supposed
to work as of multiple types, where the extenders can compose in their
order through the interface levels, the multiple inheritance is
implemented in various ways in C++ but it is so implemented.
http://www-plan.cs.colorado.edu/diwan/class-papers/mi.pdf
Then, it's the consideration of like a union type, yet with the
layouts nested instead of consequent.
What is this then about altering the multiple inheritance layout?
Hmm... it is to be keeping the compositing extractor and inserters as
part of the istream body, why? So it goes through standard APIs
normally, the istream, where it is directed by the templates.
I keep wondering about immediate applications off of the small
builder, what about this, the organization of the parser components on
the input stream, they are these input streams that maintain state of
the objects, recording and sharing constancy of input to advise data
transfer.
Then, who care if they are in standard containers or using standard I/
O semantics for unstructured data. Really it is about the string and
data semantics, particularly with so much code.
Maybe exhaustively templates could generate items off of each
predefined type to go over the input files by catting in the file read
into the headers of the file in setting up a compiler facility, where
the verbose templates are generated for the concise structures.
Then, about following chains in the input block in templates, idea
here is to maintain the seated class reference in its native library
that is as well the seated extension reference. Why, is it not
already? The types aren't clearly composable at run-time, then just
usable as such with the standard APIs, eg
mix<class c1, class c2, class c3, ...> in
// has two totally separate implementations
in = new string;
in = new ifstream(input_file_spec); // <- same object, two different
objects
Yet, then that template, what about those types? That is where the
istream is a string, to be read because as a generic source of data it
fits into algorithms with the istream, besides that the content of the
string and its input read might be similar. Yet, as totally different
classes mixed:
mix < istream& i, record& r > in;
const istream& function_return_const_ref()
{
mix<istream, record>
return in;
}
Then that would be a generated function. In C++, it doesn't matter
that the object with single-inheritance as it goes though the API as a
reference has an expanded definition of semantics.
Then, it should build up the statistics.
The vtables can be synthesized with then standard semantics about the
objects, with offsets serialized into the program of leaf functions
and loop bodies.
Here the notion is to statically generate and cache composable
function bodies, so the vtable pointers of the class are patched to
them, where they are laid out in a library offset that runs out state
trees on the vtable evaluations.
Then, want the object layout to relax.
So, the template should have lots of type information about using
mostly the type, the template is to be instrumentable in general
terms. The idea is to get a way to include template around the
standard definitions, and around each of the definitions of
structures, and as well classes and so on. Also it is about the
generation of this static work-reduction that uses the collected
results quite generally in its algorithm, the containers on operations
are to maintain the static statistics about generating the runtime
profiling of the code. It's suppose to be compilable in that way,
hopefully even without including the header, just leaving it around
the project.
Now, the C++ class composes naturally. There is a consideration, in
layout out data together, about making it into the records. Then for
those there are generally fields, but also they should be the more
concise when normalization yields a field reference per field in the
record, for making the record concise.
Then, in simply extending classes, what about where what matters is
the default type of the class. Yet, then in dynamic casting the
class, the pointers differ. Swapping the class blocks as the cast.
Problems with casting the base class back to the derived class, on
recall of interface items, instrumenting standard code.
Nice pattern, with the objects chaining up their invocations, that's
composition, for the multiply typed object to call each contained
object's method when they share the composed state, that could be
stored in the default layout.
Something like, adding constructor and destructors, modifying behavior
of new and delete at runtime, statically.
http://www-plan.cs.colorado.edu/diwan/class-papers/mi.pdf
Stroustrup's paper about the implementation of the static and virtual
inheritance in C++ really makes a lot of sense.
Thank you,
Ross F.
