A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2014-January/131820.html below:

[Python-Dev] .clinic.c vs .c.clinic

[Python-Dev] .clinic.c vs .c.clinicSerhiy Storchaka storchaka at gmail.com
Sat Jan 18 19:07:37 CET 2014
18.01.14 15:28, Nick Coghlan написав(ла):
> I can argue either side, but the biggest potential problem I see with
> Serhiy's suggestion is the likelihood of breaking automatic cross
> referencing of symbols in most IDEs, as well as causing possible issues
> for interactive debuggers. These are at least valid fragments of C
> files, even if they're not designed to be compiled independently.
> However, if both Visual Studio and gdb can still find the symbols
> correctly, even with the ".clinic" extension, then I would consider that
> a point strongly in favour of Serhiy's suggestion.

Good point. This idea did not come into my mind, and now I am almost 
ready to give up my proposals.

But C allows you to include files with any extensions (.h, hpp, .h++, 
.c, .cpp, .inc, .gen, etc), and a powerful tool should monitor 
"#include"s not paying attention to expansions. On the other hand, 
simpler tools can work with filename masks, and for them it is much 
easier to add a new extension than to set exclude condition (the last 
option may not be supported at all). At least it is so with the tools 
that I use.


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4