What are your C++ tools for development?

[Robert Hutchings]

Do you use an IDE like Code::Blocks or Eclipse? Or just Emacs or
vi/gcc/g++ on Linux/UNIX?

What about testing and debugging? Favorite tools?

[Wouter van Ooijen]

Robert Hutchings schreef op 14-Oct-14 4:30 PM:

> Do you use an IDE like Code::Blocks or Eclipse? Or just Emacs or
> vi/gcc/g++ on Linux/UNIX?
>
> What about testing and debugging? Favorite tools?

GCC
makescript
any editor that can shell out to make and interpret a compiler error
debugging: operator<<

Wouter van Ooijen

[Rick C. Hodgin]

Windows: Visual Studio 2003, Visual Studio 2008. You cannot beat
edit-and-continue. There is no other ability to write code which is
better suited to debugging. I also use the Visual Assist X plugin
for Visual Studio, which adds a lot of refactoring abilities which
make development so much nicer.

Linux: CodeLite IDE with GCC and GDB, though I find GDB to be hideous
and awful compared to Visual Studio's debugger. The IDE is close
enough, and GCC has vastly superior warnings and error catching. In
fact, in the Windows development I also use MinGW and GCC to help me
catch issues the Microsoft compilers do not. GCC does also give
several false positives, however.

Best regards,
Rick C. Hodgin

[Luca Risolia]

hm..false positives? for example?

[Rick C. Hodgin]

Line 322:
https://github.com/RickCHodgin/libsf/blob/master/source/vjr/sound/sound.cpp

Line 50:
https://github.com/RickCHodgin/libsf/blob/master/source/vjr/engine.cpp

You can use CodeLite and MinGW 4.8.1. Download CodeLite with MinGW
4.8.1 bundled:
http://www.libsf.org/software/

If you load vjr.workspace from here:
https://github.com/RickCHodgin/libsf/tree/master/source/vjr/vjr_mingw_gcc_codelite

And have cloned the project into c:\libsf\ ... then you'll see the
warnings GCC gives. In tracing through the code, I don't see why
they're being given (specifically the warning on lfHertz4, as it
does not give one on lfHertz1..3).

[Christopher Pisz]

Seeing how all my jobs have been targeting Windows platforms, except for
one, since graduation, my tools are "an MSDN subscription"

I liked Intel's Parallel studio for memory leak and deadlock detection,
but like all memory leak tools it goes bananas when going over a COM
boundry. COM needs to die and the world would be a better place without it.

[Jorgen Grahn]

On Tue, 2014-10-14, Robert Hutchings wrote:
> Do you use an IDE like Code::Blocks or Eclipse? Or just Emacs or
> vi/gcc/g++ on Linux/UNIX?

g++, Make, Emacs, Git, zsh and the infinite Unix toolbox.

> What about testing and debugging? Favorite tools?

Valgrind, tcpdmp, strace and ltrace. And the rest of Unix.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Marcel Mueller]

On 14.10.14 17.00, Rick C. Hodgin wrote:
> On Tuesday, October 14, 2014 10:31:11 AM UTC-4, Robert Hutchings wrote:
>> Do you use an IDE like Code::Blocks or Eclipse? Or just Emacs or
>> vi/gcc/g++ on Linux/UNIX?
>>
>> What about testing and debugging? Favorite tools?
>
> Windows: Visual Studio 2003, Visual Studio 2008. You cannot beat
> edit-and-continue.

I had not even one existing real life project where it ever worked
(VS2003, 2008, 2012). For me it only works for power point slides or
simple examples.
The only effect when I turn it on is that the code can no longer be
modified while debugging, which is even worse than without the feature.
I should note, that I usually work with web applications.

> There is no other ability to write code which is
> better suited to debugging.

In theory, yes.

> I also use the Visual Assist X plugin
> for Visual Studio, which adds a lot of refactoring abilities which
> make development so much nicer.

Well, refactoring is no powerful side of VS (without external tools).
Eclipse had always been far ahead of it.

> Linux: CodeLite IDE with GCC and GDB, though I find GDB to be hideous
> and awful compared to Visual Studio's debugger.

Well, and gdb is almost unusable without additional tools. The user
interface is horrible. It's strength is remoting over platform
boundaries, e.g. debugging ARM from x64.
When remote debugging with VS the speed decreases by some orders of
magnitude, almost unusable. Unfortunately x64 seem to trigger remote
debugging also even if you operate locally because VS is restricted to
32 bit. So we build all our .NET applications for any CPU and run it as
x86 even on x64 platforms, although this causes some performance
penalty, e.g. because atomic operations (Interlocked.*) with 64 bit
operands like long or DateTime create runtime overhead.

> The IDE is close
> enough, and GCC has vastly superior warnings and error catching.

First of all gcc can usually compile C++ code without major errors. With
VS I had problems to compile standard conform C++ code several times.
OK, I did not use much C++ with VS in the last years. In fact I talk
about VS <= 2008.

> GCC does also give several false positives, however.

Ack, sometimes.


Marcel

[Ian Collins]

Robert Hutchings wrote:
> Do you use an IDE like Code::Blocks or Eclipse? Or just Emacs or
> vi/gcc/g++ on Linux/UNIX?

Solaris Studio, g++, NetBeans (on Linux/Mac)

> What about testing and debugging? Favorite tools?

CppUnit, dtrace, dbx, gdb (on Linux/Mac/Arm).

--
Ian Collins

[David Brown]

Without giving any information about the warning, the compiler flags
used, or giving code that can be compiled and tested (and I don't mean
by cloning your whole project), that's about as useful as telling your
car workshop that your car has a problem and you hope they can fix it.

Write a minimal, stand-alone, compilable code snippet, and people can
test it perhaps help you out.

Oh, and declaring all your local variables at the start of a function
went out of fashion in C at the end of last century, and has never been
in fashion in C++. There are good reasons for minimising the scope of
your locals.

It is certainly possible for gcc (or any static error checking system)
to produce false positives - some types of test are particularly prone
to it since the compiler doesn't know /everything/ about the program or
the data passing through functions. But sometimes what appears to be
false positives are not false at all, so it is worth checking out.

[Marcel Mueller]

E.g. if you have an abstract base with a non virtual but protected
destructor it warns about the non virtual destructor although objects of
this type normally cannot be destroyed by a pointer to the abstract base.


Marcel

[Rick C. Hodgin]

On Tuesday, October 14, 2014 5:47:49 PM UTC-4, David Brown wrote:
> Write a minimal, stand-alone, compilable code snippet, and people can
> test it perhaps help you out.

I've lived with the GCC warnings since whenever it was I added GCC
support. I'm content with the false positives. I haven't disabled
the warnings they give because I don't want to miss other warnings
on other source lines that are legitimate.

The .mak files is in the vjr_mingw_gcc_codelite directory.

> Oh, and declaring all your local variables at the start of a function
> went out of fashion in C at the end of last century, and has never been
> in fashion in C++. There are good reasons for minimising the scope of
> your locals.

I prefer to have my code documented so that a person entering one of my
functions can, at a glance, generally know a lot about the function
before they even get started.

I use naming conventions. Names that do not have a leading "i" are
outward facing, such as "compute_data" and "parse_file". If they
have a leading i, they are internal functions, such as "iComputeData"
and "iParseFile" which means a few assumptions can be made about them
because the i-functions won't be called unless they've already passed
some degree of scrutiny through the outward-facing functions. I also
have "ii" functions, which are called from there, which are called
without any parameter checking, because it is known by the caller that
everything will be in proper order.

At the top are all of the local variables. My Visual Studio IDE has
a feature called "CodeView" which, when I highlight a variable, it
shows me where it's defined. By putting all variables at the same
location, when I position the flashing caret onto any of them, they
are all shown in that window, along with their types.

I categorically disagree with minimizing the scope of variables. I
think it's a bad idea and I do not write code that way. If I need
multiple variables, then I give them each unique names, and in that
way there is no ambiguity if the variable "i" here is the one in this
scope, or that scope, or the one declared over there, or the one
passed in as a parameter. Everything has its place. It also aids in
debugging because you simply have to type the name, and not try to
find the instance or reference of the name as the 3rd version of i
that's in use.

> It is certainly possible for gcc (or any static error checking system)
> to produce false positives - some types of test are particularly prone
> to it since the compiler doesn't know /everything/ about the program or
> the data passing through functions. But sometimes what appears to be
> false positives are not false at all, so it is worth checking out.

They don't bother me. I couldn't figure out at first why I was getting
them and assumed there was something wrong in my code ... but as it is
everything works, and I don't believe there are flaws in my logic. The
error with regards to "var" is a particularly confusing one though. I
use the "var" variable in assignment as I do so I can examine it in the
debugger, but I don't use it other places. GCC doesn't like that.

[Marcel Mueller]

On 14.10.14 16.30, Robert Hutchings wrote:
> Do you use an IDE like Code::Blocks or Eclipse?

My personal favorite is CDT. It is free and quite good with respect to
code completion and refactoring. OK, working with the Linux kernel
source tree is a bit slow.

> Or just Emacs or
> vi/gcc/g++ on Linux/UNIX?

vi - urgh, only in the thread of force. It might be powerful from the
functional point of view but the user interface is from the seventies.

> What about testing and debugging? Favorite tools?

Well, debugging depends on the target platform. The best debugger is the
one available on your platform.
And testing is for milksops. :-) Kidding aside, it really depends on the
kind of tests. Can your code operate isolated? Do you need a well
defined DB setup? Do you intend to test the UI? And so on. But most
companies do not want to spent the additional money/effort for automated
testing the first time. They rather spend the money every time for non
automated tests. ;-)


Marcel

[Luca Risolia]

Il 14/10/2014 23:48, Marcel Mueller ha scritto:
> On 14.10.14 17.16, Luca Risolia wrote:
>> Il 14/10/2014 17:00, Rick C. Hodgin ha scritto:
>>> On Tuesday, October 14, 2014 10:31:11 AM UTC-4, Robert Hutchings wrote:
>>> GCC does also give
>>> several false positives, however.
>>
>> hm..false positives? for example?
>
> E.g. if you have an abstract base with a non virtual but protected
> destructor it warns about the non virtual destructor

I personally don't get any warnings with -Wall and -pedantic turned
on...This is GCC 4.9.0

[Luca Risolia]

Il 14/10/2014 18:04, Rick C. Hodgin ha scritto:
> On Tuesday, October 14, 2014 11:16:32 AM UTC-4, Luca Risolia wrote:
>> Il 14/10/2014 17:00, Rick C. Hodgin ha scritto:
>>> GCC does also give
>>> several false positives, however.
>>
>> hm..false positives? for example?
>
> Line 322:
> https://github.com/RickCHodgin/libsf/blob/master/source/vjr/sound/sound.cpp
>
> Line 50:
> https://github.com/RickCHodgin/libsf/blob/master/source/vjr/engine.cpp

Can you isolate the code producing those false positives in a minimal,
compilable example that I can test on my Linux machine?

[Rick C. Hodgin]

Luca Risolia wrote:
> Can you isolate the code producing those
> false positives in a minimal, compilable
> example that I can test on my Linux
> machine?

That particular program will compile in MinGW
from the command line using only something
like:

g++ vjr.cpp

It includes every header and other .cpp file as
#include files.

c:\> git clone https://github.com/RickCHodgin/libsf.git
c:\> cd libsf\source\vjr\
c:\> g++ vjr.cpp

That sould compile it in MinGW 4.8.1.

[David Brown]

On 15/10/14 00:05, Rick C. Hodgin wrote:
> On Tuesday, October 14, 2014 5:47:49 PM UTC-4, David Brown wrote:
>> Write a minimal, stand-alone, compilable code snippet, and people can
>> test it perhaps help you out.
>
> I've lived with the GCC warnings since whenever it was I added GCC
> support. I'm content with the false positives. I haven't disabled
> the warnings they give because I don't want to miss other warnings
> on other source lines that are legitimate.
>
> The .mak files is in the vjr_mingw_gcc_codelite directory.

Well, the offer of suggestions or advice is there - but you have to make
the effort if you want to take advantage of it. If you are content with
the warning (which you hope is a false positive), that's up to you.

As an aside, it is very good practice to re-write errors, warnings, or
other oddities into minimal stand-alone snippets. Often you can see the
issue yourself much more clearly than when it is buried in source code,
and you solve the issue simply by asking the question the right way.

>
>> Oh, and declaring all your local variables at the start of a function
>> went out of fashion in C at the end of last century, and has never been
>> in fashion in C++. There are good reasons for minimising the scope of
>> your locals.
>
> I prefer to have my code documented so that a person entering one of my
> functions can, at a glance, generally know a lot about the function
> before they even get started.
>

I looked briefly at your "engine.cpp". The list of variable definitions
at the start of the function tells people exactly /nothing/. Names like
"comp", "compNext", "compThird", "var", etc., are anonymous and
uninformative. That's fine for small local variables in a tight scope -
just like using "i" as a loop variable. But good programming practice
is to keep the scopes of such minor "helper" variables as small as possible.

> I use naming conventions. Names that do not have a leading "i" are
> outward facing, such as "compute_data" and "parse_file". If they
> have a leading i, they are internal functions, such as "iComputeData"
> and "iParseFile" which means a few assumptions can be made about them
> because the i-functions won't be called unless they've already passed
> some degree of scrutiny through the outward-facing functions. I also
> have "ii" functions, which are called from there, which are called
> without any parameter checking, because it is known by the caller that
> everything will be in proper order.

I noticed your naming convention, and felt a shiver down my spine.

>
> At the top are all of the local variables. My Visual Studio IDE has
> a feature called "CodeView" which, when I highlight a variable, it
> shows me where it's defined. By putting all variables at the same
> location, when I position the flashing caret onto any of them, they
> are all shown in that window, along with their types.

Don't write bad code just to deal with limitations in your tools.

>
> I categorically disagree with minimizing the scope of variables. I
> think it's a bad idea and I do not write code that way. If I need
> multiple variables, then I give them each unique names, and in that
> way there is no ambiguity if the variable "i" here is the one in this
> scope, or that scope, or the one declared over there, or the one
> passed in as a parameter. Everything has its place. It also aids in
> debugging because you simply have to type the name, and not try to
> find the instance or reference of the name as the 3rd version of i
> that's in use.

You are disagreeing with mainstream standard practice, which has been
based on a great deal of experience by a great deal of people. But it's
your code - no one else has to deal with it, so you can write it the way
you want. All anyone else can do is give you suggestions.

>
>> It is certainly possible for gcc (or any static error checking system)
>> to produce false positives - some types of test are particularly prone
>> to it since the compiler doesn't know /everything/ about the program or
>> the data passing through functions. But sometimes what appears to be
>> false positives are not false at all, so it is worth checking out.
>
> They don't bother me. I couldn't figure out at first why I was getting
> them and assumed there was something wrong in my code ... but as it is
> everything works, and I don't believe there are flaws in my logic. The
> error with regards to "var" is a particularly confusing one though. I
> use the "var" variable in assignment as I do so I can examine it in the
> debugger, but I don't use it other places. GCC doesn't like that.
>

Since you still haven't said what the warning actually was, I can't
guess why "gcc doesn't like it".

[David Brown]

On 14/10/14 16:30, Robert Hutchings wrote:
> Do you use an IDE like Code::Blocks or Eclipse? Or just Emacs or
> vi/gcc/g++ on Linux/UNIX?
>

Eclipse for serious stuff, but also occasionally small edits from nano
(command line editor in Linux) or gedit.

gcc for most of my projects, but sometimes other embedded compilers.

I also work with Python, using either Eclipse, idle, gedit or nano
depending on the circumstances.


(Emacs /is/ an IDE - in fact, the only reason it is not classified as an
OS is that it doesn't ship with a simple text editor...)

> What about testing and debugging? Favorite tools?

gdb is my debugger of choice. Sometimes I just use the command line
version - it's quick and easy for simple tasks, and sometimes it is
helpful to script it. But usually I have Eclipse as a front end to gdb.

More often, however, I don't have a separate debugger, but output
logging data on a serial port (most of my systems are embedded). Quite
often in embedded systems it is not possible to stop the system on a
breakpoint - you can't debug a motor driver by single-stepping!

[Rick C. Hodgin]

> As an aside, it is very good practice to re-write errors, warnings, or
> other oddities into minimal stand-alone snippets. Often you can see the
> issue yourself much more clearly than when it is buried in source code,
> and you solve the issue simply by asking the question the right way.

I don't think there's anything wrong with my code, hence the "false
positive." All other GCC warnings I coded around. I don't see anything
wrong with either of those two remaining warnings.

> I looked briefly at your "engine.cpp". The list of variable definitions
> at the start of the function tells people exactly /nothing/. Names like
> "comp", "compNext", "compThird", "var", etc., are anonymous and
> uninformative.

It requires some knowledge of what you're doing. If you look at the comp
defintion, you'll see SComp defined there. If you go to its definition
you'll see the explanation identifying what it is.

"comp" are components. A component is a part of a parsed line.

x = 5;

A component chain would consist of:

[x][whitepsace][=][whitespace][5][semicolon]

comp refers to the current component. compNext is the one after that.
And can you guess what compThird is?

I use those here and there to determine combinations of things which can
be joined together into a single component, such as with the number 999.99
being converted to [999][decimal point][99], and then being converted into
a single [number:999.99] form. I call those "natural groupings".

> That's fine for small local variables in a tight scope - just like
> using "i" as a loop variable. But good programming practice

Never use "i" for a local variable name. That's my advice. I use
something like "lnI" for [local][numeric][i].

> is to keep the scopes of such minor "helper" variables as small as
> possible.

The concept of comp, compNext, etc., is global throughout my app.

> I noticed your naming convention, and felt a shiver down my spine.

LOL! :-)

> > At the top are all of the local variables. My Visual Studio IDE has
> > a feature called "CodeView" which, when I highlight a variable, it
> > shows me where it's defined. By putting all variables at the same
> > location, when I position the flashing caret onto any of them, they
> > are all shown in that window, along with their types.
>
> Don't write bad code just to deal with limitations in your tools.

I think it's good practice. All variables are located at one place
and I don't have to go hunting (reading) line-by-line to try to find
where this one's defined, and that one's defined.

> > I categorically disagree with minimizing the scope of variables. I
> > think it's a bad idea and I do not write code that way. If I need
> > multiple variables, then I give them each unique names, and in that
> > way there is no ambiguity if the variable "i" here is the one in this
> > scope, or that scope, or the one declared over there, or the one
> > passed in as a parameter. Everything has its place. It also aids in
> > debugging because you simply have to type the name, and not try to
> > find the instance or reference of the name as the 3rd version of i
> > that's in use.
>
> You are disagreeing with mainstream standard practice, which has been
> based on a great deal of experience by a great deal of people.

If so ... then yes.

> But it's your code - no one else has to deal with it, so you can
> write it the way you want. All anyone else can do is give you
> suggestions.

It goes both ways.

> > They don't bother me. I couldn't figure out at first why I was getting
> > them and assumed there was something wrong in my code ... but as it is
> > everything works, and I don't believe there are flaws in my logic. The
> > error with regards to "var" is a particularly confusing one though. I
> > use the "var" variable in assignment as I do so I can examine it in the
> > debugger, but I don't use it other places. GCC doesn't like that.
>
> Since you still haven't said what the warning actually was, I can't
> guess why "gcc doesn't like it".

I haven't been hiding the warnings. I just don't care enough about them
being an issue to worry about it.

But, here is the output from GCC (I had to remove the line after lfHertz4
which bypasses the warning to get it to generate that warning):

C:\WINDOWS\system32\cmd.exe /c "C:/MinGW-4.8.1/bin/mingw32-make.exe -e -f Makefile"
"----------Building project:[ vjr - Release ]----------"
mingw32-make.exe[1]: Entering directory 'C:/libsf/source/vjr/vjr_mingw_gcc_codelite'
C:\MinGW-4.8.1\bin\g++.exe -c "C:/libsf/source/vjr/vjr.cpp" -O2 -Wall -Wno-comment -Wno-multichar -Wno-narrowing -Wno-write-strings -Wno-format-contains-nul -Wno-strict-aliasing -DNDEBUG -o ./Release/vjr_vjr.cpp.o -I. -I.
In file included from C:/libsf/source/vjr/vjr.h:128:0,
from C:/libsf/source/vjr/vjr.cpp:37:
C:/libsf/source/vjr/sound\sound.cpp: In function 'void iisound_generateTones(_isSSound*, u32)':
C:/libsf/source/vjr/sound\sound.cpp:369:29: warning: 'lfHertz4' may be used uninitialized in this function [-Wmaybe-uninitialized]
*lfAccum4 += lfHertz4;
^
In file included from C:/libsf/source/vjr/vjr.h:97:0,
from C:/libsf/source/vjr/vjr.cpp:37:
\libsf\utils\common\cpp\ll.cpp: In function 'bool iEngine_executeStandaloneCommand(SEdit*)':
\libsf\utils\common\cpp\ll.cpp:294:27: warning: 'var' may be used uninitialized in this function [-Wmaybe-uninitialized]
nodeFirst->prev = node; // Ignore the GCC warning message here... I don't know why it's throwing a warning. Everything here is populated and tested before use.
^
In file included from C:/libsf/source/vjr/vjr.h:125:0,
from C:/libsf/source/vjr/vjr.cpp:37:
C:/libsf/source/vjr/engine.cpp:50:14: note: 'var' was declared here
SVariable* var; // Ignore the GCC warning message here... I don't know why it's throwing a warning. var is used correctly below.
^
C:\MinGW-4.8.1\bin\g++.exe -o ../vjr.exe @"vjr.txt" -L. -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -luuid -lodbc32 -lodbccp32 -lSDL
mingw32-make.exe[1]: Leaving directory 'C:/libsf/source/vjr/vjr_mingw_gcc_codelite'
0 errors, 6 warnings, total time: 00:00:27 seconds

-----
Here is the build in debug mode:
C:\WINDOWS\system32\cmd.exe /c "C:/MinGW-4.8.1/bin/mingw32-make.exe -e -f Makefile"
"----------Building project:[ vjr - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'C:/libsf/source/vjr/vjr_mingw_gcc_codelite'
C:\MinGW-4.8.1\bin\g++.exe -c "C:/libsf/source/vjr/vjr.cpp" -g -O0 -Wall -Wno-comment -Wno-multichar -Wno-narrowing -Wno-write-strings -Wno-format-contains-nul -o ./Debug/vjr_vjr.cpp.o -I. -I.
C:\MinGW-4.8.1\bin\g++.exe -o ../vjr.exe @"vjr.txt" -L. -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -luuid -lodbc32 -lodbccp32 -lSDL -g
mingw32-make.exe[1]: Leaving directory 'C:/libsf/source/vjr/vjr_mingw_gcc_codelite'
0 errors, 0 warnings, total time: 00:00:20 seconds

[Paavo Helde]

Robert Hutchings <rm.hut...@gmail.com> wrote in news:m1jc2t$bh6$1@dont-
email.me:

> Do you use an IDE like Code::Blocks or Eclipse? Or just Emacs or
> vi/gcc/g++ on Linux/UNIX?

Our projects are in Code::Blocks on Linux by an historic accident, but we
want to get rid of that (it crashes or hangs with a chance near 50% in
automated builds) and go back to Emacs and maybe CMake.

> What about testing and debugging? Favorite tools?

Valgrind, gdb. In general I try to reproduce the problem in Windows and
debug in Visual Studio. Trying to debug in Code::Blocks works in maybe 10%
of cases in my experience and tends to hang instead most of the time. YMMV.

[David Brown]

Fair enough, the variable names are meaningful for your code. But that
still does not mean it makes sense to declare all your variables at the
start of the function.

>
>> That's fine for small local variables in a tight scope - just like
>> using "i" as a loop variable. But good programming practice
>
> Never use "i" for a local variable name. That's my advice. I use
> something like "lnI" for [local][numeric][i].

I hope you won't feel insulted if I ignore your advice. I have seen
many pieces of code with such conventions, and many sets of coding rules
that insisted upon them - I have never seen any code in which such
things did not make code uglier and harder to follow.

>
>> is to keep the scopes of such minor "helper" variables as small as
>> possible.
>
> The concept of comp, compNext, etc., is global throughout my app.
>
>> I noticed your naming convention, and felt a shiver down my spine.
>
> LOL! :-)
>
>>> At the top are all of the local variables. My Visual Studio IDE has
>>> a feature called "CodeView" which, when I highlight a variable, it
>>> shows me where it's defined. By putting all variables at the same
>>> location, when I position the flashing caret onto any of them, they
>>> are all shown in that window, along with their types.
>>
>> Don't write bad code just to deal with limitations in your tools.
>
> I think it's good practice. All variables are located at one place
> and I don't have to go hunting (reading) line-by-line to try to find
> where this one's defined, and that one's defined.

Why single out variable definition for such special treatment? How
variables are used is just as important as their definitions - yet you
are happy to spread their usage around in the code. It is a common idea
that putting the definitions in one place somehow makes things clearer,
but that is not the case. Remember, the convention of putting
definitions at the start of a function is due to limitations on compiler
technology in the good old days of K&R - it was never picked as an
active choice or suggested as a good idea.

>
>>> I categorically disagree with minimizing the scope of variables. I
>>> think it's a bad idea and I do not write code that way. If I need
>>> multiple variables, then I give them each unique names, and in that
>>> way there is no ambiguity if the variable "i" here is the one in this
>>> scope, or that scope, or the one declared over there, or the one
>>> passed in as a parameter. Everything has its place. It also aids in
>>> debugging because you simply have to type the name, and not try to
>>> find the instance or reference of the name as the 3rd version of i
>>> that's in use.
>>
>> You are disagreeing with mainstream standard practice, which has been
>> based on a great deal of experience by a great deal of people.
>
> If so ... then yes.
>
>> But it's your code - no one else has to deal with it, so you can
>> write it the way you want. All anyone else can do is give you
>> suggestions.
>
> It goes both ways.

Absolutely true. Even the most experienced developers can sometimes
learn things from other people's habits and conventions. But after due
consideration of the points above, I've rejected your conventions :-)

(On a more positive note, your code is laid out neatly and consistently,
which is a good habit.)

>
>>> They don't bother me. I couldn't figure out at first why I was getting
>>> them and assumed there was something wrong in my code ... but as it is
>>> everything works, and I don't believe there are flaws in my logic. The
>>> error with regards to "var" is a particularly confusing one though. I
>>> use the "var" variable in assignment as I do so I can examine it in the
>>> debugger, but I don't use it other places. GCC doesn't like that.
>>
>> Since you still haven't said what the warning actually was, I can't
>> guess why "gcc doesn't like it".
>
> I haven't been hiding the warnings. I just don't care enough about them
> being an issue to worry about it.
>
> But, here is the output from GCC (I had to remove the line after lfHertz4
> which bypasses the warning to get it to generate that warning):

The way to deal with warnings is to understand them and use them as
hints to correct or improve your code. It is very rare that I accept
/any/ warnings on final code - and I use a lot more of gcc's warnings
than you do here (I start with "-Wall -Wextra" and add others). In this
particular case, I think your code would be clearer and your warnings
would disappear (or reveal real errors) if you used local variables
properly.

You should also remove the "-Wno-" flags - any warnings hidden by those
flags are almost certainly coding errors.

And you should use separate compilation for your modules - don't lump
everything together in one huge combined file. Modular programming
exists for a reason - it gives you clearer, neater code, better static
error checking, better code re-use, and easier development.


I think that's probably enough advice for today.

[Rick C. Hodgin]

David Brown wrote:
> [snip]

I appreciate your advice, David. I am aware of
the many reasons for the advice you offer, the
common viewpoints, the widely held beliefs and
practices (at least I am on several points that is).

I have very specific reasons why I do the things
I do. I have considered things, and seen from
my own experience what works best.

[Andrea Venturoli]

On 10/14/14 16:30, Robert Hutchings wrote:
> Do you use an IDE like Code::Blocks or Eclipse?

Not if I can avoid it.
Practically only on Windows, when I'm forced to (altough I usually edit
VS's project files with emacs >:-).

> Or just Emacs or vi/gcc/g++ on Linux/UNIX?

Exactly: emacs + gcc/clang.

> What about testing and debugging?

Boost, valgrind, cppcheck, gdb (again through emacs); VS's debugger on
Windows.



> Favorite tools?

Add subversion, gmake, and the usual UNIX commands like sed, grep, etc...



Also, I guess I might have to look into cmake in the future.


bye

[Martijn Lievaart]

On Tue, 14 Oct 2014 20:59:30 +0000, Jorgen Grahn wrote:

> On Tue, 2014-10-14, Robert Hutchings wrote:
>> Do you use an IDE like Code::Blocks or Eclipse? Or just Emacs or
>> vi/gcc/g++ on Linux/UNIX?
>
> g++, Make, Emacs, Git, zsh and the infinite Unix toolbox.

s/zsh/bash/

>
>> What about testing and debugging? Favorite tools?
>
> Valgrind, tcpdmp, strace and ltrace. And the rest of Unix.

s/tcpdump/tshark, wireshark/

Also gdb run from Emacs, occasionally.

M4

[Martijn Lievaart]

[ Not trying to start a holy war, please keep it factual ]

On Wed, 15 Oct 2014 00:07:09 +0200, Marcel Mueller wrote:

> vi - urgh, only in the thread of force. It might be powerful from the
> functional point of view but the user interface is from the seventies.

It's not even really powerful compared to any other modern programming
editor. Vim would be a much better choice, but that's not available
everywhere.

The only thing vi has going for it, is that it is available on any unix,
always, and is much more useful than say Windows Notepad.

M4