|
If my preprocessor define / undefine code hierarchy is in this sequence:
#define TEST
#undefine TEST
#define TEST
assuming it is read "top to bottom "
is "TEST" defined?
|
|
|
|
|
Salvatore Terress wrote: is "TEST" defined?
Most certainly
PS. By #undefine I assume you mean #undef. #undefine is not a standard preprocessor keyword
Mircea
|
|
|
|
|
It's easy enough to test it with a few lines of code. But why would you want to do this in the first place?
|
|
|
|
|
Sorry, I mixed up C and make.
THANKS
|
|
|
|
|
Sorry, I mixed up C and make.
THANKS
|
|
|
|
|
I rely on "intelisense" to help me to add CORRECT #include header file.
It sort of works in "left to right " fashion .
If I need to add "header_.h" file I have to step thru all options BEFORE I have "header_.h "
option.
#include "../ now intlesence gives all options after "/".
The "problem is " - until CORRECT , valid option is presented and selected I still have no way to see if it actually have an option to select desired header.
It would be nice to have option to determine required path BEFORE going thru the intelisense steps.
Sort of in reverse direction, opposite intelisense way.
Is there?
|
|
|
|
|
Since you are using #include " ... (double quotes) rather than #include < ... (angle brackets), you should know what the path is, as you are referring to local headers. But you could simplify things by adding the required header locations to the list of include directorie for the compiler to search.
|
|
|
|
|
For standard include files, doc pages for the function usually show what include file to use. For your own, or other dependencies, not much luck. You can try to grep function name in *.h files. Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
Mircea
|
|
|
|
|
Mircea Neacsu wrote: Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
I could challenge you to create a setup to prove the significance of this: A compilation that would consistently take noticeably (more than 1%) longer compilation time with an "uber include" than with individual includes for what you really need. I am quite sure that for an example showing significant higher compilation times, you would have to make a system wide search for .h files and include them all in the "uber" file 
There are other good reasons for avoiding the "uber" approach, though: Pollution of the name space. Not because I worry about symbol table sizes, but about too many symbols being acceptable. Sort of in the same class as languages that doesn't require declaration: If you misspell a name, it is not a misspelling, but creation of a new variable. Or, if your language lets you make local redefinitions of names in an outer scope: Remove the local (re)definition, and your code will reference a completely different variable. The "uber"
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Mircea Neacsu wrote: Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
I could challenge you to create a setup to prove the significance of this: A compilation that would consistently take noticeably (more than 1%) longer compilation time with an "uber include" than with individual includes for what you really need. I am quite sure that for an example showing significant higher compilation times, you would have to make a system wide search for .h files and include them all in the "uber" file
There are other good reasons for avoiding the "uber" approach, though: Pollution of the name space. Not because I worry about symbol table sizes, but about too many symbols being acceptable. Sort of in the same class as languages that doesn't require declaration: If you misspell a name, it is not a misspelling, but creation of a new variable. Or, if your language lets you make local redefinitions of names in an outer scope: Remove the local (re)definition, and your code will reference a completely different variable. The "uber" approach makes available to you a whole lot that you are not aware of, not its origins. You won't have an error message that a declaration is missing. You don't know what you are making use of. One day someone adds a similarly defined function to your project, doing things in a different way, and your code fails ...
Ideally, you should know every single instruction your code executes. That is of course impossible; we have to rely on libraries, OS functions etc., but we select them, deliberately and concerned. The "uber" approach invites to introducing a lot of code that is not at all selected, neither deliberately nor concerned, it just is there, ready to manipulate your data in ways that you do not know.
Blackboxing principles go both ways: Your class, module, namespace or whatever should not expose more of itself that what is absolutely necessary for others to know. But at the same time: Inside that black box, you should not see more of the environment than absolutely necessary for the blackbox to know. One of the nice features of VS is that it tells when you are using namespaces, but not using any names from them!
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Sort of in reverse direction, opposite intelisense way.
Is there?
concluding from discussion which "went sideways" ( am I allowed to have an opinion ?)
there is no such option
|
|
|
|
|
Fair enough, but your quote is not from the post that you have attached your comment to. (I am not offended, I just want to point it out.)
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
May I please inquire are you stating the compiler you are utilizing provides no means to specify a list of directories to search for #include's. That is difficult to believe. May I please inquire compiler purveyor.
|
|
|
|
|
trønderen wrote: I could challenge you to create a setup to prove the significance of this: A compilation that would consistently take noticeably (more than 1%) longer compilation time with an "uber include" than with individual includes for what you really need
Easy Peasy:
[k5054@localhost]$ cat ex1.cpp
int main()
{
std::cout << "Hello World\n";
}
[k5054@localhost]$ time g++ ex1.cpp
real 0m0.208s
user 0m0.148s
sys 0m0.058s
[k5054@localhost]$ cat ex2.cpp
int main()
{
std::cout << "Hello World\n";
}
[k5054@localhost]$ time g++ ex2.cpp
real 0m0.865s
user 0m0.718s
sys 0m0.142s
[k5054@localhost]$
That's a 400% slow down. I've never done that in real life. I stumbled across bits/stdc++.h only a couple of years ago, I think in QA. Not sure why the GNU maintainers allowed it. It seems like a good way to get a whole raft of unexpected results.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Yeah, that's what I expected.
I do not consider your example fully qualifying, though. I was speaking of "showing significant higher compilation times". I do not consider 600 and some milliseconds extra compilation time to be "significant".
If milliseconds really count, you might delete all sorts of 'copyleft'-like blurb in all your header files, reduce all whitespace to single spaces and use single/few character symbols wherever possible.
As I mentioned earlier, there are several good reasons against the "über" philosophy. I do not count saving 600 ms wall clock time as one of them.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
I have (some basic ) understanding of purpose of "forward declaration".
I am using the orignal ( 3rd party ) code and wonder what would be the
purpose of "enclosing forward declaration" in "namespace".
My test, declared class is yet not defined ,compiles and runs ,
regardless where I place the forward declaration.
<pre>#include <QMainWindow>
....
class MdiChild;
class terminal_ORIGINAL_MainWindow;
QT_BEGIN_NAMESPACE
class QAction;
class QMenu;
class QMdiArea;
class QMdiSubWindow;
QT_END_NAMESPACE
class MainWindow : public QMainWindow
{
Q_OBJECT
....
|
|
|
|
|
If you put a forward declaration inside a namespace, it is then known within that namespace. If your code compiles regardless of whether you put a forward declaration inside a namespace, it could be that you're actually creating two versions of the symbol: one inside the namespace, and one in the global namespace. But you haven't provided enough code for me to tell.
A forward declaration is used to avoid an #include for a symbol that is used in name only, which means that it is only used in a reference or pointer (name& or name*). In such a case, the compiler doesn't need to know the size of the class or any of its members; it only needs to know that the symbol exists.
|
|
|
|
|
So if it is in global space , outside the namespace, would is work in both areas?
The key would be "global". If it does not , then your explanation is either invalid or I need to implement the class (provide more code ) - then forward declaration is not required in the first place.
I did say it is a TEST code , hence there is nothing to see since the cLass is not yet used / defined.
My current "proof of concept " is therefore limited to "compiles and runs".
I need to digest the second part of your post - since actual use - definition / declaration the class in question - does not compile ...
|
|
|
|
|
If symbol is declared in the global namespace, it's still visible from other namespaces. If it's also declared in a named namespace, that's the declaration that would be picked up within that namespace unless qualified as ::symbol.
You're right that a forward declaration isn't required if you define the class--in the same file. There are times when an interface (.h) forward-declares a class that it uses in name only, and which is private (that is, implemented in its .cpp). This is done when using the PIMPL idiom[^].
|
|
|
|
|
Hi I have below code written while contesting on a platform, though I find working with code but it fails with different test cases especially when Input value is 1 and no string is provided. Can anyone please help to resolve this issue ?
#include <bits/stdc++.h>
using namespace std;
string reSize(string s)
{
if(s.length() > 0)
{
std::string res;
int count =1;
for(int i =0;i<(s.length() - 1);i++)
{
if(s[i] == s[i+1])
{
count++;
}
else
{
res += s[i];
if(count > 1)
{
res += std::to_string(count);
}
count = 1;
}
}
res += s[s.length() - 1];
if(count > 1)
{
res += std::to_string(count);
}
return res;
}
else if(s.empty())
{
return "";
}
}
int main() {
int t;
cin>>t;
while(t--)
{
string s;
cin>>s;
cout<<reSize(s)<<endl;
}
return 0;
}
modified 2-Apr-24 6:37am.
|
|
|
|
|
What you need to do is put a breakpoint in your code, and step through it a line at a time. When you are executing a line, think about what you expect the outcome of that operation to be and compare what you think should be happening with what actually happens. Generally, this will lead you to work out what the problem actually is. There's a name for this type of approach, it's called debugging, and it's one of the most valuable skills you will ever learn.
|
|
|
|
|
priyanka mp wrote: Can anyone please help to resolve this issue ?
You have not actually expalined what the issues is. What is the code supposed to do, what inputs are you using, what results do you get, and why are they not correct?
|
|
|
|
|
what is this supposed to do ?
what is the input and what is the output ? (what are the test cases ? )
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
You know, you cannot get an empty string using cin (see, for instance, Get empty input - C++ Forum[^]).
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Maybe its a contest. Guess the point and win the prize.
I do note that there are two possible inputs. So if '1' was put in for the first one, then I expect it works.
If put in for the second then I suspect '2', ..., '9' would also fail.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
