Help with some string conversion

Hey everyone... can anyone help me out with a bit of a conversion problem? I cant seem to find a way to successfully do this, so hopefully someone here can point me in the right direction.

Basically, I have a file that has a list of binary numbers, like this:

01001001
00100000
01110011
01101000
01101111
01110000

And I have this code so far:

Code:

---

#include <iostream>
#include <string.h>
#include <iomanip>
#include <fstream>
using namespace std;

int main() {

        string binstring;
        ifstream binList;
        int bytecount = 0;
        binList.open("binary.txt");
        if (binList) {
                cout<<"File opened successfully."<<endl;
        }
        if (!binList) {
                cerr<<"Unable to open the file."<<endl;
                exit(1);
        }
//start reading data and act on it
        binList>>binstring;
        bytecount++;
        cout<<bytecount<<" "<<binstring<<endl;
        while (binList) {
                binList>>binstring;
                bytecount++;
                cout<<bytecount<<" "<<binstring<<endl;
                cout<<endl;
        }
        binList.close();
        cout<<"Finished"<<endl;
return 0;
}

---

Now, of course, right now this little bit of code does nothing useful. It just opens the file, reads in a line, and prints it out.

What I want to accomplish is to take each line (in the string form 01001010) and convert that to its ascii character.

So if the program reads this: 01000001 it outputs ascii char 65, or 'a'.

any suggestions? the hard part is the conversion of the string binstring to an integer or hex that == the actual binary value of 01000001 and not the value of the char string 01000001 (if that makes any sense).

Any suggestions?

Thanks
Jeff

Iterate the chars in the line convert to decimal [y = 2y+x] cast to char.

One way : std::bitset ...

Code:

---

#include <bitset>

// ...

bitset<8> bits(binstring);
cout << bits.to_ulong() << ":" << (char)bits.to_ulong() << endl;

---

also, it should be

#include <string> // not <string.h>

Use std::bitset:

Code:

---

#include <iostream>
#include <fstream>
#include <bitset>

int main()
        {
        std::ifstream InFile("binary.txt");
        std::bitset<8> Byte;
   
        if(!InFile)
                {
                std::cerr << "Unable to open the file." << std::endl;
                return 1;
                }
       
        while(InFile >> Byte)
                {
                std::cout << Byte << ": " << static_cast<char>(Byte.to_ulong()) << std::endl;
                }

        system("pause");
        return 0;
        }

---

And that's #include <string> NOT #include <string.h>...

EDIT: Too late.. :D

Thanks... bitset does this a WHOLE lot easier than anything else I have tried...

yet another of the many c++ pieces I have yet to learn!

While I am on that topic, can anyone suggest a good reference book that goes into all the various header files, and explains the functions within? Something like a sourcebook, or compendium or some such?

It's not a book, but a good reference none the less: http://www.sgi.com/tech/stl/table_of_contents.html

Quote:

---

Originally posted by bladernr
While I am on that topic, can anyone suggest a good reference book that goes into all the various header files, and explains the functions within? Something like a sourcebook, or compendium or some such?

---

I am not sure what you are asking. Are none of the books listed in the FAQ and books in the book review sites listed in the FAQ not what you are asking about?

Quote:

---

Originally posted by bladernr
While I am on that topic, can anyone suggest a good reference book that goes into all the various header files, and explains the functions within? Something like a sourcebook, or compendium or some such?

---

Honestly, you don't need anything else other than the SGI reference for STL that was linked to before. There are a lot of good books about STL, but 95% of the interesting and useful information is already on the SGI site, so I would use that as a reference. Just read through it, try and understand the different algorithms and containers and every time you have a problem, make sure that you first think of a solution in terms of STL. This helps you learn the standard library much faster and better.

I have 3 books on STL (Jossutis and the Effective STL books), but the information in them is not a lot more than what the SGI site already contains.

Quote:

---

Originally posted by Yves M
Honestly, you don't need anything else other than the SGI reference for STL that was linked to before.

---

Honestly, I have not seen any documentation or tutorial available online (available free) that is as useful as the documentation of the C language and of the rest of the C++ language. When I say that in the newsgroup where C++ experts such as Dinkumware personnel hang out, I am told I must pay for a book to get good documentation.

I will look at the SGI link, but I am sure I have seen it before when I had questions and if so then it is not significantly better. There are many ways that all the documentation I have seen are deficient, and again, I doubt the SGI documentation is significantly better.

I know you will respond by asking for examples, and I am not trying to avoid answering that exdept to say that I have not been organized well enough to keep track of examples. The best way for me to answer that is to start developing some documentation myself and in the process I can show what has been missing.

Quote:

---

Originally posted by Sam Hobbs
Honestly, I have not seen any documentation or tutorial available online (available free) that is as useful as the documentation of the C language and of the rest of the C++ language. When I say that in the newsgroup where C++ experts such as Dinkumware personnel hang out, I am told I must pay for a book to get good documentation.

---

Yes and no. It's a reference site, not a tutorial. So if you are completely new to STL, if you don't want to invest the time to check through the index, if you don't understand parts of it, then it's not useful. It's very similar to MSDN in the sense that in order to learn proper Windows development, it's easier to get a book that guides you, so to learn how to use everything in STL correctly, it's better to start with tutorials and books. But once you know what you are doing, a reference is all you need.

My daily information needs are very well served by MSDN and SGI's STL site.

Quote:

---

Originally posted by Yves M
Yes and no. It's a reference site, not a tutorial.

---

I don't consider it to be much of a reference.

Quote:

---

Originally posted by Yves M
if you don't want to invest the time to check through the index, if you don't understand parts of it

---

I have looked through the index and other such materials and I have struggled to understand it.

Quote:

---

Originally posted by Yves M
It's very similar to MSDN in the sense that in order to learn proper Windows development, it's easier to get a book that guides you

---

Most of what I know about Windows, MFC and C++ I have learned from the MSDN; very little from (other) books.

Quote:

---

Originally posted by Yves M
so to learn how to use everything in STL correctly, it's better to start with tutorials and books.

---

Better? Nearly a necessity, but it does not need to be. It is entirely possible for documentatio to be written that is as useful as the rest of the language; for example, as useful as the documentaion of the C runtime library functions.

I think you know I can get a lot from the MSDN and documentation such as it, and I consider the C++ Standard Classes documentation to be among the worst, probably the worst. I think the main problem is the commercialization of the C++ langauge. We have to pay to look at the standard and in my opinion the adoption of the C++ Standard Classes seem to have been influenced too heavily by economics and not enough by technical merits.

Quote:

---

Originally posted by Sam Hobbs
I don't consider it to be much of a reference.

---

Well, Sam, have you read a standard algorithms books from cover to cover? The basis of all of STL is in algorithmics and you need to have a good of grasp of that in order to understand both the real intent and the usefulness of the STL.

Quote:

---

We have to pay to look at the standard and in my opinion the adoption of the C++ Standard Classes seem to have been influenced too heavily by economics and not enough by technical merits.

---

If you buy it through ANSI, it's pretty cheap. But I'll comment on the economics vs. technical merit. The technical merit IMHO of the C++ standard in regards to STL is much higher than that of the C library. It was at the time a novel design approach and it still remains a very useful idiom to specify operations by their complexity instead of their actual implementation. The fact that it is hard to understand for somebody who doesn't understand the complexities of standard algorithms is a side-effect which can't be avoided. There are the cookbook approaches and there are the insight approaches. If you (I mean generally, not you, Sam) want to get past the cookbook stage, you need to know more about algorithms in general.

Quote:

---

Originally posted by Yves M
The technical merit IMHO of the C++ standard in regards to STL is much higher than that of the C library. It

---

Which "it"? The STL or the C library? There is a big difference between them. The C library was an established part of the C language well before the language was standardized. A lot of it was developed by (I am guessing) college students and by others not motivated by economics. The STL was reviewed and standardized by an international committe. There is a big difference.

From the meaning of the two sentences it should be clear that "it" means the STL. The C library is not specified in terms in complexity.

I'm sorry but your "International Standard" point doesn't mean anything at all. C was designed by Ritchie and made an ANSI standard (i.e. reviewed and revised) in the mid 80s. C++ was designed by Stroustrup and made a standard in the mid 90s. STL was designed and implemented almost single-handedly by one person: Alex Stepanov (with help from others, of course), so no, it's not dictated by big companies or evil countries and nasty economics.

[edit: found Stepanov's name again]

Quote:

---

Originally posted by Yves M
From the meaning of the two sentences it should be clear that "it" means the STL.

---

I am sorry, but I was not sure. I try to avoid assuming. People often use words such as "it" in confusing ways. I often re-read things I have written for this forum and replace the word "it".

Quote:

---

Originally posted by Yves M
I'm sorry but your "International Standard" point doesn't mean anything at all.

---

It means a lot to me.

Quote:

---

Originally posted by Yves M
C was designed by Ritchie and made an ANSI standard (i.e. reviewed and revised) in the mid 80s.

---

I am nearly certaint that there was more colaboration with others than you are indicating here; perhaps you are not aware of it. Regardlous, it was very well established before it was considered for standardization.

Quote:

---

Originally posted by Yves M
so no, it's not dictated by big companies or evil countries and nasty economics.

---

I did not say evil or nasty. I would not use those words to refer to CodeGuru but I consider CodeGuru to be economically motivated also. And the language standards are dictated by the membership of the corresponding committees. The C++ language committe did not either design the STL nor implement it, but they did adopt it as it exists in the standard.

Quote:

---

Honestly, I have not seen any documentation or tutorial
available online (available free) that is as useful as the
documentation of the C language and of the rest of the C++
language.

---

Normally I agree with what Sam posts, but in this case I
disagree that most programmers can effectively learn
"the rest of the C++ language" from on-line (available free)
documentation. Certainly not from MSDN (in my opinion).
MSDN gives the syntax, but has very little info on C++ design.
(I admit, that the flaw might be with me, and not MSDN - I'm
certainly not a programming expert and using MSDN to learn
C++ might just be beyond my capabilities. Maybe real computer
programmers can.)

Look at the following code posted by a "stl-basher" in the
Visual C++ forum. He claimed that it was a great design.
However, the design is flawed - and flawed in a very basic way.
But I doubt that looking at MSDN will show why. (I spent about
30 minutes searching MSDN and could not find anything ...
maybe its there and I missed it.) And public inheritance is
basic to the C++ language.

Code:

---

class CUpperCaseString : public CString
{
public:
    CUpperCaseString(LPCSTR szString)
        : CString(szString)
    {
        MakeUpper();
    }

    virtual ~CUpperCaseString()
    {
    }
};

---

What is the difference between public and private inheritance,
and when/why would you ever use private inheritance? I
searched for that in MSDN and came up empty. Again, maybe its
there somewhere.

Pretty much look at any of the points in Meyers Effective C++
books. I have not found on-line documentation that covers the
majority of them in proper detail.

Personally, I don't even think the documenation for the MFC
classes is any good. I have never found any complexity
guarentees on performance for the various functions. About all I
can find is that "inserting into a CArray is slow" and
"inserting into a CMap is fast". I agree with both those
statements in GENERAL, but I can also show examples where
the statements are not true. And while performance is not an
issue in all programs, it is certainly an issue and many codes.


Some on-line sites that I find useful (both STL and C++ in general)

http://www.josuttis.com/libbook/idx.html
http://www.gotw.ca/gotw/
http://www.aristeia.com/publications_frames.html

and not leave out MSDN ...

http://msdn.microsoft.com/library/de...tml/SAMPLE.asp
http://msdn.microsoft.com/msdnmag/is...L/default.aspx

I think I pretty much agree with you, Philip. Please understand that you are coming from the opposite direction. I did not say that the MFC documentation and the rest of the MSDN is wonderful. I was just saying that they are better compared to ths STL documentation.

What is critical here is the definition of "effectively learn". What I am saying is that it is generally possible to learn enough to write a program using C and C++. That might not be true, but if not then that would support the important point of what I am trying to say; that is, that the STL documentation is not sufficient for using the STL. Good software design is a different matter, and the STL documentation is worse in that manner, not better.

Quote:

---

Originally posted by Sam Hobbs
the important point of what I am trying to say; that is, that the STL documentation is not sufficient for using the STL.

---

Fair enough, you must have an introduction other than just reading the SGI docs. This is done in varying degrees on some sites and in articles available online (e.g. std::vector by Gabriel). My point is that once you understand the concept of STL (iterators, containers, algorithms, templates), you don't need a book anymore. There are advanced techniques that are only in books, but for most of the how do I use this-type questions, the SGI docs are sufficient. But yes, it's not for the uniniatiated. I.e. if you want to learn the concepts of STL, it's a bad idea to start only from the docs. But if you have used vector, string and map, you just need the SGI docs to see what a deque and a multiset do and how to use them.

Quote:

---

Originally posted by Yves M
There are advanced techniques that are only in books, but for most of the how do I use this-type questions, the SGI docs are sufficient.

---

I have been quite frustrated trying to use the documentation for determining some very basic uses of STL.

Maybe. I've always found what I was looking for, except for the stuff about allocators and advanced techniques, like how to best combine several things into others.