Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #105584 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2017-03-08 10:04 -0800 |
| Last post | 2017-03-13 06:13 -0700 |
| Articles | 20 on this page of 108 — 20 participants |
Back to article view | Back to comp.lang.c
lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-08 10:04 -0800
Re: lambda functions in C BartC <bc@freeuk.com> - 2017-03-08 18:20 +0000
Re: lambda functions in C Chad <cdalten@gmail.com> - 2017-03-08 11:12 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-08 11:36 -0800
Re: lambda functions in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-08 20:43 +0000
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-08 21:55 +0100
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-08 13:18 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 12:44 -0800
Re: lambda functions in C Chad <cdalten@gmail.com> - 2017-03-08 13:03 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-08 11:33 -0800
Re: lambda functions in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-08 20:46 +0000
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-08 13:25 -0800
Re: lambda functions in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-10 13:55 -0500
Re: lambda functions in C supercat@casperkitty.com - 2017-03-10 11:09 -0800
Re: lambda functions in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-10 14:51 -0500
Re: lambda functions in C BartC <bc@freeuk.com> - 2017-03-10 19:19 +0000
Re: lambda functions in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-10 14:53 -0500
Re: lambda functions in C BartC <bc@freeuk.com> - 2017-03-11 14:17 +0000
Re: lambda functions in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-11 06:55 -0800
Re: lambda functions in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-11 07:05 -0800
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-08 13:55 -0800
Re: lambda functions in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-08 23:41 +0000
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-09 05:03 -0800
Re: lambda functions in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-09 14:06 +0000
Re: lambda functions in C BartC <bc@freeuk.com> - 2017-03-09 14:20 +0000
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-09 08:07 -0800
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-09 21:50 +0100
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-09 23:38 +0100
Re: lambda functions in C Ike Naar <ike@iceland.freeshell.org> - 2017-03-09 22:46 +0000
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 08:39 +0100
Re: lambda functions in C Ike Naar <ike@iceland.freeshell.org> - 2017-03-10 08:03 +0000
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 09:22 +0100
Re: lambda functions in C Ike Naar <ike@iceland.freeshell.org> - 2017-03-10 19:24 +0000
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 23:23 +0100
Re: lambda functions in C Ike Naar <ike@iceland.freeshell.org> - 2017-03-11 18:02 +0000
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-09 20:48 -0500
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 08:57 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-10 11:26 -0500
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 17:53 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-10 13:17 -0500
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-11 17:11 +0100
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-10 00:38 -0800
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 10:23 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-10 11:37 -0500
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-10 09:07 -0800
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-10 13:22 -0500
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-10 10:47 -0800
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-10 14:57 -0500
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-10 12:26 -0800
Re: lambda functions in C Chad <cdalten@gmail.com> - 2017-03-10 12:49 -0800
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 23:32 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-11 12:26 -0500
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-11 17:17 +0100
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-11 10:26 -0800
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-11 19:48 +0100
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-11 12:02 -0800
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-12 09:14 +1300
Re: lambda functions in C "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-11 15:44 -0500
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-12 09:51 +1300
Re: lambda functions in C "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-11 16:11 -0500
Re: lambda functions in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-11 22:21 +0100
Re: lambda functions in C jameskuyper@verizon.net - 2017-03-11 13:36 -0800
Re: lambda functions in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-11 23:48 +0100
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-12 11:55 +1300
Re: lambda functions in C "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-11 18:34 -0500
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-12 15:23 +1300
Re: lambda functions in C BartC <bc@freeuk.com> - 2017-03-12 11:42 +0000
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-12 13:49 +0100
Re: lambda functions in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-12 10:56 -0700
Re: lambda functions in C jameskuyper@verizon.net - 2017-03-11 15:30 -0800
Re: lambda functions in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-12 00:37 +0100
Re: lambda functions in C Keith Thompson <kst-u@mib.org> - 2017-03-11 17:23 -0800
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-12 14:32 +0100
Re: lambda functions in C Gareth Owen <gwowen@gmail.com> - 2017-03-12 07:22 +0000
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-12 11:10 +1300
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-12 11:08 +1300
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-12 00:17 +0100
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-12 14:14 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-12 09:54 -0400
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-12 15:10 +0100
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-12 08:08 -0700
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-12 16:49 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-12 14:28 -0400
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-13 00:03 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-12 19:15 -0400
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-12 18:18 +0100
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-12 10:42 -0700
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-12 20:53 +0100
Re: lambda functions in C supercat@casperkitty.com - 2017-03-10 07:09 -0800
Re: lambda functions in C supercat@casperkitty.com - 2017-03-10 08:56 -0800
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 08:49 +0100
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-09 04:12 -0800
Re: lambda functions in C Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2017-03-09 10:38 +0100
Re: lambda functions in C Siri Cruise <chine.bleu@yahoo.com> - 2017-03-09 08:48 -0800
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-09 09:45 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-09 09:51 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-09 09:50 -0800
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-09 11:08 -0800
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-10 08:22 +1300
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-09 12:12 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-09 11:29 -0800
Re: lambda functions in C Siri Cruise <chine.bleu@yahoo.com> - 2017-03-09 13:33 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-09 13:42 -0800
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-10 11:02 +1300
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-09 14:30 -0800
Re: lambda functions in C Siri Cruise <chine.bleu@yahoo.com> - 2017-03-09 15:07 -0800
Re: lambda functions in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-11 21:45 +0100
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 06:13 -0700
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-11 22:21 +0100 |
| Message-ID | <oa1piq$rf5$1@dont-email.me> |
| In reply to | #105828 |
Le 11/03/2017 à 22:11, James R. Kuyper a écrit : > My own personal real-world experience with C++ is too limited to justify > making any generalizations, but what little C++ code I've had to work > with so far suffers from design that makes it difficult to determine > where to look for the code that implements a particular feature of the > program. Put a breakpoint in the feature and you see it. C++ needs a compiler/debugger to be understood. Reading the code is quite hopeless. With a debugger and the source code, you can add a patch in C. (The subset of C that C++ accepts of course). This allows you to not meddle with the C++ code and leave it intact. C++ code is very fragile, and when I add a patch I try as I can to NOT to mess around with it. More problems give the situations where there is a bug and you have to fix it.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-03-11 13:36 -0800 |
| Message-ID | <ff891f05-e5aa-4580-85cb-6b1ea02d97b9@googlegroups.com> |
| In reply to | #105830 |
On Saturday, March 11, 2017 at 4:21:14 PM UTC-5, jacobnavia wrote: > Le 11/03/2017 à 22:11, James R. Kuyper a écrit : > > My own personal real-world experience with C++ is too limited to justify > > making any generalizations, but what little C++ code I've had to work > > with so far suffers from design that makes it difficult to determine > > where to look for the code that implements a particular feature of the > > program. > > Put a breakpoint in the feature and you see it. C++ needs a > compiler/debugger to be understood. Reading the code is quite hopeless. How do you determine where to place the breakpoint if you haven't figured out which lines of code implement that feature? For instance, right now I'm trying to figure out which lines of code were used to apply the leap second that occurred at the end of last year. I'm searching the code base for files named "leap" and lines containing "leap". How could I use your approach to avoid having to perform that search?
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-11 23:48 +0100 |
| Message-ID | <oa1und$c40$1@dont-email.me> |
| In reply to | #105832 |
Le 11/03/2017 à 22:36, jameskuyper@verizon.net a écrit : > right now I'm trying to figure out which lines of code were used to apply the leap second that occurred at the end of last year. Difficult. You have all my sympathy but there are no ready made solutions. But it would be nice, to understand what is going on, to put breakpoints in the constructor of the time classes (if any). I follow variables in the debugger, and see where things are getting done. The code is probably buried in some time stamp constructor, where the machine is calculating the elapsed seconds or similar. Maybe I am spoiled by the debugger and there other methods of course. Grep is very useful and I fixed several problems last year using it. But those were minor problems caused by the constant changing of the language (it changes every 3 years or so). In a really hard problem like that, use grep, the debugger, anything that can give you some info. Good luck.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-12 11:55 +1300 |
| Message-ID | <eijdjfFhe2lU5@mid.individual.net> |
| In reply to | #105836 |
On 03/12/17 11:48 AM, jacobnavia wrote: > > But those were minor problems caused by the constant changing of the > language (it changes every 3 years or so). 2011-1998 = 3? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-11 18:34 -0500 |
| Message-ID | <4c395d9a-b6c4-4273-e3f8-ba6ebb41761c@verizon.net> |
| In reply to | #105837 |
On 03/11/2017 05:55 PM, Ian Collins wrote: > On 03/12/17 11:48 AM, jacobnavia wrote: >> >> But those were minor problems caused by the constant changing of the >> language (it changes every 3 years or so). > > 2011-1998 = 3? Actual revisions: 2003-1998 = 5 2011-2003 = 8 2014-2011 = 3 Currently planned revisions: 2017-2014 = 3 2020-2017 = 3
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-12 15:23 +1300 |
| Message-ID | <eijpoeFhe2lU6@mid.individual.net> |
| In reply to | #105840 |
On 03/12/17 12:34 PM, James R. Kuyper wrote: > On 03/11/2017 05:55 PM, Ian Collins wrote: >> On 03/12/17 11:48 AM, jacobnavia wrote: >>> >>> But those were minor problems caused by the constant changing of the >>> language (it changes every 3 years or so). >> >> 2011-1998 = 3? > > Actual revisions: > 2003-1998 = 5 2003 was just a mop up of DRs, not language changes. > 2011-2003 = 8 > 2014-2011 = 3 2014 was what 2011 should have been! > Currently planned revisions: > 2017-2014 = 3 > 2020-2017 = 3 yep, lots new stuff on the horizon.. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-12 11:42 +0000 |
| Message-ID | <oa3c1d$1nn$1@dont-email.me> |
| In reply to | #105845 |
On 12/03/2017 02:23, Ian Collins wrote: > On 03/12/17 12:34 PM, James R. Kuyper wrote: >> On 03/11/2017 05:55 PM, Ian Collins wrote: >>> On 03/12/17 11:48 AM, jacobnavia wrote: >>>> >>>> But those were minor problems caused by the constant changing of the >>>> language (it changes every 3 years or so). >>> >>> 2011-1998 = 3? >> >> Actual revisions: >> 2003-1998 = 5 > > 2003 was just a mop up of DRs, not language changes. > >> 2011-2003 = 8 >> 2014-2011 = 3 > > 2014 was what 2011 should have been! > >> Currently planned revisions: >> 2017-2014 = 3 >> 2020-2017 = 3 > > yep, lots new stuff on the horizon.. Why? I thought C++ could already do everything. (Or do the new changes make the language simpler and smaller? Now that would be worthwhile ...) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-03-12 13:49 +0100 |
| Message-ID | <20170312134931.97cbad34ebd34652a269883e@gmail.com> |
| In reply to | #105851 |
On Sun, 12 Mar 2017 11:42:12 +0000 BartC <bc@freeuk.com> wrote: > Why? I thought C++ could already do everything. > > (Or do the new changes make the language simpler and smaller? Now that > would be worthwhile ...) They should do like the R7RS standard for Scheme, a bloated language called C++ and a efficient language called C. :o)
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-03-12 10:56 -0700 |
| Message-ID | <8f351425-d172-4c3d-88c8-86abde7804a3@googlegroups.com> |
| In reply to | #105851 |
Bartc wrote: > Ian Collins wrote: > > yep, lots new stuff on the horizon.. > > Why? I thought C++ could already do everything. > > (Or do the new changes make the language simpler and smaller? Now that > would be worthwhile ...) You literally made me LOL, Bart. I suddenly saw a "Touché" in my mind. :-) Thank you, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-03-11 15:30 -0800 |
| Message-ID | <66cb9d2d-bae2-47db-a5e0-a2cbc167e871@googlegroups.com> |
| In reply to | #105836 |
On Saturday, March 11, 2017 at 5:49:00 PM UTC-5, jacobnavia wrote:
> Le 11/03/2017 à 22:36, jameskuyper@verizon.net a écrit :
> > right now I'm trying to figure out which lines of code were used to apply the leap second that occurred at the end of last year.
>
> Difficult.
Not really - I tracked down the relevant code while waiting for your answer. I still have one more step in the search that I'm putting off till tomorrow, but it should be only another half-hour or so.
What I was trying to find out is what your advice meant. I can put breakpoints on lines of code - I have no idea how to place them on features.
> ... You have all my sympathy but there are no ready made
> solutions. But it would be nice, to understand what is going on, to put
> breakpoints in the constructor of the time classes (if any).
It actually occurs during conversions between one kind of time stamp and another. Had I been designing the code, those time stamps would have had associated classes, and those conversions would have been done by converting constructors, so your advice wouldn't have been wrong - but that's not how the authors decided to design this.
> I follow variables in the debugger, and see where things are getting
> done. The code is probably buried in some time stamp constructor, where
> the machine is calculating the elapsed seconds or similar.
If I'd known which variable to watch, I could have figured out where the leap second conversion was occurring just by reading the code referring to that variable. My problem was locating the relevant variable.
> Maybe I am spoiled by the debugger and there other methods of course.
> Grep is very useful and I fixed several problems last year using it.
Oh yes, I make extensive use of grep. A command I've issued many times this afternoon was:
grep -l search_string `find . -name "*.cpp" -o -name "*.h"`
The find command implies something about what the fundamental problem is - I had no easy way to figure out which of several thousand source code files was the relevant one. If I knew the overall design like the back of my hand, it would probably be easy - but at this point the paw of a mythological beast that I'd never seen before would be a better metaphor for my current level of understanding. Most of those files are for library routines that won't actually be linked in to this particular program - but I have no easy way of restricting the search to the ones that will be linked in.
I should make that "beast" a shape-changer, because many other people are changing this particular body of code faster than I'm gaining an understanding of it.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-12 00:37 +0100 |
| Message-ID | <oa21ip$6q8$1@dont-email.me> |
| In reply to | #105839 |
Le 12/03/2017 à 00:30, jameskuyper@verizon.net a écrit : > I make extensive use of grep. A command I've issued many times this afternoon was: > > grep -l search_string `find . -name "*.cpp" -o -name "*.h"` Ahhh very interesting. I didn't thought about that. I used the recursive option of grep but could not figure out how to avoid binary files. Your command filters the files, much better... Will use that next time.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-11 17:23 -0800 |
| Message-ID | <lnk27vffu4.fsf@kst-u.example.com> |
| In reply to | #105841 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 12/03/2017 à 00:30, jameskuyper@verizon.net a écrit :
>> I make extensive use of grep. A command I've issued many times this afternoon was:
>>
>> grep -l search_string `find . -name "*.cpp" -o -name "*.h"`
>
> Ahhh very interesting. I didn't thought about that. I used the
> recursive option of grep but could not figure out how to avoid binary
> files. Your command filters the files, much better...
>
> Will use that next time.
If you use bash with the "globstar" option enabled
"shopt -s globstar"
(and I think zsh has a similar feature) this can be simplified to:
grep -l search_string **/*.{h,c}
(Using .c rather than .cpp to make this more nearly topical.) It also
deals better with odd characters, particularly spaces, in file and
directory names. Either solution can generate a *very* long command
line for large source trees, but modern systems and shells typically
don't have a problem with that. If it is a problem:
find . -name '*.h' -o -name '*.c' -print0 | xargs -0 grep -l search_string
assuming your find and xargs commands support these options (the GNU
findutils versions do).
The "ctags" command can also be useful if you're looking for
identifiers rather than more complex patterns (both vim and emacs
interface with it).
--
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-12 14:32 +0100 |
| Message-ID | <oa3igi$mg2$1@dont-email.me> |
| In reply to | #105843 |
On 12/03/17 02:23, Keith Thompson wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> Le 12/03/2017 à 00:30, jameskuyper@verizon.net a écrit :
>>> I make extensive use of grep. A command I've issued many times this afternoon was:
>>>
>>> grep -l search_string `find . -name "*.cpp" -o -name "*.h"`
>>
>> Ahhh very interesting. I didn't thought about that. I used the
>> recursive option of grep but could not figure out how to avoid binary
>> files. Your command filters the files, much better...
>>
>> Will use that next time.
>
> If you use bash with the "globstar" option enabled
>
> "shopt -s globstar"
>
> (and I think zsh has a similar feature) this can be simplified to:
>
> grep -l search_string **/*.{h,c}
It might be slightly off-topic, but that's a useful trick - I will
remember that one. Usually I can use recursive grep without worrying
about binaries, because my binaries are in a parallel directory tree,
but this will come in handy sometimes.
>
> The "ctags" command can also be useful if you're looking for
> identifiers rather than more complex patterns (both vim and emacs
> interface with it).
>
Other IDEs (like Eclipse) can usually do such searching too.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-03-12 07:22 +0000 |
| Message-ID | <878tobrmb2.fsf@gmail.com> |
| In reply to | #105839 |
jameskuyper@verizon.net writes: >> Maybe I am spoiled by the debugger and there other methods of course. >> Grep is very useful and I fixed several problems last year using it. > > Oh yes, I make extensive use of grep. A command I've issued many times > this afternoon was: > > grep -l search_string `find . -name "*.cpp" -o -name "*.h"` A command so helpful the ability to run in simply is built into emacs. (M-x grep-find). FWIW, I find it useful in large projects regardless of language. I run it over the Linux source tree on a weekly basis in my day job, usually to find the type of of a function pointer in a structure.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-12 11:10 +1300 |
| Message-ID | <eijauaFhe2lU4@mid.individual.net> |
| In reply to | #105830 |
On 03/12/17 10:21 AM, jacobnavia wrote: > Le 11/03/2017 à 22:11, James R. Kuyper a écrit : >> My own personal real-world experience with C++ is too limited to justify >> making any generalizations, but what little C++ code I've had to work >> with so far suffers from design that makes it difficult to determine >> where to look for the code that implements a particular feature of the >> program. > > Put a breakpoint in the feature and you see it. C++ needs a > compiler/debugger to be understood. Reading the code is quite hopeless. Or a decent programmer... > With a debugger and the source code, you can add a patch in C. > > (The subset of C that C++ accepts of course). This allows you to not > meddle with the C++ code and leave it intact. C++ code is very fragile, > and when I add a patch I try as I can to NOT to mess around with it. Spoken as a true non-believer... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-12 11:08 +1300 |
| Message-ID | <eijarjFhe2lU3@mid.individual.net> |
| In reply to | #105828 |
On 03/12/17 10:11 AM, James R. Kuyper wrote: > On 03/11/2017 03:51 PM, Ian Collins wrote: >> On 03/12/17 09:44 AM, James R. Kuyper wrote: >>> On 03/11/2017 03:14 PM, Ian Collins wrote: >>>> On 03/12/17 09:02 AM, Malcolm McLean wrote: >>>>> >>>>> However C++ software projects very frequently do fail. You don't get >>>>> a workable product before time and money run out. Of course projects >>>>> built with C can also fail, but it's not at all clear that the "++" >>>>> in C++ actually indicates that the success rate is greater. >>>> >>>> Projects fail due to broken process, not the language used. >>> >>> Many projects do fail due to broken process, but it's a mistake to claim >>> that's the only way they can fail. Among many other possibilities, they >>> can also fail due to making a bad choice of implementation languages. >> >> Where that is the case, the process for choosing the implementation >> language is broken :) > > If you're going to approach the issue that way, your claim that > "projects fail due to broken process" is no justification for rejecting > his claim. His claim becomes equivalent to "Projects often fail due to > use of a broken process that causes them to choose C++, when they > shouldn't have". Note that I am not agreeing with Malcolm, merely > pointing out that your response is in the wrong form to count as a > proper rebuttal. Humour mode disengaged? > My own personal real-world experience with C++ is too limited to justify > making any generalizations, but what little C++ code I've had to work > with so far suffers from design that makes it difficult to determine > where to look for the code that implements a particular feature of the > program. I don't know whether to blame that on the language, or the > designers, or the inherent complexity of the tasks the programs need to > do - but it certainly doesn't give me examples to counter Malcolm's claim. I have probably been involved with more C than C++ projects. One C projects came close to failure due to contractual wrangling and management's defense contractor mentality (which was at odds with a commercial project). This project was saved by throwing money at it and allowing the team to adopt our own process. A similar (also C project) at another site did fail due not adapting. None of the C++ projects I have worked on failed. So from my experience I could claim that C projects are more likely to fail, but I wouldn't do so because the problems ran way deeper than the choice of language. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-03-12 00:17 +0100 |
| Message-ID | <20170312001756.406be9c1658248ca320371dc@gmail.com> |
| In reply to | #105815 |
On Sat, 11 Mar 2017 12:02:22 -0800 (PST) Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > However C++ software projects very frequently do fail. You don't get > a workable product before time and money run out. Of course projects > built with C can also fail, but it's not at all clear that the "++" > in C++ actually indicates that the success rate is greater. Actually C++ projects fail because nobody would use a swiss knife to cut anything if not himself. :o)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-12 14:14 +0100 |
| Message-ID | <oa3hf7$iu1$1@dont-email.me> |
| In reply to | #105815 |
On 11/03/17 21:02, Malcolm McLean wrote: > On Saturday, March 11, 2017 at 6:48:47 PM UTC, David Brown wrote: >> On 11/03/17 19:26, Malcolm McLean wrote: >>> On Saturday, March 11, 2017 at 4:17:51 PM UTC, David Brown wrote: >>>> On 10/03/17 21:26, Malcolm McLean wrote: >>>> >>>> I have to ask - to what are you referring as "/the/ important >>>> problem in software design" ? >>>> >>>> The important problem is how to achieve behaviour (which we know >>>> computers are capable of), to time and in a form which is usable >>>> by our clients / customers / fans. >> >> Ah, so the single major problem in software design today is how to do >> good software design? >> >> Your claim is a bit like telling us that "Bicycles are getting really >> popular now. Why now? Because cars have run their course - no one now >> believes they solve the important problem in transportation." The >> important problem in transportation being transporting things. >> > Yes,, but it's true enough to say that bicycles are getting really > popular now, because cars have run their course - congestion, pollution, > danger to pedestrians. I suppose you must be using the phrase "run their course" in a different way from everyone else. Horse-drawn carriages have run their course - they are very rarely bought or used these days. Cars are extremely popular, both for using existing cars and as a choice for new transportation uses. They have /not/ "run their course", by any stretch of the imagination. > > However C++ software projects very frequently do fail. You don't get > a workable product before time and money run out. Of course projects > built with C can also fail, but it's not at all clear that the "++" > in C++ actually indicates that the success rate is greater. C++ is not an OOP language - it is a "multi-paradigm language". It started life from adding OOP features to C (to go along with the existing procedural programming), but it also supports generic programming and steadily more functional programming - as well as the original procedural or imperative programming. Software projects in general often fail (at least to some extent). I know of no correlation between the choice of language and the risk of failure showing that the language itself and/or the use of OOP is to blame. >> >>> The other important problem is to determine what computers are capable >>> of, there it's possible Lisp makes a contribution, but it doesn't >>> solve that problem either. Object-orientation doesn't pretend to try >>> to help with that problem. >>> >> >> If you are talking about theory, then no real programming language is >> involved - it's a mathematical problem, mainly of mathematical interest. >> >> If you are talking about practice, then Lisp, OOP languages, and a vast >> array of other languages and computation models are used to see what can >> be done with computers. >> > Mainly of linguistic interest, I'd say. There are things which are > mathematically impossible to compute, but what people generally want > is a robot like R2D2 which understands instructions given to it, > even if it only answers back in bleeps. Needless to say, R2D2 was a > man dressed up (a far better actor than C3PO, who looked like a man > dressed up). > That is just one particular problem in the computing world. And the challenge here is mainly algorithmic - finding out how language can be understood. It has nothing to do with any particular language, LISP, C, C++, or any particular programming paradigm (there are many possibilities for how language comprehension software could be designed). It also has nothing to do with theoretical computability - until you have algorithms, you can't decide if they are computable or not.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-12 09:54 -0400 |
| Message-ID | <oa3jp5$qak$1@jstuckle.eternal-september.org> |
| In reply to | #105856 |
On 3/12/2017 9:14 AM, David Brown wrote: > On 11/03/17 21:02, Malcolm McLean wrote: >> On Saturday, March 11, 2017 at 6:48:47 PM UTC, David Brown wrote: >>> On 11/03/17 19:26, Malcolm McLean wrote: >>>> On Saturday, March 11, 2017 at 4:17:51 PM UTC, David Brown wrote: >>>>> On 10/03/17 21:26, Malcolm McLean wrote: >>>>> >>>>> I have to ask - to what are you referring as "/the/ important >>>>> problem in software design" ? >>>>> >>>>> The important problem is how to achieve behaviour (which we know >>>>> computers are capable of), to time and in a form which is usable >>>>> by our clients / customers / fans. >>> >>> Ah, so the single major problem in software design today is how to do >>> good software design? >>> >>> Your claim is a bit like telling us that "Bicycles are getting really >>> popular now. Why now? Because cars have run their course - no one now >>> believes they solve the important problem in transportation." The >>> important problem in transportation being transporting things. >>> >> Yes,, but it's true enough to say that bicycles are getting really >> popular now, because cars have run their course - congestion, pollution, >> danger to pedestrians. > > I suppose you must be using the phrase "run their course" in a different > way from everyone else. Horse-drawn carriages have run their course - > they are very rarely bought or used these days. Cars are extremely > popular, both for using existing cars and as a choice for new > transportation uses. They have /not/ "run their course", by any stretch > of the imagination. > Malcolm is in the U.K., where automobile use is much lower than here in the United States. OTOH, bicycles are much more popular. >> >> However C++ software projects very frequently do fail. You don't get >> a workable product before time and money run out. Of course projects >> built with C can also fail, but it's not at all clear that the "++" >> in C++ actually indicates that the success rate is greater. > > C++ is not an OOP language - it is a "multi-paradigm language". It > started life from adding OOP features to C (to go along with the > existing procedural programming), but it also supports generic > programming and steadily more functional programming - as well as the > original procedural or imperative programming. > You can do true OOP in C++, so in that respect it is an OOP language. No, you don't HAVE to do OOP, but that does not mean it is not an OOP language. > Software projects in general often fail (at least to some extent). I > know of no correlation between the choice of language and the risk of > failure showing that the language itself and/or the use of OOP is to blame. > Software projects fail for a number of reasons. I've been involved with several large C++ projects over the years which have had great success. At the same time, I've been involved with some C projects which have failed. >>> >>>> The other important problem is to determine what computers are capable >>>> of, there it's possible Lisp makes a contribution, but it doesn't >>>> solve that problem either. Object-orientation doesn't pretend to try >>>> to help with that problem. >>>> >>> >>> If you are talking about theory, then no real programming language is >>> involved - it's a mathematical problem, mainly of mathematical interest. >>> >>> If you are talking about practice, then Lisp, OOP languages, and a vast >>> array of other languages and computation models are used to see what can >>> be done with computers. >>> >> Mainly of linguistic interest, I'd say. There are things which are >> mathematically impossible to compute, but what people generally want >> is a robot like R2D2 which understands instructions given to it, >> even if it only answers back in bleeps. Needless to say, R2D2 was a >> man dressed up (a far better actor than C3PO, who looked like a man >> dressed up). >> > > That is just one particular problem in the computing world. And the > challenge here is mainly algorithmic - finding out how language can be > understood. It has nothing to do with any particular language, LISP, C, > C++, or any particular programming paradigm (there are many > possibilities for how language comprehension software could be > designed). It also has nothing to do with theoretical computability - > until you have algorithms, you can't decide if they are computable or not. > > -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-03-12 15:10 +0100 |
| Message-ID | <20170312151057.b01ce5356d8f96a0ea2f19ca@gmail.com> |
| In reply to | #105862 |
On Sun, 12 Mar 2017 09:54:22 -0400 Jerry Stuckle <jstucklex@attglobal.net> wrote: > Malcolm is in the U.K., where automobile use is much lower than here in > the United States. OTOH, bicycles are much more popular. Not to mention that United States is the country of fat consumers by choice while the urbanization is comparable to the UK. https://en.wikipedia.org/wiki/Urbanization_by_country http://i.imgur.com/eRhICfG.jpg
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web