சுதர்சன் சாந்தியப்பன்

ACE 5.6.7 does not compile with STLport in Windows environment (I used vc9 on Windows Server 2008) because of the following header in ACE (ACE_wrappers/ace/checked_iterator.h), which wrongly assumes the existence of stdext::checked_array_iterator in the iterator header.  A PRF is already submitted in the ACE mailing list (http://www.archivum.info/comp.soft-sys.ace/2008-07/00026/%5Bace-users%5D-Checked_iterator.h-problem-with-STLport..html)

# if defined (_MSC_VER) && (_MSC_FULL_VER >= 140050000)
// Checked iterators are currently only supported in MSVC++ 8 or better.
#  include <iterator>
# endif  /* _MSC_VER >= 1400 */

# if defined (_MSC_VER) && (_MSC_FULL_VER >= 140050000)
template <typename PTR>
stdext::checked_array_iterator<PTR>
ACE_make_checked_array_iterator (PTR buf, size_t len)
{
return stdext::checked_array_iterator (buf, len);
}
# else
template <typename PTR>
PTR
ACE_make_checked_array_iterator (PTR buf, size_t /* len */)
{
// Checked iterators are unsupported.  Just return the pointer to
// the buffer itself.
return buf;
}
# endif  /* _MSC_VER >= 1400 */

#endif  /* ACE_CHECKED_ITERATOR_H */

I need to develop a solution to it.  The easiest way to find a solution is to use some macro explicitly set by the STLport header, which is not set by any other STL libraries.  I chose to use the _STLP_ITERATOR macro set by “stl/stlport/iterator” header.

#ifndef _STLP_ITERATOR
#define _STLP_ITERATOR

# ifndef _STLP_OUTERMOST_HEADER_ID
#  define _STLP_OUTERMOST_HEADER_ID 0×38
#  include <stl/_prolog.h>
# endif

# ifdef _STLP_PRAGMA_ONCE
#  pragma once
# endif

#if defined (_STLP_IMPORT_VENDOR_STD)
# include _STLP_NATIVE_HEADER(iterator)
#endif /* IMPORT */

# ifndef _STLP_INTERNAL_ITERATOR_H
#  include <stl/_iterator.h>
# endif

# ifndef _STLP_INTERNAL_STREAM_ITERATOR_H
#  include <stl/_stream_iterator.h>
# endif

# if (_STLP_OUTERMOST_HEADER_ID == 0×38)
#  include <stl/_epilog.h>
#  undef _STLP_OUTERMOST_HEADER_ID
# endif

#endif /* _STLP_ITERATOR */

The solution is the following, where I have added the !defined(_STLP_ITERATOR) condition along with the check for Visual Studio compiler version.

# if !defined(_STLP_ITERATOR) && defined (_MSC_VER) && (_MSC_FULL_VER >= 140050000)
// Checked iterators are currently only supported in MSVC++ 8 or better.
#  include <iterator>
# endif  /* _MSC_VER >= 1400 */

# if defined (_MSC_VER) && (_MSC_FULL_VER >= 140050000)
template <typename PTR>
stdext::checked_array_iterator <PTR>
ACE_make_checked_array_iterator (PTR buf, size_t len)
{
return stdext::checked_array_iterator (buf, len);
}
# else
template <typename PTR>
PTR
ACE_make_checked_array_iterator (PTR buf, size_t /* len */)
{
// Checked iterators are unsupported. Just return the pointer to
// the buffer itself.
return buf;
}
#
endif  /* _MSC_VER >= 1400 */

#endif
/* ACE_CHECKED_ITERATOR_H */

To build (cross compilation) 32 bit C/C++ applications on 64 bit linux box, use “-m32″ as a compiler argument.  You would need the following 32bit libraries in place.

1. Install glibc.i386, glibc-devel.i386
2. Install libgcc.i386
3. Install libstdc++.i386

#include <cstdio>
#include <iostream>
main()
{
    std::cout << “C++” << std::endl;
    printf ( “long: %d\n”, sizeof(long) );
    printf ( “long long: %d\n”, sizeof(long long) );
    return 0;
}

To compile in native 64bit:
[sudar@tstsrv12 tmp]$ g++ -m64 -o out64 code.cpp

[sudar@tstsrv12 tmp]$ ./out64
C++
long: 8
long long: 8

[sudar@tstsrv12 tmp]$ ldd out64
        linux-vdso.so.1 =>  (0x00007fffc43fe000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003e7be00000)
        libm.so.6 => /lib64/libm.so.6 (0×0000000000601000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003e79e00000)
        libc.so.6 => /lib64/libc.so.6 (0×0000000000886000)
        /lib64/ld-linux-x86-64.so.2 (0×0000000000110000)

To compile in 32bit:
[sudar@tstsrv12 tmp]$ g++ -m32 -o out32 code.cpp

[sudar@tstsrv12 tmp]$ ./out32
C++
long: 4
long long: 8

[sudar@tstsrv12 tmp]$ ldd out32
        linux-gate.so.1 =>  (0×00130000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0×00133000)
        libm.so.6 => /lib/libm.so.6 (0×00223000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0024c000)
        libc.so.6 => /lib/libc.so.6 (0x0025a000)
        /lib/ld-linux.so.2 (0×00110000)

There is a Simple way to capture the MAC address of the machine in Win32 environment. In Win32, UUID (version 1) uses MAC address & timestamp as the seeds for generating the UUID.  In the UUID string, the last 6 bytes are the MAC address of the machine.  UuidCreateSequential() is the Win32 API which is used to capture the MAC address via the UUID generated by it.

#include <rpc.h>      // for UUID, UuidCreateSequential
#include <cstring>    // for memcpy
#include <algorithm>  // for std::swap

unsigned __int64
MACAddress( void ) const
{
    UUID u;
    ::UuidCreateSequential( &u );

    u.Data4[0] = u.Data4[1] = 0;

    std::swap( u.Data4[0], u.Data4[7] );
    std::swap( u.Data4[1], u.Data4[6] );
    std::swap( u.Data4[2], u.Data4[5] );
    std::swap( u.Data4[3], u.Data4[4] );

    unsigned __int64 code;
    ::memcpy( &code, &u.Data4, sizeof(u.Data4) );

    return code;
}   // MACAddress

Let me share another hack. If you want to generate strings which do not repeat themselves, you could use UuidCreate() Win32 API, which generates unique UUIDs everytime the function is called.  The UUID thus obtained can be converted to a number or a string depending upon the need, which guarantees non-repeatable ids.

When I tried building an multi-thread TUI application using wxWidgets framework, I got the following error while executing the application.

Error: Can not start thread: error writing TLS. (error 87: the parameter is incorrect.)

I was not able to reason out this behavior. I tried changing between THREAD_DETACHABLE and THREAD_JOINABLE, but was not able to get through.  When I search for hints from the web, I got the following link.

http://osdir.com/ml/lib.wxwindows.general/2004-01/msg00759.html

It was advised to create a dummy wxInitializer object so that the wxWidgets platform does the necessary initialization.  wxInitializer class is an undocumented class and called internally when a wxFrame or wxDialog based GUI application is built.  Typically, wxInitializer object is instantiated internally by the wxApp class.  Since, in my application there is no wxApp object which led to the above problem

When I dug the declaration of wxInitializer class, I found it declared at wx/init.h;  Also I found that instead of instantiating the object, we may call the following function.

extern bool WXDLLIMPEXP_BASE wxInitialize(int argc = 0, wxChar **argv = NULL);

In my application, I did the following:

main( int argc, char **argv )
{
      extern bool wxInitialize( int, char ** );
      wxInitialize( argc, argv );
      ….
      ….
}

It worked like piece of cream.

Powered by ScribeFire.

FFT (Fast Fourier Transform) is a technique by which one can perform 1D and 2D transforms on discrete data. Typically Discrete Fourier Transform is the primary application of FFT. One implementation of FFT is available at www.fftw.org. FFTW is currently available for multiple platforms including Windows and Linux.

I was looking for a framework to run FFT operation on a Windows Mobile 6 platform in native C++. Unfortunately, there are none. So, I decided to port the framework myself and indeed I was successful too. I have placed the framework at www.sudarsun.in/downloads/FFTW-3.0.1-ARMV4I.zip. It does not contain any documentation. I shall update it ASAP.