Char Array

[3qX21hU5]

Its really no use in debating with him he won't listen to reason. Anyways once you get past the beginner stages of C++ and get more experience in programming you will see what we are talking about.

[Dy7SLyTq]

what do you mean? the only thing you have told me was that strings are superior. as for your evidence, someone said do this with c-strings, and posted a link which at the very least showed they are equal

[cire]

I'm still waiting for you to post the equivalent code to the snippet it took me about 3 minutes to write with std::string. Having encountered more and more of your useless, misinformed posts, I'm beginning to think you couldn't manage it in a month.

as for your evidence, someone said do this with c-strings, and posted a link which at the very least showed they are equal

Your reading comprehension and logic skills could use some work.

[Dy7SLyTq]

fine give me five minutes.

[3qX21hU5]

Ok here is some things about strings that make them better.


1) std::string manages its own memory, so you can copy, create, destroy them easily. C style strings don't.

2) std::string has better searching, replacement, and manipulation functions.

3) The MAJOR reason to use std::string is for memory management since string does it for you, and probably much more efficiently then you can.

4) The buffer operation are packed with the string functionality, so less worries about the buffer problems.

5) Extra capacity for concatenation efficiency: std::string often have a capacity greater than their size. This allows increasing the size without many reallocation's.

6) Sensible comparison and assignment operators. Similarly, assigning C string pointers (or passing them to functions) creates ownership ambiguities.


Now for some disadvantages for C style strings yay

1) Getting the length is a relatively expensive operation.

2) Having to keep track separately of how each c-string is allocated and so how it must be free'd, or even if it needs to be free'd at all.

3) No way to refer to a slice of the c-string as another c-string.

4) No embedded nul characters are allowed.


I think I'll stop there I would give you some actual code example but you just ignored cire's and would probably just ignore mine to so there is not much point.

Anyways you can feel free to use what you feel more comfortable doing, but most people will agree that strings provide less chance for risks, higher functionality, and are much faster and easier to work with.

[Dy7SLyTq]

first of all:

int main()
{
	char *result;
	strcpy(result, func());
	printf("concantenated: %s\n", result);
	removeSubstring(result, "AEIOUaeiou");
	printf("w/o vowels: %s\n", result");
}

char *func()
{
	char *stringOne, *stringTwo;

	printf("First string: ");
	scanf("%s", stringOne);
	printf("Second: ");
	scanf("%s", stringTwo);
	return strcpy(strcpy(stringOne, " "), stringTwo);
}

void removeSubstring(char *s,const char *toremove)
{
	while(s = strstr(s,toremove))
		memmove(s, s + strlen(toremove), 1 + strlen(s + strlen(toremove)));
} 

secondly: zereo is the first person to actually give an arguement. and to make sure i went back and checked.

[3qX21hU5]

It has some errors but ignoring those your program still doesn't do what cire was asking you to do. I'm not trying to bring you down just pointing out facts. Don't worry once you gain more experience you will see where we are coming from. And why in 99 out of 100 cases you will use string.

When I run it this is the output

First string: zereo
Second: hello
concantenated: hello
w/o vowels: hello

Process returned 0 (0x0)   execution time : 2.966 s
Press any key to continue.

When I run cire's this is the output

Enter a string of any length.
zereo
Enter another string of any length.
hello
Concatenated: "zereo hello"
With all vowels removed: zr hll
Process returned 0 (0x0)   execution time : 4.511 s
Press any key to continue.

Then here is one that makes use of getline() and the full function of the program.

Enter a string of any length.
zereo how are you doing today?
Enter another string of any length.
 I'm doing very good thank you
Concatenated: "zereo how are you doing today?  I'm doing very good thank you"
With all vowels removed: zr hw r y dng tdy?  'm dng vry gd thnk y
Process returned 0 (0x0)   execution time : 16.171 s
Press any key to continue.

[Dy7SLyTq]

im at work w/o a compiler. i threw it up hastily. and i would listen but ur last post was the first one to actually say why

[cire]

Many people, if they didn't have a compiler handy where they were, might use an online compiler to test their code or at least see if it compiles (which yours does not.)

Your code invokes undefined behavior with alarming regularity. There is no memory allocated for the c-strings you're dealing with. All of your pointers are pointing to random places in memory. I'm not bothering to modify your code so it compiles, because that isn't necessary to see that your code does not accomplish any of the tasks correctly.

I would say you've pretty well illustrated char*'s increased opportunity for shooting oneself in the foot. Let's just hope you don't shoot it while it's still in your mouth.

[Dy7SLyTq]

well considering the fact that compilr crashed on me when i compile (with code that i know works) i cant test-compile it and as i said i threw it up hastily

[Dy7SLyTq]

i say we just drop it now

[cire]

well considering the fact that compilr crashed on me when i compile (with code that i know works)

So you mean to say that when you got home your chances of writing working code were equally abysmal? That sure makes your assertions more believable.

i say we just drop it now

The only reason I've been pushing is because you keep posting misinformation and then championing it as if it were some sort of high ideal.

When people don't know the facts, they're ignorant. When people do know the facts, but insist the conclusion which flies in the face of the facts is correct, they're stupid. So far, you like to ignore facts until they're forced down your gullet. Smarten up.

[Dy7SLyTq]

compilr is an online ide/compiler.
and what facts have u given me cire besides its just wrong. and im not championing it. im defending it

[3qX21hU5]

I have a feeling cire that DTS is just a young kid and like all young kids think they know more then they do and more then others do (I know I did). We have given you facts but you choose to ignore them because it doesn't correlate with what you claim. Its not just this thread its multiple threads you have participated in.

and im not championing it. im defending it

Your defending a point you have no experience with. The code you posted shows that, it doesn't matter if you have a IDE online or at home or you don't use one your code had MAJOR logical flaws in them not just syntax errors.

I'm just going to be blunt what we are saying is you shouldn't act like your the king shit and know everything that is worth knowing. Your trying to make yourself look smarter and more experienced then you are and its making you look dumb. The saying "Its better to keep your mouth shut and be thought stupid, then to open it and be proven stupid" comes to mind and "Respect your elders" which doesn't always mean elder by age.

Now I'm not saying your stupid or your a bad person or anything I'm just saying you need to learn to listen and accept advice from people more experience then you like cire.

Sorry to be harsh and I apologize if I offended you.

[Dy7SLyTq]

the only thing im getting offended about is no one will tell me what was wrong. you just kept saying no thats wrong. not until a few posts ago did any one actually tell me why. im sorry, but im not going to accept something as fact just because someone said so. if you want me to be quiet then tell me why

edit:
honestly i dont think im asking too much with above

[Chervil]

the only thing im getting offended about is no one will tell me what was wrong.

Why do you expect other people to do your work for you? If you don't have enough information, do some research, study the topic.

[Dy7SLyTq]

so, and this is an honest question, that i need to look up why im wrong if some one says i am? im not saying be lazy. im saying dont just say ur wrong. who does that help?

[3qX21hU5]

Gezz DTS we gave you plenty of information on why you are wrong YOU just ignore it because it doesn't correlate with what YOU think is true.

I provided you answers to what is wrong with c style strings in the very beginning of this thread

Strings are FAR less error prone then char * are and that is common knowledge I thought. The most common errors leading to errors when it comes to c style strings are unbounded string copies, null- termination errors, and string truncation.

http://www.cplusplus.com/forum/beginner/95354/#msg511873

and also gave you even more a few posts ago

Ok here is some things about strings that make them better.


1) std::string manages its own memory, so you can copy, create, destroy them easily. C style strings don't.

2) std::string has better searching, replacement, and manipulation functions.

3) The MAJOR reason to use std::string is for memory management since string does it for you, and probably much more efficiently then you can.

4) The buffer operation are packed with the string functionality, so less worries about the buffer problems.

5) Extra capacity for concatenation efficiency: std::string often have a capacity greater than their size. This allows increasing the size without many reallocation's.

6) Sensible comparison and assignment operators. Similarly, assigning C string pointers (or passing them to functions) creates ownership ambiguities.


Now for some disadvantages for C style strings yay

1) Getting the length is a relatively expensive operation.

2) Having to keep track separately of how each c-string is allocated and so how it must be free'd, or even if it needs to be free'd at all.

3) No way to refer to a slice of the c-string as another c-string.

4) No embedded nul characters are allowed.

Yet YOU ignore it. We gave you all the information you need to do research about and find out that it is true and that you are not correct on what you think. It is not our responsibility to make you do the research or present everything you need to know on a platter for you.

Researching and reading is what programming is all about so you better get used to it.

And with that I'm done with this debate with a brick wall.

[cire]

the only thing im getting offended about is no one will tell me what was wrong. not until a few posts ago did any one actually tell me why.

I'm unsure if you're talking about your code or your assertion that char* is better than std::string for string operations. If you're talking about your code, it was only posted a few posts ago. If you're talking about the assertion, people have been telling you since you made it.

I asked you to code something that would illustrate the point to you, but apparently you're not capable of coding such a thing. How many times do you expect the "I'm at work and helpless without the compiler on my computer at home" excuse to fly?

compilr is an online ide/compiler.

My apologies. I thought you were just misspelling words as per your usual abbreviated posts. However, it isn't the only online compiler out there.

im sorry, but im not going to accept something as fact just because someone said so.

If you understand the difference between a char* and a std::string (as you claim to,) and don't understand why using a std::string is better for string operations in most instances than using char*, then one must assume that you don't understand the difference between char* and a std::string.

You're free to believe whatever tripe you wish, just don't expect it to go unchallenged when you talk bullshit about things you know very little about.

Your posts are going into the troll category for me from here on out.

[zb0S216C]

"std::string" is a "char *" internally, but what that pointer pointers-to is totally different. For instance, in normal C code, "char *" normally points to a string literal, which is normally placed in a R-O segment within the data section of the ELF. On the other hand, "std::string" points to dynamically allocated memory (within the heap section of the ELF) which changes in size with each addition of a character (no exactly, but still).

The matter of fact is both "std::string" and string literals are two completely different things due to the differing read/write permissions the OS imposes on them, their positioning/mapping within memory, and the method of allocation the OS uses to accumulate memory for the two.

@DTSCode: You have to realise that both "std::string" and string literals are two different things, and therefore, cannot be thought of as synonymous and then choose string literals because you believe you have more control -- in actual fact, naked pointers are greatly limited in functionality intrinsically; it's the functions that the use those naked pointers that give the pointers worth in terms of functionality.

In conclusion, both "std::string" and string literals are both useful, but it depends on what needs to be done. For instance, if you have a program that needs to store some text that's constant, then string literals are more preferable over "std::string"; if you have some text that needs to change based on the program's state, for instance, then "std::string" would be more preferable that string literals.

By the way, pointing to a string literal and then attempting to modify that string is undefined behaviour.

_Wazzak