-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding attributes to tags in svg backend #72
Labels
enhancement
New feature or request
Comments
struct att {
std::stringstream ss;
att() { ss << std::setprecision(5); }
template<typename T>
std::string operator()(const std::string& name, const T val)
{
ss.str("");
ss << name << "=\"" << val << "\" ";
return ss.str();
}
};
|
@martinjrobins your struct is actually slightly faster than mine, with nicer semantics too 👍. Using But, I really don't like it as a solution:
I think I'll go ahead and implement something like your suggestion and we can see what it looks like. |
I agree, I don't think using |
fcooper8472
pushed a commit
to fcooper8472/trase
that referenced
this issue
Jul 14, 2018
martinjrobins
pushed a commit
that referenced
this issue
Jul 17, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I would like to implement some helper to make this kind of thing look less nasty (easier to read, reason about, and maintain):
There are several possible options.
1. Function template, something like:
so that the above example becomes
This looks quite nice, and is certainly much easier to read. But, the overhead of generating lots of
stringstream
objects and returning strings is high (~2x slower). Speed probably isn't a massive concern at this stage, but let's avoid massive slowdowns if there's a better option.2. As above, but sending straight to
m_out
:I don't like this option at all, because the example becomes:
It's super unclear at a glance what's happening and doesn't have any flexibility at all.
3. A small class for gathering attributes:
The example becomes
This has a greatly reduced cost vs 1, is flexible, but perhaps not the most elegant.
@martinjrobins Any other ideas for how this might look?
The text was updated successfully, but these errors were encountered: