>Erm so why not just use C den? Tee he he
Strong typing, of course. That's the single biggest selling point of C++ for a lot of programmers. It can also be convient to work primarily low level, but still take advantage of container classes and standard algorithms.

>It can also be convient to work primarily low level, but still take advantage of container classes and standard algorithms.


Oooooh I don't get it. Why would you want to use low level language syntax with c++ and it's container classes. I don't see the advantage. Stop confusing me now... :cry:

>I don't see the advantage.
Okay, write a C++ function that interfaces with an assembly program and see how much trouble the name mangling gives you. Then once you get that worked out, see how much trouble working with C++ objects on the assembly level gives you.

Or better yet, do the opposite. Interface an assembly subroutine with a C++ program and perform an operation that's trivial with a standard container. Keep in mind that the assembly subroutine is extremely likely to give you something low level, and you need to handle that.

>Okay, write a C++ function that interfaces with an assembly program and see how much trouble the name mangling gives you. Then once you get that worked out, see how much trouble working with C++ objects on the assembly level gives you.

I no dat silly I'm saying is why can't u just do that all in C?

Why would you want to use low level language syntax with c++ when you can use all low level syntax in C and have it work fine and dandy with an assembly program.

What is the advantage of using c++ if it is so difficult to interface a function and work with c++ objects with assembly.

Again, why not just separate the two and be done with it? This is wat we are debating isn't it?... I was sumwhat confused by your last statement.

>I'm saying is why can't u just do that all in C?
Well, what if I'm using a map in the C++ function? It should be immediately obvious that to do the same thing in C would require either a non-standard library or a *lot* of time duplicating the effort of std::map. In my experience, non-standard libraries are more likely to cause extra work than rolling your own solution. So I ask you, why not just use C++ with the container that makes your job easy?

Let me compare lines of code, since that's more obvious. Say the actual job using an std::map takes 15 lines of code. Okay, now take the map away and replace it with your own handwritten library that, if done well, would take several hundred extra lines, at least. And those are lines of intricate algorithms that are easily broken and take a lot of effort to debug and test.

Indeed, why not just do it all in C? :rolleyes:

>This is wat we are debating isn't it?
Is that what you're talking about? I was only addressing your question about the occasional convenience of writing low level C++.

Wait a minute are you saying that you can easily use the c++ style map for integration in assembly?

But I thought you said that using objects and functions in assembly is painful. Isn't the std::map using objects and fucntions behind the scenes anyway?

>But I thought you said that using objects and functions in assembly is painful.
It's painful if you try to do it directly. However, with a good interface that meshes with assembly, you can use as much C++ as you want under the hood. Then compile to an object file and link the object file with the assembly program. At that point all you need to worry about is accessing the external name and matching the interface.

Oh ok I never knew that. I just assumed if you were using c++ in assembly you couldn't easily integrate all the benefits the STL has to offer. And so was chasing the point of why anyone would want to use c++ in assembly if that was case.

In that small exception then I can see why it may be useful to mix C++ with C style syntaxing.

However, in most cases. Like most of the ppl who come here with homework problems, they are not using peripheral devices with assembly. It is just basic programs, so I would argue they shouldn't really need an excuse to use c-style strings over std::strings.

That's all I was getting at. Is that what you understood from before.

>It is just basic programs, so I would argue they shouldn't really need
>an excuse to use c-style strings over std::strings.
Knowing the low level helps to write better at the high level. This is a simple fact, and the reason why so many students come here using C-style strings, but teachers have a tendency to take it too far.

A good teacher, in my opinion, will make writing the first programs as simple as possible and then add to the student's knowledge base by introducing conveniences or details as necessary. That way a student is capable of getting immediate results, and can gradually increase the power and flexibility of their results as they learn more. You can see your improvement, you can see the necessity of something, and you're constantly succeeding. There's no depression or boredom, and you can cover more ground.

Unfortunately, the accepted curriculum is to start with the low level and move to the high level. That means working with C-style strings and eventually getting to std::string, with a stop at that godawful MFC CString along the way. The sad part is that the class is usually over long before the students would get to the std::string part, and they walk away with an incomplete perspective, if they didn't quit half way through because they couldn't "get it" at the low level.

OOpsy gotta go now. My mom keeps telling me "You spend too much time on the darn computer"...

:cheesy:

[edit]
I understand the importance of learning the c-style string. Obviously the std::string is just a fancy wrapper for the c-style string? But I think that the c-style string should only be taught in C.

When learning c++ I don't think it does the student any justice by ignoring the benefits of the std::string and the STL. Like you said unfortunately they come to the end of the course without fully appreciating the rewards of using the STL.[/edit]
I'm out.