Hello,<br><br>My apologies for not posting comprehensive code. My intention was only to lessen the reading burden for you. <br><br>However I must aver, despite your concerns to the contrary, taht you have already been very helpful. I have taken your advice on board, in particular concerning include order. I have hence managed, with a bit of trouble, to push through a few groups of errors.<br>
<br>I am currently getting this error: <br><br>/home/simon/College/PackageOne/src/BZip/BinaryTree.h: In function ‘SEXPREC* file354d98a8(SEXPREC*, SEXPREC*)’:<br>/home/simon/College/PackageOne/src/BZip/BinaryTree.h:8:1: error: expected primary-expression before ‘template’<br>
/home/simon/College/PackageOne/src/BZip/BinaryTree.h:8:1: error: expected ‘;’ before ‘template’<br><br><br>Apparently "expected primary-expression before ‘template’" gets flagged when a template is declared within a function. I am guessing that this might be due to using inline, which might wrap the code in a function?<br>
<br>I was getting similar errors for a Suffix Tree class, i.e.<br><br>/SuffixTree.h:47:29: error: local class ‘class file7e587564(SEXPREC*,
SEXPREC*)::SuffixTree’ shall not have static data member
‘file7e587564(SEXPREC*, SEXPREC*)::Edge file7e587564(SEXPREC*,
SEXPREC*)::SuffixTree::Edges [219001]’<br><br>This error ('local class shall not have static data member') is evidently flagged when a local class, i.e. one declared within a function, illegally holds a static variable.<br>
<br>I used a quick workaround, with a bump in big-O, with the above. Similarly here, I can specialize my template reasonably quickly - it is not too big a template.<br><br>But am I right that these errors are due to inline, in your opinion? The clear similarity is that both the class with the static variable, and the template class, are flagging errors that pertain to them being declared within a function.<br>
<br> I think I can see a quick solution, (not to use the template - I don''t need genericity here anyway,) but I would not mind to get my Suffix Tree back in the short term, so if you reckon that the error is inline-specific, I would be keen to fire ahead and make a package or use modules (which ever would be safest, i.e. most foolproof) sooner rather than later. <br>
<br>Thanks again,<br><br>Simon<br><br><br><br><br><br>
<br><br><br><br><br><br><br><br><br>
<br><div class="gmail_quote">On Tue, Oct 11, 2011 at 3:07 PM, Dirk Eddelbuettel <span dir="ltr"><<a href="mailto:edd@debian.org" target="_blank">edd@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On 11 October 2011 at 10:53, Simon Fuller wrote:<br>
| To be safe, I wrote a couple of quick codes that use the relevant includes, and<br>
| these work fine when using g++ from the terminal, so I do not think that it is<br>
| my c++ sources as such that are causing the problem, as far as I can ascertain<br>
| myself.<br>
<br>
</div>Use cxxfunction(...., verbose=TRUE) and study the generated file as well as<br>
environment variable (eg R CMD ... arguments) used. Copy and paste these<br>
arguments into a shell script to make repeated calling easier. Then modify<br>
the source to test suspected fixes.<br>
<br>
Unfortunately, include order can matter greatly. And cxxfunction() has hooks<br>
(via plugins) to include at different locations.<br>
<br>
We cannot help you __on-list__ unless you post replicable code.<br>
<div><br>
| Thanks again for all your help.<br>
<br>
</div>Pleasure, but as I said, you make it pretty hard to let us help you.<br>
<div><div></div><div><br>
Dirk<br>
<br>
--<br>
"Outside of a dog, a book is a man's best friend. Inside of a dog, it is too<br>
dark to read." -- Groucho Marx<br>
</div></div></blockquote></div><br>