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

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

Improving productivity

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

Contents

  Improving productivity janus <emekamicro@gmail.com> - 2016-08-07 06:46 -0700
    Re: Improving productivity Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-07 18:52 -0700
    Re: Improving productivity Real Troll <real.troll@trolls.com> - 2016-08-07 22:59 -0400
    Re: Improving productivity fir <profesor.fir@gmail.com> - 2016-08-08 00:49 -0700
      Re: Improving productivity fir <profesor.fir@gmail.com> - 2016-08-08 01:32 -0700
    Re: Improving productivity luser droog <luser.droog@gmail.com> - 2016-08-08 08:04 -0700
      Re: Improving productivity Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-08-08 09:24 -0600
      Re: Improving productivity Keith Thompson <kst-u@mib.org> - 2016-08-08 09:22 -0700
        Re: Improving productivity Nick Bowler <nbowler@draconx.ca> - 2016-08-08 18:47 +0000
        Re: Improving productivity luser droog <luser.droog@gmail.com> - 2016-08-08 15:23 -0700
          Re: Improving productivity Udyant Wig <udyant.wig@gmail.com> - 2016-08-09 11:27 +0530
      Re: Improving productivity Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 19:59 +0100
        Re: Improving productivity luser droog <luser.droog@gmail.com> - 2016-08-08 20:16 -0700
    Re: Improving productivity Nobody <nobody@nowhere.invalid> - 2016-08-10 03:19 +0100
    Re: Improving productivity jgh@mdfs.net - 2016-08-12 13:59 -0700

#91854 — Improving productivity

Hello All,

I have noticed that my productivity is pretty low when programming with C language compared to say JavaScript. I am suspecting that I am not using the right tools and systems to properly and quickly zero in on errors and bugs.  Please, list the right tools/systems one could use to troubleshoot and zero in on bugs. And also test suites.

Thanks.

Janus

[toc] | [next] | [standalone]

#91908

On Sunday, August 7, 2016 at 2:47:14 PM UTC+1, janus wrote:
> Hello All,
> 
> I have noticed that my productivity is pretty low when programming 
> with C language compared to say JavaScript. I am suspecting that
> I am not using the right tools and systems to properly and quickly
> zero in on errors and bugs.  Please, list the right tools/systems 
> one could use to troubleshoot and zero in on bugs. And also test 
> suites.
> 
Everyone works differently, and there are different problems. Currently
I'm writing a lot of graphics routines, for example, which can't
easily be tested automatically (writing the test harness to check that
the output is correct is harder than writing the function itself
and essentially incorporates the same problem), but can easily be
inspected visually, if you have suitable output device.

But tend to use this method.
10 separate out "functions" (called "Malcolm functions by some people
on clc, though I don't use the term myself) for "procedures". Functions
calculate things, procedures do IO.

Every function should be written in pure, portable ANSI C, with a
controlled list of dependencies. If it's practical to make it leaf, 
make it leaf. If you need workspace, allow malloc() and free().
If you need math and string functions, allow a dependency on the rest
of the standard library.  If the function is long, allow static
subroutines in the same file. If you must, depend on one other file
you wrote yourself. If you depend on an external library, it's a very
serious situation. Do you have skills to implement the external
function yourself? Can you guarantee that the external library will
always be available? it's a last resort.

Assuming you don't need an external library, you now have a small
collection of self-contained C files with, hopefully, clean
interfaces, which carry out functions.
So write two test routines. One is the internal "testmyfunctions",
which sits in myfunctions.c. It will need to depend on stdio.h.
It calls the static functions and unit test them. It also acts as
documentation.
Then write testmain.c This calls the functions as caller would,
doing black box testing.

Now put the files into their own temporary directory and compile
independently on Linux, and run valgrind. That gets rid of most of 
your memory access errors. Examine the test output for logic errors.
You can also run gprof to test for performance where that's an issue.

When you're happy, move from the Linux box back into your development
environment.

Procedures - same drill, but you need to specify whether it's portable
or not. Not all procedures depend solely on stdio.h, even if they do,
often they need to be written to accept funny streams. Also, end user
controls the input, so this is the portal for malicious or 
subtly corrupted input. You can't always valgrind on Linux.


 

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

#91913

On 07/08/2016 14:46, janus wrote:
> I am suspecting that I am not using the right tools and 
> systems to properly and quickly zero in on errors and bugs.  
> Please, list the right tools/systems one could use to 
> troubleshoot and zero in on bugs. And also test suites.
>

Are there any particular tools you are currently using?  I am, of course 
assuming you are a seasoned C/C++ programmer so you may want to try 
Microsoft Visual Studio Community Edition (Free version)  or Embarcadero 
C++ Builder (they had a started edition free of charge but this deal 
must have passed).

These tools have IDE and you can write and test your programs from 
within the IDE and any errors are pointed out almost instantly.  For 
learners like yours sincerely, Notepad++  and free BC++ from embarcadero 
is all I need.  I write my code in Notepad++ and compile the source in 
command-line using BCC32c.exe.  Any errors are pointed out by line 
numbers and these can be corrected in Notepad++ again, saved and recompiled.

> Embarcadero C++ 7.20 for Win32 Copyright (c) 2012-2016 Embarcadero 
> Technologies, Inc.

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

#91924

W dniu niedziela, 7 sierpnia 2016 15:47:14 UTC+2 użytkownik janus napisał:
> Hello All,
> 
> I have noticed that my productivity is pretty low when programming with C language compared to say JavaScript. I am suspecting that I am not using the right tools and systems to properly and quickly zero in on errors and bugs.  Please, list the right tools/systems one could use to troubleshoot and zero in on bugs. And also test suites.
> 
> Thanks.
> 
> Janus

they say you could improve your productivity by getting more experienced (in 
the field you want productivity) 

it is somewhat doubtfull if you can get more productivity by just using 
something becouse you will have to learn it too and this learn is 'big 
learn' too
 - besides after all most hard problems in programming are 'conceptual' 
ones (or how to call it), outside of language and libraries

you got a classical enthusiasm of the noob - it comes from lack of 
conscousness how some things really look and being overoptymistic there

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

#91928

W dniu poniedziałek, 8 sierpnia 2016 09:49:12 UTC+2 użytkownik fir napisał:
> W dniu niedziela, 7 sierpnia 2016 15:47:14 UTC+2 użytkownik janus napisał:
> > Hello All,
> > 
> > I have noticed that my productivity is pretty low when programming with C language compared to say JavaScript. I am suspecting that I am not using the right tools and systems to properly and quickly zero in on errors and bugs.  Please, list the right tools/systems one could use to troubleshoot and zero in on bugs. And also test suites.
> > 
> > Thanks.
> > 
> > Janus
> 
> they say you could improve your productivity by getting more experienced (in 
> the field you want productivity) 
> 
> it is somewhat doubtfull if you can get more productivity by just using 
> something becouse you will have to learn it too and this learn is 'big 
> learn' too
>  - besides after all most hard problems in programming are 'conceptual' 
> ones (or how to call it), outside of language and libraries
> 
> you got a classical enthusiasm of the noob - it comes from lack of 
> conscousness how some things really look and being overoptymistic there

for example i often hoped (when being noob/in your position) that when i learn language/writing procedures/using libs well/good that the reast will be 
easy

now after some years (like 10) i know c/writing procedures/using libs quite 
well but the rest is still damn hard (writing apps looks like pickaxing in the hard wall, sometimes stone is crushed but slow and you get tired and exhausted really and there is a lot of it in the mountain wall )

there is a progress and there is a good progress, effects are as okay is i 
would want them, but this progress is damn slow meandric and exhausting to the extend i feel an urge to maybe even redefine some of my attitude

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

#91957

On Sunday, August 7, 2016 at 8:47:14 AM UTC-5, janus wrote:
> Hello All,
> 
> I have noticed that my productivity is pretty low when programming with C language compared to say JavaScript. I am suspecting that I am not using the right tools and systems to properly and quickly zero in on errors and bugs.  Please, list the right tools/systems one could use to troubleshoot and zero in on bugs. And also test suites.
> 

I've grown fond of the 'classic' tools and highly 
recommend them: bash (or whatever your command shell is),
make (to automate compilation), and your text editor.
The textbook for this is Kernighan and Pike, /The Unix 
Programming Environment/. Also get a used copy of the
Unix manual, volume 1, which is all little essays and
papers about how C and Unix were initially ported to
several environments and how the language evolved to 
cope with these and lots of other cool stuff. These 2
books should be on your shelf right between K&R and 
van der Linden.

The text editor is the tool that will repay increased 
familiarity. In the "unix" milieu, you can use the same
editor for almost any language and the whole operating
system becomes your "IDE".

If you have a makefile written, then in vi you just type

  :!make<RET>

to build your project. That's light years ahead of opening
(or suspending to) a shell and typing `gcc ...`.

In emacs it's even shorter: 

  ^x^m          (where ^ indicates the ctrl- key combo)

For unit testing, there are many frameworks available. I've
used `check` successfully and it's pretty straightforward
and works well and combines easily with autotools and stuff.

But I've also become very fond of this "minimal" test suite
which I've augmented with more magic:
http://stackoverflow.com/questions/32163935/compose-a-combined-test-suite-program-from-a-collection-of-unit-tests

In summary, all of the text-manipulation tools of the command-shell
are available to the makefile to manipulate the source text for the
benefit of the compiler. sed, grep, perl, m4 (!). If something is
difficult to 'write' in C directly, it may be easy to generate from
a scripting language. <!-- any language you're more familiar with, even js

Or use an IDE.

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

#91960

luser droog <luser.droog@gmail.com> writes:

> On Sunday, August 7, 2016 at 8:47:14 AM UTC-5, janus wrote:
>> Hello All,
>> 
>> I have noticed that my productivity is pretty low when programming
>> with C language compared to say JavaScript. I am suspecting that I
>> am not using the right tools and systems to properly and quickly
>> zero in on errors and bugs.  Please, list the right tools/systems
>> one could use to troubleshoot and zero in on bugs. And also test
>> suites.
>> 
>
> I've grown fond of the 'classic' tools and highly 
> recommend them: bash (or whatever your command shell is),
> make (to automate compilation), and your text editor.
> The textbook for this is Kernighan and Pike, /The Unix 
> Programming Environment/. Also get a used copy of the
> Unix manual, volume 1, which is all little essays and
> papers about how C and Unix were initially ported to
> several environments and how the language evolved to 
> cope with these and lots of other cool stuff. These 2
> books should be on your shelf right between K&R and 
> van der Linden.
>
> The text editor is the tool that will repay increased 
> familiarity. In the "unix" milieu, you can use the same
> editor for almost any language and the whole operating
> system becomes your "IDE".
>
> If you have a makefile written, then in vi you just type
>
>   :!make<RET>
>
> to build your project. That's light years ahead of opening
> (or suspending to) a shell and typing `gcc ...`.
>
> In emacs it's even shorter: 
>
>   ^x^m          (where ^ indicates the ctrl- key combo)
>
> For unit testing, there are many frameworks available. I've
> used `check` successfully and it's pretty straightforward
> and works well and combines easily with autotools and stuff.
>
> But I've also become very fond of this "minimal" test suite
> which I've augmented with more magic:
> http://stackoverflow.com/questions/32163935/compose-a-combined-test-suite-program-from-a-collection-of-unit-tests
>
> In summary, all of the text-manipulation tools of the command-shell
> are available to the makefile to manipulate the source text for the
> benefit of the compiler. sed, grep, perl, m4 (!). If something is
> difficult to 'write' in C directly, it may be easy to generate from
> a scripting language. <!-- any language you're more familiar with, even js
>
> Or use an IDE.

I'll echo everything you have to say about emacs+make, and add gdb to
the mix for debugging (especially run from inside emacs).  I imagine
something similar is also possible with vi, but I'm an emacsophile.
-- 
"Erwin, have you seen the cat?" -- Mrs. Shrödinger

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

#91970

luser droog <luser.droog@gmail.com> writes:
[...]
> I've grown fond of the 'classic' tools and highly 
> recommend them: bash (or whatever your command shell is),
> make (to automate compilation), and your text editor.
> The textbook for this is Kernighan and Pike, /The Unix 
> Programming Environment/. Also get a used copy of the
> Unix manual, volume 1, which is all little essays and
> papers about how C and Unix were initially ported to
> several environments and how the language evolved to 
> cope with these and lots of other cool stuff. These 2
> books should be on your shelf right between K&R and 
> van der Linden.

There are a lot of Unix manuals.  Can you provide a more specific
citation?

> The text editor is the tool that will repay increased 
> familiarity. In the "unix" milieu, you can use the same
> editor for almost any language and the whole operating
> system becomes your "IDE".
>
> If you have a makefile written, then in vi you just type
>
>   :!make<RET>
>
> to build your project. That's light years ahead of opening
> (or suspending to) a shell and typing `gcc ...`.

I rarely invoke commands from within vi (actually vim) like that.
I'd suspend the editor and type "make" from the shell prompt.
Of course you can use whichever approach you're more comfortable
with.

> In emacs it's even shorter: 
>
>   ^x^m          (where ^ indicates the ctrl- key combo)

Hmm, that doesn't work for me.  Does it depend on some mode that
I'm not using?

[...]

-- 
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]

#91982

On Mon, 08 Aug 2016 09:22:33 -0700, Keith Thompson wrote:
> luser droog <luser.droog@gmail.com> writes:
[...]
>> If you have a makefile written, then in vi you just type
>>
>>   :!make<RET>
>>
>> to build your project. That's light years ahead of opening
>> (or suspending to) a shell and typing `gcc ...`.
> 
> I rarely invoke commands from within vi (actually vim) like that.
> I'd suspend the editor and type "make" from the shell prompt.
> Of course you can use whichever approach you're more comfortable
> with.

In vim you can additionally do

  :make

(note, no exclamation point).  This is similar to :!make except the
editor looks at the console output, and navigates to the first error
(if there is one).  Then you can use editor commands to go to the next
error (:cn), and more.

That being said, I usually just run make in another shell.

Cheers,
  Nick

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

#91997

On Monday, August 8, 2016 at 11:15:49 AM UTC-5, Keith Thompson wrote:
> luser droog <luser.droog@gmail.com> writes:
> [...]
> > I've grown fond of the 'classic' tools and highly 
> > recommend them: bash (or whatever your command shell is),
> > make (to automate compilation), and your text editor.
> > The textbook for this is Kernighan and Pike, /The Unix 
> > Programming Environment/. Also get a used copy of the
> > Unix manual, volume 1, which is all little essays and
> > papers about how C and Unix were initially ported to
> > several environments and how the language evolved to 
> > cope with these and lots of other cool stuff. These 2
> > books should be on your shelf right between K&R and 
> > van der Linden.
> 
> There are a lot of Unix manuals.  Can you provide a more specific
> citation?
> 
> > The text editor is the tool that will repay increased 
> > familiarity. In the "unix" milieu, you can use the same
> > editor for almost any language and the whole operating
> > system becomes your "IDE".
> >
> > If you have a makefile written, then in vi you just type
> >
> >   :!make<RET>
> >
> > to build your project. That's light years ahead of opening
> > (or suspending to) a shell and typing `gcc ...`.
> 
> I rarely invoke commands from within vi (actually vim) like that.
> I'd suspend the editor and type "make" from the shell prompt.
> Of course you can use whichever approach you're more comfortable
> with.
> 
> > In emacs it's even shorter: 
> >
> >   ^x^m          (where ^ indicates the ctrl- key combo)
> 
> Hmm, that doesn't work for me.  Does it depend on some mode that
> I'm not using?
> 

My mistake. Yes, that's my local binding. In general,

  ^x compile<RET>

will do it.

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

#92004

luser droog <luser.droog@gmail.com> writes:
> My mistake. Yes, that's my local binding. In general,
>
>   ^x compile<RET>
>
> will do it.

Earlier, you said

| In emacs it's even shorter: 
|   ^x^m          (where ^ indicates the ctrl- key combo)

[`C-x' is the authoritative way to describe `Control x' with regard to
Emacs keys.]

`C-x compile' does not work as `C-x' is a prefix key.  Are you sure you
did not mean `M-x' (Alt on most current keyboards)?  `ESC x' works too.

-- 
Udyant Wig

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

#91984

luser droog <luser.droog@gmail.com> writes:

> On Sunday, August 7, 2016 at 8:47:14 AM UTC-5, janus wrote:
>> Hello All,
>> 
>> I have noticed that my productivity is pretty low when programming
>> with C language compared to say JavaScript. I am suspecting that I
>> am not using the right tools and systems to properly and quickly
>> zero in on errors and bugs.  Please, list the right tools/systems
>> one could use to troubleshoot and zero in on bugs. And also test
>> suites.
>> 
>
> I've grown fond of the 'classic' tools and highly 
> recommend them: bash (or whatever your command shell is),
> make (to automate compilation), and your text editor.
> The textbook for this is Kernighan and Pike, /The Unix 
> Programming Environment/. Also get a used copy of the
> Unix manual, volume 1, which is all little essays and
> papers about how C and Unix were initially ported to
> several environments and how the language evolved to 
> cope with these and lots of other cool stuff.

That sounds much more like Volume 2 (which, if memory serves, was in two
parts in V7 Unix).  Volume 1 was, apart from a very brief introduction,
all the well-known man sections.

<snip>
-- 
Ben.

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

#92000

On Monday, August 8, 2016 at 1:59:30 PM UTC-5, Ben Bacarisse wrote:
> luser droog <luser.droog@gmail.com> writes:
> 
> > On Sunday, August 7, 2016 at 8:47:14 AM UTC-5, janus wrote:
> >> Hello All,
> >> 
> >> I have noticed that my productivity is pretty low when programming
> >> with C language compared to say JavaScript. I am suspecting that I
> >> am not using the right tools and systems to properly and quickly
> >> zero in on errors and bugs.  Please, list the right tools/systems
> >> one could use to troubleshoot and zero in on bugs. And also test
> >> suites.
> >> 
> >
> > I've grown fond of the 'classic' tools and highly 
> > recommend them: bash (or whatever your command shell is),
> > make (to automate compilation), and your text editor.
> > The textbook for this is Kernighan and Pike, /The Unix 
> > Programming Environment/. Also get a used copy of the
> > Unix manual, volume 1, which is all little essays and
> > papers about how C and Unix were initially ported to
> > several environments and how the language evolved to 
> > cope with these and lots of other cool stuff.
> 
> That sounds much more like Volume 2 (which, if memory serves, was in two
> parts in V7 Unix).  Volume 1 was, apart from a very brief introduction,
> all the well-known man sections.

Yes. That should teach me not to post on my way out the door.
It's volume II that I was thinking of. Mine is the 1987 edition
printed by Prentice Hall.

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

#92042

On Sun, 07 Aug 2016 14:06:59 +0000, Stefan Ram wrote:

>   while others can't be done with C (writing a script that can be
>   embedded into a web page and be executed by a browsers).

You can do this with C. Emscripten uses LLVM to compile C to JavaScript.

Obviously, you wouldn't use it for something which was intended from the
outset to be a web application, but it can be a viable option for
"porting" existing C programs to the web.

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

#92214

The most useful tool I find is a pen and paper.

jgh

[toc] | [prev] | [standalone]

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

csiph-web