mirror/eigen
2
0
Fork 0
mirror of https://gitlab.com/libeigen/eigen.git synced 2024-12-21 07:19:46 +08:00
Code Issues Packages Projects Releases Wiki Activity
734469e43f
eigen/test/dynalloc.cpp

148 lines
4.1 KiB
C++
Raw Normal View History

Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
// This file is part of Eigen, a lightweight C++ template library
remove sentence "Eigen itself is part of the KDE project." it never made very precise sense. but now does it still make any?
2009-05-23 02:25:33 +08:00
// for linear algebra.
Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
//
email change
2010-06-25 05:21:58 +08:00
// Copyright (C) 2008 Gael Guennebaud <gael.guennebaud@inria.fr>
Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
//
// Eigen is free software; you can redistribute it and/or
// modify it under the terms of the GNU Lesser General Public
// License as published by the Free Software Foundation; either
// version 3 of the License, or (at your option) any later version.
//
// Alternatively, you can redistribute it and/or
// modify it under the terms of the GNU General Public License as
// published by the Free Software Foundation; either version 2 of
// the License, or (at your option) any later version.
//
// Eigen is distributed in the hope that it will be useful, but WITHOUT ANY
// WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
// FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License or the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU Lesser General Public
// License and a copy of the GNU General Public License along with
// Eigen. If not, see <http://www.gnu.org/licenses/>.
#include "main.h"
let the user disable alignment altogether by #defining EIGEN_DONT_ALIGN. Until now, the user had to edit the source code to do that. Internally, add EIGEN_ALIGN that takes into account both EIGEN_DONT_ALIGN.and EIGEN_ARCH_WANTS_ALIGNMENT. From now on, only EIGEN_ALIGN should be used to test whether we want to align.
2009-05-03 21:50:56 +08:00
#if EIGEN_ALIGN
disable alignment altogether outside of the platforms which potentially have SSE or AltiVec This should remove most portability issues to other platforms where data alignment issues (including overloading operator new and new[]) can be tricky, and where data alignment is not needed in the first place.
2009-02-05 00:53:03 +08:00
#define ALIGNMENT 16
#else
#define ALIGNMENT 1
#endif
* implement handmade aligned malloc, fast but always wastes 16 bytes of memory. only used as fallback for now, needs benchmarking. also notice that some malloc() impls do waste memory to keep track of alignment and other stuff (check msdn's page on malloc). * expand test_dynalloc to cover low level aligned alloc funcs. Remove the old #ifdef EIGEN_VECTORIZE... * rewrite the logic choosing an aligned alloc, some new stuff: * malloc() already aligned on freebsd and windows x64 (plus apple already) * _mm_malloc() used only if EIGEN_VECTORIZE * posix_memalign: correct detection according to man page (not necessarily linux specific), don't attempt to declare it if the platform didn't declare it (there had to be a reason why it didn't declare it, right?)
2009-01-09 22:56:44 +08:00
void check_handmade_aligned_malloc()
{
for(int i = 1; i < 1000; i++)
{
char *p = (char*)ei_handmade_aligned_malloc(i);
disable alignment altogether outside of the platforms which potentially have SSE or AltiVec This should remove most portability issues to other platforms where data alignment issues (including overloading operator new and new[]) can be tricky, and where data alignment is not needed in the first place.
2009-02-05 00:53:03 +08:00
VERIFY(size_t(p)%ALIGNMENT==0);
* implement handmade aligned malloc, fast but always wastes 16 bytes of memory. only used as fallback for now, needs benchmarking. also notice that some malloc() impls do waste memory to keep track of alignment and other stuff (check msdn's page on malloc). * expand test_dynalloc to cover low level aligned alloc funcs. Remove the old #ifdef EIGEN_VECTORIZE... * rewrite the logic choosing an aligned alloc, some new stuff: * malloc() already aligned on freebsd and windows x64 (plus apple already) * _mm_malloc() used only if EIGEN_VECTORIZE * posix_memalign: correct detection according to man page (not necessarily linux specific), don't attempt to declare it if the platform didn't declare it (there had to be a reason why it didn't declare it, right?)
2009-01-09 22:56:44 +08:00
// if the buffer is wrongly allocated this will give a bad write --> check with valgrind
for(int j = 0; j < i; j++) p[j]=0;
ei_handmade_aligned_free(p);
}
}
void check_aligned_malloc()
{
for(int i = 1; i < 1000; i++)
{
char *p = (char*)ei_aligned_malloc(i);
disable alignment altogether outside of the platforms which potentially have SSE or AltiVec This should remove most portability issues to other platforms where data alignment issues (including overloading operator new and new[]) can be tricky, and where data alignment is not needed in the first place.
2009-02-05 00:53:03 +08:00
VERIFY(size_t(p)%ALIGNMENT==0);
* implement handmade aligned malloc, fast but always wastes 16 bytes of memory. only used as fallback for now, needs benchmarking. also notice that some malloc() impls do waste memory to keep track of alignment and other stuff (check msdn's page on malloc). * expand test_dynalloc to cover low level aligned alloc funcs. Remove the old #ifdef EIGEN_VECTORIZE... * rewrite the logic choosing an aligned alloc, some new stuff: * malloc() already aligned on freebsd and windows x64 (plus apple already) * _mm_malloc() used only if EIGEN_VECTORIZE * posix_memalign: correct detection according to man page (not necessarily linux specific), don't attempt to declare it if the platform didn't declare it (there had to be a reason why it didn't declare it, right?)
2009-01-09 22:56:44 +08:00
// if the buffer is wrongly allocated this will give a bad write --> check with valgrind
for(int j = 0; j < i; j++) p[j]=0;
ei_aligned_free(p);
}
}
void check_aligned_new()
{
for(int i = 1; i < 1000; i++)
{
float *p = ei_aligned_new<float>(i);
disable alignment altogether outside of the platforms which potentially have SSE or AltiVec This should remove most portability issues to other platforms where data alignment issues (including overloading operator new and new[]) can be tricky, and where data alignment is not needed in the first place.
2009-02-05 00:53:03 +08:00
VERIFY(size_t(p)%ALIGNMENT==0);
* implement handmade aligned malloc, fast but always wastes 16 bytes of memory. only used as fallback for now, needs benchmarking. also notice that some malloc() impls do waste memory to keep track of alignment and other stuff (check msdn's page on malloc). * expand test_dynalloc to cover low level aligned alloc funcs. Remove the old #ifdef EIGEN_VECTORIZE... * rewrite the logic choosing an aligned alloc, some new stuff: * malloc() already aligned on freebsd and windows x64 (plus apple already) * _mm_malloc() used only if EIGEN_VECTORIZE * posix_memalign: correct detection according to man page (not necessarily linux specific), don't attempt to declare it if the platform didn't declare it (there had to be a reason why it didn't declare it, right?)
2009-01-09 22:56:44 +08:00
// if the buffer is wrongly allocated this will give a bad write --> check with valgrind
for(int j = 0; j < i; j++) p[j]=0;
ei_aligned_delete(p,i);
}
}
void check_aligned_stack_alloc()
{
for(int i = 1; i < 1000; i++)
{
float *p = ei_aligned_stack_new(float,i);
disable alignment altogether outside of the platforms which potentially have SSE or AltiVec This should remove most portability issues to other platforms where data alignment issues (including overloading operator new and new[]) can be tricky, and where data alignment is not needed in the first place.
2009-02-05 00:53:03 +08:00
VERIFY(size_t(p)%ALIGNMENT==0);
* implement handmade aligned malloc, fast but always wastes 16 bytes of memory. only used as fallback for now, needs benchmarking. also notice that some malloc() impls do waste memory to keep track of alignment and other stuff (check msdn's page on malloc). * expand test_dynalloc to cover low level aligned alloc funcs. Remove the old #ifdef EIGEN_VECTORIZE... * rewrite the logic choosing an aligned alloc, some new stuff: * malloc() already aligned on freebsd and windows x64 (plus apple already) * _mm_malloc() used only if EIGEN_VECTORIZE * posix_memalign: correct detection according to man page (not necessarily linux specific), don't attempt to declare it if the platform didn't declare it (there had to be a reason why it didn't declare it, right?)
2009-01-09 22:56:44 +08:00
// if the buffer is wrongly allocated this will give a bad write --> check with valgrind
for(int j = 0; j < i; j++) p[j]=0;
ei_aligned_stack_delete(float,p,i);
}
}
Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
// test compilation with both a struct and a class...
the big memory changes. the most important changes are: ei_aligned_malloc now really behaves like a malloc (untyped, doesn't call ctor) ei_aligned_new is the typed variant calling ctor EIGEN_MAKE_ALIGNED_OPERATOR_NEW now takes the class name as parameter
2009-01-08 23:20:21 +08:00
struct MyStruct
Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
{
EIGEN_MAKE_ALIGNED_OPERATOR_NEW didn't actually need to get the class name as parameter
2009-01-08 23:37:13 +08:00
EIGEN_MAKE_ALIGNED_OPERATOR_NEW
Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
char dummychar;
Vector4f avec;
};
the big memory changes. the most important changes are: ei_aligned_malloc now really behaves like a malloc (untyped, doesn't call ctor) ei_aligned_new is the typed variant calling ctor EIGEN_MAKE_ALIGNED_OPERATOR_NEW now takes the class name as parameter
2009-01-08 23:20:21 +08:00
class MyClassA
Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
{
public:
EIGEN_MAKE_ALIGNED_OPERATOR_NEW didn't actually need to get the class name as parameter
2009-01-08 23:37:13 +08:00
EIGEN_MAKE_ALIGNED_OPERATOR_NEW
Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
char dummychar;
Vector4f avec;
};
template<typename T> void check_dynaligned()
{
T* obj = new T;
disable alignment altogether outside of the platforms which potentially have SSE or AltiVec This should remove most portability issues to other platforms where data alignment issues (including overloading operator new and new[]) can be tricky, and where data alignment is not needed in the first place.
2009-02-05 00:53:03 +08:00
VERIFY(size_t(obj)%ALIGNMENT==0);
Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
delete obj;
}
void test_dynalloc()
{
* implement handmade aligned malloc, fast but always wastes 16 bytes of memory. only used as fallback for now, needs benchmarking. also notice that some malloc() impls do waste memory to keep track of alignment and other stuff (check msdn's page on malloc). * expand test_dynalloc to cover low level aligned alloc funcs. Remove the old #ifdef EIGEN_VECTORIZE... * rewrite the logic choosing an aligned alloc, some new stuff: * malloc() already aligned on freebsd and windows x64 (plus apple already) * _mm_malloc() used only if EIGEN_VECTORIZE * posix_memalign: correct detection according to man page (not necessarily linux specific), don't attempt to declare it if the platform didn't declare it (there had to be a reason why it didn't declare it, right?)
2009-01-09 22:56:44 +08:00
// low level dynamic memory allocation
CALL_SUBTEST(check_handmade_aligned_malloc());
CALL_SUBTEST(check_aligned_malloc());
CALL_SUBTEST(check_aligned_new());
CALL_SUBTEST(check_aligned_stack_alloc());
Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
for (int i=0; i<g_repeat*100; ++i)
{
big huge changes, so i dont remember everything. * renaming, e.g. LU ---> FullPivLU * split tests framework: more robust, e.g. dont generate empty tests if a number is skipped * make all remaining tests use that splitting, as needed. * Fix 4x4 inversion (see stable branch) * Transform::inverse() and geo_transform test : adapt to new inverse() API, it was also trying to instantiate inverse() for 3x4 matrices. * CMakeLists: more robust regexp to parse the version number * misc fixes in unit tests
2009-10-29 06:19:29 +08:00
CALL_SUBTEST(check_dynaligned<Vector4f>() );
CALL_SUBTEST(check_dynaligned<Vector2d>() );
CALL_SUBTEST(check_dynaligned<Matrix4f>() );
CALL_SUBTEST(check_dynaligned<Vector4d>() );
CALL_SUBTEST(check_dynaligned<Vector4i>() );
Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
}
// check static allocation, who knows ?
{
disable alignment altogether outside of the platforms which potentially have SSE or AltiVec This should remove most portability issues to other platforms where data alignment issues (including overloading operator new and new[]) can be tricky, and where data alignment is not needed in the first place.
2009-02-05 00:53:03 +08:00
MyStruct foo0; VERIFY(size_t(foo0.avec.data())%ALIGNMENT==0);
MyClassA fooA; VERIFY(size_t(fooA.avec.data())%ALIGNMENT==0);
Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
}
// dynamic allocation, single object
for (int i=0; i<g_repeat*100; ++i)
{
disable alignment altogether outside of the platforms which potentially have SSE or AltiVec This should remove most portability issues to other platforms where data alignment issues (including overloading operator new and new[]) can be tricky, and where data alignment is not needed in the first place.
2009-02-05 00:53:03 +08:00
MyStruct *foo0 = new MyStruct(); VERIFY(size_t(foo0->avec.data())%ALIGNMENT==0);
MyClassA *fooA = new MyClassA(); VERIFY(size_t(fooA->avec.data())%ALIGNMENT==0);
Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
delete foo0;
delete fooA;
}
// dynamic allocation, array
const int N = 10;
for (int i=0; i<g_repeat*100; ++i)
{
disable alignment altogether outside of the platforms which potentially have SSE or AltiVec This should remove most portability issues to other platforms where data alignment issues (including overloading operator new and new[]) can be tricky, and where data alignment is not needed in the first place.
2009-02-05 00:53:03 +08:00
MyStruct *foo0 = new MyStruct[N]; VERIFY(size_t(foo0->avec.data())%ALIGNMENT==0);
MyClassA *fooA = new MyClassA[N]; VERIFY(size_t(fooA->avec.data())%ALIGNMENT==0);
Solve a big issue with data alignment and dynamic allocation: * add a WithAlignedOperatorNew class with overloaded operator new * make Matrix (and Quaternion, Transform, Hyperplane, etc.) use it if needed such that "*(new Vector4) = xpr" does not failed anymore. * Please: make sure your classes having fixed size Eigen's vector or matrice attributes inherit WithAlignedOperatorNew * add a ei_new_allocator STL memory allocator to use with STL containers. This allocator really calls operator new on your types (unlike GCC's new_allocator). Example: std::vector<Vector4f> data(10); will segfault if the vectorization is enabled, instead use: std::vector<Vector4f,ei_new_allocator<Vector4f> > data(10); NOTE: you only have to worry if you deal with fixed-size matrix types with "sizeof(matrix_type)%16==0"...
2008-09-03 08:32:56 +08:00
delete[] foo0;
delete[] fooA;
}
}
Reference in New Issue Copy Permalink