problem with strings

[Aris]

A few days ago I asked from you how to join a string like "file"

A number that change values from 1 to 5 and another string like ".txt"

to have a result like "file1.txt","file2.txt" and so on

and you gave me the right answer.

But now I got another problem.

How can I save that values to an array?

This is the code you gave me:



void CreateName(char *dest_fname, const char *fname, const char *ext, int
counter,int *a,int length)

{

sprintf(dest_fname, "%s%d%s", fname, counter, ext);

Write_File(dest_fname,a,length);

}



int main()

{

int *A;

char *B[5]; //I tried this

char fname[] = "file";

char ext[] = ".txt";

char out[64] = {'\0'};

int file_counter=0,k=0;

for(int i=20000; i<=100000; i+=20000)

{

A=Create_RundomNumbers_Array(i);

CreateName(out, fname, ext, ++file_counter,A,i);

B[k++]=out; //and this

}

But it doesn't work.

strcpy(B[k++],out); doesn't work.either.



what can I do?

 

[Ron Natalie]

A few days ago I asked from you how to join a string like "file"

So why are you ignoring everything we told you?

A number that change values from 1 to 5 and another string like ".txt"

to have a result like "file1.txt","file2.txt" and so on

and you gave me the right answer.

But now I got another problem.

How can I save that values to an array?

This is the code you gave me:

That is not the code anybody gave you. You still have exactly the same
problem as before.

char* is NOT A STRING TYPE.

Learn the difference between call by value and call by reference.

Before you can write into something with strcpy you must first
access memory for it.


Ditch your attempts to use char* and use std::string.

 

[Marcelo Pinto]

Ron Natalie wrote:

[snip]

Before you can write into something with strcpy you must first
access memory for it.

[snip]

Before you can write into something with strcpy you must first
*allocate* memory for it.

 

[Mike Wahler]

Ron Natalie wrote:

[snip]

Before you can write into something with strcpy you must first
access memory for it.

[snip]

Before you can write into something with strcpy you must first
*allocate* memory for it.

Actually that should be 'provide' memory. This memory
might be allocated, or static, or automatic.

-Mike

 

[int2str]

Ditch your attempts to use char* and use std::string.

I know this is widely echoed advise in this news group, but I'm not
sure I agree with it.

Personally I think new programmers getting into C++ should actually DO
figure out how char*'s work. Once they've mastered char*'s and start
"real projects", they should obviously use std::string or some
equivalent, but if you don't have a general understanding of new and
delete (or delete[] ), I don't think you should simply skip the basics
and move on to std::string...

Cheers,
Andre

 

[Ben Pope]

Ditch your attempts to use char* and use std::string.

I know this is widely echoed advise in this news group, but I'm not
sure I agree with it.

Personally I think new programmers getting into C++ should actually DO
figure out how char*'s work. Once they've mastered char*'s and start
"real projects", they should obviously use std::string or some
equivalent, but if you don't have a general understanding of new and
delete (or delete[] ), I don't think you should simply skip the basics
and move on to std::string...

std::string is much easier to use correctly than char*.

Surely the basics are std::strings, and the complicated bits are arrays,
resource management, and pointers?

Your comments seem backwards somehow.

Only when somebody is at ease with the basics, should they progress to
the more advanced topics of pointers, arrays and resource management.

Ben Pope

 

[int2str]

Ditch your attempts to use char* and use std::string.

I know this is widely echoed advise in this news group, but I'm not
sure I agree with it.

Personally I think new programmers getting into C++ should actually DO
figure out how char*'s work. Once they've mastered char*'s and start
"real projects", they should obviously use std::string or some
equivalent, but if you don't have a general understanding of new and
delete (or delete[] ), I don't think you should simply skip the basics
and move on to std::string...

std::string is much easier to use correctly than char*.
Yes.

Surely the basics are std::strings, and the complicated bits are arrays,
resource management, and pointers?

Sort of.. (see below)

Your comments seem backwards somehow.

Only when somebody is at ease with the basics, should they progress to
the more advanced topics of pointers, arrays and resource management.

The "usage" of std::strings is easier than char* of course. But
std::string hides implementation details and simple language
mechanism's (buffer allocation and deletion etc) that the developer
should be familiar with in order for them to apply such mechanism's to
their own classes and algorithms.

The concept of arrays may be more advanced, but a character array is
IMHO the simplest, most concrete way to explain those features and
visualize them. It's much easier to explain an array of chars than an
array of X objects.

One should be aware of what allocates memory where and who deletes it
before diving into library functions that do it for you.

This may seem backwards - heck, it may even actually be backwards - but
I believe it's a better way to learn.

Also, the recommendation of "Heck, just use std::string" usually comes
at a point where somebody is fundamentally misunderstanding what a
char* does. So I definitely think it's better to explain that first,
before just pointing towards a library feature.

Otherwise one could simply say "Don't bother with char*'s, just use
Visual Basic!"

Cheers,
Andre

 

[Gavin Deane]

I know this is widely echoed advise in this news group, but I'm not
sure I agree with it.

Personally I think new programmers getting into C++ should actually DO
figure out how char*'s work.

No, no, no, no, NO !!!! (at least, not until well after they learn
about std::string)

Once they've mastered char*'s and start
"real projects", they should obviously use std::string or some
equivalent

Ever heard of 'primacy' in teaching?

but if you don't have a general understanding of new and
delete (or delete[] ), I don't think you should simply skip the basics
and move on to std::string...

Given that std::string is basic and representing a string with an array
of chars is advanced, this statement does not make sense.

char array representation of strings is a hack invented for the sole
reason that the C language has no better option. C++ is not C.

The idea that one should not be allowed to learn how to _use_ a
standard library facility until one has learnt how to implement it in C
is ridiculous.

std::string is a fundamental that should be taught at the same level as
basic control structure (for, if, while), std::vector and std::cout.

dynamic memory management is an advanced topic that should be taught at
the same level as inheritance, polymorphism, templates and the char
array hack for representing strings.

Or are you suggesting that nobody should be shown

#include <iostream>

int main()
{
std::cout << "Hello, world!\n";
return 0;
}

until they know how to implement a stream buffer?

Gavin Deane

 

[Ben Pope]

Sort of.. (see below)


The "usage" of std::strings is easier than char* of course. But
std::string hides implementation details and simple language
mechanism's (buffer allocation and deletion etc) that the developer
should be familiar with in order for them to apply such mechanism's to
their own classes and algorithms.

Yes, but they should only need to apply those things to their own
classes and algorithms *after* hello world, and whatever else comes
after that.

The concept of arrays may be more advanced, but a character array is
IMHO the simplest, most concrete way to explain those features and
visualize them. It's much easier to explain an array of chars than an
array of X objects.

std::vector is much easier to use than a dynamically allocated array.

One should be aware of what allocates memory where and who deletes it
before diving into library functions that do it for you.

Why? Keeping that horrible resource management stuff hidden (in
constructors and destructors - RAII) is what we all strive to do in
order to create code that is not leaky and exception safe, surely?

Why should a beginner learn how to misuse dangerous tools from the very
beginning (when they don't need to), only to be set straight later on?

This may seem backwards - heck, it may even actually be backwards - but
I believe it's a better way to learn.

I guess that you think that you should learn C before C++?

Also, the recommendation of "Heck, just use std::string" usually comes
at a point where somebody is fundamentally misunderstanding what a
char* does. So I definitely think it's better to explain that first,
before just pointing towards a library feature.

I disagree. Get inexperienced people to use the features that have been
painstakingly designed and refined over time and slapped in the standard
library, instead of reinventing the wheel.

The features have to be in standard-conforming implementation. They are
there to hide all the messy details of resource allocation, provide
value-semantics and generally make your life easier.

The use of raw pointers is really only necessary in very low-level code,
and at that point you really do need to understand in detail what every
line of code *really* does... such as whether it can throw an exception,
in order to avoid resource leaks.

Pointers and the free store are often unnecessary in simple programs,
and even then, the use of references rather than pointers mitigates the
chance of many errors.

The moment you introduce pointers you have to introduce not just
reference semantics, but exception safety and resource management
techniques such as RAII. IMO this is too much to grasp in one go,
especially for a beginner.

Otherwise one could simply say "Don't bother with char*'s, just use
Visual Basic!"

I'll refer to your previous comment:

> The "usage" of std::strings is easier than char* of course. But
> std::string hides implementation details and simple language
> mechanism's (buffer allocation and deletion etc) that the developer
> should be familiar with in order for them to apply such mechanism's to
> their own classes and algorithms.

So I guess everybody should be taught machine code initially. C++ is
way too abstract!

Abstractions are what we try to model in our software, in order to not
have to think about the details. The more details that can disappear
behind an interface, the better.

Ben Pope

 

[Neil Cerutti]

Ditch your attempts to use char* and use std::string.

I know this is widely echoed advise in this news group, but I'm
not sure I agree with it.

Personally I think new programmers getting into C++ should
actually DO figure out how char*'s work. Once they've mastered
char*'s and start "real projects", they should obviously use
std::string or some equivalent, but if you don't have a general
understanding of new and delete (or delete[] ), I don't think
you should simply skip the basics and move on to std::string...

Learn std::string first, along with the other standard
containers. Then learn about iterators. After that, pointers will
practically be learned; there just another iterator, after all.

This is the approach taken in _Accelerated C++_. Before you're
done you write your own String and Vector classes. It's a
perfectly legitimate approach.

 

[Neil Cerutti]

Sort of.. (see below)

The "usage" of std::strings is easier than char* of course. But
std::string hides implementation details and simple language
mechanism's (buffer allocation and deletion etc) that the
developer should be familiar with in order for them to apply
such mechanism's to their own classes and algorithms.

That's why learning std::string before char* is so valuable. It
exposes new C++ programmers to a major C++ abstraction mechanism.
Learning it the other way around may be a disservice. The ability
to program in Brainf**k is very important in C++, but you don't
have to learn it first. ;-)

The concept of arrays may be more advanced, but a character
array is IMHO the simplest, most concrete way to explain those
features and visualize them. It's much easier to explain an
array of chars than an array of X objects.

I agree that eventually you need to understand these concepts.