Thursday, July 5, 2018

Digest for comp.lang.c++@googlegroups.com - 10 updates in 5 topics

Sky89 <Sky89@sky68.com>: Jul 05 06:12PM -0400

Hello..
 
I have just thought more about C#, and i think that when you work
with "threads" you are not able to get the native "handles" and "IDs" of
the threads, this is why managed code of C# is not "flexible", so with
C# you can not ooptimize the threads to use more than 64 logical
processors under windows and with C# you can not optimize more for NUMA,
this is why i will not port my Delphi and FreePascal projects to C#,
because many of my projects are optimized for NUMA and optimized to use
more than 64 logical processors.
 
Read the following about C# to notice it:
 
"A machine can have larger than 64 logical processors. In such cases the
processors are grouped into chunks of 64. Each such group is called a
processor group. .NET framework can only access the first processor
group, so maximum number that this property can return is 64 (or 32 for
32-bit machines)."
 
 
Read more here:
 
http://www.volatileread.com/Thread/Browse?pg=3&type=newest&tags=multithreading&questionType=1&customPageId=1
 
 
 
Thank you,
Amine Moulay Ramdane.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 05 02:25PM -0400

Are there any existing compilers with a feature to write back out a
minimum set of #include references used by the application being
compiled?
 
If I #include <windows.h> for example, it includes a tremendous amount
of things I may not use in my app. If I only use 50 things, is there
a way in an existing compiler to get a minimum use set of those tokens
or objects and write out a header file that could be used in its place,
for example, so that the huge amount of extra unused header information
is not compiled?
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Jul 05 08:43PM +0200

On 05/07/18 20:25, Rick C. Hodgin wrote:
> or objects and write out a header file that could be used in its place,
> for example, so that the huge amount of extra unused header information
> is not compiled?
 
Here are a few links to suggestions - there is no need for me to copy
out the answers. But the tools I have seen will only look at the actual
#include lines in your code. So if you have "#include <windows.h>" and
use anything that comes from there, it will be marked as used. You
would have to first list all the sub-includes in <windows.h> to see
which of them are used or not.
 
 
<https://stackoverflow.com/questions/614794/c-c-detecting-superfluous-includes>
 
 
<http://www.includator.com/projects/includator/wiki/Find_Unused_Includes_Details>
 
<https://news.ycombinator.com/item?id=10958186>
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 05 02:48PM -0400

On 7/5/2018 2:43 PM, David Brown wrote:
 
> <https://stackoverflow.com/questions/614794/c-c-detecting-superfluous-includes>
> <http://www.includator.com/projects/includator/wiki/Find_Unused_Includes_Details>
> <https://news.ycombinator.com/item?id=10958186>
 
 
Good to see. Thank you.
 
--
Rick C. Hodgin
Bart <bc@freeuk.com>: Jul 05 07:58PM +0100

On 05/07/2018 19:25, Rick C. Hodgin wrote:
> or objects and write out a header file that could be used in its place,
> for example, so that the huge amount of extra unused header information
> is not compiled?
 
I would say that that was quite difficult to do.
 
And I'm not sure how well it would work in practice. For a start, you
have to process the full set of headers once to create the minimised
header.
 
But then that's only good for compiling exactly the same program; how
often that useful? If that is the case, then just use the last object
file created. And if the program /has/ changed, then that minimised
header will be out of date as new code will reference new stuff, while
other stuff is no longer needed.
 
Such a header will anyway be the result of one 'rendering' of a header;
the next one may produce different results because there has been a
subtle change in the environment.
 
And for something like windows.h, that may involve 650 nested #includes,
of I think some 150 unique headers (for mingw's windows.h I think that
is). If one item was needed in each header, would there still be 650
#includes, but there are now 150 minimised header files? What names will
they have, as they can't clash with the originals?
 
Anyway I believe this is just scratching surface of the likely problems.
 
Depending on what you are trying to achieve, perhaps try using or
adapting a much smaller windows.h from another compiler. (Eg. lccwin's
windows.h is 20K lines in 3 unique files, compared to MS' 200K lines in
100 files. Mine is 1.4K lines but there's lots missing...)
 
--
bart
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 05 03:23PM -0400

On 7/5/2018 2:58 PM, Bart wrote:
>> for example, so that the huge amount of extra unused header information
>> is not compiled?
 
> I would say that that was quite difficult to do.
 
I think it would depend on how you parse #include files.
 
For each thing that's defined in header processing, you add a
"touchCount" variable to it, and each time it is referenced by
something outside of the header files themselves, that value
is incremented. You maintain a chain of things that have some
dependencies on other things, so that when one is touched, the
entire cascade of related things are also included. And in
some cases you can replace constants with their actual values
to remove those token names, etc.
 
In the end, you generate an output file which has been built and
established sufficiently to allow compilation of the thing without
the full compilation headers.
 
> And I'm not sure how well it would work in practice. For a start, you have to
> process the full set of headers once to create the minimised header.
 
Correct.
 
 
> Such a header will anyway be the result of one 'rendering' of a header; the
> next one may produce different results because there has been a subtle change
> in the environment.
 
Correct.
 
> item was needed in each header, would there still be 650 #includes, but there
> are now 150 minimised header files? What names will they have, as they can't
> clash with the originals?
 
I'm thinking if you're compiling file.c, then it would create something
like file_mheader.h as an output, which documents only those features of
the entire compilation that are used.
 
It would allow a minimum backup that would compile as-is, allowing a
snapshot of time for a particular version without having to rely on
ever-changing headers over time.
 
One instance we had in our office was an application that's been in
use literally since the 2007 timeframe. It has been debugged, and
working well. A need came up to extend its abilities to incorporate
some new features with one of our servers, and the logic involved in
processing what our servers generate. It wasn't really any new needs
from Windows, just a recompilation of our own logic in the same base
Windows framework for the GUI.
 
The program was last compiled using WinXP and Visual Studio 2005 in 2007.
It had several dependencies which were no longer supported as they were,
and we had to tweak little things here and there to address changes made
in Vista, Windows 7, Windows 8, and now Windows 10.
 
Note: These issues were due to changes in the Visual Studio #include
files. Things that compiled in VS2005 did not compile in VS2015
or VS2017 without tweaks.
 
It didn't take too long (30 minutes), but if we had the minimal header
for compilation, it would have compiled as it was without any changes,
and we could've focused on the change in logic we needed.
 
And if we needed to add things to that version, and we had our summary
minimized header file, we could manually add the handful of things we
need from the true header locations.
 
> much smaller windows.h from another compiler. (Eg. lccwin's windows.h is 20K
> lines in 3 unique files, compared to MS' 200K lines in 100 files. Mine is
> 1.4K lines but there's lots missing...)
 
I would like the compiler to generate the minimum output as much for
documentation and historic snapshots of versions as much anything else.
I've just never seen the ability anywhere.
 
--
Rick C. Hodgin
Peter Cheung <mcheung63@gmail.com>: Jul 05 11:22AM -0700

Chris M. Thomasson於 2018年6月27日星期三 UTC+8上午11時50分15秒寫道:
> > News, and from Indianapolis, IN.
 
> > The imposter here posted from an "en-GB" timezone using Giganews.
 
> I hope all of the mimicry could be halted sometime....
 
where is rick now?
Sam <sam@email-scan.com>: Jul 05 09:41AM -0400

Soviet_Mario writes:
 
> In particular, about function declarations, I assumed that just stripping
> away the function BODY (in braces), generated a forma declaration.
 
No, it doesn't. You have to replace the whole body with a semicolon.
Otherwise it won't compile.
 
> Paavo suggests that, moreover, in CPP files, the body definition should be
> moved from within the class body, outside.
> I'm not understanding this and how it influences linking.
 
What you're not understanding, apparently, is how class declarations work,
and how class methods are defined. Functions and class methods have several
important differences. Class methods look like functions, but they're not
functions. They're class methods.
 
> If I manually merge the files in one, even leving function definitions
> within their class block, works.
 
> Why does it no longer work splitting the project in more files ?
 
Too vague, and nebulous. to answer specifically.
 
In general, you can't just take random pieces of code from one file, chop it
up into pieces, and splatter the results into different files, randomly,
without making any other changes, and in addition to making appropriate
changes to the moved code, also writing some additional header files, so
that everything is still properly declared before it's used. It just won't
work. C++ does not work this way.
 
You can't just say, take:
 
class Foo {
 
// Some declarations
 
void bar()
{
// Some code
}
};
 
Replace it with
 
class Foo {
 
void bar();
};
 
and then go and write
 
void Foo::bar()
{
// Some code
}
 
somewhere else. At least not without including the header file. And even if
you include the header file, you can't do that if the class method is a
template class method.
 
> I can't find the difference of defining a function entirely within a class
> body or just declaring it (like in the header) and then defining out of the
> class body (using the prefix ClassOwner :: MemberFunction (...) { ... };
 
That's because there is no difference, provided that everything else is set
up correctly, and wherever the class method (not a function) gets defined,
over there the declarations of everything that the class method uses are
properly declared. And that "wherever" gets linked.
 
> I attached the whole code as you can see.
 
No, I do not see anything in your message. You might've included your code
in some other message, that's lost somewhere else in the newsgroup, but when
someone replies to a message that's all they see.
 
So, I can't really "see" anything, at the moment.
 
>> files work. If there's
 
> I missed this details both on paper book and in some C++ reference
> online ... that's why i'm trying to resort to the NG
 
The only way to rigorously learn C++ is by using a dead tree. It's true that
there are many online resources out there. But they're not a replacement for
a well-written dead tree. Some online C++ web site may seem very attractive,
leading one to believe that all they had to do is read a couple of pages and
they become an instant C++ expert. Sorry, it doesn't work this way.
 
C++ is the most complicated general purpose programming language in use
today, and its complexity increased, in my estimation, about three-fold in
the last couple of years. C++ never had a reputation for instant
gratification, and now it never will. There is no alternative to setting
aside plenty of time to read through a good book, until you thoroughly
understand how declarations work, how definitions work, and other things.
Randomly cutting and pasting chunks of code, crossing your fingers, then
hope things will compile and link, is unlikely to succeed without a
thorough, complete, fundamental understanding of what you're actually doing.
Soviet_Mario <SovietMario@CCCP.MIR>: Jul 05 07:02PM +0200

Il 05/07/2018 15:41, Sam ha scritto:
>> generated a forma declaration.
 
> No, it doesn't. You have to replace the whole body with a
> semicolon. Otherwise it won't compile.
 
I've done this, a statement needs termination ...
 
> Functions and class methods have several important
> differences. Class methods look like functions, but they're
> not functions. They're class methods.
 
could you please spend some more words on this aspect or
suggest a link ?
 
I just can think of differences from static members (not
bound to a particular instance), true members (with their
THIS pointer) and friend members, which are external
functions granted of access to data member (I don't remember
if they receive an implicit this pointer or a class object
reference or pointer have to be passed to them, that is they
are like static members but need to be associated with an
instance at runtime via argument explicitely passed).
 
But I've heard the METHOD word just in C# and VB, never in
C++. So please tell me more about this aspect
 
 
>> Why does it no longer work splitting the project in more
>> files ?
 
> Too vague, and nebulous. to answer specifically.
 
I gave the example here in this same 3D
snews://powernews.libero.it:563/phdffi$hsa$1@dont-email.me
 
<phb40c$9o2$1@dont-email.me>
 
 
 
 
> In general, you can't just take random pieces of code from
 
oh God, I don't just cut in RANDOM pieces, come on !
 
> the moved code, also  writing some additional header files,
> so that everything is still properly declared before it's
> used. It just won't work. C++ does not work this way.
 
this is futile sarcasm actually.
I don't understand why
 
 
> method (not a function) gets defined, over there the
> declarations of everything that the class method uses are
> properly declared. And that "wherever" gets linked.
 
oh
very confusing getting different opinions. I can't exteem
which is correct :\
 
 
>> I attached the whole code as you can see.
 
> No, I do not see anything in your message. You might've
 
it was above in the same tread. It is not a huge 3D
 
>> the NG
 
> The only way to rigorously learn C++ is by using a dead
> tree.
 
I did it once, on Bjarne Stroustrup textbook, I'm not
learning C++ from scratch, I just need to remove some rust
(I'm also new to QT which makes the things harder)
 
> leading one to believe that all they had to do is read a
> couple of pages and they become an instant C++ expert.
> Sorry, it doesn't work this way.
 
Friend, first of all I don't need to become an expert, and
secondly I happen to have studied a lot, just long ago.
I manage to "think" in C++ terms, but I'm no longer FLUENT
in the constructs.
I never managed every single aspect of the language (for
example closures, lamda expressions are beyond my skills),
but I just need to use a C+ (a far better and type checked
C). Rarely I used also IsA inheritance (preferring HasA pattern)
 
 
> C++ is the most complicated general purpose programming
> language in use today, and its complexity increased, in my
 
Im very outdated on last 10 yrs developments ... but
actually I need to solve rather basic doubts, I'm an hobbyist
 
> estimation, about three-fold in the last couple of years.
> C++ never had a reputation for instant gratification, and
 
oh I'm not in a hurry, never mind.
The fact is, I find it rather easy to think in C++ terms
when designing the data layout, and also easy to code
algoritms in this language.
But I make many syntax mistakes or more subtle errors
 
> plenty of time to read through a good book, until you
> thoroughly understand how declarations work, how definitions
> work, and other things. Randomly cutting and pasting chunks
 
friend, it has never been my habit to steal other's code. I
write it all by myself and try to learn from what I read.
 
> compile and link, is unlikely to succeed without a thorough,
> complete, fundamental understanding of what you're actually
> doing.
 
well, sarcasm's deluge. Congrats.
I still have to understand why
 
Just try to assume I can be misunderstood cause I don't
master English, at least
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
Ian Collins <ian-news@hotmail.com>: Jul 05 08:11PM +1200

On 16/06/18 11:54, James Kuyper wrote:
> small number of inputs, no more than 128 bits or so, and executes very
> quickly, which is why I tend to think of small functions rather than
> entire programs when I'm thinking about that possibility.
 
The key point form my side is that there often aren't "true
requirements", at least not in great detail. The customer says she
wants something to happen when an item is selected, she doesn't care how!
 
> for a test to execute the piece of software with each and every one of
> the possible inputs. I find it easier to imagine such software if it's
> only a small subroutine, and not an entire application.
 
You could argue the same form any testing philosophy.
 
> every one of those possible inputs could justifiably be considered as
> imposing the same requirements as should properly be specified in a
> separate requirements document.
 
This probably is due to the kinds of software you have worked with. A
large proportion of software is event driven, or state machines which
have a much smaller discrete set of inputs. Even software that
transforms large data sets will be broken up into smaller algorithmic
components that are easier to test. Algorithms which process analogue
data are never tested with the full range of possible inputs, that is as
you say impossible. This doesn't stop the code being tested with
representative data. Such code will undoubtedly have a written
specification defining the algorithm. I'm not claiming that a function
such as sin(x) could be specified by tests!
 
--
Ian
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.

No comments: