Forum Replies Created
-
Posts
-
The C++ Core Guidelines R.33, R.34, R.35, and R.36 state to warn if a function takes a smart pointer by reference and does not either assign to it or call reset() on it at least once in the code path, and that taking a T* or T& is suggested instead.
The is the approach I have been adopting. Only pass as a shared_ptr or move as a unique_ptr if I knowI will be assigning or reseting the pointer. If all I need to do is access the data the pointer is referring to then use raw pointers or references. Also, if multithreaded code, make sure the lifetime of the smartpointer does not go out of scope while I am using the raw pointer or reference.
I believe passing ownership means that the caller of the function that has a shared_ptr as a parameter may go out of scope and so it will be passing ownership on to the callee. Or that the callee can release the pointer at any time.
With the borrowing model, the caller retains owning the data. In that respect, the caller should stay in scope for the lifetime of the callee.
For a majority of my career, I have been in the financial industry (hedge funds, proprietary trading firms, etc). I’ll be starting a new job in a couple of weeks at a brokerage firm.
My most recent role was as a contractor at Bloomberg. The role I did there was migrating old C++ apps that were running on Solaris and AIX machines to run on Linux machines. It was a pretty interesting project taking code that compiles on C++03 compilers and get them to run on Linux. In some cases, I would make small changes here or there to get it to compile or do complete rewrites of the code for a C++17 compiler. There were several things to keep in mind e.g. little-endian vs big-endian data, whether the headers and functions being included were also Linux compatible (some of which was calling Fortran code), etc. Since a lot of this code was about 20 years old with very little documentation, it was a challenge to figure out what the code was supposed to be doing and then adding unit and regression tests.
I am looking forward to my new role where I would be migrating their old code (C++ and SQL stored procedures) to Modern C++.
Imran Javaid
Are files ever deleted from this directory?
If the process is restarted, you do not want to reprocess existing files and only pick up unprocessed files?I think a better solution would be to have a persistent queue (like Kafka) that keeps the processed files and only have one process watching/reading directory. When the process starts, it will read the whole directory, compare against the persistent queue to eliminate the already processed files, send off the unprocessed ones to downstream process and then start watching for directory changes. The downstream process would add the file to the persistent queue once it has successfully processed the file.
So I was trying to come up with an example to see if push_back would call the move constructor but it is calling the copy constructor in the following example:
https://godbolt.org/z/hrYeME1Ya
If I use the default constructor, it does a shallow copy and so member variables point to the same location as before the push_back.
Two things I am confused about in my example are:
1) if I uncomment the destructor, I get a double free error.
2) after I push_back b, and then change b, the push_backed value is the same as the new value of b, even though their address is different.EDIT: For 2) I guess it is because it is undefined behavior changing b when std::move has been called on it.
In a recent interview I was asked to only print the duplicates in a list. They need to be printed only once. This is one solution for that:
https://godbolt.org/z/vaoqv5o3c
Here is one way I can think of to do this using std::copy_if:
https://godbolt.org/z/v96c1Enfq
I have three versions in there, one that uses a variable from the enclosing scope and two that use a variable limited to the lambda.
Edit: oh, an easier way would be to just use std::unique
You created a on the stack. std::move then does “efficient transfer of resources from t to another object” (per cppreference). It has to move the value from stack to heap and so does need to do a copy. Even if you create a on the heap (as a pointer), it will have to be a copy that is then put in the vector (as far as I know).
I would add that whenever performance is an important factor, benchmark your use cases.
Take for example the following code:
https://gist.github.com/imranjavaid/ed22c7a164ac394f74a0371d20ecfa4e
I fill the containers with 100,000 random ints. In the case of vector, I sort the vector and then do an upper_bound to get a number that is likely to be in the middle. With the other two I just do the inserts (because the containers are sorted) . The vector turns out to be more performant in this case.
If my use case was just to see the performance of the upper_bound call, then the three containers have similar performance. So use cases are important. If you care about inserts into the container or if you care about lookups, treat the use cases differently and test for them and then decide which container is best for you. This is also why many variations of these containers are available outside of STL which optimize for different use cases.
Jason,
I am planning on being at the next Chicago C++ meetup: https://www.meetup.com/Chicago-C-CPP-Users-Group/events/289537682/
Sounds like an interesting topic, a Kafka alternative written in C++.
