Thread: Replace string with const char *

Originally Posted by MacNilly

Thats fine, but who knows how to pick the right tools, or .. when faced with so many, simply picks the first that "works"? Perhaps C or C++ is not even the right tool for the job. I think maybe C++ programmer like yourself is like a neurosurgeon who knows his (or her) tools so well.

I mean, I went over the source code to the C++ collections framework that's included in my linux distro thats a GCC specific distro (I forgot what its called). It's old, granted, but it came with a design documentation.. and it's very sound.. super efficient and flexible library... but the code.. my GOD, it's complexly makes it unreadable.. too much use of template classes, traits structs, and preprocessor magic.. I'm sorry, it's not designed for mortals. We can't understand that. I'll take a Java HashMap any day, even if its not as "optimal" as that, LOL.

I am not going to argue against this, because it's true. C and C++ aren't exactly easy languages if used improperly. And it is a problem today. The same thing could, of course, be done in other languages too, so it's not like it's a problem unique to C and C++.
One needs to properly learn a language in order to use it well. That's true of any language.

Originally Posted by MacNilly

No, there are many a reason to know char* semantics, even given std::string... I think that a big problem is programming to abstractions that aren't understood.. and there is always the leakly abstraction layer.. it's not possible to implement a non-leaky abstraction; some things must be known about the implementation because it affects the client.. even the STL realized this (especially in terms of big-O complexity of operations), but its not possible to encode or enforce that into the language.

For example, think about the painter who always keeps his paint at one point, getting slower and slower every day... (there's a name for that idiot, I forgot now)... but you won't use a generic class List that doesn't specify it's lookup time .. list.get(i).. if it was O(N).. when you have a large amount of data... I'm saying that you must know something about the implementation of List in order to use it effectively and practically. It could mean the difference between taking 10 seconds or 10 years on a data set; however, this requires a knowledges of the implementation.. it cannot be hidden behind an abstraction layer.

I don't disagree with you. This is very true. But you still don't need to always know how exactly it's implemented, just its semantics. Sometimes we're force into situations where we have to know the implementation, sure. But that's then, and not now. It's just going to be a waste of time to teach everyone every single little thing. As a novice programmer, you don't need char*. If you're going to implement data structures, then yes, you need to know of it. But that's for later. Perhaps I should have been more explicit about this.

Originally Posted by MutantJohn

I haven't read this entire thread but I couldn't ever possibly recommend eschewing `std::string` in favor of raw pointers O_o

I agree. Use std::string or std::vector<char>.

Originally Posted by MacNilly

I mean, I went over the source code to the C++ collections framework that's included in my linux distro thats a GCC specific distro (I forgot what its called). It's old, granted, but it came with a design documentation.. and it's very sound.. super efficient and flexible library... but the code.. my GOD, it's complexly makes it unreadable.. too much use of template classes, traits structs, and preprocessor magic.. I'm sorry, it's not designed for mortals. We can't understand that. I'll take a Java HashMap any day, even if its not as "optimal" as that, LOL.

It's not the author's intent that you understand the implementation. The author's intent is that you be able to use the interface effectively. The former is not required for the latter to be true.

this requires a knowledges of the implementation.. it cannot be hidden behind an abstraction layer.

Wrong. If the interface is well-documented (in this case, it is), it is absolutely irrelevant to know implementation details. That's literally the point of a public interface. The C++ standard library is documented in great detail, by a number of independent sources, not to mention the standard itself. They do include algorithmic complexity information, including big-O notation. If you can't find the information you need, it's because you're just not trying hard enough.

Originally Posted by Elkvis

It's not the author's intent that you understand the implementation. The author's intent is that you be able to use the interface effectively. The former is not required for the latter to be true.

I will have to respectively disagree. While I understand the purpose of interface vs. implementation, my point is that it is just simply not possible to program to an interface effectively (in some cases) without knowing the relevant parts of the implementation, regardless of the author's intent.

Often times I must look at the implementation in order to determine whether or not I should use this implementation, or perhaps another implementation, or perhaps some modification of it in order to suit my requirements.

For example, if there is an interface type IMap, then I cannot efficiently write code to the IMap interface without knowing if it is implemented as a association list (ListMap), a hash table (HashMap), or a binary tree (TreeMap), or whatever.

I simply don't see how they could all be subsumed under the same interface. For example, a HashMap requires the element type to be equality comparable as well as hashable (not to mention the contract between equality and hash), while a TreeMap requires none of those, but you need at least a partial ordering function over your elements, whereas ListMap simply requires none of those.

In addition, the complexity requirements of all these implementations are wildly different. Some are predictable (ListMap and TreeMap, for example, assuming a balanced tree), while HashMap is totally unpredictable as it depends on the implementation of the hash table (hidden) as well as its relation to the hash function (client-defined). Also, the iteration contracts are wildly different. In a TreeMap, iterators will remain valid across add(), but in a ArrayMap, you can't depend on it. Just look at C++ iterator invalidation protocols.. a huge fail, IMO.

Now, if some documentation or contract requires a big-O complexity requirement on IMap, then it has effectively limited which implementations can be used, and then there isn't any real reason to use an IMap over some concrete implementation of IMap, because they simply aren't "interchangable".

Finally, if "programming to interfaces" is a good idea (and I think it is), then all the interfaces need to have the same predictable behavior and requirements. Looking at the C++ STL, I think the whole idea of "programming to an interface" really doesn't exist. You program to the implementation.

Originally Posted by MacNilly

Looking at the C++ STL, I think the whole idea of "programming to an interface" really doesn't exist. You program to the implementation.

You're 100 percent incorrect on that statement. The behavior of the data structures and algorithms in the C++ standard library (it's not called the STL anymore) is well defined in the standard. Implementations are required to abide by the specification in the standard. There isn't a ton of wiggle room.