Sometimes you just gotta stop and have a bump…
You can directly delete iterators while looping through associative containers like set and map:
for(auto itue = usersByEmail_.begin(), itue_end = usersBySecret_.end(); itue != itue_end; )
{
if ((*itue)->bDeleted())
{
// NOTE We could do more cleanup work here if needed.
itue = usersByEmail_.erase(itue);
} else ++itue;
}
With sequential containers like vector, you should use the erase-remove idiom. Here’s an example for my multi-indexed sets of pointers that uses a lambda to keep the code tight. runsByRank_ is of my sorted_vector type:
runsByRank_.erase(
remove_if(
runsByRank_.begin(), runsByRank_.end(),
[]( StockRun*& psr )
{
// NOTE We could do more cleanup work here if needed.
return psr->bDeleted();
}
),
runsByRank_.end()
);
I’ll try to get my quick-http skeleton app updated with these best practices soon. As of now it does not include any delayed-deletion pattern.
When an unauthenticated user accesses a protected resource of my API server, I want to immediately redirect them to the login page. Research has indicated that the server should send the client an HTTP 302 page with the url. Experimentation has shown that you can successfully set cookies. The cookie can be used to hold the url to re-redirect the user back to the original request after authenticating. Nice.
Here’s the header to send from the server:
const string cstr_HTML_302_HEADER1 = "HTTP/1.1 302 Moved Temporarily\r\nLocation: ";
const string cstr_HTML_HEADER2 = "\r\n\r\n";
// ....
string cookie_header = "\r\n";
cookie_header += "Set-Cookie: .... ";
*response << cstr_HTML_302_HEADER1 << "/v1/login.html" << cookie_header << cstr_HTML_HEADER2;
The publicly available version of quick-http on github needs a refresh, hopefully I'll have some time soon to move a large set of new code there that uses Simple Web Server, HTTP 302 redirects, user authentication, etc.
Simple-Web-Server has turned out to be a perfect fit for A better Trader… more to come…
No I’ve never been that great at getting along with other (coders). Much faster to just go where I need to go on my own. Fail. Time to stop being an island, there are far too many compelling shoulders to stand on these days. Strategy shift:
- my Reusable repo will be for helpers and glue, not for major functionality that can be better found (and maintained!) by others
- Pick and CONFORM to good libraries. Better to mildly fork them than try to maintain everything myself.
Seems pretty obvious in hindsight. Working with the Causam team, and collaborating on Simple-Web-Server, were the catalysts, thanks guys.
