output formatting - Real and/or improved CForm of expressions

I'd quite like to be able to automatically generate C++ versions of certain mathematical expressions that I've manipulated in Mathematica. The resultant C++ code fragment is then going to be used independently of Mathematica.

Mathematica provides a CForm function, which almost seems like what I want, but I can't get it to do basic conversions nor tell it how to convert Mathematica symbols into my C++ identifiers.

For example, I would like the output from CForm[x[0]^2] or ToString[x[0]^2, CForm] to be "std::pow(obj.x_[0], 2)". This can be a string; it doesn't need to be usable in Mathematica any more. Of course, my actual expressions of interest are a lot more complicated than this.

But:

• I don't have a way of telling Mathematica that symbol x is to be renamed to obj.x_ (not a valid symbol name in Mathematica so can't use it directly). String manipulation after conversion is too unreliable for this so a more direct method is preferred.


• I can't tell Mathematica that x is an array, not a function, so it gives me x(0) instead of obj.x_[0].


• Mathematica thinks I want to use its own Power function, but I'd really like to use std::pow.

Perhaps CForm isn't suited to this task, but I would still appreciate a solution using any other available method if possible. I really think that Mathematica should be able to help me here, because it knows where I need brackets and so on.

I've tried:

Format[x[a_], CForm] :=
    "obj.x_[" <> ToString[a, CForm] <> "]"

Format[Power[a_, b_], CForm] := 
    "std::pow(" <> ToString[a, CForm] <> ", " <> ToString[b, CForm] <> ")"

ToString[x[0]^2, CForm]

but of course Power is protected so the second SetDelayed gives me an error, and my ToString[x[0]^2, CForm] output is really weird (Power("obj.x_[0]",2)) because I've tried to use strings in the Format.

Answer

Using SymbolicC`

I suggest to use SymbolicC. It is a very flexible and robust way to generate C (or C++) code.

It is in fact pretty easy to override the standard rules for code generation. There is a GenerateCode function in SymbolicC` package, and if you inspect it, it has a number of definitions. The one relevant here is:

GenerateCode[CExpression[SymbolicC`Private`arg_], SymbolicC`Private`opts : OptionsPattern[]] := 
 ToString[CForm[HoldForm[SymbolicC`Private`arg]]]

Since symbols like CExpression are inert (have no definitions), nothing prevents you from adding UpValues to them (but do it at your own risk, all the usual warnings about redefining some built-in functionality is in order. In particular, I would not recommend to use this simultaneously with compilation to C - but see below for the better version of this method):

CExpression /: GenerateCode[CExpression[Power[arg_, pow_]]] := 
   "std::pow(" <> ToString[arg, CForm] <> ", " <> ToString[pow, CForm] <> ")"

Now, if you call

ToCCodeString[CExpression[a^2]]

you get

(* "std::pow(a, 2)" *)

This is, of course, a rather simplistic rule, and the rule can be much more complex, but this can be a start.

ClearAll[CExpression]

Making it safer

Now, let us see what can be done to make this redefinition safer / more local. My suggestion is to construct a dynamic environment for C++ code generation:

withModifiedCCodeGenerate = 
    Function[code,
       Block[{CExpression},
           CExpression /: GenerateCode[CExpression[Power[arg_, pow_]]] := 
              StringJoin[
                 "std::pow(",

                 ToString[arg, CForm],
                  ", ",
                 ToString[pow, CForm],
                 ")"
              ];
           code
       ]
       ,
       HoldAll
    ];

Now, when you need to generate your C++ code, you call your code-generation routine within this environment:

withModifiedCCodeGenerate @ ToCCodeString[CExpression[a^2]]

This is much safer since the changes to CExpression are now localized to the execution stack of the code you run inside this environment, while the global definitions are not affected.