|
Michael Schubert wrote: Out of curiosity, what's a "Be programmer"?
Whether to be or not to be, that's his question.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
DavidCrow wrote: Michael Schubert wrote:
Out of curiosity, what's a "Be programmer"?
Whether to be or not to be, that's his question.
ToBe OR NOT ToBe == -1
Sorry, couldn't resist....
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Be programmer wrote: inline or macro
There are very, very, very, very few reasons to ever consider using a macro rather than an inline function. In fact, your question is a subset of the second item in Scott Meyer's Effective C++ (one of the C++ textbooks you really want to read):
Item 2: Prefer consts, enums, and inlines to #defines
The reasons?
- Macros live outside the type system
- Macros pollute all namespaces
- There can be unexpected outcomes from macros. Consider the following macro function and it's use:
#define CALL_WITH_MAX(a, b) f((a) > (b) ? (a) : (b))
CALL_WITH_MAX(++a, b);
CALL_WITH_MAX(++a, b+10);
Can you predict that reliably? Nope, thought not.
So, to paraphrase...just don't ever use a macro instead of an inline function.
Don't try to micro-optimise before you know what the slow things are...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
In addition to what Stuart said, an inline function probably won't actually "inline" in the compiler if it's 20 lines long. If it's only a few lines, then it might. And I wouldn't really consider 20 lines to be that "small." Generally you only want to inline 1-liners or maybe a few more lines than that, but the compiler will ultimately decide what it lets you inline even if you specifically set the function to be an "inline" function.
KR
|
|
|
|
|
Regardless of the usefulness, you can force most compilers to inline (__forceinline), no matter how much code is involved.
|
|
|
|
|
Hi Mike,
I always thought even with the __forceinline keyword, the compiler had an option to ignore it and not inline the function (if it feels so). So, is that wrong and the keyword causes the compiler to forcefully make the function inline?
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
I had mixed results when I played around with this. The VC6 compiler does ignore __forceinline when a function is beyond a certain complexity/size, especially when there is a call to another function within.
The Intel C++ compiler (at least newer versions) has a bunch of switches to control inlining and lets you inline almost every function. When you try that with a large function, the final .obj (and the resulting .exe) file(s) will be huge.
After a lot of testing I realised that it's usually best to let the compiler decide (/Ob2). The Intel compiler is especially good in this regard.
|
|
|
|
|
Michael Schubert wrote: I had mixed results when I played around with this. The VC6 compiler does ignore __forceinline when a function is beyond a certain complexity/size, especially when there is a call to another function within.
Exactly! I've struggled with this a few years back (VC6 compiler) which ignored the keyword and made it a normal function, realising that the function is a little more complex than what should it be to qualify as an inline one.
I wanted it to be inline because I kept some of the code for application validation and secure updates (based on the version purchased) in that. The function was being called from several places in the source and I didn't want it to be pointing to one function call (trying to make a cracker's job a little tough). So, I realised this is an arrogant display of - "I know it better than you, so you cannot force me" attitude by the MS compiler. They might as well remove this keyword; I don't find it to behave any different the __inline keyword.
Good to know the intel compiler just does what we ask it to do. But, after all, MS knows what's best for us, better than we do. 
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Rajesh R Subramanian wrote: I always thought even with the __forceinline keyword, the compiler had an option to ignore it and not inline the function (if it feels so).
You're right. Anyway, you may then consider __force_tha_fu@kin_function_inline_bastard directive, that usually do the job.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I'd love to have the directive though. 
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
|
I second that.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
hi every one,
we for an STL container we can use both iterator or indexing method to access the
container data, but still y iterators are preferred i mean what is advantage of
using iterator over legecy indexing...
please answer me...
if u feel silly still iam the begineer and even tried to google but
didnt found the destiny..
|
|
|
|
|
|
Iterators are a more generic and flexible concept than indices. They allow you to access the item they reference without having to refer to the parent container. Indices can't do that - they need to be explicitly used with the container they index.
Things like polymorphic algorithms (like in the STL header algorithm) would be tricky to implement with indices...
The Wikipedia page on iterators[^] has quite a good explanation.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I searched over and found that gotoxy() is defined in conio.h!!!!!!
Is it write.
I want to use gotoxy() to print the text at some other location than the origin in the following program. This program is basically a informal animation of the text entered. The code is given below.
#include<stdio.h>
#include<windows.h>
#include<conio.h>
main()
{ static char ch[100], rev[100];
int n=0,c=0,d=0,i=0,h=0,k=0,r=0;
for(n=0;n<100;n++)
{ch[n]=getche();
if(ch[n]=='\r')
break;}
system("cls");
gotoxy(20,18);
while(1)
{for(h=1,k=n;h<100,k>n/2;h++,k--)
{if(h>n)
break;
for(c=0;c<h;c++)
printf("%c",ch[c]);
for(d=n,r=0;d>k-1,r<100;d--,r++)
{
rev[r]=ch[d-1];}
for(i=h-1;i>=0;i--)
printf("%c",rev[i]);
Sleep(1000);
system("cls");}}}
|
|
|
|
|
|
|
Hi ya,
I am a noob to multi threading on C++ (did a bit on Java) and was hoping you could explain to me the following (from http://www.ddj.com/cpp/184401518?pgno=3).
<br />
<br />
#include <boost/thread/thread.hpp> #include <boost/thread/mutex.hpp> #include <iostream><br />
<br />
boost::mutex io_mutex;<br />
<br />
struct count {<br />
<br />
count(int id) : id(id) { }<br />
<br />
void operator()()<br />
<br />
{<br />
<br />
for (int i = 0; i < 10; ++i)<br />
<br />
{<br />
<br />
boost::mutex::scoped_lock lock(io_mutex);<br />
<br />
std::cout << id << ": " << i << std::endl;<br />
<br />
}<br />
<br />
}<br />
<br />
int id;<br />
<br />
};<br />
<br />
int main(int argc, char* argv[])<br />
<br />
{<br />
<br />
boost::thread thrd1(count(1));<br />
<br />
boost::thread thrd2(count(2));<br />
<br />
thrd1.join();<br />
<br />
thrd2.join();<br />
<br />
return 0;<br />
<br />
}<br />
what is this for? boost::mutex io_mutex; To say you wish to define a boost::mutex lock and call it io_mutex?
In the for loop a scoped lock is used. Does that mean any object used within the scope of the for loop is locked? Does the lock only lock "this"? How do I lock other objects or do I have to use
a scoped lock in the member function?
Thanks for any information.
|
|
|
|
|
minkowski wrote: what is this for? boost::mutex io_mutex; To say you wish to define a boost::mutex lock and call it io_mutex?
Yes
minkowski wrote: In the for loop a scoped lock is used. Does that mean any object used within the scope of the for loop is locked?
No - it means that the thread containing the for loop will own the mutex within the for loop
minkowski wrote: Does the lock only lock "this"? How do I lock other objects or do I have to use a scoped lock in the member function?
The lock isn't explicitly attached to the thing it locks - it's more of a conceptual relationship. What it means in this case is that only one thread at once can execute the line std::cout << id << ": " << i << std::endl;.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hey thanks for that. So basically, anything that is in the for loop is only executable by 1 thread?
If so, what if I have some member functions for a class, say a get() and a set() and I only want one thread at a time to access either of them (preventing a read occuring the same time as a write). How would I lock them?
|
|
|
|
|
minkowski wrote: So basically, anything that is in the for loop is only executable by 1 thread
Yup.
minkowski wrote: If so, what if I have some member functions for a class, say a get() and a set() and I only want one thread at a time to access either of them
Same sort of thing - using the same threading classes as before:
class MyClass
{
void SetMyObject(SomeClass const& value)
{
boost::mutex::scoped_lock lock(objectMutex);
myObject = value;
}
SomeClass SetMyObject() const
{
boost::mutex::scoped_lock lock(objectMutex);
return myObject;
}
private:
SomeClass myObject;
boost::mutex objectMutex;
};
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
So from your example, say one thread accesses the SetMyObject() , given that there is a lock in the function, it will also lock the GetMyObject() blocking any other thread from calling?
This kind of implies that wherever in the object there is a lock, any function owned by the object will be locked to any other thread trying to access. Is this correct?
Thanks again for your help.
|
|
|
|
|
minkowski wrote: So from your example, say one thread accesses the SetMyObject() , given that there is a lock in the function, it will also lock the GetMyObject() blocking any other thread from calling?
Yes
minkowski wrote: This kind of implies that wherever in the object there is a lock, any function owned by the object will be locked to any other thread trying to access. Is this correct?
Sort of - any function that attempts to acquire (lock) the mutex will be serialized, as only one thread can acquire the mutex at a time. So, that means if you have a group of functions that acquire the lock, only one of that group can be executed concurrently.
There are other sorts of locks that may better suit different situations (semaphores, read-write locks) - part of learning how to design multi-threaded systems is knowing which sort of synchronisation mechanism to use.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hey thanks for that, it tidied up some of my uncertainties.
I was wondering how C++ knows to lock the other member function if one is being accessed by another thread. In the thread constructor itself you pass in either a function pointer or overloaded operator() in your class. So for the case of an object, there must be some reference to the this pointer for the object for it to know to lock the other member functions if a lock is in place from another thread. Was wondering if this is correct?
Thanks for any information.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
