function to initialize vector from {1,2,3,4}

[franceschi...@gmail.com]

Hello,
copying from the web I maged to initialize a vector of integers from an array.

int myints[] = { 16, 2, 77, 29 };
vector<int> fifth(ord1, ord1 + sizeof(ord1) / sizeof(int));


Now I would like to turn this into a function that I can later call as

vector<int> myvec;
myvec = initialize_Vector( {1,2,3,4} )


I am becoming crazy with the passage of the array as argument of the function (pointer, values, ... dunno)


Can anybody explain how to write this function?


Of course any alternative solution that allows me to initialize a vector by just specifying the values it contains in a one line it's more than welcome

Thanks to everybody for reading and replying.
Roberto

[Alf P. Steinbach]

First, please dont't post lines that are longer than than about 77
characters. Such long lines may *look* like paragraphs, that are wrapped
nicely in some situations, but especially when quoted they tend to
appear as single, overly long lines. There is a format called "flowed"
that lets you post long paragraphs without manual line breaks. With that
format a space at the end of a line denotes a soft line break that can
be rearranged when the paragraph is formatted by client software. Please
use format "flowed" for those long paragraphs.


Anyway,

<code>
#include <iostream> // std::wcout, std::endl
#include <vector> // std::vector

template< class TpElem >
class Vector
: public std::vector< TpElem >
{
public:
typedef TpElem Elem;
typedef std::vector<Elem> Base;

int count() const { return Base::size(); }

Vector(): Base() {}

template< int n >
Vector( Elem const (&values)[n] )
: Base( values, values + n )
{}
};

int main()
{
using std::wcout;
using std::endl;

int const values[] = {3, 1, 4, 1, 5, 9, 2, 6, 5, 4};

Vector<int> const v = values;

for( int i = 0; i < v.count(); ++i )
{
wcout << v[i] << " ";
}
wcout << endl;
}
</code>


Cheers & hth.,

- Alf

[Alf P. Steinbach]

On 17.05.2012 19:05, Alf P. Steinbach wrote:
> [snipped]

Oh sorry, I was interrupted and posted prematurely.

I was going to also mention C++11's curly braces initializers, which
directly do what you want.

Unfortunately they're not implemented yet in Visual C++, as of Visual
C++ versions 10.0 and 11 (still in beta).

[Jorgen Grahn]

On Thu, 2012-05-17, franceschi...@gmail.com wrote:
> Hello,

> copying from the web I maged to initialize a vector of integers from
> an array.

> int myints[] = { 16, 2, 77, 29 };
> vector<int> fifth(ord1, ord1 + sizeof(ord1) / sizeof(int));

> Now I would like to turn this into a function that I can later call as

Why? This is the kind of thing which looks important at first[1] but
in my experience it's not very common in real-world code.

[1] I remember thinking it was really clumpsy when I first read the
example code in the SGI STL documentation. Every container example
started with initializing the container from a C array like you
show.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[cart...@gmail.com]

On Thursday, May 17, 2012 9:55:44 AM UTC-5, franceschi...@gmail.com wrote:
> int myints[] = { 16, 2, 77, 29 };
> vector<int> fifth(ord1, ord1 + sizeof(ord1) / sizeof(int));
>
> Now I would like to turn this into a function that I can later call as
>
> vector<int> myvec;
> myvec = initialize_Vector( {1,2,3,4} )

I've used:

template <typename T, std::size_t N>
std::vector<T> vector_from_array( const T (&array)[N] )
{ return std::vector<T>( array, array + N ); }

template <typename U, typename T, std::size_t N>
std::vector<U> vector_from_array( const T (&array)[N] )
{ return std::vector<U>( array, array + N ); }

in a couple of projects in the past, to reduce the code to:

static const int array[] = { 3, 1, 4, 1, 5, 9, 2, 6, 5, 4 };
std::vector<int> vec = vector_from_array( array );
std::vector<float> floatvec = vector_from_array<float>( array );

As Alf says, it doesn't really come up often.

[Juha Nieminen]

Jorgen Grahn <grahn...@snipabacken.se> wrote:
> Why? This is the kind of thing which looks important at first[1] but
> in my experience it's not very common in real-world code.

That's such a "windowsy" answer. "If you can't do it, you don't need it."

[Jorgen Grahn]

I wasn't telling him he didn't need it -- I was *asking* him.

[Rui Maciel]

Alf P. Steinbach wrote:

> First, please dont't post lines that are longer than than about 77

> characters. Such long lines may look like paragraphs, that are wrapped

> nicely in some situations, but especially when quoted they tend to
> appear as single, overly long lines. There is a format called "flowed"
> that lets you post long paragraphs without manual line breaks. With that
> format a space at the end of a line denotes a soft line break that can
> be rearranged when the paragraph is formatted by client software. Please
> use format "flowed" for those long paragraphs.

That issue isn't caused by the sender, only by the receiver's Usenet client.
Text lines which exceed 77 characters are perfectly valid, and they are
properly handled by some Usenet clients. The only problem which may be
associated with them is that some Usenet clients do a bad job handling long
paragraphs.

As you appear to be a Thunderbird user, when you reply to a post you only
need to hit Ctrl+R, or simply go "Edit"->"Rewrap", to nicely wrap those
overly long lines you referred to. It may not be an ideal solution, but it
provides a way to let Thunderbird handle this issue without much hassle.


Rui Maciel

[Juha Nieminen]

franceschi...@gmail.com wrote:
> int myints[] = { 16, 2, 77, 29 };
> vector<int> fifth(ord1, ord1 + sizeof(ord1) / sizeof(int));

In C++11 you can do this:

int myints[] = { 16, 2, 77, 29 };

std::vector<int> fifth(std::begin(myints), std::end(myints));

It might even be standard to omit the "std::begin()" part and use
'myints' directly as the first parameter, as std::end() probably always
returns an int* in this case. In other words:

std::vector<int> fifth(myints, std::end(myints)).

[Alf P. Steinbach]

On 18.05.2012 12:44, Rui Maciel wrote:
> Alf P. Steinbach wrote:
>
>> First, please dont't post lines that are longer than than about 77
>> characters. Such long lines may look like paragraphs, that are wrapped
>> nicely in some situations, but especially when quoted they tend to
>> appear as single, overly long lines. There is a format called "flowed"
>> that lets you post long paragraphs without manual line breaks. With that
>> format a space at the end of a line denotes a soft line break that can
>> be rearranged when the paragraph is formatted by client software. Please
>> use format "flowed" for those long paragraphs.
>
> That issue isn't caused by the sender, only by the receiver's Usenet client.

Wrong.

> Text lines which exceed 77 characters are perfectly valid, and they are
> properly handled by some Usenet clients.

"Valid" is meaningless in this context.

Since you changed the title to include "netiquette", do read up on it.

RFC 1855 "Netiquette" 2.1 User Guidelines 2.1.1 For mail (note that that
these apply also to Usenet since many Usenet groups are transported as
mailing lists and vice versa, e.g. via GMane, as noted in section 3.0,
"Any time you engage in One-to-Many communications, all the rules for
mail should also apply."):

<quote>
- A good rule of thumb: Be conservative in what you send and
liberal in what you receive.
</quote>

<quote>
- Make things easy for the recipient.
</quote>

<quote>
- Limit line length to fewer than 65 characters and end a line
with a carriage return.
</quote>

There is a distinct chance that you will pretend to not understand the
above, or that you will pretend to not understand its relevance to your
assertions and your change of subject line to include "netiquette", the
subject of that RFC.

However, I think most people reading this will get the picture, namely
that you're talking about things you don't have the slightest knowledge
of, and that your assertions are wrong.

[Rui Maciel]

Alf P. Steinbach wrote:

>> That issue isn't caused by the sender, only by the receiver's Usenet
>> client.
>
> Wrong.

That would be a reasonable answer if and only if you were able to dictate how reality works. Were you
bestowed with that power?

>> Text lines which exceed 77 characters are perfectly valid, and they are
>> properly handled by some Usenet clients.
>
> "Valid" is meaningless in this context.

Only if you don't know what the context is or what "valid" is supposed to mean, or if you wish to pretend that
your baseless assertions don't actually need to be based.

No usenet protocol puts in place any limit on how many characters there might be on any line. In other words,
there is absolutely no technical reason for this limit.

The only reason behind the 72-76 character limit dates back to the days where people actually used computer
terminals which were, at best, only capable of displaying 80 characters per line, and software was developed
with this limitation in mind.

That is a thing of the past. There is a reason why the best reference you could come up with was a text which
was last updated way back in 1995, and even then it wasn't particularly cutting-edge.

I don't believe you are using such a terminal to access usenet, and the usenet client you are using does not
suffer from this limitation. I know it because I happen use it, and I never had any problem with other
people's line breaks.

So, either you intentionally configured it to screw that up, which means that you are complaining about your
own inability to use the software you've picked, or you actually don't have any relevant reason to complain
about the presence or absence of line breaks, which means you explicitly intended to whine about a non-issue
that doesn't even affect you.

Judging by your frothing rant, I would put my money on the latter.

But hey, keep believing that playing the role of a frothing member of the line break police actually helps
anyone communicate more effectively.

And in the process, do spend a couple of minutes reflecting on the irony of you wasting your time writing
insulting posts on how others should improve the way they communicate with other people.


Rui Maciel

[Alf P. Steinbach]

On 18.05.2012 23:57, Rui Maciel wrote:
> snip

You snipped everything from RFC 1855 "Netiquette".

You added personal attacks on me.

Plonk.

[Scott Lurndal]

Rui Maciel <rui.m...@gmail.com> writes:

>The only reason behind the 72-76 character limit dates back to the days where people actually used computer
>terminals which were, at best, only capable of displaying 80 characters per line, and software was developed
>with this limitation in mind.

There are still a lot of people who use tin to read usenet. Usually after secure shell login to a
networked host somewhere. Sometimes even from a console screen with only 80 columns.

scott

[Rui Maciel]

Scott Lurndal wrote:

> There are still a lot of people who use tin to read usenet. Usually
> after secure shell login to a networked host somewhere. Sometimes even
> from a console screen with only 80 columns.

I don't dispute that. Yet, even in those cases, the problem doesn lie in
the format people wish to post messages, as was wrongly claimed by Alf P.
Steinbach. The problem only lies in the way that a defective client might
mishandle how an article is represented.

In this particular case, this isn't even the case, as the only person
whining about line breaks happens to be using a client which doesn't have
any problem with them. If you happen to check out the user agent of Alf P.
Steinbach's usenet client then you will notice that it refers to Thunderbird
12.0. That particular client does not have any limitation on line breaks.
In fact, it also provides features to explicitly rewrap line breaks at the
user's whim, which also includes the ability to rewarp only portions of a
message.

This means that the only person whining about this non-issue is a user who
actually does not experience this problem, and only used it as a pretext to
whine. Someone's predisposition to whine should not dictate how a
technology is used.


Rui Maciel

[Rui Maciel]

Alf P. Steinbach wrote:

> You snipped everything from RFC 1855 "Netiquette".

If you actually cared about netiquette then you would actually care for guidelines such as RFC 1855 2.2.1.
Instead, you cherry pick what is convenient for your petty tantrums.

> You added personal attacks on me.

That's an amusing accusation, considering your insulting rant. It appears that you either have a terrible
memory or you are a hypocrite.


Rui Maciel

[Jorgen Grahn]

On Sat, 2012-05-19, Rui Maciel wrote:
> Scott Lurndal wrote:
>
>> There are still a lot of people who use tin to read usenet. Usually
>> after secure shell login to a networked host somewhere. Sometimes even
>> from a console screen with only 80 columns.
>
> I don't dispute that. Yet, even in those cases, the problem doesn lie in
> the format people wish to post messages, as was wrongly claimed by Alf P.
> Steinbach. The problem only lies in the way that a defective client might
> mishandle how an article is represented.

And yet, over at comp.lang.c++.moderators, if you post using extremely
long line lengths, you get reprimanded and the moderator wraps the
lines (at column 70, I think) for you.

> In this particular case, this isn't even the case, as the only person
> whining about line breaks happens to be using a client which doesn't have
> any problem with them.

...

> This means that the only person whining about this non-issue is a user who
> actually does not experience this problem, and only used it as a pretext to
> whine.

Or perhaps he cares about people other than himself.

[Rui Maciel]

Jorgen Grahn wrote:

> On Sat, 2012-05-19, Rui Maciel wrote:
>> Scott Lurndal wrote:
>>
>>> There are still a lot of people who use tin to read usenet. Usually
>>> after secure shell login to a networked host somewhere. Sometimes even
>>> from a console screen with only 80 columns.
>>
>> I don't dispute that. Yet, even in those cases, the problem doesn lie in
>> the format people wish to post messages, as was wrongly claimed by Alf P.
>> Steinbach. The problem only lies in the way that a defective client
>> might mishandle how an article is represented.
>
> And yet, over at comp.lang.c++.moderators, if you post using extremely
> long line lengths, you get reprimanded and the moderator wraps the
> lines (at column 70, I think) for you.

That tells you something about which criteria were arbitrarily adopted by
those moderators, not about any actual technical limitation related to the
number of characters in a line. It's more telling that there are plenty of
newsgroups that do receive posts that don't comply with that arbitrary
limit, and yet not a single soul ever notices any actual problem, let alone
complains about it.

>> In this particular case, this isn't even the case, as the only person
>> whining about line breaks happens to be using a client which doesn't have
>> any problem with them.
> ...
>> This means that the only person whining about this non-issue is a user
>> who actually does not experience this problem, and only used it as a
>> pretext to whine.
>
> Or perhaps he cares about people other than himself.

Considering the frothing rant Alf P. Steinbach decided to spew to this
thread, it's safe to say that that's not the case.


Rui Maciel

[nick_keigh...@hotmail.com]

On Thursday, May 17, 2012 3:55:44 PM UTC+1, franceschi...@gmail.com wrote:
> Hello,
> copying from the web I maged to initialize a vector of integers from an array.
>
> int myints[] = { 16, 2, 77, 29 };
> vector<int> fifth(ord1, ord1 + sizeof(ord1) / sizeof(int));

did you mean:-

vector<int> fifth (myints, myints + sizeof(myints) / sizeof(*myints));