C / C++ / MFC

Re: read a name .left .right

17-May-06 10:35

yes, there is. it's called "Right"

but you still need to know how long the string is, because GetAt, Left, Right and Mid will all fail if you try to get characters past the end of the string.

Cleek | Image Toolkits | Thumbnail maker

Immunity1817-May-06 10:39

Immunity18

17-May-06 10:39

oh i got ur point, thanks very much Smile | :)

Declarations

koumodaki17-May-06 8:24

koumodaki

17-May-06 8:24

Hi Can some one please explain me the following...not the MSDN defination please
STDMETHODCALLTYPE
__export
__declspec

-- modified at 14:25 Wednesday 17th May, 2006

Re: Declarations

David Crow17-May-06 10:06

David Crow

17-May-06 10:06

koumodaki wrote:
STDMETHODCALLTYPE

If you are even remotely familar with the preprocessor, this should explain it:

#ifdef _WIN32   // Win32 doesn't support __export
   #define STDMETHODCALLTYPE     __stdcall
#else
   #define STDMETHODCALLTYPE     __export __stdcall
#endif

koumodaki wrote:
__export

__declspec(dllexport) allows you to export functions, data and objects.

"The largest fire starts but with the smallest spark." - David Crow

how to detect endianness of a machine ?

big_denny_20017-May-06 6:50

big_denny_200

17-May-06 6:50

in the easiest way ?

Using c++.

thank you.

-- modified at 12:50 Wednesday 17th May, 2006

C^hris L^osinger17-May-06 7:20

17-May-06 7:20

<br />
        uint32_t value; <br />
        int i; <br />
        uint8_t *cptr = (uint8_t *)&value; <br />
<br />
<br />
        /* Write 0x01020304 to value in big-endian mode */ <br />
<br />
<br />
        for (i = 0; i < sizeof(uint32_t); i++) <br />
                cptr[i] = i + 1; <br />
<br />
<br />
        /* Now see how it reads back in native endian mode */ <br />
<br />
<br />
        switch (value) { <br />
        case 0x01020304:                  /* The only sensible way ;) */ <br />
                printf("32 bit int is big-endian\n"); <br />
                break; <br />
<br />
<br />
        case 0x04030201: <br />
                printf("32 bit int is little-endian about 8 bits\n"); <br />
                break; <br />
<br />
<br />
        case 0x03040102: <br />
                printf("32 bit int is little-endian about 16 bits\n"); <br />
                break; <br />
<br />
<br />
        default: <br />
                printf("I don't understand the result\n"); <br />
                break; <br />
        } <br />

google[^]

Cleek | Image Toolkits | Thumbnail maker

Jörgen Sigvardsson17-May-06 9:04

17-May-06 9:04

Hmm.. isn't detecting the endianess at runtime a bit too late? Unsure | :~

--
100% natural. No superstitious additives.

C^hris L^osinger17-May-06 9:25

17-May-06 9:25

not necessarily. for example, if you're writing cross-platform code that reads a particular format of binary file, and you know the files are always written in Intel order, you can write ReadShort and ReadInt functions that will convert those data types on-the-fly to the appropriate order, for the machine running the code.

Cleek | Image Toolkits | Thumbnail maker

Jörgen Sigvardsson17-May-06 9:39

17-May-06 9:39

Since endianess is hardcoded for a particular platform (I don't know of any platform/CPU architecture which has a variable endianess), you can do these decisions at compile time, rather than runtime. A good side effect of handling endianess at compile time, is that you'll always get the best possible performance on systems in scenarios where endians match.

--
100% natural. No superstitious additives.

C^hris L^osinger17-May-06 9:47

17-May-06 9:47

Jörgen Sigvardsson wrote:
A good side effect of handling endianess at compile time, is that you'll always get the best possible performance on systems in scenarios where endians match.

of course.

i was just pointing out that it's possible (if not necessarily ideal) to handle it at run-time, too.

Cleek | Image Toolkits | Thumbnail maker

Trollslayer17-May-06 10:02

Trollslayer

17-May-06 10:02

We use MIPS cores and our reference designs have jumpers on which let you decide one endianess.
There are can be a test at startup to make sure this is set to match the code.

Elaine Rose | [Rose]

The tigress is here Big Grin | :-D

Jörgen Sigvardsson17-May-06 10:04

17-May-06 10:04

endian jumpers! Who would've thought! Big Grin | :-D

--
100% natural. No superstitious additives.

cmk17-May-06 10:54

cmk

17-May-06 10:54

There are/were some file formats that specified the endianness of the file in the header.
This allowed the file to be saved in a format that was optimal based on the type of machine that would be reading/writting the data the most.

There are also formats that use both types:
http://ccrma.stanford.edu/courses/422/projects/WaveFormat/[^]

...cmk

Save the whales - collect the whole set

Jörgen Sigvardsson17-May-06 10:56

17-May-06 10:56

Yeah, but you wouldn't be testing the system itself then, just the input from the file header. Smile | :)

--
100% natural. No superstitious additives.

cmk17-May-06 11:04

cmk

17-May-06 11:04

True, you wouldn't need to directly test your system - if you hard coded the endianness of it into your code.

If you want portable code then you will need functions such as:
SysToBig( long& ), BigToSys( long& ), SysToLittle(), ...
Those functions need to know if they are a no-op (e.g. SysToLittle() on a PC), or actually perform a swap.

To me, i generally treat endianness like socket code, always call the ntols, ... functions.
On a PC they do swaps but on other (big-endian) systems they are a no-op.
_I_ don't need to know the system endianness, but the ntols funstions do.

...cmk

Save the whales - collect the whole set

Jörgen Sigvardsson17-May-06 11:07

17-May-06 11:07

I too use ntol functions, mainly because of the reasons you mention. It's fool proof. Smile | :)

--
100% natural. No superstitious additives.

Joshua Quick17-May-06 14:23

Joshua Quick

17-May-06 14:23

Jörgen Sigvardsson wrote:
I don't know of any platform/CPU architecture which has a variable endianess

As of last year, Apple now creates "Universal Binaries" which support both the big-endian PowerPC and little-endian Intel chips. That means endianess is not determined at compile time.

http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/index.html[^]

Jörgen Sigvardsson17-May-06 20:26

17-May-06 20:26

Joshua Quick wrote:
That means endianess is not determined at compile time.

Yes it is. PowerPC nor Intel have variable endianess. Nor is it possible to run Intel code directly on a PowerPC and vice versa, so it's not like the same code is shared between the platforms. The Universal Binary contains sections (I think they call it bundles or forks or something like that at Apple) for each platform - copies of eachother. The Intel section is executed on an Intel machine, and the PPC section is executed on the PPC.

The data however may be of varying endianess - I don't know. If you look at the guidelines you provided a link to, it only speaks of data having different endians, and that you have to guard against that - and something that may be a real problem, as the OS is released on platform with differing endianess.

Joshua Quick17-May-06 20:58

Joshua Quick

17-May-06 20:58

Jörgen Sigvardsson wrote:
Yes it is. PowerPC nor Intel have variable endianess.

I was referring to the Apple "development" platform.

You are correct though. A universal binary does contain both a PowerPC and Intel build of the executable.