Cmd-- 1.11

Pages: 123... 6
Hello Everyone,

About a month or two ago, I decided to create a generic framework for building command line programs in C++, which eventually grew into Cmd--. Cmd-- allows users to create menus with only a single line each. It also contains my Functionalize! function repository, with some interesting tools that I wanted to have generic access to. The current version should be complete enough for general use, and is documented as of version 1.10

Cmd-- on Github:

The current example was made as a reboot of a previous program of mine called Delta-Vee!.

Please enjoy, and leave any questions, comments, suggestions, concerns, etc. here for me.

Hail the Probe 2013 ;)
Last edited on
This should be in the lounge - edit your topic (not the post) and move it to the lounge.

You should probably go through and reformat your code. There are automated tools that can do this for you (such as AStyle).

Excerpt from TCmdMenu.cpp:
void TCmdMenu::menu()
{	nswitch = 1;
	string i;
	while (true)
	{	if (nswitch == 1)
		{	cout << "--" << menuname << "--" << NEWLINE << NEWLINE;	}
		nswitch = 0;
		i = TCMD_Input_string_with_tab("");
		transform (i.begin (), i.end (), i.begin (), toupper);	
		if (i == "")
		{	cout << TAB;		}
		if (i != "")
		{	if ((TCMD_Compare_string(i, "QUIT") == true)||(TCMD_Compare_string(i, "E") == true)||(TCMD_Compare_string(i, "Q") == true))	// Checks for the direct shutdown
			{	DirectExit();	}		
			else if ((TCMD_Compare_string(i, "HELP") == true)||(TCMD_Compare_string(i, "H") == true))	// Checks for the menu help command
			{	cout << NEWLINE << endl;
				cout << NEWLINE;	}
			{	for (stringit = (Stringlist.begin()); stringit != (Stringlist.end()); ++stringit)																	
				{	bool isrel;												
					isrel = TCMD_Compare_string(i, *stringit);
					if (isrel == true)
					{	int c = 99;
						c = Execute_Function(i);
						if (c == 0)
						{	for (it = (Linkslist.begin()); it != (Linkslist.end()); ++it)					// Checks the linkslist of all defined menus to send the user
								{	bool isref;																	// on their way
									isref = TCMD_Compare_string(i, ((*it)->menuid));
									if (isref == true)
									{	cout << NEWLINE;
										(*it)->menu();		}	}	}
							else if (c == 1)
							{	nswitch++;
								continue;	}
							{	continue;
								cout << NEWLINE;	}	}	}	}
							cout << NEWLINE;	}	}	
					cout << NEWLINE;	}
Needless to say, I was unprepared for the horror that awaited me. I don't know about the quality of the code because the formatting is too distracting.

Also, IteratorRef.h is not safe for inclusion in multiple cpp files.
Last edited on
Okay, but why does it matter? None of the TCmdMenu code should ever need to be edited on a program to program basis anyways?
You're basically asking why it's important to format code :p
Okay, but why does it matter? None of the TCmdMenu code should ever need to be edited on a program to program basis anyways?

One day you're going to look back on this and have a chuckle at your naïveté.
Well yeah, in C++ it shouldnt really make any difference, although Python and other languages can be sensitive to formatting. In this case, I dont see why it should be such an issue though, none of the core stuff is meant to be edited, as it works fine right now. If you check the testrun.cpp file, it should show you how to use the framework for a bigger project.

Not that this will be perfect mind you, Ive only been coding for 8 months or so now, but I do have a strong enough grasp of the C++ language to be able to know that it does work. The basic concept is that menus are created as objects, whose pointers are scanned against user input in order to jump back and forth quite easily.
It will make a difference, trust me.

You aren't going to get very far with that setup.
@ Bruce: you're deviating from the norm, that's all. Your style is idiosyncratic, so people tend to reject it. If it works for you, then fine.
I totally agree with cire. The only programs that never need to be modified are the ones that are never used.

Take this as friendly advice: Pick one of the styles on this page (preferably K&R, Allman, or BSD, as those are the most popular) and stick with it. Unless you never, ever, ever expect to work with anyone else, writing code as if you were throwing up onto the keyboard is simply unacceptable. The excuse "it will never be modified/the compiler accepts it" is only valid for machine-generated code. Eventually all code needs to be modified and/or understood by a human being.
closed account (S6k9GNh0)
Just sayin', in this case, it doesn't matter.

I don't think it's the indentation style that's the issue, it's just the method of if/else branching.

If you have a line of code that has more than 4 or 5 tabs, then perhaps you need to refactor that code. I used to use vim a lot for personal projects and my code would never reach passed the end of the page even though I used 8-space hard tabs. Unfortunately, when I started trying to contribute to projects, I found most people didn't follow this methodology at all... and found some lines that had 8 or 9 tabs which is in my honest opinion, idiotic.

I couldn't care less about curly brace styles. I often feel like they just make my code ugly.
Last edited on

Somebody please save me from the cult of the "real programmer" ;)

@L B, Will check out that tool you mentioned, or do the formatting manually if you feel it helps. I still prefer writing my code in the above style, but I don't see much point in making an issue of it. Thanks for the heads up.

@Pretty much everybody who found issue with the formatting in general,
Yes I get the message, but has anyone actually tried using the Cmd++? The whole point of this was to allow for much easier menu-building; is it helpful?
@helios, took a look at the various coding styles, how does whitesmiths style sound? The only thing I cannot stand is the K&R style, since it makes code damn unreadable in my opinion, with minor formatting advantages at best.

Edit: interesting note, it appears that what I was using was the "Pico Style". I still like it, but maybe the Horstmann style could be reasonable enough, what with at least giving all of those closing braces their own lines.
Last edited on
Bruce its as simple as this,

Does your code achieve want you wanted? Did it do what you needed it to do the way you want it to be done? How you want it to be done? then it as served its purpose. ITS AS SIMPLE AS THAT. All that other stuff in the end of the day bs. It doesn't matter. The only question beside the ones I listen above that you might want to ask yourself is.

Will you expand on your already existing program? If not then your done and the job as been fulfilled. If yes then you might want to see how you can reduce anything that you feel can be taken out. This has nothing to with stupid styles and all that other nonsense because in the end of the day you're making this for yourself. If you were working for someone then you would have to code it the way they wanted. You're not. So it doesn't matter.

If this help someone out there then people will use it simple as that, and people who don't won't.

In the end of the day computer programming is about bring your idea and making it come to life. How you go about doing it doesn't matter as long as it fulfills this three question.

Does your code achieve want you wanted?
Did it do what you needed it to do the way you want it to be done?
How you want it to be done?

Also to the people saying how when looking back on it in the future.... you can say that no matter how he changes it. in the future he will be better and the way he codes will be far different. Look at your first program you ever coded right now. i bet you will smile to yourself and say, " Wow I have came a long way since then."
Last edited on
I agree Stormhawk. Nice.
Haha thank superdude.
Bruce its as simple as this,

I would tend to avoid posts that say "My opinion is better or more relevant than that of others because it is a feel-good post, despite the fact that it has no substance."

It's all friendly advice. Take it or leave it. It's as simple as that.
I never said it was better or worst. When I said its as simple as this. What I meant what was;

At the end of the day it comes down to this. or you can think of it like

At the core of programming what is it really?

Think of it this way. A t-shirt is just a t-shirt at the end of the day. The styles you put on it are just the stuff on the surface. Its all fluff.

My opinion or your opinion are no better than one another. They are just different path one can take to get to their goal. Bruce will always have the final say in what path he will take in programming. All I am trying to do is show him that there is more then one path you can take to get to your goal. Because you get a lot of people on the internet who are the more out spoken people that like to say," DO IT MY WAY BECAUSE ITS RIGHT." I am not saying you are like that but I see it a lot.
closed account (S6k9GNh0)
I find that ironic. People generally give advice based on experience. The "DO IT MY WAY BECAUSE ITS RIGHT" approach is usually not posed in a way that tells him to do something but in the form of advice given the context.

You went out of your way to say that people shouldn't do that and then did it yourself just by explaining that people shouldn't do that.

Not that I completely disagree with you but may I advise some consistency.

On a separate note, my personal coding style is considered horrendous by some but I find it the most readable and sensible. I hate things that are spread out when most people tend to like the opposite because people equate space to readability.

On another separate note, it does actually matter the manner of which something is coded, especially when it affects functionality. For instance, it's constantly advised that you do not use system() as it's a security hole and not consistent across platforms. But given your logic, you could say, "Forget these guys who tells you whats right, do what works best!" I'm hoping I don't have to explain why that's bad.
Last edited on
Stormhawk wrote:
I never said it was better or worst.
Stormhawk wrote:
All that other stuff in the end of the day bs. It doesn't matter.

Sounded a lot like you were dismissing previous advice as "bs" that doesn't matter. And since you went on to expound on that in a manner that is consistent with that interpretation, I don't believe I misinterpreted it.

It is helpful on programming sites to have your code looked at with a critical eye. It is not so helpful to have one look at it and say, "Does it get the job done? GOOD ENOUGH!"

One hopes most will aspire to a higher standard.

Think of it this way. A t-shirt is just a t-shirt at the end of the day. The styles you put on it are just the stuff on the surface. Its all fluff.

An inappropriate T-shirt in some workplaces can cost you a job.
That t-shirt example is ridiculous. It's got nothing to do with making code pretty or style or whatever, it's about quality, legibility and maintainability.

The point is that if you don't use a consistent coding style, not only will others find it hard to understand and modify your code--which might be a barrier to you getting help if you ask for it at some point--but, after a break of a few days or weeks, you will find it hard to understand and modify.

Not only that, but code that is written in a deliberate manner with attention paid to clarity, correctness and maintainability, is of higher quality than code that isn't. There will be fewer bugs, and when there are bugs, they will be easier to spot because your code will actually be legible. And, if you ever end up with a job in the software industry (god help us), and you write crap code, and you tell your boss "It doesn't matter that no-one else on the team can read it because it works", you will lose your job. And you'd deserve it for perpetuating the well-deserved reputation that commercial software has of being poor quality and full of bugs.

Take pride in your work, even the presentation, and your work will be better.

p.s. It's not that your code is ugly that's the problem, it's yours and Stormhawk's attitude towards it that is. Everyone writes ugly code when they start out, but the people who turn into good programmers are the ones who strive to make their code better.
Pages: 123... 6