- About C# - 1 Update
- Compilers which produce minimum #include set - 5 Updates
- Christianity is a religion - 1 Update
- [newbie] visibility again - 2 Updates
- High horse - 1 Update
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:
Post a Comment