views:

186

answers:

5

In the spirit of Go-language, where simpler syntax is considered pretty important, here's a proposal for simpler array declaration in C++:

int   value;
int_1 list;
int_2 table;
int_3 cube;
RECT  rect;
RECT_1 rects;

Using typedefs this can expand to:

int   value;
vector<int> list;
vector<vector<int> > table;
vector<vector<vector<int> > > cube;
RECT  rect;
vector<RECT> rects;

Would you use it, or is there such a thing as too simple syntax?

EDIT: there was a mistake in expansion syntax.. fixed vector< int> to vector< vector< int> >..

A: 

I wouldn't.

How is this simpler exactly?

Also, the syntax for arrays in C++ is:

int   value;
int list[1];
int table[2];
int cube[3];
RECT  rect;
RECT rects[1];

Not sure it that was the intention of your blurb since I don't see the sense in a 1 cell array.

shoosh
sorry, there was a mistake in expansion syntax.. fixed vector< int> to vector< vector< int> >..
AareP
@shoosh, i believe "list" is thought as int[], and "table" is thought as "int[][]" and cube is "int[][][]". Of course, these types are invalid in C++ currently.
Johannes Schaub - litb
no but `int x[3][4][5]` certainly is.
shoosh
+2  A: 

Names carry semantics, nothing else does. int_1 doesn't convey a lot in terms of meaning, whereas vector< int > is quite clear here.

Space_C0wb0y
A: 

I personally wouldn't use it. Maybe if you did macro's that would expand to tuples instead:

_(int, int) int_pair; // tr1::tuple<int, int>
_(int, int, int) coord_3d; // tr1::tuple<int, int, int>

If you don't like _ as a macro then you might want to look at using something less often used.

Dean Michael
A: 

I understand that a simpler syntax is welcome, specifically in C++ where control characters (dots, brackets, parenthesis, semi-columns) often introduce graphical noise in the code.

But why use numbers in order to identify an array? Is this the array size? In this case, a vector<int> might not be appropriate...

I would go with something simpler like intArray. But again, you have to balance between the benefits and the WTF-effect when a programmer will see this.

EDIT: Wow, based on your edit, looks like the number means the dimension. It might be a little trickier than simply using a typedef since multi-dimensions array have difficult semantics. You to have initialize your array dimension by dimension whenever needed.

When is actually the hardest part, it might be simpler to initialize everything at the beginning but large data may force you to initialize dimensions as you go.

Vincent Robert
You mean noise like the '+' and '=' signs in a = b + c?
anon
Yes and no. Your example is perfectly clear and does not carry noise. I meant noise comparing C++ "object.doSomething();" compared to Ruby "object.do_something". I was referring to graphical noise if you see what I mean. Operators might not be the right word I agree. Editing.
Vincent Robert
"multi-dimensions array have difficult semantics" - yes, it might take page or few of simple typedef-listings, and some amount of manual work to upkeep it :)
AareP
A: 

The choice of vector for an array would seem somewhat strange. Why not std::(tr1::)array?

But how about something like that:

#include <vector>

template <class T, size_t N>
struct Nested
{
    typedef std::vector< typename Nested<T, N - 1>::type > type;
};

template <class T>
struct Nested<T, 0u>
{
    typedef T type;
};


int main()
{
    Nested<int, 2>::type table;
    table.push_back(Nested<int, 1>::type());
    table.front().push_back(10);
}

For the lack of template typedefs until C++0x where you could add:

template <class T, size_t N>
using NestedVector = typename Nested<T, N>::type

//usage:
NestedVector<int, 3> vec; //vector<vector<vector<int>>>
UncleBens
Actually vector<x> was more of a pseudocode.. I'm not saying it should be std::vector :)
AareP