C++ Gurus

@kshegunov said in What is the point of using noexcept as specificator?: almost always auto I have run into problems with this. You can write code you think is doing one thing. Yet because you didn't explicitly provide the type, you may be getting something else altogether. Then you wonder why something downstream is not working as you thought. I find it useful to specify the type in cases where there might be ambiguity in my mind as to what I am actually getting. auto sometimes clouds this perception and makes for confusing moments in coding.

@Christian-Ehrlicher said in How to remove an element in an array in c++?: When the element is movable and big enough I'm pretty sure your results will be much different. If it's big enough (whether it's movable is irrelevant), then the standard swap in-place on each removal is going to perform the worst. Move semantics can't magically prevent a copy, it's just a hint to the compiler where it can elide the copy, but you can't cheaply reorder memory regardless of the compiler knowing or not knowing if the element is movable. Just sayin'.

If coding for the platform then it's ok to use the Qt types. If the function is more generic then use the equivalent standard types. As for myself: I generally use standard types even if Qt aliases them.

@fcarney said in Efficiency of std::vector copy?: Interesting. This will affect my decision for references. I will have to play with this a bit. It really depends upon what my life cycle ends up being for each module involved. Do I pass a football around or do I copy and keep them more independent? That will be something I need to figure out. If we are talking performance, the best would always be having a common buffer that's not locked at all (i.e. every thread working on its piece). Especially when you manage to align the pieces on the cache line size to have better cache coherency. It'd really depend on what exactly you're doing though, as for most cases the signal-slot mechanism is just fine. @Chris-Kawa said in Efficiency of std::vector copy?: Using QVector in this scenario is pretty much like using std::shared_ptr<std::vector<double>>. Sharing is protected but access to the data is not and is up to you. Although to QVector's advantage in that case it's internally ref-counted, thus you get one indirection less accessing the underlying object (independent of syncing that actual data that is).

If your program starts, then you can put in a delay somewhere, for example: for (;;); so that you will have time to run ListDLLs

Referring to a 25 year old framework in a discussion of modern C++ best practices really doesn't help your case though Why? Things haven't changed that much really. Some new stuff came along but the old is very much still there. There's still a lot of software using MFC today. I'm not saying you should use it in new projects or anything like that, but it's still there, still works and the rules of how it works didn't change, so I think it's a perfectly valid point in this discussion. I'm not talking about some obscure tech that fell out of use. It's (sadly) very much alive. and even humble MFC had a main(), they just didn't call it that. I think it was _tmain() or wmain(). Right, well, it's, again, a little bit more complicated. Yes, that framework provides a _tWinMain that called AfxWinMain and that's one way to make an MFC app, but you can also skip that and start the event pump another way. Anyways, I don't want to get into MFC discussion, that wasn't the point :P The point was you don't need a main() or any other function to initialize global statics and run some code in their constructors. Another example is global statics in dynamically loaded libraries. I hope this one is less controversial :) The best practice in the regulated field I work in is to use the "construct on first use" paradigm. I think we have a misunderstanding coming from that name, but the thing it names is a perfectly valid strategy, I agree. Global (static) objects are bad when they have interdependence upon each other. I absolutely agree. If I seemed to advocate for using static globals let me be very clear - I'm not. They have their uses, sure, but also the order of initialization problem you mentioned, so that's something to take into account in your app design. If it matters - don't do it, if it doesn't - go ahead. I was merely trying to convey how they work on a technical level. that's why it is often better to use global static pointers to those object and construct them in a well-defined order in main(). See, I think this is the point of confusion we had. If you use global pointers then those pointers get initialized (zeroed) in the way I was taking about. The pointers, not the objects that they later point to and you can obviously assign to them in main() or wherever else in a controlled order that you like. The pointers themselves though are originally initialized for you in an unspecified order. It doesn't really matter in that scenario of course as you overwrite them later in a way you see fit. The gist of it is that the pointers are the global static objects we're talking about here, not the things they later point to. I suspect we'll continue to agree to disagree. LOL I think we actually agree. We just misunderstood each other on some technicalities ;)

@kshegunov Thank you, will remember that.

@Please_Help_me_D said in Error using qEndian: Is that beacause my computer native is little endian? Yes.

Wow. How did I miss that... Well that should solve it. Thanks!

@Please_Help_me_D OK, but in case someone observes that this is not the way to do it (which they are entitled to do!), be aware of that. Given: There is official description of the file format that tells us that number in 3225-3226 bytes should be in range from 1 to 5. somewhere in such an official description there should also be a statement as to how they store 2-byte/16-bit numbers!

@Kent-Dorfman said in QHash<int,QString> vs QHash<int,QByteArray>: Where would those roleNames commonly be used? Since they are themselves a type of code metadata (possibly used internally by the Qt framework), I don't think you'd want any QString locale conversion done on them. Also, for ASCII-only strings QString takes twice as much memory than QByteArray because of UTF16 encoding.

@Christian-Ehrlicher, @Konstantin-Tokarev thank you very much for your inputs.

@Weichao-Wang said in Iterator algorithm: assignment: double instead of doppelt (which is German). You can edit your posts by clicking on the three vertical dots right down of the post. And when the topic is solved you can mark it as such with the 'Topic Tools' button.

I have written the following code: if (fileEndian == "Little"){ for(quint32 i = 0; i < nTrc; i++){ FFID(i) = *util::bit_cast<qint32*>(qFromLittleEndian(qFile->map(3608+i*bytesPerTrc, 1))); } } else if (fileEndian == "Big"){ for(quint32 i = 0; i < nTrc; i++){ FFID(i) = *util::bit_cast<qint32*>(qFromBigEndian(qFile->map(3608+i*bytesPerTrc, 1))); } } It gives me errors: readsegy.obj:-1: ошибка: LNK2019: unresolved external symbol "unsigned char * __cdecl qbswap<unsigned char *>(unsigned char *)" (??$qbswap@PEAE@@YAPEAEPEAE@Z) referenced in function "unsigned char * __cdecl qFromBigEndian<unsigned char *>(unsigned char *)" (??$qFromBigEndian@PEAE@@YAPEAEPEAE@Z) debug\ReadSegy.exe:-1: ошибка: LNK1120: 1 unresolved externals The compilator output: jom: C: \ Users \ tasik \ Documents \ Qt_Projects \ build-ReadSegy-Desktop_x86_windows_msvc2017_pe_64bit-Debug \ Makefile.Debug [debug \ ReadSegy.exe] Error 1120 jom: C: \ Users \ tasik \ Documents \ Qt_Projects \ build-ReadSegy-Desktop_x86_windows_msvc2017_pe_64bit-Debug \ Makefile [debug] Error 2 19:05:31: The process "C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe" ended with code 2. Error during assembly / deployment of ReadSegy project (bundle: Desktop (x86-windows-msvc2017-pe-64bit)) During the execution of the "Assembly" Actually the problem was that I didn't know the line which throws these errors but by intuation I just commented the BigEndian part of the code and it works: if (fileEndian == "Little"){ for(quint32 i = 0; i < nTrc; i++){ FFID(i) = *util::bit_cast<qint32*>(qFromLittleEndian(qFile->map(3608+i*bytesPerTrc, 1))); } } else if (fileEndian == "Big"){/* for(quint32 i = 0; i < nTrc; i++){ FFID(i) = *util::bit_cast<qint32*>(qFromBigEndian(qFile->map(3608+i*bytesPerTrc, 1))); }*/ } I use little endian Windows 10 x64, Qt 5.14.0, MSVC 2017 x64. Why do I can use qFromLittleEndian but I can't qFromBigEndian?? By the way the endian of my file is LITTLE now I think I just found a solution. If I change the order of performing bit_cast and qFromBigEndian it works: if (fileEndian == "Little"){ for(quint32 i = 0; i < nTrc; i++){ FFID(i) = qFromLittleEndian(*util::bit_cast<qint32*>(qFile->map(3608+i*bytesPerTrc, 1))); } } else if (fileEndian == "Big"){ for(quint32 i = 0; i < nTrc; i++){ FFID(i) = qFromBigEndian(*util::bit_cast<qint32*>(qFile->map(3608+i*bytesPerTrc, 1))); } } I don't understand why but that works fine

@ASCsk said in Nested Map QDialog sharing: QDate Calendario::on_calendarWidget_clicked(const QDate &date) { *selecteddate = date; qDebug() << *selecteddate; return *selecteddate; } This screams for cleanup. There's no need to allocate a QDate on the heap. In any case, from your description, you should really consider using a database. Please take the time to go through the corresponding chapter in Qt's documentation as well as read the examples.

Thanks for the input guys, much appreciated!

@Chris-Kawa It looked a bit like "Kiwi" to me, I was way off. "("Down-under" means Australia or New Zealand.) It may be wasted on you, but the one thing I was thinking I might regret on my deathbed is that Kylie never chose to marry me. I do not believe that is because she is disappointed that I did not use compiler optimizations ;-) All the best :)

@UnknownCOder But how many LEDs? If leds contains 60 elements then leds[z] will crash if z is 60 as the biggest valid index is 59!

To an extend it does. The chart does not compare the advantages of using a singleton vs an uncreatable type if the singleton is not instantiated at all.