headers
Glynn Clements | 1 Jul 2007 03:02

Re: no number->string conversion in stdc++?


Shriramana Sharma wrote:

> I learnt today to my dismay that there is in fact no number to string 
> conversion function in the standard C++ library? I can't do simple 
> natural things like:
> 
> std :: string a ( 2 ) ;
> std :: string b ( 2.5 ) ;

These conversions are neither simple nor natural.

Look at the printf() documentation, and note how much of it applies to
formatting numeric values. Base, precision, field width, leading
zeroes/spaces, exponential notation. And that's aside from locale
issues (e.g. decimal separator), which aren't described there.

> The three ways out of this problem I got to know:
> 
> 1. stringstream from std, resulting in somewhat unweildy operations
> 2. lexical_cast from boost, resulting in dependency on huge boost lib
> 3. QString from Qt, resulting in depdency on huge Qt lib
> 
> Of course stdc++ is also a huge lib, but thought I can expect stdc++ to 
> be there on more machines than boost or Qt.
> 
> So shall I go with std::string and std::stringstream, std::string and 
> boost::lexical_cast or simply Qt's QString? QString seems most 
> appealing, but I would listen to your better judgment.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Glynn Clements | 1 Jul 2007 03:08

Re: Using operator ! twice


Luong Ngo wrote:

> I came across several times codes that use ! operator on an integer
> variable. I am curious what is the purpose of using it twice.
> For example:
> 
> int flag;
>                if( !! flag) {
>                    //do something
>                }
> 
> 
> The first ! operator will make !flag to be true if flag is 0, and if
> we not again it become false, which is just exactly the same if we
> just left it as
>    if(flag), since 0 is the same as false. Similar logic for non-0
> value of flag. Then why do we need to use ! operator twice to get back
> the same value as if we don't use at all?

The !! idiom converts anything which can be used as a boolean to an
integer which is either zero or one.

It isn't necessary in a context where any boolean value is acceptable
(e.g. the test of an if, while or do-while statement, or an operand to
the && and || operators), but is useful if you need a value which must
be either zero or one.

> this seems to be the same
> for me if we do this in math:  -(-( -8)) = -8;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Holger Kiehl | 2 Jul 2007 10:55
Picon
Favicon

Question about ULLONG_MAX

Hello

When compiling the following program on a Fedora 6 x86_64 system:

    #include <stdio.h>
    #include <limits.h>

    int
    main(void)
    {
       (void)printf("%llu\n", ULLONG_MAX);

       return 0;
    }

Produces the following result:

   cc longlong.c
   longlong.c: In function 'main':
   longlong.c:7: error: 'ULLONG_MAX' undeclared (first use in this function)
   longlong.c:7: error: (Each undeclared identifier is reported only once
   longlong.c:7: error: for each function it appears in.)

If I compile it with cc -std=c99 longlong.c it works.

Why is it necessary to specify -std=c99? If I use for example strtoull()
I do not need to set -std=c99.

Compiling the above on AIX compiles and runs without problems. Also
on an older Solaris 8 system using gcc (3.3.2) it compiles and runs
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stephen Kratzer | 2 Jul 2007 14:57

Re: Question about ULLONG_MAX

From limits.h,

#  ifdef __USE_ISOC99

/* Minimum and maximum values a `signed long long int' can hold.  */
#   define LLONG_MAX    9223372036854775807LL
#   define LLONG_MIN    (-LLONG_MAX - 1LL)

/* Maximum value an `unsigned long long int' can hold.  (Minimum is 0.)  */
#   define ULLONG_MAX   18446744073709551615ULL

#  endif /* ISO C99 */

/* The <limits.h> files in some gcc versions don't define LLONG_MIN,
   LLONG_MAX, and ULLONG_MAX.  Instead only the values gcc defined for
   ages are available.  */
#if defined __USE_ISOC99 && defined __GNUC__
# ifndef LLONG_MIN
#  define LLONG_MIN     (-LLONG_MAX-1)
# endif
# ifndef LLONG_MAX
#  define LLONG_MAX     __LONG_LONG_MAX__
# endif
# ifndef ULLONG_MAX
#  define ULLONG_MAX    (LLONG_MAX * 2ULL + 1)
# endif
#endif

On Monday 02 July 2007 04:55:00 Holger Kiehl wrote:
> Hello
(Continue reading)

Permalink | Reply | 0 comments |
headers
Glynn Clements | 2 Jul 2007 20:55

Re: Question about ULLONG_MAX


Holger Kiehl wrote:

> Hello
> 
> When compiling the following program on a Fedora 6 x86_64 system:
> 
>     #include <stdio.h>
>     #include <limits.h>
> 
>     int
>     main(void)
>     {
>        (void)printf("%llu\n", ULLONG_MAX);
> 
>        return 0;
>     }
> 
> Produces the following result:
> 
>    cc longlong.c
>    longlong.c: In function 'main':
>    longlong.c:7: error: 'ULLONG_MAX' undeclared (first use in this function)
>    longlong.c:7: error: (Each undeclared identifier is reported only once
>    longlong.c:7: error: for each function it appears in.)
> 
> If I compile it with cc -std=c99 longlong.c it works.
> 
> Why is it necessary to specify -std=c99? If I use for example strtoull()
> I do not need to set -std=c99.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pedro de Medeiros | 2 Jul 2007 21:52
Picon

Using both wchar_t and GCC __attribute__((format(...)))

Hello,

I am trying to convert some functions in my library from (char *) to
(wchar_t *), and it has been a bit of a nightmare. I want to use GCC error
detection for printf-style functions, but that doesn't seem to work when
functions use wchar_t *. For instance:

void trace(conn_t *, wchar_t *, ...)
        __attribute__ ((format(printf, 2, 3)));

And GCC aborts with:

"error: format string argument not a string type"

Then I tried something like:

void trace(conn_t *, wchar_t *, ...)
        __attribute__ ((format(wprintf, 2, 3)));

But GCC tells me that:

"warning: 'wprintf' is an unrecognized format function type"

Which I assume will disable GCC printf-style error checking.

How do I solve this other than disabling this feature completely?
Any help would be greatly appreciated.

Cheers,
Pedro.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Holger Kiehl | 2 Jul 2007 22:39
Picon
Favicon

Re: Question about ULLONG_MAX

On Mon, 2 Jul 2007, Glynn Clements wrote:

>
> Holger Kiehl wrote:
>
>> Compiling the above on AIX compiles and runs without problems. Also
>> on an older Solaris 8 system using gcc (3.3.2) it compiles and runs
>> straight out of the box.
>>
>> If I want to use ULLONG_MAX how can I do this in a portable way so it
>> compiles on different systems?
>
> You need to explicitly enable C99 support; "long long" isn't in C89,
> so you shouldn't assume that it will be available when using the
> default compilation settings.
>
You are right. Enabling C99 support explicitly is the better solution.

Thanks,
Holger

-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
cyon.john | 3 Jul 2007 06:03

RE: Using both wchar_t and GCC __attribute__((format(...)))

Hi, 

I haven't used this attribute before, but the following is what I feel
after giving it a try now...

> void trace(conn_t *, wchar_t *, ...)
>         __attribute__ ((format(printf, 2, 3)));
> 
> And GCC aborts with:
> 
> "error: format string argument not a string type"

Here, the error is due to the fact that gcc expects the 'string-index'
parameter of format attribute to point to 'const char *' type.

> void trace(conn_t *, wchar_t *, ...)
>         __attribute__ ((format(wprintf, 2, 3)));
> 
> But GCC tells me that:
> 
> "warning: 'wprintf' is an unrecognized format function type"

This error is because, according to gcc-4.2.0 manual it only supports
the following - printf, scanf, strftime or strfmon - for the 'archetype'
parameter offormat attribute.

So I feel we are out of luck unless gcc adds support for 'wprintf' as
archetype for format attribute.

I found a mail loop at gcc-patches mailing list where a patch is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Li YanBo | 3 Jul 2007 06:12
Picon

Re: Confuse with big endian bitwise field

On 6/28/07, Ranjan Sinha <rnjn.sinha <at> gmail.com> wrote:
> Thanks for this discussion, since this really gets confusing at times.
> > >
> > > struct xxx {
> > >         __be32 pdu_cnt:6;
> > >         __be32 y:3;
> > >         __be32 wep_key:2;
> > >         __be32 uses_wep_key:1;
> > >         __be32 keep_alive:1;
> > >         __be32 buff_tail_addr:19;
> > >
> > >         __be32 cts_11g:1;
> > >         __be32 rts_11g:1;
> > >         __be32 x:2;
> > >         __be32 frag_size:12;
> > >         __be32 payload_len:12;
> > >         __be32 frag_num:4;
> > > }
> >
> > this isn't safe if you want to mimic hardware layout; the order of the
> > bits in the struct is different for little endian and big endian
> > machines...
> >
> What is the best way in such scenario? Should we then use an unsigned
> char array and then keep separate mappings of each bit for little and
> big endian machines ?
>

I am sorry I still can't figure out how to use bits shift and make it
can be portability to any Be or Le endian machine. what I can tell you
(Continue reading)

Permalink | Reply | 2 comments |
headers
mudassir | 5 Jul 2007 14:57
Favicon

C/C++ File Parser


Hi All,

I am in search of a snippet that could parse a C/C++ source file and
give out as output different information on it. For example

1. Signature of function defined in a file.
2. Name of Global Variables declared.
3. Files dependencies..(#include).

Can you help?

thanks,
mudassir. 
--

-- 
View this message in context: http://www.nabble.com/C-C%2B%2B-File-Parser-tf4029536.html#a11445958
Sent from the linux-c-programming mailing list archive at Nabble.com.

-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 3 comments |

Gmane