- Pragma once support - 9 Updates
- experimental multi-mutex algorithm... - 3 Updates
- On-line code generation - 1 Update
- constexpr issues - 4 Updates
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 30 02:58AM +0100 > One of the comments in this thread: > https://www.reddit.com/r/cpp/comments/a14o5q/real_world_problems_with_pragma_once/ > said that Cray doesn't support pragma once. There is a table in Wikipedia, <url: https://en.wikipedia.org/wiki/Pragma_once#Portability>. > I know gcc, > Clang and MSVC do support it. I was wondering if Intel, > IBM or Oracle compilers support it. Intel yes, IBM yes since version 3.1.1, Oracle yes since dev studio version 12.5, all according to that table. [snip] Cheers!, - Alf |
| woodbrian77@gmail.com: Nov 29 08:06PM -0800 On Thursday, November 29, 2018 at 7:58:45 PM UTC-6, Alf P. Steinbach wrote: > > IBM or Oracle compilers support it. > Intel yes, IBM yes since version 3.1.1, Oracle yes since dev studio > version 12.5, all according to that table. I downloaded the Nvidia/Portland Group compiler. It also handles pragma once. It produces chubby text segments, though compared to gcc or even clang. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| David Brown <david.brown@hesbynett.no>: Nov 30 08:38AM +0100 On 29/11/18 22:56, Vir Campestris wrote: >> changing, unless someone complains about it not working with their >> compiler. > To be fast, and standard compliant, I use both. That may limit the speed advantages of both, depending on the compiler and on the order you have them. It's not going to make much difference (either way, you skip compilation - and preprocessing is generally very fast). I can appreciate that some people think "#pragma once" is neater than include guards, and so choose to use it. And I can appreciate people choosing include guards, as they are standard and supported everywhere. But using both kind of defeats the purpose - it combines the disadvantages of both methods. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 30 01:46AM -0800 > I downloaded the Nvidia/Portland Group compiler. It also > handles pragma once. It produces chubby text segments, > though compared to gcc or even clang. It is hard to find conforming compilers that do not support pragma once. There can be issue with projects where there are copies of same header; when more than one of those end up included to same cpp file then pragma once and include guards handle it differently. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 30 05:45PM +0100 > I think "#pragma once" is supported by most compilers, but include > guards are supported by /all/ compilers. I would expect performance > of them to be very similar - ... Thinking about the efficiency of #pragma once or include-guards is idiotic. |
| Vir Campestris <vir.campestris@invalid.invalid>: Nov 30 09:47PM On 30/11/2018 16:45, Bonita Montero wrote: > Thinking about the efficiency of #pragma once or include-guards is > idiotic. When your compile cycle takes 35 minutes using Icecream and a pool of a couple of hundred CPUs you care. Andy |
| Vir Campestris <vir.campestris@invalid.invalid>: Nov 30 09:49PM On 30/11/2018 09:46, Öö Tiib wrote: > same header; when more than one of those end up included > to same cpp file then pragma once and include guards > handle it differently. I can't think of any reasonable case where they would. (unreasonable? two files with the same guard name??) Andy |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 30 10:59PM +0100 On 30.11.2018 22:47, Vir Campestris wrote: >> idiotic. > When your compile cycle takes 35 minutes using Icecream and a pool of a > couple of hundred CPUs you care. Did you try Lakos external include guards? Cheers!, - Alf |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 30 11:12PM +0100 On 30.11.2018 22:49, Vir Campestris wrote: >> handle it differently. > I can't think of any reasonable case where they would. > (unreasonable? two files with the same guard name??) Generally a local file can be identified by volume id and file id within the volume. This means that with a compiler with some smarts in its file identification scheme a /copy/ B of a local file A will not be viewed as the same file as A. One hypothetical way that that could happen is when a 3rd party library L that you're using bundles a library M header it uses, when you're also using library M directly. A second scenario can be when it's difficult to identify a file residing on a different host on the local network, or even out in the cloud. However, in the Reddit thread referred to by Brian, AFAICS nobody reported ever actually having had problems with `#pragma once`, but some reported having had problems with ordinary include guards, in particular stemming from the not uncommon technique of copy-and-modify programming. Cheers!, - Alf |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Nov 30 02:18PM -0500 Chris M. Thomasson wrote: > } > _____________________________ > Will post more info sometime tomorrow. Chris, do you have a use case? Your approach of ordering multiple resources that need locking in some global order (along with alternative optimistic algorithms) has been successfully used by DBMS s for years to transactionally alter multiple rows (or records or sets etc for non-relational DBMSs) for concurrent transactions so the algorithm itself is sound. With regard to mutexes in a multi-threaded program, however, I cannot recall when I saw a necessity to simultaneously lock more than one mutex (I saw code that did it but always in the context where I would either refactor it to not do it or at least wanted to refactor it so). It might certainly be that my experience is skewed so I am curious to see a use case. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Nov 30 08:01PM > (I saw code that did it but always in the context where I would either > refactor it to not do it or at least wanted to refactor it so). It might > certainly be that my experience is skewed so I am curious to see a use case. Refactor this: { AutoLock<Mutex> l(lstSvcM_); AutoLock<Mutex> ll(availM_); AutoLock<Mutex> guard(rtlock); if(!lstSvc_.empty()) { s= lstSvc_.front(); lstSvc_.pop_front(); } else if((running_threads < 100 || threadsAvail_ > 3) && !lstSvcLow_.empty()) { s = lstSvcLow_.front(); lstSvcLow_.pop_front(); } else { more = false; s=0; continue; } } -- press any key to continue or any other to quit... |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Nov 30 04:31PM -0500 Melzzzzz wrote: > continue; > } > } What does "this" compute and why? |
| woodbrian77@gmail.com: Nov 30 11:03AM -0800 > Brian > Ebenezer Enterprises - Enjoying programming again. > http://webEbenezer.net First, the link above for wrappers.hh has changed. The new link is https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/Buffer.hh Some may make fun of on-line code generation, but today I'm trying to install the Intel C++ compiler. I got "Checking the prerequisites. It can take several minutes. Please wait...". That was over an hour ago and nothing has happened. I'm sure there are hundreds of others across the world who are having problems installing C++ compilers. Some of them have realized they have a problem, but others haven't even realized that their install is faulty yet. On-line code generation minimizes the software that you have to download/build/maintain, thereby avoiding most of these install problems. Brian Ebenezer Enterprises http://webEbenezer.net |
| wyniijj@gmail.com: Nov 29 05:18PM -0800 Öö Tiib於 2018年11月29日星期四 UTC+8下午9時25分08秒寫道： > > 'for fun' looked to me (much less insightful). > The constexpr function of C++11 can contain only one, return, > statement. That is clearly too limiting. That's another helpful piece of information for me. By the way, is the function definition constexpr size_t slen(const char* cstr) { return ::strlen(cstr); } correct in c++11 (or c++14,c++17)? > So it is developer who should choose what tool to use > for what task. Python is better tool for some situations, > C++ for other situations. We were using the same words 'user/developer' in different context. with 'user' I meant (c++) language user with 'developer' I meant (c++) language developer Because I used to encounter c++ language developers here in this forum, or people who speak like c++ language developers. I thought you might be a c++ language developer too, or at least one devoted to the development of c++ language. I sensed you recommend c++17. The major concern is a part of my program require nearly exaustive accompanying test codes. If c++17 is adopted, I have to skip/ignore those new things added sine c++11, I am not sure this skip/ignore-ness is safe, or proper. By the way, thanks to Scott Lurndal who explained 'sub-par' |
| "Öö Tiib" <ootiib@hot.ee>: Nov 30 01:11AM -0800 > > > Öö Tiib於 2018年11月28日星期三 UTC+8下午9時13分36秒寫道： > > > > On Wednesday, 28 November 2018 02:09:10 UTC+2, wyn...@gmail.com wrote: > > > > > Öö Tiib於 2018年11月28日星期三 UTC+8上午12時28分20秒寫道： snipping a bit. > By the way, is the function definition > constexpr size_t slen(const char* cstr) { return ::strlen(cstr); } > correct in c++11 (or c++14,c++17)? No. Implementation may do strlen compile time as optimization but C++ committee avoids retrofitting constexpr to library functions. I don't know the reason of it. People can make their own in C++11 with recursion: constexpr int length(const char* str) { return *str ? 1 + length(str + 1) : 0; } > We were using the same words 'user/developer' in different context. > with 'user' I meant (c++) language user > with 'developer' I meant (c++) language developer Ok, I misunderstood. > forum, or people who speak like c++ language developers. I thought > you might be a c++ language developer too, or at least one devoted > to the development of c++ language. I am programmer. I am not implementer of programming languages. I have actually only in one project dealt with kind of self-made scripting language. It convinced me that such efforts are waste of time. There are too many programming languages. There are no point to add one more. It is lot easier and fruitful to fit one of those into any situation. > I sensed you recommend c++17. Actually C++14 improved constexpr in language. The C++17 added constexpr-compatible class templates (string_view, optional and variant) to standard library. > program require nearly exaustive accompanying test codes. If c++17 > is adopted, I have to skip/ignore those new things added sine c++11, > I am not sure this skip/ignore-ness is safe, or proper. I do not understand that logic. How difficulties with C++17 follow from tests? Tests are normal with any toolset and there are AFAIK nothing in C++17 that makes testing harder. It is even easier to migrate to newer compiler when there are tests since those help to discover cases when some incompatibility or defect starts to manifest itself. |
| wyniijj@gmail.com: Nov 30 06:02AM -0800 Öö Tiib於 2018年11月30日星期五 UTC+8下午5時12分05秒寫道： > { > return *str ? 1 + length(str + 1) : 0; > } Brilliant solution! (or resolution made by c++11) > easier to migrate to newer compiler when there are tests since > those help to discover cases when some incompatibility or > defect starts to manifest itself. I mean manually writting test cases for, for instance, all the 'new words' that can be found in the mentioned webpage for constexpr https://en.cppreference.com/w/cpp/language/constant_expression like , including constexpr, lvalue-rvalue*reference, glvalue, prvalue, immediate function, lambda expression, odr-use , implicit conversion,... Hope you can see that is not an easy job. I had done such things for pre-c++11. Even today there are still several things inconvenient to say loudly, e.g. multiple inheritance. I appreciate your expertise in c++. But if you examine it closely, you might end-up recall the experience 'waste of time' again. That is what I thought and the reason hesitate. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 30 06:50AM -0800 > https://en.cppreference.com/w/cpp/language/constant_expression > like , including constexpr, lvalue-rvalue*reference, glvalue, > prvalue, immediate function, lambda expression, odr-use , implicit conversion,... Do you use all that in your code? If you don't then why to test how compiler handles it? Is your program a parser of C++? Tests are usually checking if the program (or functions in it) give expected outputs to test inputs, and not how C++ features work on any kind of code. > in c++. But if you examine it closely, you might end-up recall the > experience 'waste of time' again. That is what I thought and the > reason hesitate. In my programs inheritance is rare, the few inheritance trees are flat and multiple inheritance is extra rare. The tests are only written if these few classes with multiple inheritance behave as expected in contexts where these are used. I do not need tests how multiple inheritance works in general and in whatever context. |
| 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. |
