olafvdspek / ctemplate Goto Github PK

I get this warning from the unused paramenters in MightModify

from /opt/ctemplate/include/ctemplate/template.h:48,
from Hello.cpp:8:
/opt/ctemplate/include/ctemplate/template_modifiers.h:116: warning: unused
parameter ‘per_expand_data’
/opt/ctemplate/include/ctemplate/template_modifiers.h:116: warning: unused
parameter ‘arg’ 

 virtual bool MightModify(const PerExpandData* per_expand_data,
                           const std::string& arg) const {
    return true;
  }

It will be better to get rid of the name of the unused parameters to avoid
this warnning.

 virtual bool MightModify(const PerExpandData*,
                           const std::string&) const {
    return true;
  }

What steps will reproduce the problem?
1. run .configure to get config.h
2. add files to eclipse IDE project
3. compile on ubuntu 8.04 64 bit. gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) 

What is the expected output? What do you see instead?
  compile fails.

What version of the product are you using? On what operating system?
  ubuntu 8.04 64 bit. gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) 
  Using eclipse IDE.

Please provide any additional information below.

make all 
Building file: ../source/template.cc
Invoking: GCC C++ Compiler
g++ -I"/home/jay/axion/ctemplate/source"
-I"/home/jay/axion/ctemplate/source/base"
-I"/home/jay/axion/ctemplate/source/google" -O0 -g3 -Wall -c
-fmessage-length=0 -MMD -MP -MF"source/template.d" -MT"source/template.d"
-o"source/template.o" "../source/template.cc"
In file included from
/home/jay/axion/ctemplate/source/google/template_dictionary.h:57,
                 from /home/jay/axion/ctemplate/source/google/template.h:51,
                 from ../source/template.cc:58:
/home/jay/axion/ctemplate/source/google/template_modifiers.h:289: error:
‘hash_compare’ was not declared in this scope
/home/jay/axion/ctemplate/source/google/template_modifiers.h:289: error:
template argument 3 is invalid
/home/jay/axion/ctemplate/source/google/template_modifiers.h:289: error:
expected unqualified-id before ‘,’ token
/home/jay/axion/ctemplate/source/google/template_modifiers.h:292: error:
‘DataMap’ does not name a type
In file included from /home/jay/axion/ctemplate/source/google/template.h:51,
                 from ../source/template.cc:58:

as provided the source code references missing include files.
Changed includes to
#include <ext/hash_set>
#include <ext/hash_map>

this defines hash_map but neither defines the compare operator.

Why is this project organized in such strange way, with multiple *.h.in
files which need to be preprocessed for Windows instead of a single
config.h (which would still need to be manually written for Windows but it
would be _one_ file only) included by all the files? This makes it more
painful than necessary to change anything when working under Windows as you
need to modify the .h.in file, preprocess it, test your changes, correct
them in .h.in file (and not in the .h file where the error occurs as
changes to it can't be easily backported to .h.in) and then make a patch
containing both changes.

It would be really much better if a single config.h could be used and
AFAICS there are no technical difficulties with this. I'd be willing to
provide a patch changing the build system to use config.h if you decide to
accept it.

The ctemplate is great, but I met a problem when I try to expand the
template file with large data(up to 20M).
as I know, the procedure to expand a template is to: get tpl; set dict;
expand to string buffer; write buffer to dest file.
1. when data is very large, i.e. 10M, the dict is very large
2. the expanded buffer is very large.
is it possible a dict item referring to a external file?
is it possible directly expand tpl to file instead of totally in memory?

Thanks,
Eric

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Compiling src/tests/htmlparser_test.cc fails with undefined symbols strchr,
memchr, strlen due to header cleanup in gcc-4.3.x/glibc-2.8

Furthermore the project seems to use deprecated c++ headers in various places.

The attached patch fixes the compilation failure and replaces some of the
deprecated header-files in htmlparser_test.cc by the corresponding new ones.

[ported from sourceforge, where it was submitted by sfdivan at
users.sourceforge.net]

Almost the final step is filesystem-stuff.
It's not complete, for example in what format would you prefer to use path:
os::native, posix, other?
Sad thing - we'll need to include another boost lib - boost::filesystem :)

I just started playing around with CTemplate, and I see that the examples 
are oriented toward generating HTML or related stuff. However, if we were 
to think about generating C or C++ with this tool, there would be the 
issue of comma-separated lists - for class parents, constructor init 
statements, enums, operation & template parameters, etc. Since I'm so new 
to this tool, maybe there's simple way to generate these things that I've 
overlooked, but I've so far been unable to find anything helpful in the 
examples or documentation. Of course, the application can always handle 
the comma logic and include commas or not in dictionary entries, but I 
would hope for a more elegant solution. Anybody have any ideas or see 
something I've missed?

Not that important, but should hardly take any time.

Looks like ctemplate uses a deprecated header somewhere.

In file included from /usr/include/c++/4.3/ext/hash_map:64,
                 from /usr/include/google/template_dictionary.h:55,
                 from /usr/include/google/template.h:48,
                 from /home/olaf/xcc/wol/Web Server/request_handler.cpp:6:
/usr/include/c++/4.3/backward/backward_warning.h:33:2: warning: #warning
This file includes at least one deprecated or antiquated header which may
be removed without further notice at a future date. Please use a
non-deprecated interface with equivalent functionality instead. For a
listing of replacement headers and interfaces, consult the file
backward_warning.h. To disable this warning use -Wno-deprecated.

$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --enable-targets=all --enable-cld --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1) 

$ dpkg -l|grep ctem
ii  libctemplate-dev                            0.93-1                  
This package contains a library implementing
ii  libctemplate0                               0.93-1                  
This package contains a library implementing

Only including the development packages in featured downloads isn't very
useful. I think it's better not to include them if there's not enough space
to also include the normal packages.

I have provided pkg-config support for ctemplate, to make it easier to
distribute and use this library in other projects.  Attached is a patch to
the build system against the current (as of 2008-05-02) repository.

I wasn't sure how to handle the _nothreads case, so I include two separate
pkgconfig entries.  Feel free to revise as you see fit.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

I noticed that there are no plain C bindings for this project.  Is that
something that the maintainers would be interested in?  I can provide a
patch myself, however I would prefer not to maintain it moving forward if
any APIs are added, changed, or removed.

The latest version of the library allocates template_string_set and arena
global variables in template_string.cc in AddToGlobalIdToNameMap(). This is
not really such a huge problem as these variables are only allocated once
and so, strictly speaking, it's not a memory leak but it's still annoying
when using any memory leak checker as it certainly detects it as one. This
includes the built-in MSVC CRT checker meaning that I get plenty of leak
reports (as it also finds the blocks allocated from these objects ctors)
whenever I run my application using the library.

So I fixed it in the simplest way I could think of:

--- lib/ctemplate/src/template_string.cc        (revision 316)
+++ lib/ctemplate/src/template_string.cc        (working copy)
@@ -238,6 +238,15 @@

 TemplateStringSet* template_string_set;
 UnsafeArena* arena;
+
+// Clean up the variables above when the program terminates.
+struct GlobalsCleanup {
+    ~GlobalsCleanup() {
+        delete template_string_set;
+        delete arena;
+    }
+} globalsCleanup;
+
 }  // namespace


I don't know if it would be better to provide an explicit cleanup function,
but at least this fixes the problem with memory leaks reports I had.

Thanks!

At the moment code like 1 is required. Could you add operator[] so code
like 2 can be used? It seems a lot cleaner.

int pid;
dict.SetIntValue("pid", pid); // 1
dict["pid"] = pid; // 2

Can AddSectionDictionary return NULL? If so, when does it return NULL?

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

This is more about what I did to make it work rather than a defect itself.
The goal was to compile against shared libgcc and libstdc++.dll with GCC
4.4.0 (MinGW stock). I would appreciate some assistance in figuring out why
the SCRIPTS test fails.  The two outputs look the same on-screen, but I
cannot find where these files are actually layed out on-disk for comparison.

configure was run within MSYS with default options, and the following
environment variables set:
CXXLD=gcc
LDFLAGS="-shared-libgcc -Wl,--enable-auto-import
-Wl,--enable-auto-image-base -Wl,--export-all-symbols"
LIBS="-lstdc++_s -lsupc++"

Manually edit the resulting Makefile:
set line 311 to
CXXLD=gcc
set line 427 to
PTHREAD_LIBS=-mthreads

Near line 100, add libctemplate_la-port.lo to am_libctemplate_la_OBJECTS
Repeat for am_objects_2 am_objects_3 and am_objects_4.

Near line 1215, copy the definition of libctemplate_la-template.lo to
provide a rule for libctemplate_la-port.lo depending on src/windows/port.cc

Manually edit src/config.h:
#undef HAVE_RWLOCK
#undef HAVE_PTHREAD
#define PRIdS "Id"
#define PRIuS "Iu"
#define PRIxS "Ix"

#ifndef GOOGLE_CTEMPLATE_WINDOWS_CONFIG_H
#define GOOGLE_CTEMPLATE_WINDOWS_CONFIG_H
#include "windows/port.h"
#endif

Manually edit src/windows/port.h (see attached)

Compile the project with `make -j2`.  Observe repeated warnings about
src/ctemplate/template_string.h:165 dereferencing pointer <anonymous> does
break strict-aliasing rules

Observe that libtool in its great idiocy on windows will refuse to link
DLL's against libsupc++.a. Therefore, manually link them as follows:
$ cd .libs
$ gcc -shared -shared-libgcc -mthreads -o ctemplate.dll
-Wl,--out-implib,libctemplate.a  libctemplate_la*.o -lstdc++_s -lsupc++
-Wl,--enable-auto-image-base -Wl,--enable-auto-import -Wl,--export-all-symbols
$ # Repeat for the other 3 dll configurations
$ cp *.dll ../ && cd ../

Compile and run the test suite.
Remove the check_SCRIPTS task from check-am, near line 2135. This test
fails (due to line endings?) and inhibits further testing
$ PATH=/c/Python26:$PATH make check
===================
All 18 tests passed
===================

The resulting ctemplate.dll depends on libstdc++-6.dll libgcc_s_dw2-1.dll,
mingwm10.dll, and msvcrt.dll.  I have attached all four DLLs.  The
non-debug builds have been stripped.

What steps will reproduce the problem?
1. Try to compile ctemplate on ppc

What is the expected output? What do you see instead?

Expected result is to compile correctly. Make ends with:
src/template_string.cc:120: error: 'bswap32' was not declared in this scope

What version of the product are you using? On what operating system?

ctemplate 0.93 on openSUSE Linux

Please provide any additional information below.

According to the byteswap.h correct function should be byteswap_32. Patch
attached. Tested on i686, x86_64 too.

[ported from sourceforge, where it was submitted by sfdivan at
users.sourceforge.net]

Another step to windows and other platforms port is threads, locks, and so on.
This file contains 3 alternative threads-stuff:
1) threads_no: no locking is done (but now there is no need in #ifdef
anywhere else than threads.h)
2) threads_p: original pthreads locking (but now all locks are scoped, i.e.
wrapped in a class)
3) threads_b: wrapped boost::threads, so you'll need boost::thread lib
(which is available for win of course)

This warning is reported when compiling with VS9. Removing the
Detect64BitPortabilityProblems="true" entries from the project files should
avoid this.

Issue:

It is necessary to perform a conversion of the existing VS2003 solution in
order to build in 2005.

What could fix this:

If there was a VS2005 solution and associated project files that are VS2005
specific in the tree to support developers with this version of visual
studio (and associated compiler options determined to be best)

What this patch does:
- creates a google-ctemplate-vs8.sln in the root for VS2005 users.
- creates a vs8projects folder that mirrors that of vsprojects.

This is a straight-forward transition of the existing solution.  I did not
tinker with any compiler options, so that this could be a clean starting
place for this to come to life.

How to use this patch:

1. Perform a clean check out of the following url at rev 29:
   http://google-ctemplate.googlecode.com/svn/trunk
2. Apply the patch.

You should then be able to open up the google-ctemplate-vs8.sln in visual
studio 2005 from the root of the project.

ctemlate 0.96 generates

#include <ctemplate/template_string.h>
static const StaticTemplateString kM_MenuItem =
STS_INIT_WITH_HASH(kM_MenuItem, "MenuItem", 12751148691163768839LLU);

It will be better if the is generated as

static const ctemplate::StaticTemplateString kM_MenuItem =
STS_INIT_WITH_HASH(kM_MenuItem, "MenuItem", 12751148691163768839LLU);

In that way i will be not forced to put "using namespace ctemplate;" before
include the generated file

What steps will reproduce the problem?
1. write a simple tpl including like {{DATA}}
2. prepare a very large text file test.txt with size 10MB
3. expand {{DATA}} with content from test.txt.

What is the expected output? What do you see instead?
there should be a way to replace the template items directly by writing file.
What version of the product are you using? On what operating system?
ctemplate 0.93
os: Ubuntu 8.10

Please provide any additional information below.
I'm not sure if it supports the way of writing file directly when doing the
expand.
Thanks,
Eric

It seems this needs to be in upstream. May be it is already but it would be
great if distributed tarball have these changes.


diff -Naur ctemplate-0.90.orig/src/tests/htmlparser_test.cc
ctemplate-0.90/src/tests/htmlparser_test.cc
--- ctemplate-0.90.orig/src/tests/htmlparser_test.cc    2008-08-10
15:33:53.000000000 +0200
+++ ctemplate-0.90/src/tests/htmlparser_test.cc 2008-08-10
15:35:10.000000000 +0200
@@ -62,9 +62,10 @@
 // insert_text: Executes HtmlParser::InsertText() if the argument is true.

 #include "config_for_unittests.h"
-#include <stdlib.h>
+#include <cstdlib>
 #include <ctype.h>
-#include <assert.h>
+#include <cassert>
+#include <cstring>
 #include <string>
 #include <utility>
 #include <vector>

What steps will reproduce the problem?
1. Install gcc 4.4
2. Try to compille ctemplate

What is the expected output? What do you see instead?

Program will compile ok.

What version of the product are you using? On what operating system?

Found on ctemplate 0.92, patch applies correctly on 0.93 too. Testing on
openSUSE Linux.

Please provide any additional information below.

Attached patch fixes the issue by adding missing include.

Is there cookie support for this?  Is there a mailing list or forum for 
google-ctemplate?  Thank you

Attached is 64 bit RPMs for ctemplate 0.92.

The file src/template.cc uses static_cast and reinterpret_cast incorrectly
in 2 instances as these casts can't be used to remove "const". The attached
trivial patch fixes compilation with VC8 and VC9 (a.k.a. MSVS 2005 and
2008) without any ill effects on neither g++ nor VC7 (MSVS 2003) build.

automake1.10 generates a Makefile.in that substantially differs from the
one created by 1.9, and causes failures compiling statemachine_test as a
result.  Here's a small snippet of the failure:

/bin/bash ./libtool --tag=CXX   --mode=link g++ -xc -g -O2   -o
statemachine_test statemachine_test.o statemachine_test-statemachine.o  
g++ -xc -g -O2 -o statemachine_test statemachine_test.o
statemachine_test-statemachine.o 
statemachine_test.o:1: error: stray '\177' in program
statemachine_test.o:1: error: stray '\1' in program
statemachine_test.o:1: error: stray '\1' in program
statemachine_test.o:1: error: stray '\1' in program
statemachine_test.o:1:8: warning: null character(s) ignored


I installed automake1.9 and invoked:

ACLOCAL=aclocal-1.9 AUTOMAKE=automake-1.9 autoreconf -i -s

Which generated a Makefile.in more closely matching the distributed one,
and the build succeeded.

What steps will reproduce the problem?
1. Instantiate a TemplateDictionary
2. Add a bunch of Section Dictionaries
3. Watch memory be eaten up by a lot (almost an order of magnitude more
than clearsilver's HDF, which is not very efficient itself.)

What is the expected output? What do you see instead?
    Less memory be used.  Right now, it looks like each node has more than
3k of overhead, which is a heck of a lot.

What version of the product are you using? On what operating system?
    ctemplate-0.90 on Ubuntu Linux 8.04 x64, up to date as of Jul 24, 2008.

Please provide any additional information below.

    I've attached sample code that will generate dictionaries for
clearsilver's HDF format (for comparison purposes) and ctemplate's
TemplateDictionary, as well as sample output from 'pmap -d `pidof
$EXECUTABLE_NAME`'.

    A Note from csilvers (see
http://groups.google.com/group/google-ctemplate/browse_thread/thread/9113ccc7086
8c03d
for the full thread):

    There has been some talk of changing the TemplateDictionary
constructor so that variable_dict_, section_dict_, and include_dict_
are allocated lazily, rather than always being allocated in the
constructor.  My guess -- untested -- is most of the space in a
TemplateDictionary is going to these hashtables, and lazy construction
could save about 50% of the space used.  The cost is probably low in
terms of running time.  If you'd like to play around with something
like that, feel free!  It would be nice to get both timing effects and
space effects of such a change.

When compiling a file that includes google/template.h,
I get warnings like this:
ctemplate-0.7/src/google/template_modifiers.h:169: warning: ‘class
google::template_modifiers::HtmlEscapeWithArg’ has virtual functions but
non-virtual destructor

Using g++ (g++ (GCC) 4.1.2), google-ctemplate version 0.7.

An easy fix is to add
  virtual ~TemplateModifier() {}
to template_modifiers.h at line 95.

I have code that worked fine with 0.92 and in 0.93 either refuses to
compile or if compiled refuses to run.

What steps will reproduce the problem?
1. Create main.cpp and add the following

#include <google/template_dictionary.h>
#include "template.h"

using google::Template;
using google::TemplateDictionary;

 TemplateDictionary * dict;
/*
 * 
 */
int main(int argc, char** argv)
{
    dict = new TemplateDictionary("class");

    return (EXIT_SUCCESS);
}

2. Try to compile with:
g++  -I/usr/local/include/google -lctemplate_nothreads main.cpp


What is the expected output? What do you see instead?

In 0.92 it would compile, instead with 0.93 I get the following:

/tmp/cc4izpr8.o: In function
`__static_initialization_and_destruction_0(int, int)':
main.cpp:(.text+0x28): undefined reference to
`google::StaticTemplateStringInitializer::StaticTemplateStringInitializer(google
::StaticTemplateString
const*)'
collect2: ld returned 1 exit status

With some fiddling I can get it to compile however when it does it produces
the following runtime error:

 symbol lookup error: ./dist/Debug/test: undefined symbol:
_ZN6google31StaticTemplateStringInitializerC1EPKNS_20StaticTemplateStringE

What version of the product are you using? On what operating system?
0.93 Linux - SuSe 11.1 64 bit

[ported from sourceforge, where it was submitted by sfdivan at
users.sourceforge.net]

Minimalistic patch to build under win.
Unittests won't work for win(but i've added one working test test1.cc,
derived from template_unittest.cc), and make_tpl_varnames won't work too.
Also there is no support for multithreading, and absolute paths won't work ;)

I'm happy that there is a new feature, "separator" sections, is added
to the latest version. I want a similar section call "last", which is
only shown in the last section.

I currently write a C code generator using CTemplate. I wish my
template looks like following:

{{#CODE_SEC}}
{{#CODE_SEC_seperator}} case {{CASE_NUMBER}}:{{/CODE_SEC_seperator}}
{{#CODE_SEC_last}}default:{{/CODE_SEC_last}}

...

{{/CODE_SEC}}

In tpl-mode.el
http://code.google.com/p/google-ctemplate/source/browse/trunk/contrib/tpl-mode.e
l

There's a TODO for multiline comments,

;; TODO(tonyg) Figure out a way to support multiline comments.
(defconst tpl-mode-comment "\\({{!.*?}}\\)")

The repaired line could read
(defconst tpl-mode-comment "\\({{![^}]?}}\\)")

This is known to work.

See
http://code.google.com/p/hapax2/source/browse/support/emacs/tpl-mode.el

Hope this is right place for this.  Could not find somewhere else to upload.

Attached is archive containing 64 bit ctemplate 0.93 , and
ctemplate-devel-0.93 rpms.

The file src/windows/google/per_expand_data.h contains an "#ifdef WIN32"
which is problematic because WIN32 symbol is not always defined for WIN32
applications. It is defined for the projects created in MSVC IDE by default
but not if you create the projects yourself (e.g. using a tool such as
bakefile) or if you compile from the command line. The symbol _WIN32 is,
OTOH, always predefined by the compiler (see
http://msdn.microsoft.com/en-us/library/b0084kay.aspx) so it would be
better to test for it.

Or maybe you should test for _MSC_VER and not _WIN32 at all as I think the
code using stdext::hash_map<> is completely MSVC-specific. But currently if
a MSVC project doesn't define WIN32 you get several pages of not very
intelligible warnings which is not very user-friendly.

Thanks!

What steps will reproduce the problem?
1. Perform SVN Checkout with TortoiseSVN on Windows. Repository URL:
http://google-ctemplate.googlecode.com/svn/trunk

What is the expected output? What do you see instead?
I expected to receive the latest bleeding edge CTemplate source code, but
all I got were documentation files.

What version of the product are you using? On what operating system?
I am using TortoiseSVN 1.4.1

Please provide any additional information below.
The file attached is the list of files, including the SVN files, that I got
from the checkout.

Rev: 29

Issue:  If you create a template with {{/__MAIN__}} anywhere in it, all
template processing on the template will be halted.  If this was by design,
please ignore this issue.

Note: I did not really find much documentation on __MAIN__ outside of
digging through the code.  This is where I realized __MAIN__ was special.

Recommendation: In the event that anyone was to inadvertently type this
into a template, it would probably be beneficial to have a warning issued
(unless this was done for good reason!)

Just glancing at it, I think this could probably be easily handled inside
of SectionTemplateNode::AddSubnode, case TOKENTYPE_SECTION_END.


Your thoughts?

[deleted issue]

What steps will reproduce the problem?

Maybe its only for me reproducable. Here are my configurations
1. configure ctemplate 0.96/0.95 with ./configure --enable-static
--disable-shared (Host1, Host2 (see below))

What is the expected output? What do you see instead?

I expect a wondeful well formed xml file.
The template file has following structure: (sorry that I can not show the
original template file)

TemplateDictionary -> SectionDictionary -> SectionDictionary (Show/Hide
functionality)
                                        -> SectionDictionary (Show/Hide
functionality)
                                        -> SectionDictionary (Show/Hide
functionality)
                                        -> SectionDictionary ->
SectionDictionary (Show/Hide functionality)
                   -> SectionDictionary (Show/Hide functionality) ->
SectionDictionary
In the section dicts always 1 or more vars.

What version of the product are you using? On what operating system?

ctemplate 0.95/0.96
Host 1: Linux version 2.6.27.38-170.2.113.fc10.i686 (gcc version 4.3.2
20081105 (Red Hat 4.3.2-7) (GCC) )
Host 2: Linux version 2.6.18-128.4.1.el5.centos.plus (gcc version 4.1.2
20080704 (Red Hat 4.1.2-44))

Please provide any additional information below.

The problem: When I start my program which was compiled on host 2, I get a
segmentation fault during expanding and/or dumping. On host 1, there is
absolutly no error without changing the code.

I debugged a little bit and here is a backtrace, maybe useful:

Program received signal SIGSEGV, Segmentation fault.
ctemplate::TemplateDictionary::DictionaryPrinter::DumpSectionDict
(this=0xbfd0f7ac, section_dict=@0x8e3720c)
    at
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_iter
ator.h:650
650 in
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_iter
ator.h
(gdb) backtrace
#0  ctemplate::TemplateDictionary::DictionaryPrinter::DumpSectionDict
(this=0xbfd0f7ac, section_dict=@0x8e3720c)
    at
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_iter
ator.h:650
#1  0x0812ee2c in
ctemplate::TemplateDictionary::DictionaryPrinter::DumpDictionary
(this=0xbfd0f7ac, dict=@0x8e37138) at src/template_dictionary.cc:786
#2  0x08130f86 in
ctemplate::TemplateDictionary::DictionaryPrinter::DumpSectionDict
(this=0xbfd0f7ac, section_dict=@0x8e370d0) at src/template_dictionary.cc:731
#3  0x0812ee2c in
ctemplate::TemplateDictionary::DictionaryPrinter::DumpDictionary
(this=0xbfd0f7ac, dict=@0x8ded288) at src/template_dictionary.cc:786
#4  0x081294d1 in ctemplate::TemplateDictionary::DumpToString
(this=0x8ded288, out=0xbfd0f9a8, indent=2) at src/template_dictionary.cc:731

row 826 in template_dictionary.cc: "for (DictVector::const_iterator it2 =
it->second->begin();"

I get the same error if using ctemplate 0.95

Generally:
I have six different template files which are similar to the example above.
Two of these template produce the segmentation fault but there are no
important differences
between them and the other templates. If I remove the first section
dictionary from the example above, the program runs greate, its very strange.

My template vars only consits of letters and "_". I tested the templates
without modifier too, the same error.

I have to compile the program on host 2 and there is no possibility to
update the gcc.

I hope these information are enought.

Regards, Tholmer

What steps will reproduce the problem?
1. configure and install ctemplate like this:

./configure --host=arm-none-linux-gnueabi \
            CC=${CROSS_COMPILE}gcc \
            CXX=${CROSS_COMPILE}g++ \
            AR=${CROSS_COMPILE}ar \
            RANLIB=${CROSS_COMPILE}ranlib \
            STRIP=${CROSS_COMPILE}strip
make
make install-strip

where CROSS_COMPILE is cross compiler path
2. compile example from start page (http://code.google.com/p/google-ctemplate)
3. run the example, you'll get segmentation fault at
'dict.ShowSection("IN_CA");'

What is the expected output? What do you see instead?
expected output is HTML generated from template, what I see is
"segmentation fault" message

What version of the product are you using? On what operating system?
ctemplate-0.95 on machine at91sam9260ek
os - linux 2.6.27

Please provide any additional information below.
segmentation fault is arrised because ctemplate's arena object
is first returns address not multiple of 4 from 'GetMemory'
and then uses in in 'placement new' operator like this:
new (buff) T
which is not allowed on ARM.
To fix this, it mustn't return addresses not multiple of 4, because any
address returned by an arena object could be used in 'placement new',
to fix the problem, replace:
  char* Alloc(const size_t size) {
    return reinterpret_cast<char*>(GetMemory(size, 1));
  }
with:
  char* Alloc(const size_t size) {
    return reinterpret_cast<char*>(GetMemory(size, kDefaultAlignment));
  }

What steps will reproduce the problem?
1. use template from file instead of string
2.
3.

What is the expected output? What do you see instead?
no mem leak. but using valgrind to check the status, a mem leak happened.

What version of the product are you using? On what operating system?
ctemplate: 0.93
os: ubuntu8.10
Please provide any additional information below.
in template.cc, global template_root_directory_ is allocated in
AssuredGlobalInitialized(), but looks no place to free it.
please check. maybe need an exit housekeeping action or use a smart pointer?

[ported from sourceforge, where it was submitted by sfdivan at
users.sourceforge.net]

Using that header will help to write msvc compatible port. Tested under g++
3.4.2+, msvc8 (in that case you should "#define HASH_NAMESPACE stdext" in
config.h)

What steps will reproduce the problem?
1. download the 386 deb package for a 64 bit PC
2. double click over the downloaded file
3. the lib cannot be installed: Wrong architecture 'i386'

What is the expected output? What do you see instead?
Expected output: package installed
Actual output: Wrong architecture 'i386'

What version of the product are you using? On what operating system?
version: latest
os: ubuntu hardy 64 bit

Please provide any additional information below.
N/A

Noticed the following comment in template.cc:
// TODO(csilvers): have InsertLine take a size_t

I took a stab at it and figured it would be worthwhile to trace through the
warnings suppressed by pragma 4018 as well.

[deleted issue]

What steps will reproduce the problem?
1. write a simple template replacement program from the "example" in
"howto" document.
2. run it with valgrind
3. valgrind will show a warning like this:

==23223== Mismatched free() / delete / delete []
==23223==    at 0x4024B4A: free (vg_replace_malloc.c:323)
==23223==    by 0x404F43F: google::BaseArena::~BaseArena() (arena.cc:119)
==23223==    by 0x406605C: google::UnsafeArena::~UnsafeArena() (arena.h:261)
==23223==    by 0x405FAC9:
google::TemplateDictionary::~TemplateDictionary() (template_dictionary.cc:205)
....

What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
ctemplate 0.93
os: ubuntu 8.10
Please provide any additional information below.