+6  A: 

If you use auto, why use macros at all?

int main()
{
    std::vector<int> vector_with_uncommonly_long_identifier;

    {
        auto& o = vector_with_uncommonly_long_identifier;

        o.push_back(1);
        o.push_back(2);
        o.push_back(3);
    }

    const std::vector<int> constant_duplicate_of_vector_with_uncommonly_long_identifier
        (vector_with_uncommonly_long_identifier);

    {
        const auto& o = constant_duplicate_of_vector_with_uncommonly_long_identifier;

        std::cout
            << o[0] << '\n'
            << o[1] << '\n'
            << o[2] << '\n';
    }

    {
        auto o = constant_duplicate_of_vector_with_uncommonly_long_identifier.size();
        std::cout << o <<'\n';
    }
}

EDIT: Without auto, just use typedef and references.

int main()
{
    typedef std::vector<int> Vec;

    Vec vector_with_uncommonly_long_identifier;

    {
        Vec& o = vector_with_uncommonly_long_identifier;

        o.push_back(1);
        o.push_back(2);
        o.push_back(3);
    }
}
dalle
I already thought of this. I already *mentioned* it. It's not really what I was asking.
Jon Purdy
+2  A: 

For C++0x (which you're assuming):

int main() {

    std::vector<int> vector_with_uncommonly_long_identifier;

    {
        auto& o = vector_with_uncommonly_long_identifier;

        o.push_back(1);
        o.push_back(2);
        o.push_back(3);

    }
}

Cheers & hth.,

Alf P. Steinbach
Thanks, but I wasn't actually assuming C++0x. Maybe that's not clear.
Jon Purdy
@Jon: `auto` as automatic type inference is C++0x. Cheers,
Alf P. Steinbach
@Alf P. Steinbach: I was looking for a non-`auto` solution, hence, specifically non-C++0x. But I gave up.
Jon Purdy
Alf P. Steinbach
@Alf: You...continue to miss my point. Don't worry about it.
Jon Purdy
A: 

Why not just use a good lambda?

auto func = [&](std::vector<int>& o) {
};
func(vector_with_a_truly_ridiculously_long_identifier);

The simple fact is that if your identifiers are so long, that you can't type them out every time, use a reference, function, pointer, etc to solve this problem, or better, refactor the name. Statements like this (e.g. using() in C#) have additional side effects (deterministic cleanup, in my example). Your statement in C++ has no notable actual benefits, since it doesn't actually invoke any additional behaviour against just writing the code out.

DeadMG
The problem with this approach is that it makes the code harder to read -- you have to jump downwards to the bottom of the lambda definition to find the object being acted on, then jump back up to figure out what the code is doing to that object, instead of just reading the code in order.
Adam Rosenfield
@Adam Rosenfield: It also has the advantage that func could be dynamically passed around through the use of std::function. Moreover, the OP's entire not-really-a-problem is ridiculous. Are you expecting a non-ridiculous solution?
DeadMG
@Adam Rosenfield, @DeadMG: Jeez, I just get the bug to know if the obviously, deliberately useless macro I wrote was written as well as it could've been, and a slew of irrelevant answers ensue. I don't want to delete the question, but there's no point to it anymore.
Jon Purdy
+5  A: 

?? attempted vb syntax into C++

with says do all the things in the following block by default referencing the object I've said to do it with right? Executes a series of statements making repeated reference to a single object or structure.

with(a)
 .do
 .domore
 .doitall

so how is the example giving you the same syntax?

to me examples of why to use a with where multiple de referencess

so rather than

book.sheet.table.col(a).row(2).setColour
book.sheet.table.col(a).row(2).setFont
book.sheet.table.col(a).row(2).setText
book.sheet.table.col(a).row(2).setBorder

you have

with( book.sheet.table.col(a).row(2) )
  .setColour
  .setFont
  .setText
  .setBorder

seems just as easy, and more common syntax in C++ to

cell& c = book.sheet.table.col(a).row(2);
c.setColour
c.setFont
c.setText
c.setBorder
Greg Domjan