469,647 Members | 1,789 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,647 developers. It's quick & easy.

New to c++, need help with advanced topics

Hi list,
First let me explain that my background is in Java and I am quite
spoiled to its niceties (read "less ambiguous nature"). Anyway to my
problems.

1. I want to write my own library for what I consider to be some holes
in the standard language. How do I go about writing and compiling this
without this stupid error about not having a 'main' function. I don't
want a stupid 'main' function. (I'm compiling using gcc 4.0.) I would
also like to have all my functions use the std:: scope.

2. For the time being I want this library to be a two file entity, a
header file and an implementation file. Below is what I'm testing but I
can't discern the errors the compiler is throwing at me. I'm obviously
not educated on the finer details of c++ but I've got a pile of books
and this is what I gathered on my own.

<code>
Header:
template <typename T>
string toString(const T &);

cpp file:
#include <sstream>
#include <string>
#include <iomanip>
#include <iostream>

using namespace std;

template <typename T>
string toString(const T &i) {
ostringstream oss;
oss << fixed << i;
return oss.str();
}
</code>

3. Now obviously I don't need an executable file, just object code. How
do I simply compile for object code and package it?

TIA,
Anthony

Dec 4 '05 #1
22 1923
ma****@gmail.com wrote:
Hi list,
First let me explain that my background is in Java and I am quite
spoiled to its niceties (read "less ambiguous nature"). Anyway to my
problems.

1. I want to write my own library for what I consider to be some holes
in the standard language. How do I go about writing and compiling this
without this stupid error about not having a 'main' function. I don't
want a stupid 'main' function. (I'm compiling using gcc 4.0.) I would
also like to have all my functions use the std:: scope.

2. For the time being I want this library to be a two file entity, a
header file and an implementation file. Below is what I'm testing but I
can't discern the errors the compiler is throwing at me. I'm obviously
not educated on the finer details of c++ but I've got a pile of books
and this is what I gathered on my own.

<code>
Header:
template <typename T>
string toString(const T &);

cpp file:
#include <sstream>
#include <string>
#include <iomanip>
#include <iostream>

using namespace std;

template <typename T>
string toString(const T &i) {
ostringstream oss;
oss << fixed << i;
return oss.str();
}
</code>

3. Now obviously I don't need an executable file, just object code. How
do I simply compile for object code and package it?

First of all, I would be carefull how you word your question in a C++
topic area, so-as to avoid a flame war, instead of getting your
question answered.

How you create an object file depends on your compiler. I believe for
gcc the option is -o
You should be able to determine the correct option by reading your man
page for gcc.

With the code you posted, you would not be able to create a usable
object file, since you're using template code, and the above template
implementation needs to be in the header file, and not your *.cpp file.

Also, you want to avoid adding using namespace std in your header file,
because then you force all code referring to your header to be exposed
to the std namespace in the global namespace.

Dec 4 '05 #2
ma****@gmail.com wrote:
Hi list,
First let me explain that my background is in Java and I am quite
spoiled to its niceties (read "less ambiguous nature"). Anyway to my
problems.

1. I want to write my own library for what I consider to be some holes
in the standard language. How do I go about writing and compiling this
without this stupid error about not having a 'main' function. I don't
want a stupid 'main' function. (I'm compiling using gcc 4.0.) I would
also like to have all my functions use the std:: scope.
Usually C++ compilers by default will build and "link". If you want to
create a "library" you need to ask it to compile only. This is usually
done with the "-c" option (or /c option for MSVC's "cl" compiler). Once
you've created a bunch o ".o" files (or .obj files) you may want to
either create a ".so" (shared object) (or a .dll for MS cl). For this I
suggest you read up on the documentation - or perhaps you want to create
a ".a" (archive or library of object files) (or a .lib for MSVC) which I
also suggest you read the docs on the "ar" command (or the lib command).

2. For the time being I want this library to be a two file entity, a
header file and an implementation file. Below is what I'm testing but I
can't discern the errors the compiler is throwing at me. I'm obviously
not educated on the finer details of c++ but I've got a pile of books
and this is what I gathered on my own.

<code>
Header:
template <typename T>
string toString(const T &);

cpp file:
#include <sstream>
#include <string>
#include <iomanip>
#include <iostream>

using namespace std;

template <typename T>
string toString(const T &i) {
ostringstream oss;
oss << fixed << i;
return oss.str();
}
</code>
You can only have a header file if you want this to work in gcc or you
have to use a compiler that supports template "export".

------------------- header.h ---------------------
#include <sstream>
#include <string>
#include <iomanip>
#include <iostream>

template <typename T>
std::string toString(const T &i) {
std:: ostringstream oss;
oss << std::fixed << i;
return oss.str();
}

------------------ end ---------------------------

You might want to consider putting it in a namespace and putting header
"guards" in the file.
------------------- header.h ---------------------
#ifndef x_header_h_x
#define x_header_h_x

#include <sstream>
#include <string>
#include <iomanip>
#include <iostream>

namespace macawm
{

template <typename T>
std::string toString(const T &i) {
std:: ostringstream oss;
oss << std::fixed << i;
return oss.str();
}

} // namespace macawm

#endif // x_header_h_x
------------------ end ---------------------------


3. Now obviously I don't need an executable file, just object code. How
do I simply compile for object code and package it?


In this case you don't. All you need is the header file.

Look at other examples - Austria C++ (shameless plug) or boost, loki,
ACE etc.

Dec 4 '05 #3
* ma****@gmail.com:
First let me explain that my background is in Java and I am quite
spoiled to its niceties (read "less ambiguous nature").
Actually it's the other way around: C++ is less ambigious, more formally
well-defined, and depends much less than Java on dynamic type checking.

Anyway to my
problems.

1. I want to write my own library for what I consider to be some holes
in the standard language.
You can be sure that that has already been done.

Are you familiar with the Boost library?

That's almost a standard library number 2 (parts of Boost will be part
of the standard library in the next standard), and if you do anything in
C++ you should have it -- and use it: <url: http://www.boost.org>.

How do I go about writing and compiling this
without this stupid error about not having a 'main' function. I don't
want a stupid 'main' function. (I'm compiling using gcc 4.0.)
With most compilers it's option "-c".

I would also like to have all my functions use the std:: scope.
Formally you can't. In practice the compiler won't stop you, but it's
not a good idea. The menu of what you're allowed to put in namespace
std (it's a namespace, not a scope) is very limited, essentially only
specializations of existing std namespace templates.

2. For the time being I want this library to be a two file entity, a
header file and an implementation file. Below is what I'm testing but I
can't discern the errors the compiler is throwing at me. I'm obviously
not educated on the finer details of c++ but I've got a pile of books
and this is what I gathered on my own.

<code>
Header:
template <typename T>
string toString(const T &);
That's boost::lexical_cast.

Anyway, in your header file you need to include <string>.

cpp file:
Here you should #include your header file first of all.

See chapter 1.6 in
<url: http://home.no.net/dubjai/win32cpptut/html/w32cpptut_01.html>.

#include <sstream>
#include <string>
#include <iomanip>
#include <iostream>

using namespace std;

template <typename T>
string toString(const T &i) {
ostringstream oss;
oss << fixed << i;
return oss.str();
}
</code>

3. Now obviously I don't need an executable file, just object code. How
do I simply compile for object code and package it?


See above, plus your compiler's documentation.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Dec 4 '05 #4
* ma****@gmail.com:
cpp file:

template <typename T>
string toString(const T &i) {
ostringstream oss;
oss << fixed << i;
return oss.str();
}


Sorry, didn't see that when I posted my first reply.

Template code can in practice not be separately compiled: such code
meant to be reused must, in practice, be placed in header files.

The way you're doing it you can only provide specializations for a fixed
number of types (and you're not doing even that).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Dec 4 '05 #5

Axter wrote:
ma****@gmail.com wrote:
Hi list,
First let me explain that my background is in Java and I am quite
spoiled to its niceties (read "less ambiguous nature"). Anyway to my
problems.

1. I want to write my own library for what I consider to be some holes
in the standard language. How do I go about writing and compiling this
without this stupid error about not having a 'main' function. I don't
want a stupid 'main' function. (I'm compiling using gcc 4.0.) I would
also like to have all my functions use the std:: scope.

2. For the time being I want this library to be a two file entity, a
header file and an implementation file. Below is what I'm testing but I
can't discern the errors the compiler is throwing at me. I'm obviously
not educated on the finer details of c++ but I've got a pile of books
and this is what I gathered on my own.

<code>
Header:
template <typename T>
string toString(const T &);

cpp file:
#include <sstream>
#include <string>
#include <iomanip>
#include <iostream>

using namespace std;

template <typename T>
string toString(const T &i) {
ostringstream oss;
oss << fixed << i;
return oss.str();
}
</code>

3. Now obviously I don't need an executable file, just object code. How
do I simply compile for object code and package it?
First of all, I would be carefull how you word your question in a C++
topic area, so-as to avoid a flame war, instead of getting your
question answered.


Point taken.
How you create an object file depends on your compiler. I believe for
gcc the option is -o
You should be able to determine the correct option by reading your man
page for gcc.
Believe me I've tried reading the man pages, but they're awful long and
more complex than I need.
With the code you posted, you would not be able to create a usable
object file, since you're using template code, and the above template
implementation needs to be in the header file, and not your *.cpp file.
So, I need to put the actual implementation code in the header file?!?
How will I compile it then? Last I checked a header file is used by the
preprocessor not in compiler itself.
Also, you want to avoid adding using namespace std in your header file,
because then you force all code referring to your header to be exposed
to the std namespace in the global namespace.


More along the lines of "using std::out" instead of "using namespace
std"?

Dec 4 '05 #6
On Sun, 4 Dec 2005 03:22:54 UTC, "ma****@gmail.com" <ma****@gmail.com> wrote:
Hi list,
First let me explain that my background is in Java and I am quite
spoiled to its niceties (read "less ambiguous nature"). Anyway to my
problems.

1. I want to write my own library for what I consider to be some holes
in the standard language. How do I go about writing and compiling this
without this stupid error about not having a 'main' function. I don't
want a stupid 'main' function. (I'm compiling using gcc 4.0.) I would
also like to have all my functions use the std:: scope.
You may compile a C/C++ file into an object file. A group of object
files is usually called a library. Read the help for your compiler
to find the options related to "compile only". These are the options
you will use to create object files. The compiler or perhaps a library
manager can be used to combine and manage a group of object files to
create a library. The linker is used to combine objects and libraries
into executable and dynamic link libraries. The compiler/librarian/linker
may be presented as a single interface or multiple interfaces depending on
your tool set. In the case of gcc, you will want to become familiar
with its options.

You are free to insert the scope directives you prefer in your header
files.
2. For the time being I want this library to be a two file entity, a
header file and an implementation file. Below is what I'm testing but I
can't discern the errors the compiler is throwing at me. I'm obviously
not educated on the finer details of c++ but I've got a pile of books
and this is what I gathered on my own.

<code>
Header:
template <typename T>
string toString(const T &);

cpp file:
#include <sstream>
#include <string>
#include <iomanip>
#include <iostream>

using namespace std;

template <typename T>
string toString(const T &i) {
ostringstream oss;
oss << fixed << i;
return oss.str();
}
</code>
Header files (.h, .hh .hpp) generally carry the definitions and templates.
Code files (.c .cc .cpp) generally carry the implementations. Templates
are generally in the header files and compiled each time they are actually
used. An uninstantiated/unused template does not have any code component
that would exist in an object/library file.
3. Now obviously I don't need an executable file, just object code. How
do I simply compile for object code and package it?
You can check the man gcc and gcc -h commands. I believe you are looking
for the gcc -c option. I'm working from memory and won't bother to look it
up for you. See my answer to #1 for a more complete description.
TIA,
Anthony


David
Dec 4 '05 #7
Ok, I believe I have a better grasp of what I need to do. Many thanks
for the (shameless) plugs to Boost and other libraries that already do
what I need. I really don't feel like making any new wheels.

G.M. I really like the attention to detail i.e. namespace macawm { ...
}. My current literature doesn't mention this explicitly. And I have
definitely put the guards in, I simply removed them for the post.
Actually it's the other way around: C++ is less ambigious, more formally
well-defined, and depends much less than Java on dynamic type checking.

A.S. I agree with this statement, but _I feel_ that dynamic type
checking is a must have. (Please no language debate.)

Thanks for the insightful and precise info.
Anthony

Dec 4 '05 #8
Ian
macawm wrote:
Actually it's the other way around: C++ is less ambigious, more formally
well-defined, and depends much less than Java on dynamic type checking.


A.S. I agree with this statement, but _I feel_ that dynamic type
checking is a must have. (Please no language debate.)

dynamic_cast ?

Ian
Dec 4 '05 #9
On 3 Dec 2005 19:47:39 -0800, "macawm" <ma****@gmail.com> wrote:

So, I need to put the actual implementation code in the header file?!?
How will I compile it then? Last I checked a header file is used by the
preprocessor not in compiler itself.


Then you've never learned about header files properly.

When you #include a header file, the preprocessor simply inserts the
file in that location. Copying and pasting the header file directly
into your source code would achieve the same thing (but that would be
a nightmare!).

Header files are usually used for declarations. Sometimes you'll
define a function or class method inside of a header file, but the one
thing you'll (probably) never do is declare an instance of anything
(as this will end up in multiple symbol errors when you link should
you use the header file more than once).

So if you're writing a template, you'll be writing code inside of the
header file. This is because the source file using the template will
need its definition to insert the necessary code. It can't do this
with compiled code from another module.
Dec 4 '05 #10

macawm wrote:
Axter wrote:
How you create an object file depends on your compiler. I believe for
gcc the option is -o
You should be able to determine the correct option by reading your man
page for gcc.
Believe me I've tried reading the man pages, but they're awful long and
more complex than I need.


Yes, most newbies that are unwilling to read the documentation on a
language and its tools usually do find it a rather difficult language
to learn. At this point the best advice anyone can give to you is,
"Give up." I mean, you already have so why kid yourself?
With the code you posted, you would not be able to create a usable
object file, since you're using template code, and the above template
implementation needs to be in the header file, and not your *.cpp file.
So, I need to put the actual implementation code in the header file?!?
How will I compile it then?


You don't. Not until you use it anyway. If you had read about
templates more you may have figured this one out. Granted templates
can be tough for newbies (and this very problem comes up), but I have
no simpathy for them when they won't even read the docs and start
blaming their shortcommings on the language instead of trying to learn.
Also, you want to avoid adding using namespace std in your header file,
because then you force all code referring to your header to be exposed
to the std namespace in the global namespace.


More along the lines of "using std::out" instead of "using namespace
std"?


No, more along the lines of not polluting the global namespace with
symbols that could collide with other symbols.

Programming is difficult and requires someone that likes to learn and
solve problems.

Dec 4 '05 #11
macawm wrote:
<code>
Header:
template <typename T>
string toString(const T &);

cpp file:
#include <sstream>
#include <string>
#include <iomanip>
#include <iostream>

using namespace std;

template <typename T>
string toString(const T &i) {
ostringstream oss;
oss << fixed << i;
return oss.str();
}
</code>

Also, you want to avoid adding using namespace std in your header file,
because then you force all code referring to your header to be exposed
to the std namespace in the global namespace.


More along the lines of "using std::out" instead of "using namespace
std"?


No, more like fully qualifying everything in the header file:

#include <sstream>
#include <string>

template <typename T>
std::string toString(const T &i) {
std::ostringstream oss;
oss << fixed << i;
return oss.str();
}

Incidentally, it's preferable in C++ to describe types, hence the
argument to your function:

const T &i

is preferably written

const T& i

Ben Pope
Dec 5 '05 #12

Ben Pope wrote:
Incidentally, it's preferable in C++ to describe types, hence the
argument to your function:

const T &i

is preferably written

const T& i


Unfortunately, because of the way the syntax of C++ works that doesn't
really work all the time.

char* c, x;

What is x? That's right, it's a char, not a char*. It would be nice
if it worked the other way but it doesn't. So it is actually better to
put modifiers like * and & next to the variable:

char *c, x;

Less confusion that way.

Dec 5 '05 #13

ro**********@gmail.com wrote:
Ben Pope wrote:
Incidentally, it's preferable in C++ to describe types, hence the
argument to your function:

const T &i

is preferably written

const T& i
Unfortunately, because of the way the syntax of C++ works that doesn't
really work all the time.

char* c, x;

What is x? That's right, it's a char, not a char*. It would be nice
if it worked the other way but it doesn't. So it is actually better to
put modifiers like * and & next to the variable:


Only if you like uninitialised variables.
char *c, x;
Let's suppose p is a valid pointer-to-char. Variables should always be
initialised at the point of declaration. If you don't know what to
initialise it to yet, don't declare it yet.So your example becomes

char *c = p, x = '\n';

Hang on, which symbol is a new variable and which is an initialiser.
It's not as clear as it could be.
Less confusion that way.


Not compared to

char* c = p;
char x = '\n';

You can still do char* c or char *c according to your preference, but
the multiple declarations in a single statement point isn't a very
significant argument. If you always initialise your variables at the
point of declaration, as you should for robustness, then you get least
confusion be declaring one variable on each line.

Gavin Deane

Dec 5 '05 #14
ro**********@gmail.com wrote:
Ben Pope wrote:
Incidentally, it's preferable in C++ to describe types, hence the
argument to your function:

const T &i

is preferably written

const T& i


Unfortunately, because of the way the syntax of C++ works that doesn't
really work all the time.

char* c, x;

What is x? That's right, it's a char, not a char*. It would be nice
if it worked the other way but it doesn't. So it is actually better to
put modifiers like * and & next to the variable:

char *c, x;

Less confusion that way.


Just declare variables on their own line, and always initialise them!

Less confusion and problems that way.

Ben Pope
Dec 5 '05 #15
de*********@hotmail.com writes:
ro**********@gmail.com wrote:

Variables should always be
initialised at the point of declaration. If you don't know what to
initialise it to yet, don't declare it yet.


Not always true, sometimes there are reasons not to initialize a
variable. Below are two cases where a delayed initalization is
necessary:

int func1()
{
int i;

for (i = 0; i < some_max_value; ++) {
/* some logic here */
if (some_condition)
break;
/* more logic here */
}

/* do more stuff here */
return i;
}

void func2(const char* s)
{
const char* x;
int i;

for (i = 0, x = s; *s != 0; ++i, ++s) {
/* do stuff here which might increment i or s, but not both */
}
}

/Niklas Norrthon
Dec 5 '05 #16

Niklas Norrthon wrote:
de*********@hotmail.com writes:
ro**********@gmail.com wrote:

Variables should always be
initialised at the point of declaration. If you don't know what to
initialise it to yet, don't declare it yet. Not always true, sometimes there are reasons not to initialize a
variable. Below are two cases where a delayed initalization is
necessary:


I should have added

If, because of language rules, you are forced to declare a variable
before its first use, declare it as late as possible and initialise it
to some defined value anyway.
int func1()
{
int i;
int i = 0;

for (i = 0; i < some_max_value; ++) {
/* some logic here */
if (some_condition)
break;
/* more logic here */
}

/* do more stuff here */
return i;
}

void func2(const char* s)
{
const char* x;
int i;
const char* x = 0;
int i = 0;
for (i = 0, x = s; *s != 0; ++i, ++s) {
/* do stuff here which might increment i or s, but not both */
}
}


You are not delaying initialisation. You are leaving the variables
uninitialised then later assigning values to them when you first use
them.

I agree that sometimes you cannot declare a variable at precisely the
point of its first use. But if you are forced to declare it early,
that's no reason for leaving it unitialised.

Gavin Deane

Dec 5 '05 #17

deane_ga...@hotmail.com wrote:
I agree that sometimes you cannot declare a variable at precisely the
point of its first use. But if you are forced to declare it early,
that's no reason for leaving it unitialised.


Oops. That final word should be "uninitialised".

Gavin Deane

Dec 5 '05 #18
Ben Pope wrote:
Incidentally, it's preferable in C++ to describe types,
Says who?
hence the argument to your function:

const T &i

is preferably written

const T& i


This is a non-sequitur. Instead of:

int (&foo)[5];

would you prefer:

int (&)[5] foo;

? Even if you would, this is not how the syntax of C++ works.
A declaration is NOT always a type followed by a variable name,
although it turns out that way in simple cases.

Dec 5 '05 #19
Old Wolf wrote:
Ben Pope wrote:
Incidentally, it's preferable in C++ to describe types,


Says who?


I was supposed to say there is a bias towards describing types, rather
than variables.

I'm not sure who said it, and it is of course personal preference. Both
are equally valid.

From what I've seen, Bjarne Stroustrup prefers the former (FWIW).
hence the argument to your function:

const T &i

is preferably written

const T& i


This is a non-sequitur. Instead of:

int (&foo)[5];

would you prefer:

int (&)[5] foo;

? Even if you would, this is not how the syntax of C++ works.
A declaration is NOT always a type followed by a variable name,
although it turns out that way in simple cases.


No, I understand that.

Ben Pope
Dec 5 '05 #20
Ben Pope <be*******@gmail.gone> wrote:
Old Wolf wrote:
Ben Pope wrote:
Incidentally, it's preferable in C++ to describe types,


Says who?


I was supposed to say there is a bias towards describing types, rather
than variables.

I'm not sure who said it, and it is of course personal preference. Both
are equally valid.

From what I've seen, Bjarne Stroustrup prefers the former (FWIW).


Agreed, see http://www.research.att.com/~bs/bs_faq2.html#whitespace

The choice between "int* p;" and "int *p;" is not about right and
wrong, but about style and emphasis. C emphasized expressions;
declarations were often considered little more than a necessary evil.
C++, on the other hand, has a heavy emphasis on types.

A "typical C programmer" writes "int *p;" and explains it "*p is what
is the int" emphasizing syntax, and may point to the C (and C++)
declaration grammar to argue for the correctness of the style.
Indeed, the * binds to the name p in the grammar.

A "typical C++ programmer" writes "int* p;" and explains it "p is a
pointer to an int" emphasizing type. Indeed the type of p is int*.
I clearly prefer that emphasis and see it as important for using the
more advanced parts of C++ well.

...

Whenever something can be done in two ways, someone will be confused.
Whenever something is a matter of taste, discussions can drag on
forever.

--
Marcus Kwok
Dec 6 '05 #21
de*********@hotmail.com writes:
Niklas Norrthon wrote:
de*********@hotmail.com writes:
ro**********@gmail.com wrote:

Variables should always be
initialised at the point of declaration. If you don't know what to
initialise it to yet, don't declare it yet.

Not always true, sometimes there are reasons not to initialize a
variable. Below are two cases where a delayed initalization is
necessary:


I should have added

If, because of language rules, you are forced to declare a variable
before its first use, declare it as late as possible and initialise it
to some defined value anyway.
int func1()
{
int i;


int i = 0;

for (i = 0; i < some_max_value; ++) {

Here we are in disagreement. I see no reason why one would init a
variable, if it assigned on the very next line of code.

If I really wanted to init the variable I'd rather do:

int = 0;

for (; i < some_max_val; ++i) { // and so on...

There is no harm in doing it your way, but I think my way is
perfectly acceptable too, and even prefered, since it makes
the code clearer. It's somewhat related assigning NULL to a
pointer after a call to free, which is totally unnecessary
if the variable goes out of scope on the next line of code...

/Niklas Norrthon
Dec 6 '05 #22

Niklas Norrthon wrote:
de*********@hotmail.com writes:
Niklas Norrthon wrote:
de*********@hotmail.com writes:

> ro**********@gmail.com wrote:
>
> Variables should always be
> initialised at the point of declaration. If you don't know what to
> initialise it to yet, don't declare it yet.
Not always true, sometimes there are reasons not to initialize a
variable. Below are two cases where a delayed initalization is
necessary:
I should have added

If, because of language rules, you are forced to declare a variable
before its first use, declare it as late as possible and initialise it
to some defined value anyway.
int func1()
{
int i;


int i = 0;

for (i = 0; i < some_max_value; ++) {

Here we are in disagreement. I see no reason why one would init a
variable, if it assigned on the very next line of code.


The reason is to avoid ever having uninitialised variables around. That
way, when I restructure the code, I can guarantee that, no matter what
stupid mistake I make, the bug I introduce will not be a hard to track
down, appears to only break in release mode, undefined behaviour bug
caused by trying to use an uninitialised variable. Always initialising
the variable is a simple technique to avoid ever having that problem.
If I really wanted to init the variable I'd rather do:

int = 0;

for (; i < some_max_val; ++i) { // and so on...

There is no harm in doing it your way, but I think my way is
perfectly acceptable too, and even prefered, since it makes
the code clearer.
I certainly never suggested doing that!

Explicitly assigning the initial value to the loop variable is
certainly preferable to relying on previous code. But that point is
orthogonal to whether you should ever allow uninitialised variables in
your code.
It's somewhat related assigning NULL to a
pointer after a call to free, which is totally unnecessary
if the variable goes out of scope on the next line of code...


Well, I suppose I wouldn't care too much about initialising i in code
like this

void f()
{
// ... do lots of stuff
int i; // immediately going out of scope
}

but I've never written code like that.

Using RAII principles, all resource release happens in destructors, so
I find that pointers do indeed go out of scope immediately after delete
is called on them. But if I was going to keep a pointer hanging around
for reuse, I would consider setting it to null for the same reason.

Gavin Deane

Dec 6 '05 #23

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Stylus Studio | last post: by
11 posts views Thread by Larry | last post: by
9 posts views Thread by John Robert | last post: by
3 posts views Thread by Luis Esteban Valencia | last post: by
11 posts views Thread by manochavishal | last post: by
9 posts views Thread by Brett Romero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.