Re: [Geeqie-devel] Geeqie++ fever dreams
On 2016-12-23 20:42, Omari Stephens wrote: > It is at least hypothetically possible to port Geeqie to C++11 / GtkMM. [...snip...] > Thoughts? libstdc++ ABI compatibility problems? -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
[Geeqie-devel] Geeqie++ fever dreams
It is at least hypothetically possible to port Geeqie to C++11 / GtkMM. Ignoring the inevitable ridiculous mountain of work that it would take, does the end state seem like a good idea? Personally, I only knew C89 and small quantities of C++98 until I started using C++11 for work earlier this year. One of the things I've come to appreciate about it is that std::unique_ptr and std::move make memory _ownership_ explicit, which basically makes memory leaks, double-frees, and other pointer maladies a non-issue. You still have bare pointers when you need them, but you only have to use them when really needed. The other thing that seems useful is that between C++ and GtkMM, you get real namespaces and an actual honest-to-goodness GTK class hierarchy. And templates mean GList* turns into GList*, so you can know what's inside of it just by glancing at the header file, without having to dig through the code. And then if you try to put the wrong thing into it, it's a compile-time error instead of a segfault. Thoughts? --xsdg -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie coding standards? Third edition :o)
Omari> It appears that each time I come back to working on Geeqie, I send one Omari> of these emails ;o) LOL! Omari> Here are threads #1 and #2: Omari> #1: https://sourceforge.net/p/geeqie/mailman/message/22531197/ Omari> #2: https://sourceforge.net/p/geeqie/mailman/message/27441283/ Omari> In #2, I had created a one-liner to compute a line-length Omari> histogram our codebase. I've rerun it and included the results Omari> below as [1]. If also attached a list of max-line-length by Omari> source file. As of my git clone from earlier this week, Geeqie Omari> has 106k lines. 227 of those lines are over 160 characters. Omari> That's 0.2% Omari> I am willing to change those 227 lines by hand if it means we can commit Omari> to a line length limit of 160 characters. Why don't you setup a test branch on github and show what you propose? Heck, I'd be happy to limit lines to 100 columns unless absoltely required. Omari> But beyond that, ClangFormat exists now. Because it's part of Omari> Clang, and actually lexes/parses the C language, it can make Omari> actual semantically-driven decisions about how a piece of Omari> source code should look. This means that _if_ we decide on Omari> some style, ClangFormat should make it relatively Omari> straightforward to update the codebase in one fell swoop. (And Omari> FYI, the C++ standard at Google, where I work, is to run all Omari> code through ClangFormat, with exceptions specified as per [2]) Again, run the codebase through and send out a link to a sample branch so we can look it over. Omari> With that said, I would love for us to get away from a style Omari> that encourages us to mix tabs and spaces. See, for instance, Omari> [3]. There is no way to match an arbitrary paren on the prior Omari> line without using spaces for some indentation. But if our Omari> style is to use tabs for most indentation, it either means that Omari> you can't match the exact paren offset from the previous line, Omari> or you have to mix tabs and spaces. Samples? Omari> My personal preference would be to switch to using spaces for Omari> all indentation, but I would be okay with using tabs for all Omari> indentation as well, so long as we avoid situations where the Omari> tabs need to be padded with spaces. Something consistent that vim/emacs/joe/eclipse/your favorite IDE can all agree on is fine with me. John -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
[Geeqie-devel] Geeqie coding standards? Third edition :o)
It appears that each time I come back to working on Geeqie, I send one
of these emails ;o)
Here are threads #1 and #2:
#1: https://sourceforge.net/p/geeqie/mailman/message/22531197/
#2: https://sourceforge.net/p/geeqie/mailman/message/27441283/
In #2, I had created a one-liner to compute a line-length histogram our
codebase. I've rerun it and included the results below as [1]. If also
attached a list of max-line-length by source file. As of my git clone
from earlier this week, Geeqie has 106k lines. 227 of those lines are
over 160 characters. That's 0.2%
I am willing to change those 227 lines by hand if it means we can commit
to a line length limit of 160 characters.
But beyond that, ClangFormat exists now. Because it's part of Clang,
and actually lexes/parses the C language, it can make actual
semantically-driven decisions about how a piece of source code should
look. This means that _if_ we decide on some style, ClangFormat should
make it relatively straightforward to update the codebase in one fell
swoop. (And FYI, the C++ standard at Google, where I work, is to run
all code through ClangFormat, with exceptions specified as per [2])
With that said, I would love for us to get away from a style that
encourages us to mix tabs and spaces. See, for instance, [3]. There is
no way to match an arbitrary paren on the prior line without using
spaces for some indentation. But if our style is to use tabs for most
indentation, it either means that you can't match the exact paren offset
from the previous line, or you have to mix tabs and spaces.
My personal preference would be to switch to using spaces for all
indentation, but I would be okay with using tabs for all indentation as
well, so long as we avoid situations where the tabs need to be padded
with spaces.
--xsdg
[1] Note that keymap_template.c is a C-wrapped XML file, which is why I
exclude it.
$ruby -e 'lc = Hash.new{|h,k| h[k] = 0}; ARGV.each{|f|
File.new(f).each_line{|l| l.gsub!(/\t/, " "*8); lc[l.length/10] += 1}};
csum = 0; lc.sort.each{|(x,y)| csum += y; printf "%3d-%3d: %s %d\n",
10*x, 10*(x+1)-1, y.to_s.ljust(5), csum}' $(\ls *.c *.h *.cc | grep -v
keymap_template.c)
0- 9: 30198 30198
10- 19: 9074 39272
20- 29: 14334 53606
30- 39: 13148 66754
40- 49: 9292 76046
50- 59: 7223 83269
60- 69: 7534 90803
70- 79: 6587 97390
80- 89: 3974 101364
90- 99: 2194 103558
100-109: 1254 104812
110-119: 681 105493
120-129: 355 105848
130-139: 143 105991
140-149: 64106055
150-159: 39106094
160-169: 28106122
170-179: 22106144
180-189: 32106176
190-199: 38106214
200-209: 64106278
210-219: 36106314
220-229: 7 106321
[2]
http://clang.llvm.org/docs/ClangFormatStyleOptions.html#disabling-formatting-on-a-piece-of-code
[3]
http://geeqie.org/cgi-bin/gitweb.cgi?p=geeqie.git;a=blob;f=src/pan-types.h;h=de114bf5111ff7d676ac3fad8c70d630f5f10ccb;hb=HEAD#l274
["keymap_template.c", 404]
["rcfile.c", 226]
["rcfile.h", 214]
["ui_tree_edit.c", 201]
["filefilter.c", 192]
["utilops.c", 188]
["image_load_tiff.c", 187]
["image_load_jpeg.c", 187]
["image_load_gdk.c", 186]
["preferences.c", 175]
["filefilter.h", 175]
["editors.c", 171]
["layout_util.c", 167]
["metadata.h", 166]
["metadata.c", 165]
["utilops.h", 162]
["image-load.h", 161]
["bar_histogram.c", 161]
["renderer-tiles.c", 160]
["bar_keywords.c", 160]
["jpeg_parser.c", 157]
["bar_comment.c", 156]
["filedata.h", 155]
["filedata.c", 154]
["main.c", 153]
["image-load.c", 149]
["view_file_list.c", 148]
["compat.h", 147]
["secure_save.c", 146]
["ui_fileops.c", 145]
["main.h", 143]
["print.c", 142]
["editors.h", 142]
["dupe.c", 142]
["pixbuf-renderer.h", 141]
["debug.c", 140]
["cellrenderericon.h", 139]
["view_file.c", 138]
["pixbuf-renderer.c", 138]
["image.c", 138]
["bar_exif.c", 137]
["image-overlay.c", 136]
["view_file.h", 135]
["remote.c", 135]
["layout.c", 134]
["view_dir.h", 133]
["typedefs.h", 133]
["histogram.h", 131]
["exiv2.cc", 131]
["histogram.c", 130]
["view_file_icon.c", 128]
["compat.c", 128]
["collect-table.c", 128]
["bar.c", 128]
["layout.h", 127]
["ui_tabcomp.h", 126]
["exif.c", 126]
["ui_tabcomp.c", 125]
["collect-io.c", 124]
["bar_histogram.h", 124]
["bar_keywords.h", 123]
["search.c", 122]
["layout_image.c", 122]
["bar_exif.h", 122]
["bar_comment.h", 122]
["ui_menu.h", 121]
["ui_menu.c", 121]
["cellrenderericon.c", 121]
["trash.c", 120]
["bar_gps.c", 120]
["cache.c", 119]
["bar_sort.h", 118]
["bar_gps.h", 118]
["pixbuf_util.c", 117]
["bar_sort.c", 117]
["menu.h", 116]
["layout_image.h", 116]
["thumb_standard.h", 115]
["similar.c", 115]
["menu.c", 115]
["view_dir_tree.c", 114]
["ui_tree_edit.h", 114]
["thumb_standard.c", 114]
["bar.h", 114]
["ui_pathsel.c", 112]
["renderer-clutter.c", 112]
["fullscreen.h", 112]
["fullscreen.c", 112]
["view_dir_list.c", 111]
["ui_misc.c", 111]
["thumb.c", 111]
["img-view.c", 111]
["collect.c", 111]
["slideshow.h", 110]
["slideshow.c", 110]
["format_nikon.h", 110]
