C++0x lambda syntax

[Andrew Venikov]

Hi all,

 

in c++0x it will be possible to use lambda functions.

 

So, for example, this:

 

[](int n) { return n+ 1; }

 

Will become valid c++.

 

Unfortunately it breaks current C++ highlighting.

After a line like the one above, all curly brackets will be highlighted by VIM as “unmatched”, making reading the code really hard.

 

Is there a quick way to fix that?

 

Thanks,

       Andy.

 

[Bram Moolenaar]

Andrew Venikov wrote:

You can vote for the C++ standard to not add things like this to make
the language even more cryptic.

Well, perhaps that's not a quick way, but it will make programmers who
try to decipher C++ programs a lot more sane.

--
It might look like I'm doing nothing, but at the cellular level
I'm really quite busy.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Karthick Gururaj]

On Wed, Nov 24, 2010 at 1:42 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>
> Andrew Venikov wrote:
>
>> in c++0x it will be possible to use lambda functions.
>>
>> So, for example, this:
>>
>> [](int n) { return n+ 1; }
>>
>> Will become valid c++.
>>
>> Unfortunately it breaks current C++ highlighting.
>> After a line like the one above, all curly brackets will be highlighted by VIM as "unmatched", making reading the code really hard.
>>
>> Is there a quick way to fix that?
>
> You can vote for the C++ standard to not add things like this to make
> the language even more cryptic.
>
> Well, perhaps that's not a quick way, but it will make programmers who
> try to decipher C++ programs a lot more sane.

:) Quotable quote. I like this response, having spent many hours
trying to decrypt a C++ code base that has template-based functional
programming..

[pansz]

On Nov 24, 4:12 am, Bram Moolenaar <B...@Moolenaar.net> wrote:

> Andrew Venikov wrote:
> > Is there a quick way to fix that?
>

> Well, perhaps that's not a quick way, but it will make programmers who
> try to decipher C++ programs a lot more sane.

A quick way may be to contact the author of syntax/c.vim

Voting C++ features may not be of any help, C++ have the most complex
syntax and is already extremely hard to understand. It is unlikely to
become easy with a single feature removal.

[Andrew Venikov]

Bram Moolenaar wrote:
>
> Andrew Venikov wrote:
>
> > in c++0x it will be possible to use lambda functions.
> >
> > So, for example, this:
> >
> > [](int n) { return n+ 1; }
> >
> > Will become valid c++.
> >
> > Unfortunately it breaks current C++ highlighting.
> > After a line like the one above, all curly brackets will be
> highlighted by VIM as "unmatched", making reading the code really hard.
> >
> > Is there a quick way to fix that?
>
> You can vote for the C++ standard to not add things like this to make
> the language even more cryptic.

Funny you should mention it, but the whole reason for the lambda
functions (and not just in C++) is to make code more readable.
Oftentimes when you need to pass a function or a function-object to
a generic algorithm, this function would consist of only a short expression.
Currently, you're forced to define this expression else-where, where
it's out of context. The lambda functions allow you to specify the logic
in-line so that the whole algorithm would be in one place.

I understand the knee-jerk reaction to this new feature, but the C++
community has been anxiously waiting for lambdas (closures) for a
long time for a reason. The other languages (JavaScript, Python, Ruby,
Haskell, heck even Perl has it) have had them for a long time.
Lisp had them since, oh 1965?

>
> Well, perhaps that's not a quick way, but it will make programmers who
> try to decipher C++ programs a lot more sane.

I guess C++ does have a bad rep in this area. But the reason for that is
that there was a wide-spread misconception that C++ is just C with classes.
And a lot of C programmers (good and bad) tried to write C++ code with C
mindset. You just can't do that.

But I promise you that things will get much better, as C++ community has
evolved since then and proper C++ techniques are much more wide-spread now.
Reading a properly written C++ code is like watching a beautify painting.
It's a work of art.

But the bottom line is:

PLEASE, don't make me chose between my favorite language and my favorite editor.


Thanks,
Andy.

[Bill Liao]

> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
No one is forcing you to make a choice.
There MUST be a way to figure this out. I dunno however.
u can work it out after reading the syntax schema of c.vim.
I believe it's easy for you, because it's also a very very beautiful painting.

--
If the dream is BIG enough,the facts don't count!

[Andrew Venikov]

Bill Liao wrote:
> No one is forcing you to make a choice.
> There MUST be a way to figure this out. I dunno however.
> u can work it out after reading the syntax schema of c.vim.
> I believe it's easy for you, because it's also a very very beautiful
> painting.

Fair enough. I can take on that work. I'll just need a few pointers.
I know that c.vim is built-in. How can I get a hold of it?

[Taylor Hedberg]

Syntax files install to /usr/share/vim/vim73/syntax (for Vim 7.3) by
default, if I'm not mistaken. If you're on Windows, it's probably
somewhere underneath the Vim installation directory.

[Andrew Venikov]

> No one is forcing you to make a choice.
> There MUST be a way to figure this out. I dunno however.
> u can work it out after reading the syntax schema of c.vim.
> I believe it's easy for you, because it's also a very very beautiful
> painting.

Shouldn't it be cpp.vim?
Or does cpp.vim include c.vim's definitions too?

[Karthick Gururaj]

cpp.vim includes c.vim as well.. you'll see a code-block like:

" Read the C syntax to start with
if version < 600
so <sfile>:p:h/c.vim
else
runtime! syntax/c.vim
unlet b:current_syntax
endif

..in c.vim.

A quick fix to solve the problem is to clear all bracket errors - you
can do this by a line:
:hi link cErrInParen Normal
in your .vimrc/_vimrc

The side effect is that *NONE* of the bracket errors are highlighted.

[Mike Williams]

Before hacking c.vim, try setting c_no_curly_error in your .vimrc and
see if that gives you what you want. See :help ft-c-syntax for other
options.

Mike
--
Doing nothing is tiring because you can't take a break.