From: acehreli on
On Apr 18, 5:13 am, mpho <tjab...(a)gmail.com> wrote:
> On Apr 17, 7:13 pm, Chris Uzdavinis <cuz...(a)gmail.com> wrote:
]
> The obvious errors have really been mistypes and not deliberate.

You still left a comma in there ;)

> for (int i = 0, i < sz; i++)

> typedef T //something

A number of people mentioned the unknown definition of T. Try T as a
typedef of this something:

struct something
{
int * p;

something()
:
p(new int[0xffffffff])
{}

something(int)
{}
};

typedef something T;

With that definition, my system throws std::bad_alloc as well.

Ali

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Daniel Krügler on
On 18 Apr., 14:13, mpho <tjab...(a)gmail.com> wrote:
> The obvious errors have really been mistypes and not deliberate. I
> apologize. Thanks for the replies, the problem still persists. The
> complete code, excluding the unnecessary stuff by your comments, is:

> No try/catch blocks in the program. Should this not work?

No, because it should not compile. If I fix the error in the
for-loop (the comma, which can only be a semicolon with the
code you provided), and I assume int for T (This is the most natural
assumption given your array initializer list), and I
simply ignore any form of ... or "No problem with copy constructor
and
assignment." text this should compile and run successfully.

Please, if you want any help, the group will provide that,
but you need to give us a complete program. So *your* job
is to create a completely compilable program that leads to
the actual problem. Assertions like

"No problem with copy constructor and assignment."

are based on your own judgment and no-one of us can
proof that without seeing your code. Indeed, copy constructor
and copy assignment operator are typical traps for resource
administrating classes and typically *are* sensitive to
programmer errors - but this is a simple shot in the dark.
And why do you talk about both member functions at all,
because the shown code does not use them. Or do you mean
the copy operations of T?

Another shot in the dark would be the actual type of T.
A wrongly programmed type T could cause *anything*. E.g.
if this is a user-defined type, your program involves
implicitly the default c'tor of T, it's copy-assignment
operator, and it's (implicit?) c'tor accepting an int -
check these as well.

Greetings from Bremen,

Daniel Kr�gler



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3
Prev: Namespace vs. isnan
Next: strcpy_s vs strcpy