Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #5223 > unrolled thread

// at beginning of line

Back to article view | Back to comp.lang.c

Contents

  // at beginning of line Federico <no.adress@nospam.com> - 2011-06-01 19:44 +0000
    Re: // at beginning of line Ben Pfaff <blp@cs.stanford.edu> - 2011-06-01 12:48 -0700
    Re: // at beginning of line Angel <angel+news@spamcop.net> - 2011-06-01 19:55 +0000
      Re: // at beginning of line Federico <no.adress@nospam.com> - 2011-06-01 20:46 +0000
        Re: // at beginning of line Keith Thompson <kst-u@mib.org> - 2011-06-01 13:54 -0700
          Re: // at beginning of line Federico <no.adress@nospam.com> - 2011-06-02 19:34 +0000
            Re: // at beginning of line Ben Pfaff <blp@cs.stanford.edu> - 2011-06-02 12:38 -0700
            Re: // at beginning of line Keith Thompson <kst-u@mib.org> - 2011-06-02 13:13 -0700
        Re: // at beginning of line Angel <angel+news@spamcop.net> - 2011-06-01 20:59 +0000
    Re: // at beginning of line Keith Thompson <kst-u@mib.org> - 2011-06-01 12:56 -0700
      Re: // at beginning of line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-06-01 23:06 -0700
        Re: // at beginning of line Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-02 07:15 +0000
          Re: // at beginning of line Chris H <chris@phaedsys.org> - 2011-06-02 08:40 +0100
            Re: // at beginning of line James Kuyper <jameskuyper@verizon.net> - 2011-06-02 06:15 -0400
              Re: // at beginning of line Chris H <chris@phaedsys.org> - 2011-06-02 11:35 +0100
                Re: // at beginning of line James Kuyper <jameskuyper@verizon.net> - 2011-06-02 07:58 -0400
                Re: // at beginning of line Lorenzo Villari <vlllnz@tiscali.it> - 2011-06-02 15:18 +0200
                  Re: // at beginning of line Chris H <chris@phaedsys.org> - 2011-06-02 14:59 +0100
                Re: // at beginning of line Ian Collins <ian-news@hotmail.com> - 2011-06-03 09:09 +1200
                  Re: // at beginning of line Chris H <chris@phaedsys.org> - 2011-06-03 09:40 +0100
                    Re: // at beginning of line Ian Collins <ian-news@hotmail.com> - 2011-06-03 20:51 +1200
                    Re: // at beginning of line James Kuyper <jameskuyper@verizon.net> - 2011-06-03 06:57 -0400
                    Re: // at beginning of line Nobody <nobody@nowhere.com> - 2011-06-03 12:54 +0100
                      Re: // at beginning of line Chris H <chris@phaedsys.org> - 2011-06-03 13:27 +0100
                        Re: // at beginning of line Keith Thompson <kst-u@mib.org> - 2011-06-03 09:42 -0700
                          Re: // at beginning of line Chris H <chris@phaedsys.org> - 2011-06-05 17:27 +0100
                            Re: // at beginning of line Keith Thompson <kst-u@mib.org> - 2011-06-05 12:35 -0700
                              Re: // at beginning of line Chris H <chris@phaedsys.org> - 2011-06-06 09:27 +0100
                                Re: // at beginning of line Keith Thompson <kst-u@mib.org> - 2011-06-06 09:29 -0700
                                  Re: // at beginning of line Roberto Waltman <usenet@rwaltman.com> - 2011-06-06 14:37 -0400
                        Re: // at beginning of line Nobody <nobody@nowhere.com> - 2011-06-03 23:16 +0100
                          Re: // at beginning of line Chris H <chris@phaedsys.org> - 2011-06-05 17:28 +0100
                            Re: // at beginning of line Nobody <nobody@nowhere.com> - 2011-06-06 22:39 +0100
    Re: // at beginning of line Shao Miller <sha0.miller@gmail.com> - 2011-06-01 23:05 -0500
    Re: // at beginning of line Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-06-02 13:34 -0400

Page 2 of 2 — ← Prev page 1 [2]

#5344

On 06/ 3/11 08:40 PM, Chris H wrote:
> In message<94qcg5F4saU1@mid.individual.net>, Ian Collins<ian-
> news@hotmail.com>  writes
>> On 06/ 2/11 10:35 PM, Chris H wrote:
>>>
>>> You would hope that the ISO team learnt their lesson from C99 and only
>>> added things to C12 that the *industry* wanted ie things the compiler
>>> vendors already wanted to add. And made optional thing the majority were
>>> never going to add.
>>
>> I hope they do.  Because programmers want them, several major C++
>> compilers are already offer most of the features in the upcoming C++0x
>> standard.
>
> That is the way it should be.
>
> My worry is they will try and move C closer to C++.  A vast amount of C
> is in the embedded area on 8-128 bit systems where they don't want C++
> (4 bit systems are still used but usually in assembler)
>
> C and C++ are separate languages and should be kept that way. People who
> want the features of C++ can use C++ not fit them to C  otherwise the
> vast majority of the C compilers will not follow the new standard.

I'm sure that isn't the main reason for the poor uptake of C99.  The two 
most obvious "closer to C++" additions are probably the most widely 
supported - // comments and mixed declarations and code.

Oh, and C++ has moved nearer C as well - we now officially have long long!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#5347

On 06/03/2011 04:40 AM, Chris H wrote:
> In message <94qcg5F4saU1@mid.individual.net>, Ian Collins <ian-
> news@hotmail.com> writes
...
>> I hope they do.  Because programmers want them, several major C++
>> compilers are already offer most of the features in the upcoming C++0x
>> standard.
> 
> That is the way it should be.
> 
> My worry is they will try and move C closer to C++.  A vast amount of C
> is in the embedded area on 8-128 bit systems where they don't want C++
> (4 bit systems are still used but usually in assembler)
> 
> C and C++ are separate languages and should be kept that way. People who
> want the features of C++ can use C++ not fit them to C  otherwise the
> vast majority of the C compilers will not follow the new standard.

The most poorly supported of the new C99 features are those which moved
C away from C++, not those which moved it closer, so I don't think
that's as big of an issue as you suggest.

In fact, the existence of compilers which can compile code as either C
or C++ means that changes (to either standard) which bring C and C++
closer together tend to get adopted faster than those which do not.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#5354

On Fri, 03 Jun 2011 09:40:26 +0100, Chris H wrote:

> My worry is they will try and move C closer to C++.  A vast amount of C
> is in the embedded area on 8-128 bit systems where they don't want C++

I doubt that they'll add features which increase the run-time overhead
even if you don't use those features. And even if they did, embedded
compilers will inevitably provide an option to disable support for such
features, in the same way that C++ compilers typically allow support for
exceptions and RTTI to be disabled.

It's not as if you can run typical C89/C99 code on a small embedded
system. Most such code assumes a hosted implementation, while small
embedded systems often only provide a freestanding implementation plus the
most critical portions of the standard library (e.g. most of <string.h>,
maybe malloc() etc if memory is measured in kilobytes rather than bytes,
but probably not <stdio.h>).

At the low end, compilers won't hesitate to deviate from the standard if
it's appropriate. E.g. "rom"-qualified pointers (and RAM/ROM variants of
much of <string.h>) on systems where flash is more plentiful than RAM.

[toc] | [prev] | [next] | [standalone]

#5355

In message <pan.2011.06.03.11.54.42.78000@nowhere.com>, Nobody
<nobody@nowhere.com> writes
>
>It's not as if you can run typical C89/C99 code on a small embedded
>system.

Yes you can... though it depends what you call "typical"   C is widely
used on the 8051 family which up to a few years ago was 1 in 3 of the
MCU's on (or off) the planet.

>Most such code assumes a hosted implementation, while small
>embedded systems often only provide a freestanding implementation plus the
>most critical portions of the standard library (e.g. most of <string.h>,
>maybe malloc() etc if memory is measured in kilobytes rather than bytes,
>but probably not <stdio.h>).

Well you are wrong there.

>At the low end, compilers won't hesitate to deviate from the standard if
>it's appropriate.

Quite true.



-- 
Support Sarah Palin for the next US President
Go Palin! Go Palin! Go Palin!
In God We Trust! Rapture Ready!!!
http://www.sarahpac.com/

[toc] | [prev] | [next] | [standalone]

#5365

Chris H <chris@phaedsys.org> writes:
> In message <pan.2011.06.03.11.54.42.78000@nowhere.com>, Nobody
> <nobody@nowhere.com> writes
>>
>>It's not as if you can run typical C89/C99 code on a small embedded
>>system.
>
> Yes you can... though it depends what you call "typical"   C is widely
> used on the 8051 family which up to a few years ago was 1 in 3 of the
> MCU's on (or off) the planet.
>
>>Most such code assumes a hosted implementation, while small
>>embedded systems often only provide a freestanding implementation plus the
>>most critical portions of the standard library (e.g. most of <string.h>,
>>maybe malloc() etc if memory is measured in kilobytes rather than bytes,
>>but probably not <stdio.h>).
>
> Well you are wrong there.

That's an utterly useless remark unless you provide more details.  Which
parts of his statement are wrong?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#5502

In message <ln7h92kgsz.fsf@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes
>Chris H <chris@phaedsys.org> writes:
>> In message <pan.2011.06.03.11.54.42.78000@nowhere.com>, Nobody
>> <nobody@nowhere.com> writes
>>>
>>>It's not as if you can run typical C89/C99 code on a small embedded
>>>system.
>>
>> Yes you can... though it depends what you call "typical"   C is widely
>> used on the 8051 family which up to a few years ago was 1 in 3 of the
>> MCU's on (or off) the planet.
>>
>>>Most such code assumes a hosted implementation, while small
>>>embedded systems often only provide a freestanding implementation plus the
>>>most critical portions of the standard library (e.g. most of <string.h>,
>>>maybe malloc() etc if memory is measured in kilobytes rather than bytes,
>>>but probably not <stdio.h>).
>>
>> Well you are wrong there.
>
>That's an utterly useless remark unless you provide more details.  Which
>parts of his statement are wrong?

Most embedded systems do provide most of the standard library including
stdio.h




-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[toc] | [prev] | [next] | [standalone]

#5520

Chris H <chris@phaedsys.org> writes:
> In message <ln7h92kgsz.fsf@nuthaus.mib.org>, Keith Thompson <kst-
> u@mib.org> writes
>>Chris H <chris@phaedsys.org> writes:
>>> In message <pan.2011.06.03.11.54.42.78000@nowhere.com>, Nobody
>>> <nobody@nowhere.com> writes
>>>>
>>>>It's not as if you can run typical C89/C99 code on a small embedded
>>>>system.
>>>
>>> Yes you can... though it depends what you call "typical"   C is widely
>>> used on the 8051 family which up to a few years ago was 1 in 3 of the
>>> MCU's on (or off) the planet.
>>>
>>>>Most such code assumes a hosted implementation, while small
>>>>embedded systems often only provide a freestanding implementation plus the
>>>>most critical portions of the standard library (e.g. most of <string.h>,
>>>>maybe malloc() etc if memory is measured in kilobytes rather than bytes,
>>>>but probably not <stdio.h>).
>>>
>>> Well you are wrong there.
>>
>>That's an utterly useless remark unless you provide more details.  Which
>>parts of his statement are wrong?
>
> Most embedded systems do provide most of the standard library including
> stdio.h

Including 8051 systems?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#5549

In message <lnmxhwgjg9.fsf@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes
>Chris H <chris@phaedsys.org> writes:
>> In message <ln7h92kgsz.fsf@nuthaus.mib.org>, Keith Thompson <kst-
>> u@mib.org> writes
>>>Chris H <chris@phaedsys.org> writes:
>>>> In message <pan.2011.06.03.11.54.42.78000@nowhere.com>, Nobody
>>>> <nobody@nowhere.com> writes
>>>>>
>>>>>It's not as if you can run typical C89/C99 code on a small embedded
>>>>>system.
>>>>
>>>> Yes you can... though it depends what you call "typical"   C is widely
>>>> used on the 8051 family which up to a few years ago was 1 in 3 of the
>>>> MCU's on (or off) the planet.
>>>>
>>>>>Most such code assumes a hosted implementation, while small
>>>>>embedded systems often only provide a freestanding implementation plus the
>>>>>most critical portions of the standard library (e.g. most of <string.h>,
>>>>>maybe malloc() etc if memory is measured in kilobytes rather than bytes,
>>>>>but probably not <stdio.h>).
>>>>
>>>> Well you are wrong there.
>>>
>>>That's an utterly useless remark unless you provide more details.  Which
>>>parts of his statement are wrong?
>>
>> Most embedded systems do provide most of the standard library including
>> stdio.h
>
>Including 8051 systems?

Yes.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[toc] | [prev] | [next] | [standalone]

#5571

Chris H <chris@phaedsys.org> writes:
> In message <lnmxhwgjg9.fsf@nuthaus.mib.org>, Keith Thompson <kst-
> u@mib.org> writes
>>Chris H <chris@phaedsys.org> writes:
>>> In message <ln7h92kgsz.fsf@nuthaus.mib.org>, Keith Thompson <kst-
>>> u@mib.org> writes
>>>>Chris H <chris@phaedsys.org> writes:
>>>>> In message <pan.2011.06.03.11.54.42.78000@nowhere.com>, Nobody
>>>>> <nobody@nowhere.com> writes
[...]
>>>>>>Most such code assumes a hosted implementation, while small
>>>>>>embedded systems often only provide a freestanding implementation plus the
>>>>>>most critical portions of the standard library (e.g. most of <string.h>,
>>>>>>maybe malloc() etc if memory is measured in kilobytes rather than bytes,
>>>>>>but probably not <stdio.h>).
>>>>>
>>>>> Well you are wrong there.
>>>>
>>>>That's an utterly useless remark unless you provide more details.  Which
>>>>parts of his statement are wrong?
>>>
>>> Most embedded systems do provide most of the standard library including
>>> stdio.h
>>
>>Including 8051 systems?
>
> Yes.

For example,
    http://www.keil.com/support/man/docs/c51/c51_lib_stream.htm
Is that typical?

It looks like a *partial* implementation of ISO C <stdio.h>; for
example, it has versions of printf and sprintf, but not fprintf or
fopen.

Interesting.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#5575

I wrote:
>Keith Thompson  wrote:
>>For example,
>>    http://www.keil.com/support/man/docs/c51/c51_lib_stream.htm
>>Is that typical?
>>
>>It looks like a *partial* implementation of ISO C <stdio.h>; for
>>example, it has versions of printf and sprintf, but not fprintf or
>>fopen.
>
>I wouldn't call it typical, but it is not unexpected.
>Many embedded systems, (your microwave oven, for example,) do not have
>file systems, so fopen() and family are no implemented. (Or are
>implemented as do-nothing stubs.)

(Clicked on send instead of save ...)

The oven's display and keypad, on the other hand, could be
masquerading as stdout and stdin, and string conversion and handling
functions are needed most of the time, so there is a justification to
have printf() and sprintf().

(There could be also a serial port assigned as stdin/stdout, ditto for
a serial channel available only when a hardware debugging tool is
connected, etc.)
--
Roberto Waltman

[ Please reply to the group.
  Return address is invalid ]

[toc] | [prev] | [next] | [standalone]

#5390

On Fri, 03 Jun 2011 13:27:09 +0100, Chris H wrote:

>>It's not as if you can run typical C89/C99 code on a small embedded
>>system.
> 
> Yes you can... though it depends what you call "typical"

I mean code which is portable insofar as it doesn't assume any particular
platform (CPU and OS), but was targeted at general-purpose computing
platforms designed to run third-party programs: desktops, servers,
consoles, larger embedded systems (smartphones, tablets, hand-held
consoles etc; a 32-bit CPU with RAM measured in megabytes).

As opposed to code which was explicitly written with support for smaller
(8-bit/16-bit) embedded platforms in mind.

[toc] | [prev] | [next] | [standalone]

#5503

In message <pan.2011.06.03.22.16.03.234000@nowhere.com>, Nobody
<nobody@nowhere.com> writes
>On Fri, 03 Jun 2011 13:27:09 +0100, Chris H wrote:
>
>>>It's not as if you can run typical C89/C99 code on a small embedded
>>>system.
>>
>> Yes you can... though it depends what you call "typical"
>
>I mean code which is portable insofar as it doesn't assume any particular
>platform (CPU and OS), but was targeted at general-purpose computing
>platforms designed to run third-party programs: desktops, servers,
>consoles,

Most assume a particular OS.

> larger embedded systems (smartphones, tablets, hand-held
>consoles etc; a 32-bit CPU with RAM measured in megabytes).

Those are not larger embedded systems.... many hare and have been far
larger for a decade or two.  Eg defence, telecoms etc.

>As opposed to code which was explicitly written with support for smaller
>(8-bit/16-bit) embedded platforms in mind.

There are vastly more of these systems (both in number of different
applications and numbers in use) than the "typical" ones you mention.

Up until about 5 years ago the 8 bit 8051 family may up just over 30% of
the MCU on or off the planet!

So your "typical" platform is in fact a non typical one.

On the other hand  I do have libraries that are designed to be portable
across most 8,16 and 32 bit embedded systems

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[toc] | [prev] | [next] | [standalone]

#5585

On Sun, 05 Jun 2011 17:28:52 +0100, Chris H wrote:

>>> Yes you can... though it depends what you call "typical"
>>
>>I mean code which is portable insofar as it doesn't assume any particular
>>platform (CPU and OS), but was targeted at general-purpose computing
>>platforms designed to run third-party programs: desktops, servers,
>>consoles,
> 
> Most assume a particular OS.

Most (but not all) complete programs assume a particular OS (or one OS
from a fixed set, using preprocessor conditionals). There's plenty of
library code which doesn't assume any specific OS, but much of it does
assume at least 32 bits for int and/or size_t (or, even if technically it
works on a 16-bit platform, in practice it won't be useful because it's
too wasteful of memory).

>> larger embedded systems (smartphones, tablets, hand-held
>>consoles etc; a 32-bit CPU with RAM measured in megabytes).
> 
> Those are not larger embedded systems.... many hare and have been far
> larger for a decade or two.  Eg defence, telecoms etc.

Larger. Not largest. Meaning: excluding the smallest systems (8/16-bit).

>>As opposed to code which was explicitly written with support for smaller
>>(8-bit/16-bit) embedded platforms in mind.
> 
> There are vastly more of these systems (both in number of different
> applications and numbers in use) than the "typical" ones you mention.

The word "typical" referred to code, not platforms. Code aimed at 8-bit
and 16-bit systems is less common and more likely to be platform-specific.

> On the other hand  I do have libraries that are designed to be portable
> across most 8,16 and 32 bit embedded systems

I don't doubt that such libraries exist, but they're much less common than
code which assumes a 32-bit (or better) target. Writing (and testing) code
which works on smaller platforms takes extra effort.

Practically anyone who can program has ready access to at least one 32-bit
(or 64-bit) system and a suitable toolchain. Fewer people have both ready
access to a suitable 8/16-bit system and a reason to ensure that their
code actually works on such.

Many of the libraries used on a Linux system can be compiled for Windows,
MacOSX or various other 32-bit targets with little or no changes. Very
little of it would compile (and be useful) on a 16-bit platform without
significant changes.

[toc] | [prev] | [next] | [standalone]

#5247

On 6/1/2011 2:44 PM, Federico wrote:
> Hello. I'd like to understand the following piece of source:
>
> .........
>
> fscanf ( Infile, "%3s %6s", string1, string2);
> //fscanf(Infile,"%5s %5s",string3,string4);
>
> ^^--------- I don't know the meaning of this double slash.

You might also enjoy:

   fscanf(Infile, "%3s %6s", string1, string2);
   #if 0
   fscanf(Infile, "%5s %5s", string3, string4);
   #endif

or even:

   #define TEST_MODE 0
   ...
   fscanf(Infile, "%3s %6s", string1, string2);
   #if TEST_MODE
   fscanf(Infile, "%5s %5s", string3, string4);
   #endif

or maybe:

   #define TEST_MODE 0
   ...
   #if !TEST_MODE
   fscanf(Infile, "%3s %6s", string1, string2);
   #else
   fscanf(Infile, "%5s %5s", string3, string4);
   #endif

[toc] | [prev] | [next] | [standalone]

#5289

On Wed, 1 Jun 2011 19:44:54 +0000 (UTC), Federico
<no.adress@nospam.com> wrote:

>Hello. I'd like to understand the following piece of source:
>
>.........
>
>fscanf ( Infile, "%3s %6s", string1, string2);
>//fscanf(Infile,"%5s %5s",string3,string4);
>
>^^--------- I don't know the meaning of this double slash.

Just a few things to add to what the other posters have added ...

a)The feature ("//") is so convenient that a lot of (but not all)
compilers that aren't compliant with later standards support it.  This
can cause (and in your case may have caused) cross-compilation
problems.

b)It must be rembered that "//" goes into the end of the line, whereas
C itself is not a record-oriented language.

So, you can actually break up a C statement legally, i.e.

x =   a
      +b
//      +c
      +d;

In the statement above "d" gets added in.

This may be somewhat surprising to you.

DFC

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web