Variables | Pointers in arguments really needed?

Code:

---



      class Database {
 public:
 std::string Query;
 void SendQuery(std::string,&Database); // Would this be faster?
 //Reminds me of like a wildcard variable/pointer/reference thing

 // or

 void SendQuery( std::string Query, Database& db ); // or would this be faster?

}

---

Not sure what your two choices really represent. The actual code in alternative 1 is incorect:

Code:

---

void SendQuery(std::string,&Database);

---

, you probably mean:

Code:

---

void SendQuery(std::string,Database&);

---

If my "probably mean" is what you actually mean, then this:

Code:

---

void SendQuery( std::string Query, Database& db );

---

is exactly the same - the only difference is that you give anyone (including yourself) reading the function prototype a clue as to what the string (and to some extent) argument(s) are referring to.

There will be absolutely no difference in speed whether you mention the parameter name or not, nor will the compiler produce any different code if you put the same or different names for the parameters in different places where they are mentioned [but it helps us humans that have a more complex associative memory than the compiler to understand that we really mean the same thing if it's called the same thing across different points].

--
Mats

Quote:

---

Originally Posted by matsp

Not sure what your two choices really represent. The actual code in alternative 1 is incorect:

Code:

---

void SendQuery(std::string,&Database);

---

, you probably mean:

Code:

---

void SendQuery(std::string,Database&);

---

If my "probably mean" is what you actually mean, then this:

Code:

---

void SendQuery( std::string Query, Database& db );

---

is exactly the same - the only difference is that you give anyone (including yourself) reading the function prototype a clue as to what the string (and to some extent) argument(s) are referring to.

There will be absolutely no difference in speed whether you mention the parameter name or not, nor will the compiler produce any different code if you put the same or different names for the parameters in different places where they are mentioned [but it helps us humans that have a more complex associative memory than the compiler to understand that we really mean the same thing if it's called the same thing across different points].

--
Mats

---

Thanks man, and by the way, I didn't know where to put the reference symbol there because there was no variable name ( as there is in the second example ). :]

Oh, and if you don't change the Query within SendQuery, make it

Code:

---

void SendQuery(const std::string& Query, Database& db );

---

That way, when the compiler calls SendQuery, it doesn't have to make a copy of the Query string itself[and it that query is anything like some of the longer ones I've made in my life, that could save quite a lot of time, as it could possibly get into the kilobytes range].

--
Mats

Quote:

---

Originally Posted by matsp

Oh, and if you don't change the Query within SendQuery, make it

Code:

---

void SendQuery(const std::string& Query, Database& db );

---

That way, when the compiler calls SendQuery, it doesn't have to make a copy of the Query string itself[and it that query is anything like some of the longer ones I've made in my life, that could save quite a lot of time, as it could possibly get into the kilobytes range].

--
Mats

---

Thanks. I still have to get use to const's. ;P although they remind me of REAL constants ( #define CONSTANT ) :P I'm from PHP sorry ( Although in advanced php programming, you can still make a constant member like so: CONST myConstant = "You have to initialize constants in oop php no matter, otherwise it gives you a error", that's the only known keyword I know from PHP that uses const so )

The pointer symbol (*) and the reference symbol (&) is placed after the type.
So if the type is int, it becomes int* or int&.
If the type is Database, it becomes Database* or Database&.
If the type is std::string, it becomes std::string* or std::string&.

Simple enough.

Quote:

---

Originally Posted by Elysia

The pointer symbol (*) and the reference symbol (&) is placed after the type.
So if the type is int, it becomes int* or int&.
If the type is Database, it becomes Database* or Database&.
If the type is std::string, it becomes std::string* or std::string&.

Simple enough.

---

-_- Well I am a bit confounded about Pointers still. I mean, I feel like no one would give me a good answer to them, otherwise references are easy to understand, they just get the object of the variable.

It's like you need to experience pointers to understand them profoundly.

References are typically good for arguments to functions, but as class members, for example, their usefulness drops significantly because they cannot be reassigned.
A good thing to try to strive for to learn: use references whenever you can. If you can't, then use pointers. Try it and you'll find situations where pointers are the only solution.

As for understanding how they work, that's the work of books and tutorials.

Quote:

---

Originally Posted by Elysia

References are typically good for arguments to functions, but as class members, for example, their usefulness drops significantly because they cannot be reassigned.
A good thing to try to strive for to learn: use references whenever you can. If you can't, then use pointers. Try it and you'll find situations where pointers are the only solution.

As for understanding how they work, that's the work of books and tutorials.

---

Hmm, well someone ( forgot) in that other thread "Specifically need to use pointers .. etc" said that the value of the variable is really the only memory, so it's like if you have a pointer, and that variable doesn't have a value already placed, then it's forced as memory allocation? hmm Would that be a reason for pointers?

If you would really like a detailed explanation of pointers, you can look to these references:
http://www.eternallyconfuzzled.com/t..._pointers.aspx
http://cpwiki.sf.net/Pointers

Pointers are useful for memory allocation, yes. Since pointers hold a memory address, you can keep track of, and browse, a block of memory. Examples of memory allocation would be strings, or vectors of objects, which definitely employ pointers to store data.

A pointer is not special in any sense. It's just a variable, just like all other variable types which are non-pointers. So in that sense, pointers do take memory, just like any variable.
The only "special" thing about pointers is that they store memory addresses. But that is all they do. They do no allocate memory in any way (contrary to many beliefs).
Therefore, defining a variable consumes about 4 bytes of memory (on the stack). However, what the pointer points to is not guaranteed to be owned memory (allocated memory). Therefore you have to either point the pointer to an existing variable, or allocate some memory using new. Then your point is valid.

Quote:

---

Originally Posted by citizen

If you would really like a detailed explanation of pointers, you can look to these references:
http://www.eternallyconfuzzled.com/t..._pointers.aspx
http://cpwiki.sf.net/Pointers

Pointers are useful for memory allocation, yes. Since pointers hold a memory address, you can keep track of, and browse, a block of memory. Examples of memory allocation would be strings, or vectors of objects, which definitely employ pointers to store data.

---

Oh man this is awesome, very helpful citizen!

Thank You!

I wish we still had that thanks button. :( I have the urge to so badly.

Code:

---


int main()
{
        int test = 100;
        int t = *(&test);
        std:: cout << t << std:: endl;

}

---

I did this, and it worked. so hmm.. From what Elysia said and this, I'm starting to become comfortable with them.

By the way, is the reason you say Pointers are good for speed and such is because they're just storing the addresses of which hold the indirected value? Thus the memory address holds all that data, and you just have to reference it to get the data from it? Neat.

Yes, the same analogy holds true with references. A reference can be a name, an alias for something, and when passed to another function, the name or alias is passed, and not the actual data.

Quote:

---

Originally Posted by Elysia

Yes, the same analogy holds true with references. A reference can be a name, an alias for something, and when passed to another function, the name or alias is passed, and not the actual data.

---

I understand. The code above seemed to take the object ( the reference ) and pass it through the pointer, thus it got the value.

When it comes to speed, pointers are references are essentially equal - a reference, when it gets compiled, gives identical code to the same solution using pointers [1]. The detail differences between pointers and references are mainly in what the compiler allows you to do and what you have to type into your source file to let it know what you want to have happen.

So a reference and pointer (at least when we pass them to functions) will have the same benefits and drawbacks:
1. Passing a pointer/reference passes a pointer-sized element.
2. Dereferencing such a pointer/reference will incur some overhead compared to having the object directly available.


[1] Assuming we're not looking for strange & unusual ways of using either pointers or references, and equal level of understanding from the compiler as to what the code tries to achieve - some compilers occasionally get confused by one or the other concept in some circumstances, but please ignore this for now, I'm just adding this stuff to prevent someone else from contradicting me with regards to details which will just confuse the matter vs. the general rule [Just like when we study physics at a basic level, everything works according to Newton's equations, but once we get deeper into physics, we learn about Einstein's relativity theory, which "break" Newton's rules].

--
Mats

Quote:

---

Originally Posted by matsp

When it comes to speed, pointers are references are essentially equal - a reference, when it gets compiled, gives identical code to the same solution using pointers [1]. The detail differences between pointers and references are mainly in what the compiler allows you to do and what you have to type into your source file to let it know what you want to have happen.

So a reference and pointer (at least when we pass them to functions) will have the same benefits and drawbacks:
1. Passing a pointer/reference passes a pointer-sized element.
2. Dereferencing such a pointer/reference will incur some overhead compared to having the object directly available.


[1] Assuming we're not looking for strange & unusual ways of using either pointers or references, and equal level of understanding from the compiler as to what the code tries to achieve - some compilers occasionally get confused by one or the other concept in some circumstances, but please ignore this for now, I'm just adding this stuff to prevent someone else from contradicting me with regards to details which will just confuse the matter vs. the general rule [Just like when we study physics at a basic level, everything works according to Newton's equations, but once we get deeper into physics, we learn about Einstein's relativity theory, which "break" Newton's rules].

--
Mats

---

Well it seems that way.

It seems references must rely on pointers. soo...


Off Topic:

Why do they call you the kernel hacker? :P

Ironic since the kernel handles the memory. xD

Quote:

---

Originally Posted by bobbelPoP

Off Topic:
Why do they call you the kernel hacker? :P

Ironic since the kernel handles the memory. xD

---

Well, technically it is myself that calls me a Kernel Hacker, but in the last many years, I have spent most of my time dealing with code that one way or another operates within or in close conjunction with OS kernels, working on Real-time OS's [at a commercial level at least three different ones], Linux and Windows. In Windows I worked for a graphics card producer, writing the Windows Driver for the graphics card [mostly dealing with Low-Level driver stuff, rather than the more interesting 3D side of things], in other work I have been working either for a processor manufacturer or the OS manufacturer.

--
Mats

Quote:

---

Originally Posted by matsp

Well, technically it is myself that calls me a Kernel Hacker, but in the last many years, I have spent most of my time dealing with code that one way or another operates within or in close conjunction with OS kernels, working on Real-time OS's [at a commercial level at least three different ones], Linux and Windows. In Windows I worked for a graphics card producer, writing the Windows Driver for the graphics card [mostly dealing with Low-Level driver stuff, rather than the more interesting 3D side of things], in other work I have been working either for a processor manufacturer or the OS manufacturer.

--
Mats

---

Awesome. :D

I have messed with the windows kernel functions. :P Like WriteProcessMemory ( writes memory to a process ) and ReadProcessMemory ( reads the processes memory ) from the winapi ( msdn helps ) but that's about it. xD

They aren't Windows kernel functions...
Kernel functions are those functions that can only be called from code running inside the kernel (like drivers).
Or in other words: low level operating system functions.

Quote:

---

Originally Posted by Elysia

They aren't Windows kernel functions...
Kernel functions are those functions that can only be called from code running inside the kernel (like drivers).
Or in other words: low level operating system functions.

---

kay. :P that is all.

Quote:

---

Originally Posted by Elysia

They aren't Windows kernel functions...
Kernel functions are those functions that can only be called from code running inside the kernel (like drivers).
Or in other words: low level operating system functions.

---

Sort of correct - but I would call them Kernel API functions, and whilst ReadProcessMemory() in itself doesn't call directly into the kernel [it goes through a API translation layer], it will directly cause kernel code to run and perform the requested operation [if allowed].

Some API calls may of course not enter the kernel at all - they may be part of the user-mode side of the API and fulfill the entire functionality in user-mode.

--
Mats

Speed of your parameter passing will be negligible compared to actually running a database query.

Quote:

---

Originally Posted by medievalelks

Speed of your parameter passing will be negligible compared to actually running a database query.

---

Yes, quite likely. But saving time [with zero loss of functionality] doesn't hurt, does it?

--
Mats

No, I'd just rather have my engineers focussed on optimizing their DB queries, caching of results, threading, etc. than trivial issues like this.

Quote:

---

Originally Posted by medievalelks

No, I'd just rather have my engineers focussed on optimizing their DB queries, caching of results, threading, etc. than trivial issues like this.

---

Sure. Particularly "remembering" the result from a previous query rather than redoing it a few lines further on in the code can have dramatic effect on performance, compared to the "a few dozen clock-cycles" which you'd save on passing something with const reference.

--
Mats

Quote:

---

No, I'd just rather have my engineers focussed on optimizing their DB queries, caching of results, threading, etc. than trivial issues like this.

---

Sutter and Alexandrescu's advice to "don't pessimize prematurely" should be applied here: sure, there are larger gains to be had by optimising database queries and choosing appropriate indices, but appropriately choosing to use pass by reference instead of pass by value neither requires considerable thought nor results in code obfuscation, so it might as well be done.

Aside from Laserlight (excellent) reply, I would also point out that missing the const reference on a rather long string that may actually be passed along SEVERAL TIMES before it reaches the actual database interface can have a noticeable effect on performance too - sure it's nothing like halving the number of DB queries for a whole application, but copying a kilobyte of query string say a dozen times between the user-interface-code and the actual query will be significantly slower than passing 4 bytes of reference a dozen times. Having the const reference there in the first place will prevent someone else from "messing up" the interface where the string is passed from one object to the next.

--
Mats

I don't disagree with either reply, just hoping that the OP realizes the importance of profiling to find real bottlenecks, and that they're usually tied to the design, algorithms, etc.

Quote:

---

Originally Posted by medievalelks

I don't disagree with either reply, just hoping that the OP realizes the importance of profiling to find real bottlenecks, and that they're usually tied to the design, algorithms, etc.

---

And with that, I fully agree too.

--
Mats

Teaching new programmers to do the little things early is never a bad idea. :)

Quote:

---

Originally Posted by bobbelPoP

Code:

---



      class Database {
 public:
 std::string Query;
 void SendQuery(std::string,&Database); // Would this be faster?
 //Reminds me of like a wildcard variable/pointer/reference thing

 // or

 void SendQuery( std::string Query, Database& db ); // or would this be faster?

}

---

---

there is no reason that a class database should require a reference to an instance of database to execute a query.

if you need to execute a query on an external database, just execute the query off that instance. inside the query implementation it should always refer to this

Quote:

---

Originally Posted by rags_to_riches

Teaching new programmers to do the little things early is never a bad idea. :)

---

I'm not new at programming, I'm new at C/C++. I have past experience with java and php. :P

Quote:

---

Originally Posted by bobbelPoP

I'm not new at programming, I'm new at C/C++. I have past experience with java and php. :P

---

In this context, you are a new C++ programmer, and it still means that understanding when and where to use const reference to avoid copying is a good thing to learn NOW, rather than later.

Note that objects that are less than or equal to twice the size of a pointer should be passed as copies (so no const reference there), as there would be no benefit to pass a pointer (reference) to those objects.

--
Mats

Well I'd like to create something that I originally wanted to create first, even if it has a few bugs. It doesn't mean I'm going to release it, just means I want to do what I originally planned to do with the language. xD

I wanteed to create:
a game ( 2d shooter ),
a web browser,
and an os ( far from my league atm )

I would say they're all far from your current skill. All complex programs.
Although that doesn't mean you can't achieve something in the future.

Quote:

---

Originally Posted by Elysia

I would say they're all far from your current skill. All complex programs.
Although that doesn't mean you can't achieve something in the future.

---

Well I know the concepts of creating them, and I know some code that will actually make it work, but the problem is, how to assemble it correctly. I just need to feel more comfortable about C/C++ and learn more about it.


By the way, I have a book called absolute C++, will that help me. And one more thing, how long will it take me to fully learn C/C++

Quote:

---

Originally Posted by bobbelPoP

a game ( 2d shooter ),

---

This is probably doable.

Quote:

---

a web browser,

---

That's a HUGE task if you want to do all that a normal browser does with JavaScript and other extensions.

Quote:

---

and an os ( far from my league atm )

---

On some levels this is probably easier than a web-browser, because you need a lot less of your own OS to actually do something useful - but if you are after something that can read disks, talk to the internet and display 3D graphics [using a modern graphics card], you are in for a big task f'sure.

--
Mats

I have worked with the functions ( WINAPI ( MSDN ) ) in DX & Windows, I know how to import textures, and I've made polies on 2d space and such. So..

By the way, I forgot, a database software was one of the things I wanted to create. :P