The IDE feature that VC++ Needs... #region and #endregion

[Russell Mangel]

I was thinking about what IDE feature I would want the most in the next
version of VC++?

I would definately ask for the C# feature: #region / #endregion.
In my opinion this feature was a brilliant idea.
This thing really helps to abstract out code, and gives you a view of your
code you can not otherwise see.

C++ needs this feature even more so than C#, because C++'s code can become
much more complex.

Pretty please... can we have this in C++?

Does anyone else agree with me?

Russell Mangel
Las Vegas, NV

[Jonathan Turkanis]

Russell Mangel wrote:

I was thinking about what IDE feature I would want the most in the
next version of VC++?

I would definately ask for the C# feature: #region / #endregion.
This isn't strictly an IDE feature, although IDE support would presubably be
needed to make it useful.
In my opinion this feature was a brilliant idea.
This thing really helps to abstract out code, and gives you a view of
your code you can not otherwise see.
Adding #region / #endregion directives would make code using these directives
uncompilable on other compilers. The usual way to get around this wouldn't work,
since

#ifdef _MSC_VER
# region
#endif

is incorrectly nested.

The C++ way to introduce this feature would be #pragma region/endregion. This
would still yield a lot of unrecognized pragma warnings, which I personally
would find very annoying.
Pretty please... can we have this in C++?

Does anyone else agree with me?

Not me.

Jonathan

[Tomas Restrepo \(MVP\)]

Jonathan,

The C++ way to introduce this feature would be #pragma region/endregion. This would still yield a lot of unrecognized pragma warnings, which I personally would find very annoying.

#pragma region and #pragma endregion are already supported by the VS2005 ide
(at least in beta1) and they do not generate unrecognized pragma warnings by
the compiler.

--
Tomas Restrepo
to****@mvps.org

[Jonathan Turkanis]

Tomas Restrepo (MVP) wrote:

Jonathan,

The C++ way to introduce this feature would be #pragma
region/endregion. This would still yield a lot of unrecognized
pragma warnings, which I personally would find very annoying.
#pragma region and #pragma endregion are already supported by the
VS2005 ide (at least in beta1)

I didn't know this.
and they do not generate unrecognized
pragma warnings by the compiler.

I'm talking about non-microsoft compilers.

Jonathan

[Russell Mangel]

Oh my! It works!

Yippeeeeeeeeeeeeee!

My favorite feature!

Give the MS VC VS2005 team a box of candy bars, and a big raise.

Russell Mangel
Las Vegas, NV

[Russell Mangel]

Always somebody working on something...

So now that we both learned something, do you think this is useful?
If not, why?

Russell Mangel
Las Vegas, NV

[Jonathan Turkanis]

I gather you're talking to me.

Russell Mangel wrote:

Always somebody working on something...
??
So now that we both learned something, do you think this is useful?
If not, why?
As I said before, #pragma region leads to 'unrecognized pragma' warnings on
compilers which don't support the pragma. But I see they chose to relax the
restrictions on nesting, so I can write something like

#ifdef _MSC_VER
#pragma region
#endif

I really don't see the great benefit. After all, we have classes and namespaces
to partition our code, and comments to annotate it. Splitting enormous files
into smaller ones also helps.
Russell Mangel
Las Vegas, NV

Jonathan

[Bret Pehrson]

Russell Mangel wrote:

Always somebody working on something...

So now that we both learned something, do you think this is useful?
If not, why?

Russell Mangel
Las Vegas, NV

I used to think that (C#) #regions were a great thing. However, after a year+
of using them, I no longer like/use them. They make navigation too difficult
(nested regions, regions to large, maintenance, etc.). If I can't locate what
I need in a file, then there is probably something else wrong and it should be
seriously looked at (i.e. refactored).

In short, I've found #regions to be a bad way to hide bad code design and
unwarranted complexity.