Convert Java To C++

Hello I wrote this out to count out the letters in a sequence for use in decryption class. but I want to knw can someone convert it to c or c++ for me

Code:

---

package Bsc;


import java.io.*;


 
public class MyAppMain {


  public static final int MAX_CHAR = 65535;


  public static void main(String[] args) throws IOException {
        InputStreamReader isr = new InputStreamReader(System.in);
        BufferedReader br = new BufferedReader(isr);
        System.out.println("Enter the line :- ");
        String text = br.readLine();
        System.out.println("You have Enterd :- " + text);


      String s = text.toUpperCase();
      int res[]  = new int[256];


      for(int i=0 ; i<s.length() ; i++)
      {
          res[s.charAt(i)]++;
      }


      for(int i=0 ; i<res.length ; i++)
      {
          if(res[i] !=0)
          {
              System.out.println(""+(char)i+" : "+res[i]);
          }
      }
  }
}

---

Any help is appreciated

Looks like homework. Have you attempted anything?

Here's your first hint: main is not part of a class in C++.


Quzah.

C++ Made Easy. Start here.

Quote:

---

Originally Posted by quzah

Here's your first hint: main is not part of a class in C++.
Quzah.

---

Depends. Personally, I prefer to use a class in place of 'main'. For one thing, it can make accessing command line parameters and environment variables much simpler by prepackaging them into more user friendly formats. Since your member variables can take the place of globals, you can utilize less verbose function calls without resorting to uncompartmentalized coding. Finally, instead of returning a value, you can simply define an 'exit' function in your 'main' base class that throws an exception to be caught from the wrapped 'main'/'wmain' to do so, making it easy to safely return from anywhere in your 'main' class' functions.

[Edit]Okay, I can't find the quote so I'll guesstimate. The point here is that Java makes you jump through hoops like that imposing a level of "OOP" that is absolutely not needed in C and C++; you don't need to bring those mistakes home, so don't.[/Edit]

Quote:

---

Personally, I prefer to use a class in place of 'main'. For one thing, it can make accessing command line parameters and environment variables much simpler by prepackaging them into more user friendly formats.

---

A standard C or C++ program begins with `main'; you don't "use a class in place of 'main'"; you are simply calling another function.

Quote:

---

Since your member variables can take the place of globals, you can utilize less verbose function calls without resorting to uncompartmentalized coding.

---

Congratulations, you've hidden global state behind a badly protected pointer; every problem related to global variables still applies without actually providing the convenience of globally visible state.

Quote:

---

Finally, instead of returning a value, you can simply define an 'exit' function in your 'main' base class that throws an exception to be caught from the wrapped 'main'/'wmain' to do so, making it easy to safely return from anywhere in your 'main' class' functions.

---

O_o

Now you've committed a terrifying assault on program logic while managing to poorly hide what is essentially a `goto' or `setjmp'/`longjmp' and badly implementing a measure of the behavior of the standard `exit' function.

Soma

Quote:

---

Originally Posted by phantomotap

A standard C or C++ program begins with `main'; you don't "use a class in place of 'main'"; you are simply calling another function.

---

Yes, I use a class instead of defining main when I write a program. What happens "behind the scenes" is immaterial.

Quote:

---

Originally Posted by phantomotap

Congratulations, you've hidden global state behind a badly protected pointer; every problem related to global variables still applies without actually providing the convenience of globally visible state.

---

Not at all. Suppose you wanted to use the class in a different context (that is, not as the actual main driver of your program). You could basically just change the name of the base class and reuse the code as-is, without dragging around global declarations that could conflict elsewhere. It's just a cleaner design, really.

Quote:

---

Originally Posted by phantomotap

O_o

Now you've committed a terrifying assault on program logic while managing to poorly hide what is essentially a `goto' or `setjmp'/`longjmp' and badly implementing a measure of the behavior of the standard `exit' function.

---

How so? The stack unwinds safely, so destructors are called appropriately, plus you get to write more lucid code to boot. I don't see anything inherently flawed with that.

Quote:

---

Originally Posted by phantomotap

[Edit]Okay, I can't find the quote so I'll guesstimate. The point here is that Java makes you jump through hoops like that imposing a level of "OOP" that is absolutely not needed in C and C++; you don't need to bring those mistakes home, so don't.[/Edit]

---

Oh, I see. You just hate the idea of using a class instead of main. Got it.

Quote:

---

Originally Posted by gardhr

I use a class instead of defining main when I write a program.

---

More accurately, you use a class in addition to defining main when you write a program.

Quote:

---

Originally Posted by gardhr

Not at all. Suppose you wanted to use the class in a different context (that is, not as the actual main driver of your program). You could basically just change the name of the base class and reuse the code as-is, without dragging around global declarations that could conflict elsewhere. It's just a cleaner design, really.

---

I am curious as to the feasibility of reusing a "main class" in the first place.

Quote:

---

Originally Posted by gardhr

How so? The stack unwinds safely, so destructors are called appropriately, plus you get to write more lucid code to boot. I don't see anything inherently flawed with that.

---

I agree. However, this has less to do with the class and more to do with having that last resort exception handler in main.

Quote:

---

Originally Posted by gardhr

Yes, I use a class instead of defining main when I write a program. What happens "behind the scenes" is immaterial.

---

Can you please explain that? I thought that a C++ program HAS to have its "main" defined. Is there another way?!

Quote:

---

Originally Posted by GReaper

Can you please explain that? I thought that a C++ program HAS to have its "main" defined. Is there another way?!

---

gardhr's approach is to write a class whose constructor or other, possibly static, member function contains the code that would normally be in the global main function. The global main function is then implemented to use this class, e.g., by calling the static member function or instantiating an object of the class (and possibly calling the designated member function).

This approach is uncommon in C++. I think that it would be more common to write another function that is called from the global main function. This function would contain the code that would normally be in the global main function. The global main function itself would then do things like translate the command line arguments to a preferred format.

Quote:

---

What happens "behind the scenes" is immaterial.

---

Ah, of course, the "Ostrich" argument.

Quote:

---

It's just a cleaner design, really.

---

If your design is truly "clean", the one bit of code that can not be repurposed without a lot of work is the bit of code that drives the relationship between all other components.

Quote:

---

I don't see anything inherently flawed with that.

---

Depending on an exception mechanism as a means of flow control is flawed program design by definition.

Quote:

---

You just hate the idea of using a class instead of main.

---

Not at all, but I do hate bad design and the illusion of good design.

Consider it a character flaw.

Soma

Quote:

---

Can you please explain that?

---

I find an example in addition to the comments Laserlight made will be useful.

He is essentially doing something like this:

Code:

---

class program
{
    void start
    (
        int argc
      , char ** argv
    )
    {
        // program logic
    }
    void * data;
};

void main
(
    int argc
  , char ** argv
)
{
    try
    {
        program a;
        a.start(argc, argv);
    }
    catch(...)
    {
        // cleanup logic
    }
}

---

which basically looks like this:

Code:

---

struct program
{
    void * data;
};

void start
(
    struct program * this
  , int argc
  , char ** argv
)
{
    // program logic
}

void main
(
    int argc
  , char ** argv
)
{
    try
    {
        program a;
        start(&a, argc, argv);
    }
    catch(...)
    {
        // cleanup logic
    }
}

---

in order to avoid doing this:

Code:

---

void * data;

void start
(
    int argc
  , char ** argv
)
{
    // program logic
}

void main
(
    int argc
  , char ** argv
)
{
    if(start(argc, argv))
    {
        // cleanup logic
    }
}

---

because he thinks it magics away design and globally visible state problems.

Soma

Quote:

---

Originally Posted by gardhr

Depends.

---

No it doesn't.

Quote:

---

Originally Posted by gardhr

Personally, I prefer to use a class in place of 'main'.

---

No you don't.

You can't use a class instead of main, unless they changed it in the standard. You must have a main function AFAIK. That was my whole point, almost word for word in fact.


Quzah.

Quote:

---

Originally Posted by laserlight

More accurately, you use a class in addition to defining main when you write a program.

---

Rather, 'main' resides in a header file where the class is defined.

Quote:

---

Originally Posted by laserlight

I am curious as to the feasibility of reusing a "main class" in the first place.

---

Well, let's say you have a program that provides some file conversion facility. You have another program that performs some higher level functionality and decide to "drag and drop" it into that codebase. Point it, if you really wanted to do it, you could do so with minimal effort.

Quote:

---

Originally Posted by laserlight

I agree. However, this has less to do with the class and more to do with having that last resort exception handler in main.

---

It isn't a really "last resort", but a practical way to return a value to the operating system without having to engineer the program with all of the "plumbing" needed to safely do so without such a facility. For example, you might be several function calls deep into the program when you realize that the user has supplied some malformed input. You can simply have defined a 'usage' function that reports the error and exits gracefully. The only safe alternative would be to return an error code or whatnot from each function, which has to be rechecked at multiple points before you get down to the business of shutting the program down.

Quote:

---

Originally Posted by GReaper

Can you please explain that? I thought that a C++ program HAS to have its "main" defined. Is there another way?!

---

See above. Basically, it entails invoking 'main' within the header file, which in turn calls the 'main' function of the wrapper class.

Hiding 'main' away in a header file doesn't magically make it not part of your program. So there is no 'depends' answer.


Quzah.

I'm confused... If "main" residents in a header file, which source file will be our "main.cpp"? :D

Quote:

---

Rather, 'main' resides in a header file where the class is defined.

---

As it happens, this is probably a violation of the standard and certainly a violation of good taste.

Imagine passing your source along and the poor newbie who gets your code really does try reusing the monstrous thing only to find dozens of "multiple definition" errors all of them related to `main'.

Have fun with that $@*&!% newbie!

Quote:

---

For example, you might be several function calls deep into the program when you realize that the user has supplied some malformed input. You can simply have defined a 'usage' function that reports the error and exits gracefully.

---

Thank you; that is exactly what I was talking about.

If at all possible, you should design your program such that processing happens after validation so that this sort of event can not happen.

If that is not possible, you should design your program to allow the possibility of recovery.

If that is not possible, such a failure means dying anyway so `atexit' and `exit' are perfectly acceptable.

If necessary, you can even wrap the `exit' call to issue a log in order to make it a more graceful death.

Soma

The syntax basically looks like so:

Code:

---

class app : program<app>
{
        void main()
        {
                print_args();
        }
        void print_args()
        {
                if(argv.empty())
                        usage();
                copy(argv.begin(), argv.end(), ostream_iterator<string>(cout, "\n"));
        }
        void usage()
        {
                cout << "Usage: " << argv0 << " <input_files>" << endl;
                exit();
        }
}
        start();

---

Quote:

---

Originally Posted by gardhr

It isn't a really "last resort"

---

It is a last resort because it is placed at the outer most boundary to catch any exception that falls through the cracks of other exception handlers, so to speak. It is hardly unusual for a global main function to have such a last resort exception handler, so the fact that you write a class has nothing to do with it.

Quote:

---

Originally Posted by GReaper

I'm confused... If "main" residents in a header file, which source file will be our "main.cpp"?

---

Presumably the one that includes that header file. I suggest that you do not adopt gardhr's approach, at least not for now.

Code:

---

class app : program<app>
{
    void main()
    {
        print_args();
    }
    void print_args()
    {
        if(argv.empty())
            usage();
        copy(argv.begin(), argv.end(), ostream_iterator<string>(cout, "\n"));
    }
    void usage()
    {
        cout << "Usage: " << argv0 << " <input_files>" << endl;
        exit();
    }
}
    start();

---

O_o

Code:

---

start();

---

Yog Sothoth!

A lower-case, function-like macro used outside of a function definition all in order to fake the elimination of `main'.

You are doomed to blow your leg off, the legs of your partners, and those of the mail man.

Soma

Quote:

---

Originally Posted by quzah

Hiding 'main' away in a header file doesn't magically make it not part of your program. So there is no 'depends' answer.

Quzah.

---

Technically, yes. Effectively, no.

Quote:

---

Originally Posted by phantomotap

As it happens, this is probably a violation of the standard and certainly a violation of good taste.

---

The standard does not dictate and your personal opinions about what is or is not tasteful has no bearing on how I decide to write my own programs.

Quote:

---

Originally Posted by phantomotap

Thank you; that is exactly what I was talking about.

If at all possible, you should design your program such that processing happens after validation so that this sort of event can not happen.

If that is not possible, you should design your program to allow the possibility of recovery.

If that is not possible, such a failure means dying anyway so `atexit' and `exit' are perfectly acceptable.

If necessary, you can even wrap the `exit' call to issue a log in order to make it a more graceful death.

---

Albert Einstein once said "Everything should be made as simple as possible, but not simpler". I think this is a much better design philosephy than the sort of ad-hoc principles that you seem to follow.

Quote:

---

Originally Posted by gardhr

Technically, yes. Effectively, no.

---

There is no last half of that argument. Technically yes. Period. See also:

Quote:

---

Originally Posted by gardhr

The standard does not dictate and your personal opinions about what is or is not tasteful has no bearing on how I decide to write my own programs.

---

The standard does dictate that you have a main function. So regardless of how you choose to pretend it doesn't exist, it really does. So keep your falsehoods out of this thread.


Quzah.

Quote:

---

Originally Posted by laserlight

It is a last resort because it is placed at the outer most boundary to catch any exception that falls through the cracks of other exception handlers, so to speak. It is hardly unusual for a global main function to have such a last resort exception handler, so the fact that you write a class has nothing to do with it.

---

No, it simply provides a direct pathway to egress. Nothing more. Other execeptions are caught elsewhere (or not at all, if you wish), so the behavior compared to a "typical" program is identical.

Quote:

---

Originally Posted by laserlight

Presumably the one that includes that header file. I suggest that you do not adopt gardhr's approach, at least not for now.

---

Why? Because it "defies the norm"? How absurd!

Quote:

---

Originally Posted by phantomotap

A lower-case, function-like macro used outside of a function definition all in order to fake the elimination of `main'.

You are doomed to blow your leg off, the legs of your partners, and those of the mail man.

---

Sorry, that was a typo. No parenthesis should appear after the program instance 'start'.

Quote:

---

Originally Posted by quzah

There is no last half of that argument. Technically yes. Period. See also:The standard does dictate that you have a main function. So regardless of how you choose to pretend it doesn't exist, it really does. So keep your falsehoods out of this thread.


Quzah.

---

Your whole argument centers around the wording I chose, to wit "I use a class instead of defining main when I write a program". But I never said that main is not invoked in my programs, nor any such nonsense that it doesn't exist. The implication was simply that I don't use it directly. Is that really so difficult to understand?

I'd prefer the ol' *defining "main" in "main.cpp"* way, thank you. After all, I do a little trick with headers and sources in order when debugging different object files are outputed, while when releasing all is compiled onto a single object file, letting the compiler inline the functions. If I didn't have a "main.cpp" file, my trick would be dead!

Quote:

---

Originally Posted by gardhr

Your whole argument centers around the wording I chose

---

Of course it does, because you were wrong:

Quote:

---

Originally Posted by gardhr

, to wit "I use a class instead of defining main when I write a program".

---

There is no "depends". There is no "instead of".

Quote:

---

Originally Posted by gardhr

But I never said that main is not invoked in my programs, nor any such nonsense that it doesn't exist. The implication was simply that I don't use it directly. Is that really so difficult to understand?

---

You're wrong on all accounts, so it doesn't matter how you word it.

1. You do define main.
2. You do use it directly, because it is always the entry point of your program, and it is always used.
3. It is not part of a class (which is what my post said).

You were wrong, I wasn't. Period.

edit - Furthermore, as to why I wouldn't suggest "your method":

Code:

---

#include"myclass.h"
int main( void )
{
    MyClass Main();
    return 0;
}

---

Having that be my entire main program in my entire main.cpp isn't any worse than whatever method you're coming up with. At least mine is clear. Putting main off in a header is pointless.

edit edit - Also: Go read my first post and your reply. You are wrong. I said 'main is not part of a class in C++'. There is no "depends" in reply to that.


Quzah.

Quote:

---

Originally Posted by gardhr

Your whole argument centers around the wording I chose, to wit "I use a class instead of defining main when I write a program". But I never said that main is not invoked in my programs, nor any such nonsense that it doesn't exist. The implication was simply that I don't use it directly. Is that really so difficult to understand?

---

Not defining main means that main is not invoked and if main is never defined the program cannot link. Further if you do this instead of that the logical conclusion is that never happens. So you did trap yourself.

CHI!

Okay... I'm done.

Soma

Quote:

---

Originally Posted by gardhr

Why? Because it "defies the norm"? How absurd!

---

You are proposing that your unusual and unnecessary method of doing things be adopted? How absurd!

Sure, it may be more akin to what ForeverAndOne is used to in Java, and maybe GReaper likewise finds it familiar, but when in Rome, do as the Romans do... at least until you become a Roman citizen and can get away with acting like you are Greek (with all due respect to GReaper :) ).

Quote:

---

Originally Posted by quzah

Having that be my entire main program in my entire main.cpp isn't any worse than whatever method you're coming up with. At least mine is clear.

---

Actually, your program does nothing much. The global main function only contains a return statement, and before that, a declaration of a function named Main that takes no arguments and returns a MyClass :)

Quote:

---

Originally Posted by laserlight

Actually, your program does nothing much. The global main function only contains a return statement, and before that, a declaration of a function named Main that takes no arguments and returns a MyClass :)

---

That's why I don't post on the C++ forum usually. ;) My programs don't do anything much.


Quzah.

Quote:

---

Originally Posted by laserlight

at least until you become a Roman citizen and can get away with acting like you are Greek (with all due respect to GReaper :) ).

---

Well :), in Sparta ( a.k.a Sparti ) they would have probably thrown him out! :D

Quote:

---

Originally Posted by whiteflags

Not defining main means that main is not invoked and if main is never defined the program cannot link. Further if you do this instead of that the logical conclusion is that never happens. So you did trap yourself.

---

All of this hair-splitting is unnecessary though, really - everyone here should have known what I meant from the very beginning. Instead, some chose to sift through my words like a pack of lawyers, for no other reason than to claim some hollow victory of semantics.

Touche!

Anyone may do as they are so enclined insofar as using either a main function directly or else by way of some class. Both surely have their own merits and disadvantages, but neither is "wrong", "incorrect", or "bad style". It's all just a matter of preference.

Quote:

---

Originally Posted by gardhr

All of this hair-splitting is unnecessary though,

---

It's not hair splitting. I said "main is not part of a class" and you said "depends".

No, it doesn't depend. It's not part of a class. It's the entry point to every C++ program. That's all. There are no split hairs. It is always there. It's not part of a class. Period.

You didn't say "I make a class that I call from main and have it be the starting point for the remainder of my program."

Quote:

---

Originally Posted by gardhr

really - everyone here should have known what I meant from the very beginning. Instead, some chose to sift through my words like a pack of lawyers, for no other reason than to claim some hollow victory of semantics.

---

I didn't sift through your words. I took the first thing you said in reply to the first thing I said, and the first thing you said was wrong. Period.

Quote:

---

Originally Posted by gardhr

main function directly or by way of some class. Both surely have their own merits and disadvantages, but neither is "wrong", "incorrect", or "bad style". It's all just a matter of preference.

---

WRONG. There is no main "by way of some class".


Quzah.

Quote:

---

Originally Posted by gardhr

All of this hair-splitting is unnecessary though, really - everyone here should have known what I meant from the very beginning. Instead, some chose to sift through my words like a pack of lawyers, for no other reason than to claim some hollow victory of semantics.

---

I can see where you are coming from, but consider GReaper's confusion expressed in post #9 that required clarifications from various people, including yourself. To be fair, quzah's statement was inaccurate too: a function named main can indeed be a member of a class; but the global main function cannot be a member of a class.

Quote:

---

Originally Posted by laserlight

You are proposing that your unusual and unnecessary method of doing things be adopted? How absurd!

Sure, it may be more akin to what ForeverAndOne is used to in Java, and maybe GReaper likewise finds it familiar, but when in Rome, do as the Romans do... at least until you become a Roman citizen and can get away with acting like you are Greek (with all due respect to GReaper :) ).

---

Your method might force the user to declare command line arguments and environment variables (not to mention a useless integer) to be passed along to the object. Mine does not. I have merely simplified a needlessly redundant artifice of C++ programming. How could that possibly be labeled "unnecessary"?

If "acting like a Greek" means being creative and open-minded, sure, I'll go with that. I don't prescribe to anything more than safe, intelligent coding practices. It that's a crime (and in Rome, everything seems to be), so be it. As they say, "I'll follow the Sun".

Quote:

---

Originally Posted by laserlight

To be fair, quzah's statement was inaccurate too: a function named main can indeed be a member of a class; but the global main function cannot be a member of a class.

---

I should have been more precise. The entry point to your program is not part of a class as it is in Java.


Quzah.

Quote:

---

Originally Posted by laserlight

I can see where you are coming from, but consider GReaper's confusion expressed in post #9 that required clarifications from various people, including yourself. To be fair, quzah's statement was inaccurate too: a function named main can indeed be a member of a class; but the global main function cannot be a member of a class.

---

This may have been to the root of the confusion, I suppose. I was referring to the fact that my class defines it's own main function, while the real 'main' is invoked implicitly from within a header file. I thought I was being clear. Perhaps not.

Quote:

---

Originally Posted by gardhr

Your method might force the user to declare command line arguments and environment variables (not to mention a useless integer) to be passed along to the object. Mine does not.

---

That isn't actually an advantage, and there would not necessarily be a "useless integer" passed with what I stated as more common in post #10.

Quote:

---

Originally Posted by gardhr

I have merely simplified a needlessly redundant artifice of C++ programming. How could that possibly be labeled "unnecessary"?

---

I don't see how it is "a needlessly redundant artifice" to begin with.

Quote:

---

Originally Posted by gardhr

This may have been to the root of the confusion, I suppose. I was referring to the fact that my class defines it's own main function, while the real 'main' is invoked implicitly from within a header file. I thought I was being clear. Perhaps not.

---

You did not state the details earlier, so that was not clear, though I understood that you were not saying that there would not be a global main function at all. However, to someone with less knowledge of C++, it would and did seem that you were saying that there would not be a global main function. That's unfortunate, but having been clarified, so be it.

Quote:

---

Originally Posted by gardhr

the real 'main' is invoked implicitly from within a header file.

---

What exactly do you mean by this? I understand it to mean that you define the main function in a header file that is included in exactly one source file.

Quote:

---

Originally Posted by laserlight

You did not state the details earlier, so that was not clear, though I understood that you were not saying that there would not be a global main function at all. However, to someone with less knowledge of C++, it would and did seem that you were saying that there would not be a global main function. That's unfortunate, but having been clarified, so be it.

---

Agreed.

Quote:

---

Originally Posted by laserlight

What exactly do you mean by this? I understand it to mean that you define the main function in a header file that is included in exactly one source file.

---

Correct. From the header file, 'main' invokes a virtual function on a singleton pointer to the program's sub-base-class which then propagates the parameters to the actual (CRTP) base class, which is customizable via a 'traits' parameter (optionally) specified by the final derived class (to control the underlying container types to be used, etc; in case you want to use a map-type interface for the environment variables or what have you).