Thread: Replace string with const char *

  1. #16
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by MacNilly View Post
    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.

    Quote Originally Posted by MacNilly View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #17
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466

    Sorry for hijacking

    Sorry for hijacking the thread with my conversation with Elysia, but to the OP I would say:

    You can't replace std::string with const char*... however, it is possible to replace const char* with std::string in the the majority of use cases, unless you really need an array of just bytes. Actually, this is not an uncommon requirement, I/O interfaces comes to mind here. But I think Elysia's point was just that you can ignore char* and just use std::string here.

  3. #18
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    I haven't read this entire thread but I couldn't ever possibly recommend eschewing `std::string` in favor of raw pointers O_o

  4. #19
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by MutantJohn View Post
    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>.
    What can this strange device be?
    When I touch it, it gives forth a sound
    It's got wires that vibrate and give music
    What can this thing be that I found?

  5. #20
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by MacNilly View Post
    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.
    What can this strange device be?
    When I touch it, it gives forth a sound
    It's got wires that vibrate and give music
    What can this thing be that I found?

  6. #21
    Informer -Adrian's Avatar
    Join Date
    Jan 2013
    Posts
    830
    Quote Originally Posted by MacNilly View Post
    Sorry for hijacking the thread with my conversation with Elysia, (...)
    I'd say about 3/4th of threads don't involve the OP after the first or second question. This board could really be called ExpertsExchange™, because that's what many threads turn into ;P

  7. #22
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466
    Quote Originally Posted by Elkvis View Post
    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.
    Last edited by MacNilly; 12-02-2016 at 02:47 AM.

  8. #23
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by MacNilly View Post
    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.
    What can this strange device be?
    When I touch it, it gives forth a sound
    It's got wires that vibrate and give music
    What can this thing be that I found?

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. replace char by string
    By rveger in forum C Programming
    Replies: 13
    Last Post: 09-04-2011, 03:29 PM
  2. Best way to return a const char* from a string
    By cyberfish in forum C++ Programming
    Replies: 4
    Last Post: 08-16-2009, 08:44 PM
  3. String and const char *
    By sawer in forum C++ Programming
    Replies: 5
    Last Post: 03-05-2006, 02:16 AM
  4. Convert Const Char * to string
    By winsonlee in forum C++ Programming
    Replies: 3
    Last Post: 08-25-2004, 02:38 PM
  5. const char[] or string?
    By prog-bman in forum C++ Programming
    Replies: 10
    Last Post: 07-11-2004, 06:13 PM

Tags for this Thread