| 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.