I'm trying to find an option in Uncrustify that does nearly what sp_cmt_cpp_start does for C++ comments but for c.
Specifically, what I would like is to change this comment:
/*some comment*/
to this:
/* some comment */
Is there an option for this?
Related
I'm using clang-format to format code.
I noticed that it adds white spaces to include statements and fully qualified method references.
Given the following ("correctly formatted") piece of code:
#include bli/bla/blub/_foo;
fun()
{
bli/bla/blub/_foo::bar();
}
When running it through clang-format, it turns it into this:
#include bli / bla / blub / _foo;
fun() { bli / bla / blub / _foo::bar(); }
I do not want the spaces to be added before and after the / since the path may not be modified. The curly bracket placements don't matter.
I'm not sure how to accomplish this, I've taken a look at the documentation here but I didn't see a respective style option. Any ideas/help on fixing this?
That code is not valid C++, so clang-format doesn't behave the way you might expect (I'm assuming C++ is what you're going for).
The statement #include bli/bla/blub/_foo; should have double quotes before and after the header path, and the semicolon omitted.
For fully qualifying symbols in C++, you have to use :: for the seperator, so bli/bla/blub/_foo::bar(); is not valid C++, either.
In the include statement, since double quotes are missing, clang-format sees bli/bla/blub/_foo as "bli divided by bla divided by blub divided by _foo::bar()" - just as any C/C++ compiler would - and adds spaces between / and the operands, which seems sensible.
If you feed clang-format with proper C++ code, for example:
#include "bli/bla/blub/_foo"
void fun()
{
bli::bla::blub::_foo::bar();
}
You'd get:
#include "bli/bla/blub/_foo"
void fun() {
bli::bla::blub::_foo::bar();
}
I want uncrustify to ignore new lines which is formatted by developer but with my config file it does not do this.
What my code looks like and i want it unchanged
+ (void)doSometingAwesomeWithIndex:(NSInteger)index
howManyDaysLater:(BOOL)howManyDaysLater
myBroes:(NSMutableArray *)broes
completion:(AwesomeBlock)completionBlock
What uncrustify does when it formats
+ (void)doSometingAwesomeWithIndex:(NSInteger)index
howManyDaysLater:(BOOL)howManyDaysLater
myBroes:(NSMutableArray *)broes
completion:(AwesomeBlock)completionBlock
I am using uncrustify 0.61 and my config file is http://www.megafileupload.com/edbM/uncrustify.cfg
I suggest https://github.com/square/spacecommander.
Possible duplicate of Can Uncrustify align colons in Objective-C method calls?
In my Objective-C code for my GPUImage framework, I have the following macro:
#define STRINGIZE(x) #x
#define STRINGIZE2(x) STRINGIZE(x)
#define SHADER_STRING(text) # STRINGIZE2(text)
which allows me to inline multiline vertex and fragment shaders as NSString literals within my custom filter subclasses, like this:
NSString *const kGPUImagePassthroughFragmentShaderString = SHADER_STRING
(
varying highp vec2 textureCoordinate;
uniform sampler2D inputImageTexture;
void main()
{
gl_FragColor = texture2D(inputImageTexture, textureCoordinate);
}
);
GPUImage needs this in order to provide formatted vertex and fragment shaders that are included in the body text of filter subclasses. Shipping them as separate files would make the framework unable to be compiled into a static library. Using the above macro, I can make these shaders able to be copied and pasted between the framework code and external shader files without a ridiculous amount of reformatting work.
Swift does away with compiler macros, and the documentation has this to say:
Complex macros are used in C and Objective-C but have no counterpart
in Swift. Complex macros are macros that do not define constants,
including parenthesized, function-like macros. You use complex macros
in C and Objective-C to avoid type-checking constraints or to avoid
retyping large amounts of boilerplate code. However, macros can make
debugging and refactoring difficult. In Swift, you can use functions
and generics to achieve the same results without any compromises.
Therefore, the complex macros that are in C and Objective-C source
files are not made available to your Swift code.
Per the line "In Swift, you can use functions and generics to achieve the same results without any compromises", is there a way in Swift to provide multiline string literals without resorting to a string of concatenation operations?
Alas Swift multiline strings are still not available, as far as I know. However when doing some research regarding this, I found a workaround which could be useful. It is a combination of these items:
A Quick Hack to Quote Swift Strings in a Playground - Describing how to make an service replacing and fixing texts
The comment by pyrtsa, regarding using "\n".join(...) to emulate the multiline strings
Setup an automated service
Using Automator you could set up an extra service with the following properties:
A single action of "Run Shell Script"
Tick off the "Output replaces selected text"
Change shell to /usr/bin/perl
Add the code excerpt below to the action window
Save as something like "Replace with quoted swift multiline join"
Code excerpt
print "\"\\n\".join([\n"; # Start a join operation
# For each line, reformat and print
while(<>) {
print " "; # A little indentation
chomp; # Loose the newline
s/([\\\"])/\\$1/g; # Replace \ and " with escaped variants
print "\"$_\""; # Add quotes around the line
print "," unless eof # Add a comma, unless it is the last line
print "\n"; # End the line, preserving original line count
}
print " ])"; # Close the join operation
You are of course free to use whatever shell and code you want, I chose perl as that is familiar to me, and here are some comments:
I used the "\n".join(...) version to create the multiline string, you could use the extension answer from Swift - Split string over multiple lines, or even the + variant, I'll leave that as an exercise for the user
I opted for a little indentation with spaces, and to replace the \ and " to make it a little sturdier
Comments are of course optional, and you could probably shorten the code somewhat. I tried to opt for clarity and readability
The code, as is, preserves spaces, but you could be edited if that is not wanted. Also left as an exercise for the user
Usage of service
Open up your playground or code editor, and insert/write some multline text:
Mark the text block
Execute Xcode (or similar) > Services > Replace with quoted swift multiline join
You now have a multiline string in proper swift coding. Here are an example of before and after text:
Here is my multiline text
example with both a " and
a \ within the text
"\n".join([
"Here is my multiline text ",
"example with both a \" and",
"a \\ within the text"
])
It looks like your end goal is to avoid including standalone shader files?
If so one technique would be to write a quick command line utility that generates a .swift file of string constants representing the shader functions in a certain folder.
Include the resulting .swift file in your project and you have no runtime penalty, and even easier debugging if you generate the code nicely.
Would probably take less than an hour, never need macros again for shaders.
I'm unable to comment-out and compile the following line of code with /* */, within the XCode editor. I distilled this example down from a more complex string used in an XPath query:
the string itself seems fine:
NSString* s = #"//*//";
won't compile for me:
/*
NSString* s = #"//*//";
*/
XCode 4.4. I'll file a radar if anyone can confirm I'm not being stupid.
EDIT: nice to see that the SO syntax highlighter also exhibits an issue with this...
EDIT: okay, I filed a bug report with Apple. Thanks.
EDIT: Per Rob's answer below, this is NOT a bug :) Thanks for explaining it, Rob; totally makes sense now.
This is not a compiler bug. The double-quote character " has no special meaning inside a comment, so the preprocessor doesn't pay any attention to it. The preprocessor just ends the comment as soon as it sees the */ characters.
The best way to comment out a section of code is to put // at the beginning of each line. A // comment ends at the next newline. Xcode has a menu command (shortcut: ⌘/) that will comment or uncomment your selected lines by inserting or removing // at the start of each line.
It detects and end comment in #"//*//"; I don't know of any editor that allows nesting of block comments (I know that's not what you're doing, but same issue). Notice how even the syntax highlighter on SO screws up.
Just a question of interest: Does anyone know why there's no block comment capability in VB .NET? (Unless there really is - but I've never yet come across it.)
It is a side-effect of the Visual Basic syntax, a new-line terminates a statement. That makes a multi-line comment pretty incompatible with the basic way the compiler parses the language. Not an issue in the curly brace languages, new-lines are just white space.
It has never been a real problem, Visual Basic has had strong IDE support for a very long time. Commenting out multiple lines is an IDE feature, Edit + Advanced + Comment Selection.
Totally abusing compiler directives here... but:
#If False Then
Comments
go
here
#End If
You don't get the benefits of proper code coloration (it doesn't show in green when using the default color scheme) and the implicit line-continuation system automatically indents lines in a paragraph starting at the second line. But the compiler will ignore the text.
As can be read in “Comments in Code“ there isn't any other way:
If your comment requires more than one line, use the comment symbol on each line, as the following example illustrates.
' This comment is too long to fit on a single line, so we break
' it into two lines. Some comments might need three or more lines.
Similarly, the help on the REM statement states:
Note:
You cannot continue a REM statement by using a line-continuation sequence (_). Once a comment begins, the compiler does not examine the characters for special meaning. For a multiple-line comment, use another REM statement or a comment symbol (') on each line.
Depending on how many lines are to be ignored, one can use compiler directives instead. It may not be technically equivalent to comments (you don't get the syntax coloring of comments, for example), but it gets the job done without commenting many lines individually. So you just add 3 more lines of code.
#Const COMMENT = "C"
'basically a false statement
#If COMMENT = "Y" Then
'code to be commented goes between #If and #End If
MsgBox('Commenting failed!')
#End If
This is assuming the purpose is for ignoring blocks of code instead of adding documentation (what "comments" are actually used for, but I also wouldn't mind using compiler directives for that).
The effort required however, makes this method inconvenient when there are just around 10 lines to comment.
Reference: http://msdn.microsoft.com/en-us/library/tx6yas69.aspx