C++Extra (Add-on) (New!) (Please try!)

[N36fSL3A]

I did it once upon a time, but realized it was useless.

The only time you wait is when a large file is being loaded. (Never had any loading times over 1 second.)

EDIT: Forgot closing parenthesis.

[3qX21hU5]

Ohh lay off him DTS.

Please tell me where in this post you see him telling people he can do something he cant? Please don't say

load() - Adds a short, but effective loading screen

because that might not have been a proper loading screen and it might not be what you thought it was but that is a far stretch from saying he can do something he can't.

Or where do you see him saying anything more then asking for a review and letting anyone who wants to use it use it.

Don't mean to get on your case but damn give it a break you guys are reading into this way to much.

I have created my own custom little add-on like thing for c++, called C++Extra it adds lots of new features!

C++Extra (Version 0.01)
http://www.filedropper.com/cextra

I hope it helps you alot! Please reply feedback and anything I should add!

Planned Features:

Make the load() command be customizable, for example
a border around it or not.

var() - You type the variable name between ( and ) and
it will created a variable called that.

print() - It is cout but more easyer to type, just type text
in the ( and ).

wait() - Type a number of mili-seconds to wait between
( and ). It basically waits for the number of mili-seconds.


Current Features:

clear() - Clears the console
load() - Adds a short, but effective loading screen

[N36fSL3A]

Quick way to make the print command:
#define print printf

[giblit]

I think his print is different than printf

It probably looks similar to this

#include <iostream>
void print( std::string ); //or char pointer I guess

int main()
{
    std::string str = "Hello world!";
    print( str );
}

void print( std::string input )
{
    std::cout << input << std::endl;
}

*added int main to code

[JLBorges]

> If I was on the fourms when you posted your first program like hello world.
> I wouldn't of mocked you and said it was stupid and useless.
> I will work on it ALOT more and probably repost this topic.

Next time, don't post your stuff in the lounge if you are looking for useful feedback on your code. (The 'Beginners' section would be appropriate.) I would expect that the majority of responses there would be far more constructive and meaningful than what you encountered in the Lounge.

[CplusplusAcolyte]

As another beginner, I can say that creating one's own functions to perform various activities has it's advantages. I myself have created similar functions within my header file for my own convenience. Example:

void Color(int color)
{
    //sample usage: Color(7); (7 is default color)
   HANDLE hCon=GetStdHandle(STD_OUTPUT_HANDLE);
   SetConsoleTextAttribute(hCon,color);
}

Still, while I may find it more convenient to type "Color(192)" or whatever than the entire SetConsoleTextAttribute command, it's not exactly revolutionary and may only confuse others. Similarly, I also created a clear function and random function that simplifies the range involved. You guys make a good point that in many cases specific libraries may do a better job of some of these things, but creating functions to simplify existing functions can be a convenience for beginning programmers. Of course, as JLBorges said, it was probably more appropriate for the beginners forum, though.

[giblit]

Well you kind of necro'd a post :P but anyways you may want to invest some time into enums CplusplusAcolyte

Something like this

enum Color { DARKBLUE = 1, DARKGREEN, DARKTEAL, DARKRED, DARKPINK, DARKYELLOW, GRAY, DARKGRAY, BLUE, GREEN, TEAL, RED, PINK, YELLOW, WHITE };

Then you can do

void Color( Color color )
{
    HANDLE hCon = GetStdHandle( STD_OUTPUT_HANDLE );
    SetConsoleTextAttribute( hCon , color );
}

And call it like this

int main()
{
    Color( RED );
    std::cout << "Hello world!" << std::endl;
    Color( GRAY );
}

[Disch]

Just to chime in... you should avoid all caps names for things. All caps implies a macro. And since macros do not obey language scoping rules... it's best to just let them have that as their "thing".

[LB]

@giblit your solution does not allow setting background colors

[giblit]

Yeah. I wasn't trying to change background color. Also I thought you named constant variables , enums , and macros all caps to show that they are read-only thanks for the tip @disch

*typo

[Albatross]

@Disch

Doesn't that vary depending on the convention you're following? I've seen code that prefixes macros with two underscores and uses allcaps for constants.

-Albatross

[Disch]

@ Albatross


Yeah.... but the widespread accepted style for macros is that they're all caps. Underscore prefixes are not super common from what I've seen... but just about every macro in every lib I can remember using were all caps (apart from WinAPI's min and max and their whole TCHAR fiasco).

(EDIT: Then again WinAPI does a lot of all-caps for other crap too, so it's probably not a great example)

IMO it's kind of like an unwritten rule. And it pays to follow it because stray macros are not at all guarded against by the language.

A simple rule "all caps for macros and nothing else" goes incredibly far in avoiding macro collisions.

[Albatross]

@Disch

In that case, how do you typically see constants indicated?

-Albatross

[Disch]

It varies.

Quite frankly I don't see much reason to distinguish constants from non-constants (EDIT: in the naming convention). The usage of the variable and/or its name is usually a pretty clear indication of whether or not you can modify it.

maxAllowedSize - probably constant
currentSize - not constant
SIZE - probably a macro

[chrisname]

@Disch
Personally I only use all caps for macro constants, but I thought it was a common convention for the names of all kinds of constants to be capitalised.

Also, I almost exclusively use macros for stuff like conditional compilation. I avoid macro functions and macro constants as much as I can because they don't obey any kind of scoping rules. I wish the standard library used enum constants instead of macros, then things like EXIT_* and SIG* would be in namespace std.

[BHX]

@Disch
You should point out that is your preference and not make it sound like it is a set rule. There is no set rules for coding style. It is up to programmer preference and it may be his preference to use caps. Some programmers do constants, class names, struct names, macros, and globals in capitals. While others, like yourself, think that all caps is only for a macros or such.

For example:

enum Color{
	COLOR_BLACK,  // could have set COLOR_BLACK to say 10 then the others would have been +1 
	COLOR_RED,
	COLOR_BLUE,
	COLOR_GREEN,
	COLOR_WHITE, 
	COLOR_CYAN, 
	COLOR_YELLOW,
	COLOR_MAGENTA
};

enum ParseResult{
	SUCCESS = 0, 
	ERROR_OPENING_FILE = -1, 
	ERROR_READING_FILE = -2, 
	ERROR_PARSING_FILE = -3
};

bool OpenFile(){ return 0; }
bool ReadFile(){ return 0; }

ParseResult ParseFile()
{
	if(!OpenFile())
		return ERROR_OPENING_FILE;
	if(!ReadFile())
		return ERROR_READING_FILE;
	if(!ParseFile())
		return ERROR_PARSING_FILE;
	return SUCCESS;
};

[Disch]

Yes it is personal preference... but it's also wide-spread acceptance.

To further clarify... in most libraries, all caps denotes a macro. And since there are literally no in-language protections against macros collisions other than choosing a different name.... picking an all-caps name for something increases the risk of colliding with a macro name.

It's frowned upon for the same reason using namespace std; is frowned upon. Only the consequences for macro collisions are much worse, because at least with std collisions, you can still work them out with scoping rules. Macros have no scoping rules, so if you collide, you're boned.


So yeah... you don't have to do it... but you should. And yes that is personal opinion, but it's not just personal opinion.


EDIT:

To further drive my point... here is an off-the-top-of-my-head list of libs which use all-caps for macro names:

- C and C++ Standard libraries
- zlib
- libpng
- OpenGL
- SDL
- Boost

EDIT3:
- vorbisfile
- directX
/EDIT3


EDIT 2:

enum ParseResult{
	SUCCESS = 0, 

This is especially bad not only because it's all caps but also because it's a common word which is likely to be a macro in some lib.

[BHX]

Yes, but wide acceptance doesn't make it a set rule either :P. Also the using namespace is frowned on, but every beginner tutorial and book ends up having you use it without mentioning how bad it is. This is one of the cases where taking the easy way of doing things will bite you in the butt in the end. You teach them that it is easier to do using namespace std; and seldom have I found programmers that end up willingly moving away from that to do one of the variants std::cout << "Text!" << std::endl; or using std::cout; using std::endl; using std::cin;.

[EDIT]
Could do like learncpp.com does and put the using namespace std; in the scope of all functions and main().

[N36fSL3A]

I always use std::<insert object> mainly because I don't know everything about the STL, and I don't want any redefinition errors.

I never, ever, not even with my own namespaces, use "using". I'm not planning on it either.

[giblit]

There is nothing wrong with the using keyword.

What errors would you have with this lumpkin:

#include <iostream>

int main()
{
    using std::cout;
    using std::endl;
    cout << "Hello world!" << endl;
}