Related articles |
---|
Trouble implementing a standard library -- Calling C functions from wi noitalmost@cox.net (noitalmost) (2014-03-19) |
Re: Trouble implementing a standard library -- Calling C functions fro DrDiettrich1@aol.com (Hans-Peter Diettrich) (2014-03-20) |
Re: Trouble implementing a standard library -- Calling C functions fro alexfrunews@gmail.com (2014-03-19) |
Re: Trouble implementing a standard library -- Calling C functions fro noitalmost@cox.net (noitalmost) (2014-03-21) |
From: | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
Newsgroups: | comp.compilers |
Date: | Thu, 20 Mar 2014 03:37:23 +0100 |
Organization: | Compilers Central |
References: | 14-03-049 |
Keywords: | design |
Posted-Date: | 19 Mar 2014 23:40:14 EDT |
noitalmost schrieb:
> And then have
> class CCall : public Expr
> {
> CCall(string name, vector<Expr*> params);
> string genC();
> ...
> }
>
> where, Expr is a AstNode. But CCall::genC() would be a really
> complicated list of special cases.
Right now I see a problem with Expr (lval), when the C function
expects an pointer (rval). This should be handled at least for
variables, i.e. Expr should include an hint on whether it *is* an
lval. When you produce C code, your data types already should match
the C definitions, else another transformation may be required for
passing parameters back and forth. All that should be built into Expr,
or a DataType member of Expr.
DoDi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.