Friday, October 4, 2019

Digest for comp.lang.c++@googlegroups.com - 25 updates in 4 topics

Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 04 05:45AM

On Tue, 2019-10-01, Frederick Gotham wrote:
 
> This has taken me a lot longer than it should have, but I think I've
> put together a Makefile that will compile a program from all the C
> and C++ files in the current directory.
 
What's its purpose? It's nice as a demo of Make with dependency
tracking, but I wouldn't want it in projects I work with: I like a
Makefile to be a bill of materials, and build only a fixed set of
source files.
 
I also tend to split source code in a bunch of subdirectories, and
generate several executables (the unit tests shouldn't be linked into
the main executable).
 
...
> Here's what I've got so far:
 
> PROGRAM = super_cool_prog
 
> FLAGS_IN_COMMON = -pedantic -Wall -rdynamic -funwind-tables -fno-omit-frame-pointer -fdump-rtl-expand -Og -g
 
Also consider -Wextra.
 
> CXXFLAGS = $(FLAGS_IN_COMMON) -std=c++11
> CFLAGS = $(FLAGS_IN_COMMON) -std=c99
...
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 03 11:51PM -0700

On Friday, October 4, 2019 at 6:46:02 AM UTC+1, Jorgen Grahn wrote:
 
> tracking, but I wouldn't want it in projects I work with: I like a
> Makefile to be a bill of materials, and build only a fixed set of
> source files.
 
 
If a ".cpp" or ".c" file exists in the folder, it's there to be compiled. Otherwise it should have a different extension, e.g. ".cpp.old".
 
I don't use Makefiles as a bill of materials like that. For such a bill of materials, I would run the command "ls *.{c,cpp}".
 

> I also tend to split source code in a bunch of subdirectories, and
> generate several executables (the unit tests shouldn't be linked into
> the main executable).
 
 
I will be looking at changing "SRC_FILES_C" and "SRC_FILES_CPP" to take in all source files in subdirectories.
 
 
> Also consider -Wextra.
 
 
Missed that one.
Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: Oct 04 09:45AM +0200

Am 04.10.19 um 08:51 schrieb Frederick Gotham:
 
> If a ".cpp" or ".c" file exists in the folder, it's there to be compiled.
 
There may be source files providing interfaces to different OS
platforms, sources related to different configurations of the main
program, sources related to experimental features not being part of the
current release, sources used in debug mode only, sources related to
tools which must be compiled into separate executables, and many more.
 
In any non-trivial project, you will quickly run into a state, where you
actually NEED to use the makefile as a "bill of materials" rather than
throwing in every file there is.
David Brown <david.brown@hesbynett.no>: Oct 04 10:01AM +0200

On 04/10/2019 07:45, Jorgen Grahn wrote:
> tracking, but I wouldn't want it in projects I work with: I like a
> Makefile to be a bill of materials, and build only a fixed set of
> source files.
 
That's fair enough. Personally, I don't - I use Makefiles that build on
the same principles as this example (but a good deal more advanced,
according to need - handling multiple directories, multiple executables,
and whatever else).
 
To me, the "bill of materials" for a software project is the files in
the directory (and subdirectories). If there is a file there, it is
part of the project. If it is not part of the project, it should not be
in the directory. So "*.c" gives me exactly the C files used for the
project - there is no need to list them.
 
This makes the build system almost zero maintenance - adding a new file
to the project means adding a new file to the directory and typing "make".
 
 
>> PROGRAM = super_cool_prog
 
>> FLAGS_IN_COMMON = -pedantic -Wall -rdynamic -funwind-tables -fno-omit-frame-pointer -fdump-rtl-expand -Og -g
 
> Also consider -Wextra.
 
Agreed. (I like quite a few more warning flags, but that is a matter of
personal preference, coding standard, etc. People have to decide on
those themselves. The same goes for "-pedantic" and many other flags.)
 
"-fno-omit-frame-pointer" is a strange choice. It is just a "give me a
bit bigger and slower code" flag. It certainly isn't any help for
debugging with gdb. But maybe the OP has specialist requirements for
which the flag helps.
 
Another very good choice, IMHO, is "-fno-common".
 
Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 04 01:16AM -0700

On Friday, October 4, 2019 at 9:02:09 AM UTC+1, David Brown wrote:
 
> bit bigger and slower code" flag. It certainly isn't any help for
> debugging with gdb. But maybe the OP has specialist requirements for
> which the flag helps.
 
Some of our products are embedded Linux on x86_64, and some are on ARM (aarch64). I'm not sure who to believe, but someone told me that the function call stack on ARM might leave out a frame pointer, meaning that I won't be able to do a stack trace. If this is true, then presumably "-rdynamic" would implicitly include "-fno-omit-frame-pointer" on ARM processors. I don't know who do believe, so I throw in both.
Ian Collins <ian-news@hotmail.com>: Oct 04 09:23PM +1300

On 04/10/2019 21:16, Frederick Gotham wrote:
> then presumably "-rdynamic" would implicitly include
> "-fno-omit-frame-pointer" on ARM processors. I don't know who do
> believe, so I throw in both.
 
You have -Og, so getting a stack trace won't be a problem...
 
--
Ian.
David Brown <david.brown@hesbynett.no>: Oct 04 10:49AM +0200

On 04/10/2019 09:45, Hergen Lehmann wrote:
 
> In any non-trivial project, you will quickly run into a state, where you
> actually NEED to use the makefile as a "bill of materials" rather than
> throwing in every file there is.
 
No, you won't. You might find a "bill of materials" makefile to be a
convenient way to handle it, but it most certainly is /not/ the only way
to do it.
 
There is also endless scope for hybrid solutions. A practical way is to
have different directories for your common code, your test code, your PC
simulator code, your embedded target code, etc. A build for the
embedded target would use all *.c *.cpp files in the "common" and
"embedded" directories, while a simulator build would use all files in
the "common" and "simulator" directories.
 
There is no one solution that fits all projects, of course. /I/ prefer
a makefile that takes all *.c *.cpp files in the source directories -
but that does not mean I think it is the best choice for everyone or
every project.
David Brown <david.brown@hesbynett.no>: Oct 04 10:51AM +0200

On 04/10/2019 10:16, Frederick Gotham wrote:
> then presumably "-rdynamic" would implicitly include
> "-fno-omit-frame-pointer" on ARM processors. I don't know who do
> believe, so I throw in both.
 
I am afraid I don't know what might be needed for stack tracing on
embedded Linux. My main work is with bare-bones embedded systems, with
gdb connected to the target via a JTAG debugger. There is certainly no
problem looking through stack frames there without forcing a frame pointer.
Bonita Montero <Bonita.Montero@gmail.com>: Oct 03 11:42PM +0200

>> FREE_NODE to its own type, i.e. (uint32_t const), then I don't
>> get an error anymore. That's simply a bug.
 
> No, that is because the cast creates a new temporary with the same value.
 
LOL.
James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 03 10:20PM -0400

On 3.10.2019 16:41, Bonita Montero wrote:
> like it's not a const at this point in the constructor. So I asked for
> a work-around bcause I needed the constant in the innner class as well
> in the outer.
 
When reporting such a problem, you should
1. Present a complete program that is as simple as possible, while still
presenting the problem that you're talking about.
2. Identify the specific compiler that you used, including version
information, and the complete command line that you used to compile.
3. Show us the messages, if any, generated by compiling it.
 
I've constructed the simplest program I could come up with that was
consistent with everything you've said about this problem. It compiled,
linked, and executed without any problems. I used g++ (Ubuntu
7.4.0-1ubuntu1~18.04.1) 7.4.0. In order to give it an opportunity for a
link error, I broke it up into two source code files and a shared header
file:
 
A.h:
#define H_A
#include <cstdint>
 
struct A
{
static std::uint32_t const UNPINNED_NODE = 0,
FREE_NODE = 0xFFFFFFFFu;
struct B
{
int pinCounter;
int f();
} *nd;
 
A(){
nd = new B();
nd->pinCounter = FREE_NODE;
}
 
~A(){
delete nd;
}
};
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)