Re: Vista security


"Aaron Gray" <ang.usenet@xxxxxxxxx> wrote in message
news:5738i9F2auv1gU1@xxxxxxxxxxxxxxxxxxxxx
me, I don't use C++ much myself.

My favorite systems programming language ( not having my own).


yeah.
I typically stick with C, C being the only really "general" language I have.


one possible justification at this point is that it is doubtful I would
write a full C++ compiler, but C is simpler.

The complexities of C++ are many fold over that of C. Like its "C"
compatible at base level, plus its own grammar and gramatical ambiguities.


yes, this is a problem.


I am intending on writting my own open C++ compiler at some stage that
you can add language constructs and semantics too from the frontend. But
first I thought I should learn from the masters and port the existing
GCC C++ frontend to C++, or at least see if it is possible.


C to C++ shouldn't be all that difficult (well, unless you are doing
something drastic, like trying to rework it to use OOP style or
somesuch...).

Its just the vastness of the code. converting parser.c into lexer and
parser classes was not that bad in theoiry but getting them to compile
with all the other headers and c files is proving a nightmare.


well, yes, this is likely part of the problem.
a straight C to C in C++ conversion is likely less work, but hardly makes
good use of C++...


Its the AST "tree" thats the hard bit at the moment. Having a 'C' base
plus C++ extensions it just lots of unionized structures plus thousands of
#def'ed 'functions' which ideally become inlined fuctions. I am wondering
whether to turn the union and structs into a baseclass based affair. Its
just codinbg it all to see if it fits and thats alot of work. The semantic
checking and generation is really all in the tree AST stuff and its not
that neat and neatening it up is proving a nightmare.

Oh well its only a couple of weeks recoding if it works I have something
really great if it does not then its only a couple of weeks wasted.


yeah.
sounds like you were taking the hard route anyways...


well, in my case I am mostly working off my script compiler as a base,
every so often getting around to working on it a little more (well, in my
case, my personal life, ... takes a higher priority than coding, so it is
going slow).

Yes get some real life at your age you will not regret it. plenty of time
in later life for coding :)


yeah. talking to a female of interest (I have known since last summer, but
not really interested in persuing anything). she was in a better mood today,
then again, her truck is fixed, which may be part of it...


starting to work on modifying my compiler stage (from my script VM) to
output similar, but different, bytecode (main differences: C needs types,
everywhere, differences wrt opcode structure, jumps, ...).

in my case, for this compiler there will be no interpreter, rather it
will be JIT-only (the JIT being responsible for a lot of the low-level
optimizations). I eventually opted with making the bytecode focus on a
stack machine for simplicity reasons.

Yes keep it simple make it complex later ! The devil is in the details,
but do delay envoking the devil for that is a deal that is hard to
reverse.

Dont over complicate code too early for efficiencies sake, dont take false
ecconomies too early. Prfilling can be the best way to see where to put
the cdoing effort for speeding up bottlenecks when you want to optimize
your code base.


yeah.

getting something like a C compiler written is a task in itself...


in some places I changed the workings of the bytecode for JIT-related
reasons (for example, all vars, labels, ... are now referenced
indirectly/symbolically, rather than with scope-indices, relative
offsets, ...). this saves some on needing to regenerate this info.

right, the right targetting at earlier stages in the pipeline can prove a
good choice (waffle).

I am going to fork my code base, back track and see if I can get GCC
compiling as C++ with little effort then if that works that will smooth
over and speed up my currect coding problems and then I can remerge my C++
efforts on the parser and lexer back in and end up with something that may
compile and hopefully run...

or such....


yeah.


Aaron




.

Relevant Pages

  • Re: Programming careers
    ... writers for any language 'X', ... Yeah, I am being semantically sloppy and using the term ... "compiler" to cover a much wider range of possibilities... ...
    (rec.arts.sf.composition)
  • Re: CFO: Why C?
    ... Yeah, I think so. ... Well, C's syntax is pretty machine-like, so it's quite easy to turn decent C ... into reasonably efficient assembly language. ... compiler does a pretty smooth job, ...
    (comp.os.linux.development.apps)
  • Re: help need in develop dll for use in pocket pc
    ... Yeah, you'll have to make some decisions. ... I think the Dinkumware library (w/ STL) is around $600. ... Intel has a compiler for eVC which is better than the one ...
    (microsoft.public.pocketpc.developer)
  • Re: 0xdeadbeef vs 0xdeadbeefL
    ... compiler doesn't error about it is because it's not an error. ... If you want unsigned chars don't be lazy, ... Yeah it uses LibTomCrypt. ...
    (Linux-Kernel)
  • Re: Why 64bit Delphi compiler from Borland may be meaningless!
    ... why would AN ENTIRE CUSTOMER BASE of Win32 Delphi code want to ... Yeah this is ... its easier to imagine that the Delph customer base would rather ... Everybody knows writing and maintaining a robust code base is the CHEAP part ...
    (borland.public.delphi.non-technical)