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

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

Some ideas about c?

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

Contents

  Some ideas about c? Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-17 23:23 +0300
    Re: Some ideas about c? Ian Collins <ian-news@hotmail.com> - 2017-05-18 08:40 +1200
    Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-17 23:00 +0200
      Re: Some ideas about c? supercat@casperkitty.com - 2017-05-17 14:59 -0700
        Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 00:08 +0200
          Re: Some ideas about c? supercat@casperkitty.com - 2017-05-17 22:09 -0700
            Re: Some ideas about c? Ian Collins <ian-news@hotmail.com> - 2017-05-18 18:22 +1200
            Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 12:36 +0200
              Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 03:53 -0700
                Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 14:24 +0200
                  Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 08:37 -0400
                    Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 05:47 -0700
                    Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 15:20 +0200
                      Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 06:28 -0700
                      Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-18 13:56 +0000
                        Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 16:30 +0200
                          Re: Some ideas about c? Thiago Adams <thiago.adams@gmail.com> - 2017-05-18 07:45 -0700
                            Re: Some ideas about c? Richard Heathfield <rjh@cpax.org.uk> - 2017-05-18 16:08 +0100
                              Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 08:15 -0700
                                Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 11:46 -0400
                                  Re: Some ideas about c? Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-18 21:33 +0300
                                    Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 15:29 -0400
                                    Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-19 01:23 +0200
                                      Re: Some ideas about c? Thiago Adams <thiago.adams@gmail.com> - 2017-05-18 18:12 -0700
                              Re: Some ideas about c? Thiago Adams <thiago.adams@gmail.com> - 2017-05-18 10:08 -0700
                            Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-19 00:39 +0200
                              Re: Some ideas about c? Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-19 14:27 +0300
                                Re: Some ideas about c? David Brown <david.brown@hesbynett.no> - 2017-05-19 13:41 +0200
                                  Re: Some ideas about c? Richard Heathfield <rjh@cpax.org.uk> - 2017-05-19 13:04 +0100
                                  Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 10:00 -0700
                                Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-19 14:14 +0200
                      Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 11:33 -0400
                        Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 08:47 -0700
                        Re: Some ideas about c? supercat@casperkitty.com - 2017-05-18 08:48 -0700
                          Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 09:02 -0700
                            Re: Some ideas about c? supercat@casperkitty.com - 2017-05-18 10:52 -0700
                          Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 15:35 -0400
                            Re: Some ideas about c? supercat@casperkitty.com - 2017-05-18 14:01 -0700
                              Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 17:38 -0400
                                Re: Some ideas about c? supercat@casperkitty.com - 2017-05-18 15:54 -0700
                                  Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 22:17 -0400
                  Re: Some ideas about c? John Bode <jfbode1029@gmail.com> - 2017-05-18 08:06 -0700
                    Re: Some ideas about c? John Bode <jfbode1029@gmail.com> - 2017-05-18 09:17 -0700
    Re: Some ideas about c? fir <profesor.fir@gmail.com> - 2017-05-17 14:34 -0700
      Re: Some ideas about c? Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-18 16:16 +0300
    Re: Some ideas about c? Cholo Lennon <chololennon@hotmail.com> - 2017-05-18 10:26 -0300
    Re: Some ideas about c? John Bode <jfbode1029@gmail.com> - 2017-05-18 07:36 -0700
      Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-18 18:23 +0000
        Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-18 21:51 +0100
          Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-19 12:38 +0000
            Re: Some ideas about c? supercat@casperkitty.com - 2017-05-19 07:44 -0700
              Re: Some ideas about c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 16:45 +0100
                Re: Some ideas about c? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-19 21:59 -0700
              Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 10:06 -0700
                Re: Some ideas about c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 18:18 +0100
                  Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 11:59 -0700
                    Re: Some ideas about c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 21:05 +0100
            Re: Some ideas about c? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-19 12:42 -0400
              Re: Some ideas about c? Richard Heathfield <rjh@cpax.org.uk> - 2017-05-19 17:54 +0100
              Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-19 18:52 +0100
            Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-19 18:51 +0100
              Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-19 18:55 +0000
                Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-19 19:58 +0100
                Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 12:12 -0700
              Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 12:01 -0700
      Re: Some ideas about c? Ian Collins <ian-news@hotmail.com> - 2017-05-19 08:22 +1200
        Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-18 21:53 +0100
        Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-19 12:36 +0000
          Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-19 18:54 +0100
            Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-19 18:58 +0000
              Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 12:18 -0700

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

#110399

scott@slp53.sl.home (Scott Lurndal) writes:

> Gareth Owen <gwowen@gmail.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>>> stdin), stdout); }
>>
>>Great.  Except it doesn't work if the input line is too big.
>
> Sure it does.  It just truncates it.  And the programmer is, of
> course, aware of that.

If I want a program to duplicate the line, and sometimes it truncates it
then that program does not work correctly.  For every programming
problem there is a solution that is short, elegant and wrong.

>>
>>> For that matter, this code also compiles just fine as C++ code.
>>
>>But doesn't run fine as either.  I assume, you knew that.
>
> Actually, it does compile and run using the C++ compiler.

Except that sometimes it does not duplicate the output correctly.

The program has a bug in it - to whit whenever an input line is longer
than 512 bytes, the output is incorrect.

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

#110404

Gareth Owen <gwowen@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Gareth Owen <gwowen@gmail.com> writes:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>>>> stdin), stdout); }
>>>
>>>Great.  Except it doesn't work if the input line is too big.
>>
>> Sure it does.  It just truncates it.  And the programmer is, of
>> course, aware of that.
>
>If I want a program to duplicate the line, and sometimes it truncates it
>then that program does not work correctly.  For every programming
>problem there is a solution that is short, elegant and wrong.

The program solves the original assignment:

    Write a program, that reads in a line from the console and then
    echoes the same line to the console again.

There is nothing there about 'infinite line length' explictly, and
even the C++ version using getline() can't handle every possible input,
eventually the std::string will hit a memory limitation.

I would never write such code for production, but that wasn't the purpose here.

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

#110406

scott@slp53.sl.home (Scott Lurndal) writes:

> The program solves the original assignment:
>
>     Write a program, that reads in a line from the console and then
>     echoes the same line to the console again.
>
> There is nothing there about 'infinite line length' explictly, and
> even the C++ version using getline() can't handle every possible input,
> eventually the std::string will hit a memory limitation.

Weak

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

#110409

scott@slp53.sl.home (Scott Lurndal) writes:
> Gareth Owen <gwowen@gmail.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Gareth Owen <gwowen@gmail.com> writes:
>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>>> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>>>>> stdin), stdout); }
>>>>
>>>>Great.  Except it doesn't work if the input line is too big.
>>>
>>> Sure it does.  It just truncates it.  And the programmer is, of
>>> course, aware of that.
>>
>>If I want a program to duplicate the line, and sometimes it truncates it
>>then that program does not work correctly.  For every programming
>>problem there is a solution that is short, elegant and wrong.
>
> The program solves the original assignment:
>
>     Write a program, that reads in a line from the console and then
>     echoes the same line to the console again.
>
> There is nothing there about 'infinite line length' explictly, and
> even the C++ version using getline() can't handle every possible input,
> eventually the std::string will hit a memory limitation.

It fails the original requirements if the line is longer than 512 bytes.
There could be perfectly valid reasons to have input lines longer than
that; perhaps the input was automatically generated, or perhaps your cat
sat on the keyboard.  The C++ version is unlikely to fail for lines that
short.

> I would never write such code for production, but that wasn't the purpose here.

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

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

#110408

Gareth Owen <gwowen@gmail.com> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Gareth Owen <gwowen@gmail.com> writes:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>>>> stdin), stdout); }
>>>
>>>Great.  Except it doesn't work if the input line is too big.
>>
>> Sure it does.  It just truncates it.  And the programmer is, of
>> course, aware of that.
>
> If I want a program to duplicate the line, and sometimes it truncates it
> then that program does not work correctly.  For every programming
> problem there is a solution that is short, elegant and wrong.
>
>>>
>>>> For that matter, this code also compiles just fine as C++ code.
>>>
>>>But doesn't run fine as either.  I assume, you knew that.
>>
>> Actually, it does compile and run using the C++ compiler.
>
> Except that sometimes it does not duplicate the output correctly.
>
> The program has a bug in it - to whit whenever an input line is longer
> than 512 bytes, the output is incorrect.

One way to address that issue would be to modify the problem statement
so that the program's behavior is undefined if the input line (including
the trailing newline) is longer than 512 characters.

That might seem silly but there are times when it's not unreasonable to
document that a program is intended to work only with some restricted
input.

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

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

#110329

On 05/19/17 05:46 AM, Stefan Ram wrote:
> John Bode <jfbode1029@gmail.com> writes:
>> C is definitely the simpler language of the two, and by that metric easier
>
>    It might be easier to /learn/. But is it also easier to apply?
>
>    One example: Write a program, that reads in a line from the
>    console and then echoes the same line to the console again.
>
>    C++:
>
> #include <iostream>
> #include <ostream>
> #include <string>
>
> int main()
> { ::std::string line;
>    getline( ::std::cin, line );
>    ::std::cout << line << '\n'; }

Beginners shouldn't be instructed to use all those superfluous colons, 
they'll piss of their future colleagues.

-- 
Ian

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

#110332

Ian Collins <ian-news@hotmail.com> writes:

> On 05/19/17 05:46 AM, Stefan Ram wrote:
>> int main()
>> { ::std::string line;
>>    getline( ::std::cin, line );
>>    ::std::cout << line << '\n'; }
>
> Beginners shouldn't be instructed to use all those superfluous colons,
> they'll piss of their future colleagues.

Or the hideous brace style...

Its fine to *be* e.e.cummings, but don't teach "no capitals"

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

#110374

Ian Collins <ian-news@hotmail.com> writes:
> Thunderbird/38.5.1
>In-Reply-To: <C++-20170518184518@ram.dialup.fu-berlin.de>
>X-Received-Body-CRC: 3760745476
>X-Received-Bytes: 1629
>
>On 05/19/17 05:46 AM, Stefan Ram wrote:
>> John Bode <jfbode1029@gmail.com> writes:
>>> C is definitely the simpler language of the two, and by that metric easier
>>
>>    It might be easier to /learn/. But is it also easier to apply?
>>
>>    One example: Write a program, that reads in a line from the
>>    console and then echoes the same line to the console again.
>>
>>    C++:
>>
>> #include <iostream>
>> #include <ostream>
>> #include <string>
>>
>> int main()
>> { ::std::string line;
>>    getline( ::std::cin, line );
>>    ::std::cout << line << '\n'; }
>
>Beginners shouldn't be instructed to use all those superfluous colons, 
>they'll piss of their future colleagues.

Only if they pass the interview screening, and the superfluous colons
would be a huge red negative checkmark around here.

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

#110401

scott@slp53.sl.home (Scott Lurndal) writes:

> Only if they pass the interview screening, and the superfluous colons
> would be a huge red negative checkmark around here.

I think you'd get through the screening (all other things being
excellent) but you'd certainly get a "what's with all the ::'s?" as an
interview question.

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

#110405

Gareth Owen <gwowen@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Only if they pass the interview screening, and the superfluous colons
>> would be a huge red negative checkmark around here.
>
>I think you'd get through the screening (all other things being
>excellent) but you'd certainly get a "what's with all the ::'s?" as an
>interview question.

I'm not so sure.  We hire programmers here, and that would certainly
be a tickmark in the negative column.   We don't look for people who
can leverage every feature of the language, but those who can solve
problems and maintain existing, sometimes decades old, code in
multiple languages (C, C++, Python, Perl, Verilog, SystemC are the
main languages).

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

#110410

scott@slp53.sl.home (Scott Lurndal) writes:
> Gareth Owen <gwowen@gmail.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> Only if they pass the interview screening, and the superfluous colons
>>> would be a huge red negative checkmark around here.
>>
>>I think you'd get through the screening (all other things being
>>excellent) but you'd certainly get a "what's with all the ::'s?" as an
>>interview question.
>
> I'm not so sure.  We hire programmers here, and that would certainly
> be a tickmark in the negative column.   We don't look for people who
> can leverage every feature of the language, but those who can solve
> problems and maintain existing, sometimes decades old, code in
> multiple languages (C, C++, Python, Perl, Verilog, SystemC are the
> main languages).

This is off-topic, since it's about C++, but I'll jump in anyway.

There is a valid reason for writing, for example, `::std::string`
rather than `std::string`.  The identifier `std` is not reserved,
so it would be possible to define a local class or namespace named
`std` with a member named `string`.  Then `std::string` would refer
to that member, not to the standard type declared in the <string>
header.  `::std::string` is unambiguous and doesn't break anything.

It's a trick for avoiding a problem that's unlikely to occur in
practice, and that can be easily avoided by not redefining `std`.
It might partially guard against accidental inclusion of malicious
headers, but if that's a possibility you're probably screwed anyway.
It clutters the code and it's non-idiomatic.  But it is defensible.

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

[toc] | [prev] | [standalone]

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

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

csiph-web