// I'm going to explain something, and I just want to know if that something exists. This is just to increase my understanding of C++ capabilities.
// As a simple example, let's say I want to take the line of code: std::cout << <x>(ignore the <x> for now) and make it so that I only have to type maybe just a word I define(I think that would be considered a macro, but I don't know) except there is something I can add after that word in order to fill the space between for <x>(not to say that '<' and '>' would be used).
// Let's pretend I knew the syntax and this is what it was. First, say I define the macro-ish thingy as EZCOUT, then to adjust it for that <x> I type it as: EZCOUT("Hello World!" ;)
so that it would basically just turn it into: std::cout << "Hello World!" ;
// Anyway, does this sort of thing exist? Based on the way the language is designed I would think so. Could you create something like this for your own use in some way? If this kind of thing wouldn't work I'd love to know why, even if it's a bit advanced I'll try to decipher it.
Is that what you are looking for? I'm not sure if it's only functions that can be created as such, or if we can get away with a cout call or not.
I wonder why not just make a function to do that though? I'm very new to this myself, but macros seem to be warned against their overuse in c++, but creating a function to handle it seems entirely feasible to me (fwiw).
I've often take similar approaches in VB, creating your own function to easily wrap something that can already be implemented but is a little more of a pain through the native methods. From what I gather, in C++ you would create a header and corresponding source file to define the function, then #include that header from the source you want to implement it in.
I would suggest a function: it's what they're designed to do. From what I gather, working with macros is sort of a way of "working around the natural flow of things" - apparently they have disadvantages when trying to implement them with classes.
// I have most definitely learned a lot(and more than just a solution to the beginning thought), especially nice to see simplified code that shows exactly how to "do" certain things. Mission accomplished!
// Don't worry about the EZCOUT being longer than cout, the code was hypothetical and shortened for a simpler use of the example since I would guess you could use these shortcut-words on longer pieces of code. That "Better:" you have there Athar is quite cryptic with it's template and uses of the & sign, both beyond my learningz, but the rest makes sense.
// Optional Question: Logically it sounds like that using #ifndef before #define is good practice and of course needed in situations. Though I wonder, in a situation where you are sure it wouldn't have to check and therefore not need any #ifndev... would it be wiser to leave out #ifndef? Does that extra step of "checking" take a certain amount of memory/time/resources/something, and can I check that myself with a sizeof() thingy or is sizeof() very specific?
Athar is quite cryptic with it's template and uses of the & sign, both beyond my learningz, but the rest makes sense.
Google"c++ templates" - one of the first results is a link to the tutorials section of this site which explains the syntax behind the function and class templates (the & I'm still working on). This prompted me to start this thread:
Though I wonder, in a situation where you are sure it wouldn't have to check and therefore not need any #ifndev... would it be wiser to leave out #ifndef?
It's there, so it must take a likely insignificant amount more time to check than not to check, but I personally wouldn't count on any situation where we are "sure" that it won't be needed. Three years down the road when you unexpectedly use this in a seperate project, you would be quite happy with yourself if you took the extra time to add it in the first place instead of having to go back and add it later (at that point making sure that it doesn't screw up any of your other code). As a rule, I never plan on "never".
// Well thank you for the directions, buut the tutorials here are a barrier to me with my lack of terminology understanding heh.
// Totally no offense but when it comes to non-specific words like "insignificant" I'm afraid I can't do with just that, too much ambiguity in the sometimes seemingly flawed language of English. I've also seen arguments/debates over all sorts of things for programming such as significance, so when I get told something without details I quickly imagine that someone somewhere would have a counter-point and disagree.
// I like to see things in all possibilities(especially since programming will be my life and career, so knowing all about how much memory, no matter how small, will be used how, why, where, and etc for, say, programming on a very limited amount of memory for maybe robotics or something it'd be important...and yes I understand C++ isn't for that I've heard but I plan on using C++ as my first main foundation of understanding programming in all forms).
// LOOK: The following contains a lot of questions that aren't really questions and I'm not asking for answers unless you'd want to out of pure free will or for just conversation. Hmm but is that allowed, and is questioning things to myself out loud in my own topic allowed? Hmmmm....
// As for a situation where you would always define something, I thought I've heard of one so far. Something that would be used in a sort of main beginning file(is that what a header file is I wonder?)... I'm guessing you'd define something sort of globally among all other files if that's what it does, and then I wonder if you could "not" include them in places where you specifically didn't need it.. or something like that.
// In the long run though, no matter how insignificant the difference, I would think that the less times you have to define something that will be re-used the better, especially if the files that needed it outnumbered the files that explicitly said "no don't use this". Then again I wonder how much memory saying "don't use this" would take, and if it'd be reasonable to not check before(I mean, is it necessary to say "if this is defined, undefine it" or just say "un-define this".. unless un-defining something that isn't defined is an issue. Ah, so many wonderingz...
Fair enough, but as beginners we should probably concern ourselves with the basics (terminolgy like that found in the templates tutorial, for instance) before we concern ourselves with the inner workings of compilation and runtime semantics. I'd be willing to bet that to us, as beginners, "insignificant" is in perspective with what we need to be immediately concerned with. Sure, it's a relative word, and I fully understand your points and desire to learn, but in this case I think it fits for us. When we find ourselves more experienced and researching concepts such as making blazing-fast applications, then it would certainly be taken out of the "insignificant" (and at that point, function and class template and their terminology will be our second-nature).
Anyway, don't get me wrong, I understand your points completely, but at heart I love a good debate, and this is something I feel strongly enough debating :) I'm self taught in VB, and have done quite well with it I think, and a lot of what I learned about how to learn a language through trial and error can apply here.
Logically it sounds like that using #ifndef before #define is good practice and of course needed in situations.
That has nothing to do with good practice. This pattern is called an include guard and without #ifndef it wouldn't guard anything at all. When you include the same file twice in the same compilation unit, you'd normally get a lot of problems. The include guard checks if a certain macro has been defined using #ifndef (=if not defined) (e.g. _EZCOUT_H_) and if not, the enclosed block is parsed by the compiler. If not, it is skipped. Inside the block _EZCOUT_H_ is defined (using #define), so any future inclusion of the same file will have no effect due to the #ifndef check now failing.
Nohbdy wrote:
and can I check that myself with a sizeof() thingy or is sizeof() very specific?
sizeof is something completely unrelated, so I'm not sure what you mean.
@ OP: Although I applaud your conservative outlook at memory allocation you should be aware that it doesn't make a difference when you're talking about individual bytes or even Kilobyte differances in the memory foot print.
Although it is Windows specific this guy has some very good generic information on how modern day operating systems handle memory allocation:
The short and simplified version is this, memory is allocated in chuncks, called pages and books, at a time not individual bytes as needed. So if you go even one byte over the size of the default allocation your program gets a whole new page dedicated to it's use. Also check newegg or amazon, memory is cheap and gets cheaper ever week.
You mentioned robotics and I can tell you from experiance that memory management is important but bad programming practices have a greater negative impact on this then the libraries and header files that you use.
// Athar: #1a: What I thought I meant by good practice was, well it seems like you can use #define without using #ifndefine... and I would think good practice such as "Well, this isn't complicated and I don't need to check before defining this... but I should do that just out of forming a good habit." #1b: All this talk about multiple files, even just a header file, is still advanced to me btw. Anything anyone mentions about it other than what I have spoken to understand isn't entirely clear to me. #2a: I think you're looking at it wrong xP, because when I use words like "thing" it's to point out I don't know what I'm talking about. What I'm asking for is if I can use sizeof() to see how a #define thingy uses memory(or whatever else there is) because sizeof() is the only thing I know that has anything to do with those kinds of measurements so far.
// jleach: #1a: First of all, I'm very glad you enjoy debate because I sure do too. It seems to always be an educational experience no matter what. #2a: The whole "terminology" is what I've been focusing myself on for quite a while, I just seem to do better at understanding concepts and general ideas over specific usage but I am not trying to. I can't understand the tutorials here because of it's use of terminology starting from the beginning, I just can't learn well from these tutorials at all, no offense to whoever made them! #2b: My current goal is mastering the basics(also, I keep seeing templates in advanced sections, and since I barely have a good understanding of functions and classes I really don't feel ready to move onto that) so understanding as in-depth as I can about each basic thing will help me in the long run I think. Believe me, I'm about ready to start trying out assembly any day just out of curiosity... besides I also would like to be fluent in assembly, and of course understand a good amount of machine code even.
// Computergeek01: #1a: Definitely going to check that info out soon. #2a: The "memory is cheap" thing is funny, because a big issue is money. I have zero money except for the rare 10-20 dollars every few months which usually goes to food. We can't afford our phone(almost not our electricity/water) so that should give you a better idea lol. My computer has 256mb 1.4ghz(something like 16mb on the video card memory) RAM and everything else old as well(About all my computers are found in dumpsters). Memory, along with other things, are very expensive to me. And yes I'm still looking for a job, but the 18 applications to different places haven't done much. I'd like to add though, even if I had a supercomputer I will always care about memory efficiency, and I believe an understanding of how to make even the simplest of programs memory efficient will help me with programming practices, wouldn't it?
// I type a lot don't I? I hope that isn't a problem in my own topics ^.^ eheh X.x
You seem to think that #ifndef only applies to the #define that follows it. That is not the case. If the specified macro is defined, everything between #ifndef and #endif will be skipped.
#ifndef/#define are preprocessor directives, by the way. The preprocessor is run even before the compiler, so there is no way they could have a direct impact on memory usage or anything else in the final program (other than the result of their actual function).