mirror of
https://github.com/jmcnamara/libxlsxwriter.git
synced 2026-05-15 14:15:54 -06:00
[GH-ISSUE #102] char* to const char* for chart #84
Labels
No labels
awaiting user feedback
bug
cmake
cmake
docs
feature request
in progress
long term
medium term
medium term
pull-request
question
question
ready to close
short term
under investigation
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/libxlsxwriter#84
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Alexhuszagh on GitHub (Mar 9, 2017).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/102
chart.h and chart.c currently use
char *for 3 functions (chart_series_set_labels_num_format,chart_series_set_trendline_name,chart_axis_set_num_format), without modifying the source buffers. These should takeconst char *as an argument, rather thanchar *, both as a guarantee that they will not be modified, but also for integration with STL containers (std::string::data()andstd::vector<char>::data()both returnconst char *).I've attached diffs of the changes required to make this change.
chart.h
chart.c
@Alexhuszagh commented on GitHub (May 22, 2017):
I'm wondering if there is any update on this issue? I wrote C++ wrappers for your C API (that I am looking to maintain) using object-oriented design and this would be the last remaining step so I could build off the source tree.
@jmcnamara commented on GitHub (May 23, 2017):
I've been very busy and haven't had time to work on my OS projects recently. However, I'll try push this up soon.
It would be good if there was some test, or tests, that I could add that would catch this and other C++ issues in the interface. Can you suggest something?
@Alexhuszagh commented on GitHub (May 23, 2017):
@jmcnamara No worries, thanks for all the help.
I can think of a few solutions (although none are preferable):
The bindings only wrap API functions, so this should change minimally and any changes on your end that affect the wrappers should also affect other programs, meaning this is not a unique issue.
A sample of a C++ binding declaration is below. It's mainly wrapped for OOP, and to respect C++'s RAII idiom. I was mostly using this for my own personal use, but I'm open to changing the interface to better reflect the C API (so
typedef lxw_row_t Row;becomestypedef lxw_row_t row_t;,ChartSeriesbecomeschart_series, andnamespace xlsxwriterbecomeslxw).@jmcnamara commented on GitHub (Jun 25, 2017):
I've fixed this on master and added a test so that other omissions like this are caught in the future.
Thanks.