Wednesday, August 21, 2019

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

James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 21 09:15AM -0400

On 8/19/19 4:05 PM, Lynn McGuire wrote:
 
>>> <https://www.codeproject.com/Tips/5164768/Cplusplus-Size-Matters-in-Platform-Compatibility>
 
>> Please put < > marks around links.
 
> Why ?
 
Doing so is specified by one of the relevant international standards (I
don't remember which one - I last read that specification about 25 years
ago). Standards are often ignored, but applications whose designers did
pay attention to that clause of that standard may handle links enclosed
in <> better than links that are not so delimited.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 21 05:14PM +0200

I prefer Win32's FILETIME which is a 64 bit integer that
counts the number of 100ns-steps since 1.1.1601 00:00.
Unfortunately that's not portable.
Eli the Bearded <*@eli.users.panix.com>: Aug 21 06:30PM

> I prefer Win32's FILETIME which is a 64 bit integer that
> counts the number of 100ns-steps since 1.1.1601 00:00.
 
First thing I think of when I see that is "In what calendar?" Gregorian
transition started in 1582, happend in Britain and it's colonies in
1752, and I think you have to get to 1923 for Europe to finish switching
from Julian. (Greece was 1923, Turkey was 1926.)
 
> Unfortunately that's not portable.
 
Yes. Julian is still drifting apart at a rate of 1 day per 400 years,
which is around 0.0016 seconds day. That's a big jump in nanoseconds.
 
Elijah
------
given MS, probably whatever calender Redmond was on in 1995
scott@slp53.sl.home (Scott Lurndal): Aug 21 07:05PM


>Elijah
>------
>given MS, probably whatever calender Redmond was on in 1995
 
Starting dates are completely arbitrary, and no one is better than the
other. Personally, a 64-bit unix time_t works just fine.
 
 
http://www3.sympatico.ca/n.rieck/docs/calendar_time_y2k_etc.html#vax_vms_time
 
QUESTION:
 
Why is Wednesday, November 17, 1858 the base time for OpenVMS (VAX VMS)?
 
ANSWER:
 
November 17, 1858 is the base of the Modified Julian Day system.
 
The original Julian Day (JD) is used by astronomers and expressed in
days since noon January 1, 4713 B.C. This measure of time was
introduced by Joseph Scaliger in the 16th century. It is named in
honor of his father, Julius Caesar Scaliger (note that this Julian Day
is different from the Julian calendar named for the Roman Emperor
Julius Caesar!).
 
Why 4713 BC? Scaliger traced three time cycles and found that they
were all in the first year of their cyle in 4713 B.C. The three
cycles are 15, 19, and 28 years long. By multiplying these three
numbers (15 * 19 * 28 = 7980), he was able to represent any date from
4713 B.C. through 3267 A.D. The starting year was before any
historical event known to him. In fact, the Jewish calendar marks the
start of the world as 3761 B.C. Today his numbering scheme is still
used by astronomers to avoid the difficulties of converting the months
of different calendars in use during different eras.
 
So why 1858? The Julian Day 2,400,000 just happens to be November 17,
1858. The Modified Julian Day uses the following formula:
 
MJD = JD - 2,400,000.5
 
The .5 changed when the day starts. Astronomers had considered it
more convenient to have their day start at noon so that nighttime
observation times fall in the middle. But they changed to conform to
the commercial day.
 
The Modified Julian Day was adopted by the Smithsonian Astrophysical
Observatory (SAO) in 1957 for satellite tracking. SAO started
tracking satellites with an 8K (non-virtual) 36-bit IBM[R] 704 computer
in 1957, when Sputnik was launched. The Julian day was 2,435,839 on
January 1, 1957. This is 11,225,377 in octal notation, which was too
big to fit into an 18-bit field (half of the IBM standard 36-bit word).
And, with only 8K of memory, no one wanted to waste the 14 bits left
over by keeping the Julian Day in its own 36-bit word. However, they
also needed to track hours and minutes, for which 18 bits gave enough
accuracy. So, they decided to keep the number of days in the left 18
bits and the hours and minutes in the right 18 bits of a word.
 
Eighteen bits would allow the Modified Julian Day (the SAO day) to
grow as large as 262,143 ((2 ** 18) - 1). From Nov. 17, 1858, this
allowed for seven centuries. Using only 17 bits, the date could
possibly grow only as large as 131,071, but this still covers 3
centuries, as well as leaving the possibility of representing negative
time. The year 1858 preceded the oldest star catalog in use at SAO,
which also avoided having to use negative time in any of the satellite
tracking calculations.
 
This base time of Nov. 17, 1858 has since been used by TOPS-10,
TOPS-20, and VAX VMS and OpenVMS. Given this base date, the 100
nanosecond granularity implemented within OpenVMS and the 63-bit
absolute time representation (the sign bit must be clear), OpenVMS
should have no trouble with time until:
 
31-JUL-31086 02:48:05.47
 
At this time, all clocks and time-keeping operations in OpenVMS will
suddenly stop, as system time values go negative.
 
Note that the OpenVMS time display and manipulation routines allow for
only 4 digits in the 'YEAR' field. We expect this to be corrected in
a future release of OpenVMS sometime prior to 31-DEC-9999.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 21 09:25PM +0200

> transition started in 1582, happend in Britain and it's colonies in
> 1752, and I think you have to get to 1923 for Europe to finish switching
> from Julian. (Greece was 1923, Turkey was 1926.)
 
Try to google:
"The FILETIME structure records time in the form of 100-nanosecond
intervals since January 1, 1601. Why was that date chosen?
The Gregorian calendar operates on a 400-year cycle, and 1601 is the
first year of the cycle that was active at the time Windows NT was
being designed. In other words, it was chosen to make the math come
out nicely."
Keith Thompson <kst-u@mib.org>: Aug 21 12:28PM -0700

> transition started in 1582, happend in Britain and it's colonies in
> 1752, and I think you have to get to 1923 for Europe to finish switching
> from Julian. (Greece was 1923, Turkey was 1926.)
 
Fortunately, there's an answer: it refers to 1601-01-01 in the Gregorian
calendar.
 
<https://devblogs.microsoft.com/oldnewthing/20090306-00/?p=18913>
 
[...]
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
JiiPee <no@notvalid.com>: Aug 21 08:22PM +0100

Which one is better:
 
1)
 
class Person
 
{
 
public:
 
int getAge() { return age;}
 
void setAge(int a) { age = a;}
 
private:
 
int age;
 
};
 
or
 
2)
 
struct Person
 
{
 
int age;
 
};
 
####
 
I know Herb Sutter recommended 1) but for example isocpp
 
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-get
 
seems to recommend 2). Herb says that for example when debugging 1) is
good because you can write to file all the accesses of the age, or cout
all the calls. Also debugger can stop at the function call, but can
debugger stop at :
 
person.age = 6;
 
?
 
So debugger can put a red dot to setAge and see which object changed it.
And cout/write on file information.
 
Argument also, that later on can add other functionality punder setAge
(like cache logic).
 
But 2) people argue its so simple and not likely to change, so it breaks
OO idea.
 
I do currently 1) but wondering which way to go.
 
Like now I have a "Settings" class. Simple data members. I started
adding getters and setters....
Sam <sam@email-scan.com>: Aug 20 08:07PM -0400

stdcerr writes:
 
 
> public:
> foo(const QSettings *set=0, const QString s="") :
> name(s),settings(set){}
 
You must be using an obsolete C++ book. Modern C++ uses uniform
initialization syntax, which would be:
 
foo(const QSettings *set=0, const QString s="") : name{s},settings{set}{}
 
Basically {} instead of (). This resolves some syntax ambiguities in other
situations (not this particular one, but others, and it's better to remain
consistent).
 
> QSettings * const settings;
 
settings is now a const class member that's a pointer to a non-const
QSettings object.
 
const QSettings *set=nullptr, const QString s="") :
> make: *** [foo.o] Error 1
 
> Why does it still say "invalid conversion from 'const QSettings*' to
> 'QSettings*'"
 
Because your parameter to the constructor is a 'const QSettings *', and your
const class member is a pointer to a non-const QSettings.
 
These are two different things: the pointer, and what it points to. Either
one, or both, can be const.
 
So, either your parameter to the constructor should be
 
QSettings *set=nullptr
 
or your class member should be
 
const QSettings * const settings;
 
Which is a const class member named "settings" which is a pointer to a const
QSettings object.
stdcerr <ron.eggler@gmail.com>: Aug 20 07:10PM -0700

On Tuesday, August 20, 2019 at 11:20:00 AM UTC-7, Paavo Helde wrote:
 
> A const pointer to mutable QSettings is 'QSettings * const'. If you want
> this, you need to use the same type also in the constructor, not 'const
> QSettings *' you have above.
 
DUH! That seems obvious! Thanks!
red floyd <dont.bother@its.invalid>: Aug 21 10:19AM -0700

On 8/20/2019 7:10 PM, stdcerr wrote:
>> this, you need to use the same type also in the constructor, not 'const
>> QSettings *' you have above.
 
> DUH! That seems obvious! Thanks!
 
Easiest way to check is to read the declaration from RIGHT TO LEFT.
 
Thus,
 
const QSettings *x = x is a pointer to a const QSettings
QSettings * const x = x is a const pointer to QSettings
 
This is why some people write:
 
int const x = 7; // x is a const int
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 20 05:24PM -0700

On 8/20/2019 4:09 AM, Frederick Gotham wrote:
 
> For the past 15 years or so, I've been using "Dependency Walker" for this on MS-Windows and it works great.
 
Big time. Iirc, it was bundled up with Visual Studio a long time ago.
David Brown <david.brown@hesbynett.no>: Aug 21 10:29AM +0200

On 20/08/2019 23:59, Keith Thompson wrote:
> the gcc maintainers responded to the addition of "other
> implementation-defined character" in C++11, but did not respond to its
> removal in C++17.
 
I wonder if the change in C++17 was with a view to future uses of $ for
other purposes in C++ (such as for metaclasses)? Has the status here
changed in C++20 ?
 
 
 
> The effect is the same: a diagnostic is required. (If the
> implementation chooses to produce an executable after printing the
> required diagnostic, I suppose the behavior is undefined by omission.)
 
Thanks for filling out the details here.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 21 11:14AM +0200

On 21.08.2019 10:29, David Brown wrote:
>>> undefined behaviour (since it is not defined in the standard), and
>>> therefore a compiler can support it, or would it constitute a syntax
>>> error (requiring a diagnostic for conformity) ?
 
Herb was thinking about that, at least as a for-the-moment temporary
scheme allowing exploration, but as mentioned he dropped it because at
least one company had $-based simple preprocessing.
 
 
 
>> The effect is the same: a diagnostic is required. (If the
>> implementation chooses to produce an executable after printing the
>> required diagnostic, I suppose the behavior is undefined by omission.)
 
There's no need to print anything. /Not/ blinking the caps lock
indicator for a millisecond is a valid diagnostic. The standard doesn't
specify what a "diagnostic" or a "diagnostic message" is, that it should
involve text at all, or that it should be context-independent...
 
That may sound like a silly argument.
 
But it's exactly the same kind of argument as the quoted text that it
responds to: a literal formal interpretation of text that was meant to
be read with some common sense engaged. To the degree that that quoted
text is a valid argument, this caps lock non-blink argument is valid.
 
Of course, both are silly.
 
It doesn't make sense to assume that kind of absolute formal rigor in
the standard, and taking the standard's words literally proves that that
leads to totally absurd consequences.
 
 
> Thanks for filling out the details here.
 
 
Cheers!,
 
- Alf
Keith Thompson <kst-u@mib.org>: Aug 21 02:42AM -0700

> On 20/08/2019 23:59, Keith Thompson wrote:
[...]
> I wonder if the change in C++17 was with a view to future uses of $ for
> other purposes in C++ (such as for metaclasses)? Has the status here
> changed in C++20 ?
 
I doubt it. The DR that led to the "other implementation-defined
characters" wording being dropped
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1963
doesn't specifically mention the '$' character. (It could apply equally
to '`' and '@', the other two printable ASCII characters that are
outside the basic source character set). It was removed because it was
thought that it wasn't needed.
 
As for C++20, there's a git repo for the C++ standard at
https://github.com/cplusplus/draft
The "other implementation-defined characters" wording was dropped in
commit fcde0c485c4, 2015-05-03, file source/lex.tex . There are no
changes to the syntax of "identifier" after that.
 
[...]
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Keith Thompson <kst-u@mib.org>: Aug 21 02:55AM -0700

> On 21.08.2019 10:29, David Brown wrote:
>> On 20/08/2019 23:59, Keith Thompson wrote:
[...]
> specify what a "diagnostic" or a "diagnostic message" is, that it should
> involve text at all, or that it should be context-independent...
 
> That may sound like a silly argument.
 
Yes, it does.
 
The standard requires a diagnostic message for certain errors, and
defines a "diagnostic message" as "a message belonging to an
implementation-defined subset of the implementation's output messages".
The phrase "implementation-defined" means the documentation has to
document it.
 
gcc's documentation, for example, says:
 
* 'How a diagnostic is identified (C90 3.7, C99 and C11 3.10, C90,
C99 and C11 5.1.1.3).'
 
Diagnostics consist of all the output sent to stderr by GCC.
 
That's for C, but the "C++ Implementation-Defined Behavior" says "Some
choices are documented in the corresponding document for the C
language."
 
So no, for gcc/g++ not blinking the caps lock is not a diagnostic.
 
 
> It doesn't make sense to assume that kind of absolute formal rigor in
> the standard, and taking the standard's words literally proves that that
> leads to totally absurd consequences.
 
I prefer to assume that *the standard means what it says* whenever
possible.
 
In this particular case, I think that the wording of the current
standard, though it's unambiguous, has an unintended consequence.
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 21 12:30PM +0200

On 21.08.2019 11:55, Keith Thompson wrote:
> choices are documented in the corresponding document for the C
> language."
 
> So no, for gcc/g++ not blinking the caps lock is not a diagnostic.
 
I'm sorry, that's a simple fallacy.
 
That g++ doesn't do that now, has no bearing on what it /can/ do.
 
As far as the formal is concerned g++ can use the non-blinking caps lock
as a diagnostic.
 
 
> possible.
 
> In this particular case, I think that the wording of the current
> standard, though it's unambiguous, has an unintended consequence.
 
Maybe.
 
For example, I remember `$` being used in the system API in the HP3000.
That's long ago, 1980s, but presumably use of `$` in system API function
names was part of the reasons why compilers supported it. And continue
to support it.
 
Also, Richard Smith's DR that you linked to (thank you) simply neglects
to consider the matter, and is worded as if he were unaware.
 
* * *
 
I think this one is just as ill-conceived as his UTF-8 character literal
limited to ASCII. My impression is that since C++14 there is a stronger
slant towards really marginal benefit for compiler writers, while
ignoring the far more significant negative consequences for practical
programming, education and knowledge sharing. But it's nothing I can
prove, I have no statistics.
 
 
Cheers!,
 
- Alf
David Brown <david.brown@hesbynett.no>: Aug 21 02:22PM +0200

On 21/08/2019 12:30, Alf P. Steinbach wrote:
> That's long ago, 1980s, but presumably use of `$` in system API function
> names was part of the reasons why compilers supported it. And continue
> to support it.
 
It is not at all unreasonable for compiler implementations to support $
in identifiers in system functions or other "internal" uses, without it
being usable for other cases. A compiler could view it as part of its
reserved namespace, like __identifiers. But once they do that, it's
usually easier to allow it in ordinary code than add extra checking to
detect and diagnose it.
 
I've seen many assemblers that use $ for different reasons - to indicate
local labels, for register names, for hexadecimal numbers, for comments.
It's awkward for compilers to accept $ identifiers when working with
such lower-level tools - it means some sort of name mangling.
 
Paavo Helde <myfirstname@osa.pri.ee>: Aug 21 09:02AM +0300

On 20.08.2019 23:58, Vir Campestris wrote:
 
> But it's big. It isn't going to be rewritten unless it's proved to be a
> problem. And proving this would be hard - it'll be a race condition
> somewhere.
 
Race conditions are not so hard to demonstrate, especially when you know
where the problem is. Just make a volatile integer counter with initial
value one, then let your 4 cores increase and decrease it in tight loops
in parallel. Whenever the counter drops to zero or below you have
demonstrated the race condition. Should happen in seconds or minutes,
but my experience is from Intel, not ARM, so YMMV.
 
BTW, the above is an extract from a real life scenario where the counter
mimics a smartpointer reference counter. In real life the effects are
much more fun - the pointed object will be released when the refcount
drops to zero, so the next non-trivial member function call to it will
probably segfault. This kind of behavior might make the demo a bit more
convincing ;-)
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 20 11:10PM -0700

On 8/20/2019 11:02 PM, Paavo Helde wrote:
> value one, then let your 4 cores increase and decrease it in tight loops
> in parallel. Whenever the counter drops to zero or below you have
> demonstrated the race condition.
 
Indeed. :^)
 
 
> drops to zero, so the next non-trivial member function call to it will
> probably segfault. This kind of behavior might make the demo a bit more
> convincing ;-)
 
Kind of reminds me of creating a rng using race-condition's:
 
https://groups.google.com/d/topic/comp.lang.c++/7u_rLgQe86k/discussion
David Brown <david.brown@hesbynett.no>: Aug 21 08:34AM +0200

On 20/08/2019 22:58, Vir Campestris wrote:
 
> I know what the code ought to be. It ought to be re-written in C++ using
> atomics (and in several cases other library features - I noticed a
> spin-lock)
 
It could use C11 atomics - there is no need to switch it to C++ just for
the atomic accesses.
 
> somewhere.
 
> I was only hoping someone here had experience of the actual behaviour of
> volatile - but it looks like not.
 
Many of us - like me - have plenty of experience of using volatile. And
in the right place, it is fine.
 
But unfortunately for you, it sounds like this is /not/ the right place.
I'm guessing this is code that worked fine before on a single-core
system, but you can be quite confident that it is not correct for a
multi-core device.
 
You often can't prove you have no race conditions in existing code - you
can only program in a way to make them impossible. And you can't be
sure of finding them by testing. It is very easy to have code that
worked when you tested it in the lab, and fails in the field.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 21 08:43AM +0200

> all, some things do some don't, it was never meant for threading.
> Use std::atomic with _relaxed_ membars to read and write volatiles
> for a device or something.
 
Sometimes it doesn't matter that volatile fetches or writes from or
to memory completely asynchronously. Remember my shared-readers mutex
where the flags and counters value is repeatedly read from a volatile
memory-location on each (failed) iteration.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 21 04:59AM +0200

Specifically, is
 
auto foo() -> auto { return 42; }
 
auto main() -> int
{
return foo();
}
 
... valid?
 
I'd guess that it's not valid as C++11, but possibly valid as C++14 or
later.
 
It compiles with Visual C++ 2019 and g++ 9.2.
 
 
Cheers!,
 
- Alf
woodbrian77@gmail.com: Aug 20 06:24PM -0700

Shalom
 
I'm looking for someone interested in using my messaging
and serialization library:
https://github.com/Ebenezer-group/onwards
 
. I'll spend 16 hours/week for six months on your
project if we use my software as part of the project.
More info here: http://webEbenezer.net/about.html
.
 
If you have an idea on how to improve my repo, please
let me know. Thanks in advance.
 
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net
Bart <bc@freeuk.com>: Aug 21 12:27AM +0100

On 20/08/2019 23:50, Keith Thompson wrote:
>> }
>> }
 
> "gcc -v" or "g++ -v" is easier.
 
But it gives totally different output, where I have to search for the ld
options, if they are there at all (I wasn't able to find them).
 
For example, doing 'gcc -v hello.o' as you suggest produces:
 
--------------------------------------------------------
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/8.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-8.1.0/configure
--host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw810/x86_64-810-posix-seh-rt_v6-rev0/mingw64
--enable-shared --enable-static --disable-multilib
--enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes
--enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto
--enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona
--with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/c/mingw810/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw810/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw810/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw810/prerequisites/x86_64-w64-mingw32-static
--with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project'
--with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2
-pipe -fno-ident
-I/c/mingw810/x86_64-810-posix-seh-rt_v6-rev0/mingw64/opt/include
-I/c/mingw810/prerequisites/x86_64-zlib-static/include
-I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include'
CXXFLAGS='-O2 -pipe -fno-ident
-I/c/mingw810/x86_64-810-posix-seh-rt_v6-rev0/mingw64/opt/include
-I/c/mingw810/prerequisites/x86_64-zlib-static/include
-I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include'
CPPFLAGS='
-I/c/mingw810/x86_64-810-posix-seh-rt_v6-rev0/mingw64/opt/include
-I/c/mingw810/prerequisites/x86_64-zlib-static/include
-I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include'
LDFLAGS='-pipe -fno-ident
-L/c/mingw810/x86_64-810-posix-seh-rt_v6-rev0/mingw64/opt/lib
-L/c/mingw810/prerequisites/x86_64-zlib-static/lib
-L/c/mingw810/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 8.1.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)
COMPILER_PATH=c:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/8.1.0/;c:/tdm/bin/../libexec/gcc/;c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/
LIBRARY_PATH=c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/;c:/tdm/bin/../lib/gcc/;c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib/../lib/;c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../lib/;c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib/;c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../
COLLECT_GCC_OPTIONS='-v' '-mtune=core2' '-march=nocona'
c:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/8.1.0/collect2.exe
-plugin
c:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/8.1.0/liblto_plugin-0.dll
-plugin-opt=c:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/8.1.0/lto-wrapper.exe
-plugin-opt=-fresolution=C:\Users\DESKTO~1\AppData\Local\Temp\cch8uh5p.res
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt
-plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
-plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-liconv
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt
--sysroot=C:/mingw810/x86_64-810-posix-seh-rt_v6-rev0/mingw64 -m i386pep
-Bdynamic
c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o
c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/crtbegin.o
-Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0 -Lc:/tdm/bin/../lib/gcc
-Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib/../lib
-Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../lib
-Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib
-Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../.. hello.o
-lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lpthread
-ladvapi32 -lshell32 -luser32 -lkernel32 -liconv -lmingw32 -lgcc
-lgcc_eh -lmoldname -lmingwex -lmsvcrt
c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/crtend.o
COLLECT_GCC_OPTIONS='-v' '-mtune=core2' '-march=nocona'
--------------------------------------------------------
 
But using my trick, then 'gcc hello.o' generates this much clearer list
of options sent to ld.exe:
 
--------------------------------------------------------
1:
c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe
2: -plugin
3: c:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/8.1.0/liblto_plugin-0.dll
4:
-plugin-opt=c:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/8.1.0/lto-wrapper.exe
5:
-plugin-opt=-fresolution=C:\Users\DESKTO~1\AppData\Local\Temp\ccwqayB7.res
6: -plugin-opt=-pass-through=-lmingw32
7: -plugin-opt=-pass-through=-lgcc
8: -plugin-opt=-pass-through=-lgcc_eh
9: -plugin-opt=-pass-through=-lmoldname
10: -plugin-opt=-pass-through=-lmingwex
11: -plugin-opt=-pass-through=-lmsvcrt
12: -plugin-opt=-pass-through=-lpthread
13: -plugin-opt=-pass-through=-ladvapi32
14: -plugin-opt=-pass-through=-lshell32
15: -plugin-opt=-pass-through=-luser32
16: -plugin-opt=-pass-through=-lkernel32
17: -plugin-opt=-pass-through=-liconv
18: -plugin-opt=-pass-through=-lmingw32
19: -plugin-opt=-pass-through=-lgcc
20: -plugin-opt=-pass-through=-lgcc_eh
21: -plugin-opt=-pass-through=-lmoldname
22: -plugin-opt=-pass-through=-lmingwex
23: -plugin-opt=-pass-through=-lmsvcrt
24: --sysroot=C:/mingw810/x86_64-810-posix-seh-rt_v6-rev0/mingw64
25: -m
26: i386pep
27: -Bdynamic
28:
c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o
29: c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/crtbegin.o
30: -Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0
31: -Lc:/tdm/bin/../lib/gcc
32:
-Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib/../lib
33: -Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../lib
34:
-Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib
35: -Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../..
36: hello.o
37: -lmingw32
38: -lgcc
39: -lgcc_eh
40: -lmoldname
41: -lmingwex
42: -lmsvcrt
43: -lpthread
44: -ladvapi32
45: -lshell32
46: -luser32
47: -lkernel32
48: -liconv
49: -lmingw32
50: -lgcc
51: -lgcc_eh
52: -lmoldname
53: -lmingwex
54: -lmsvcrt
55: c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/crtend.o
--------------------------------------------------------
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 21 01:07AM +0100

On Tue, 20 Aug 2019 04:34:09 -0700 (PDT)
 
> Very cool idea.
 
> I was hoping to use 'ld' instead of 'g++' but if it's that complicated
> then I might not bother.
 
It's not just complicated, it's non-portable, possibly even between
different versions of the same compiler, because you have to link to the
compiler's own C++ and other libraries. If you are compiling your C++
code with g++ on unix-like OSes, then including '-lstdc++ -lm
-shared-libgcc' in the link line (in addition to the C libraries) might
be enough. With clang and libc++ then '-lc++ -lm' might work. But
that is pointless: invoking g++ (or clang++) will automatically do the
job correctly for you. If you want "to be generic", then that's the
way to do it.
 
There are occasions when you have to call up the necessary C++
libraries directly with the linker and take your chances, accepting that
your code is brittle, usually when interfacing with some other
language's FFI where that language's linker assumes C linkage. But
your case does not fall into that category.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)