I just came to know that if we include anything in .pch file, we don't have to include later in other files. Now I am thinking of adding all of my files in it so that I don't have to include them in other files and create a mess at the start of each file. But I was thinking if this is a good practice? If not, why? And if good, why?
"Hi Alex .. I'll take bad ideas for $1000" :D
Aside from Oscar's answer, you will also subvert the build process. As every file knows about and hence depends on every other file, then changing a single file will mean that all compilation units in the project will be forced to be built on every recompilation - rather than just building what has changed.
It is definitely not a good practice, you should however definitely include the files that will be needed in all or most of the files, singletons and data models would be a good candidate for example.
The reason why this is a bad idea is cycling references, if you were to include all your files in that .pch file you will soon get some errors about cycling references.
Related
I cannot find any similar questions on this topic, which seems strange..
I have what is turning out to be a rather large project. As I build each chunk, I'm aware that I must be making properties and other resources, that do not end up being used.
Is there a way to find these?
Good question. I always need this too in my projects. What I do is either use search for .property or setProperty etc. in the whole project.
Or I traverse the .h files and comment out the property declarations that I suspect I might not be using and hit Command+b and see if it gives any errors.
I hope there is a function/tool specifically built for this need.
First of all, I've never worked on iOS, so this may or may not be a stupid question, I don't know :)
I have an iOS App, and I need to run it.
In the 'Project Navigator' I have a folder/package called 'Reuse and Platform Libraries'. Inside, I have another four folders but 3 of them seem like missing.
I am not sure if this is the case. I've tried googling their name but without results so I assume they are not some open source libraries.
Can someone clear this up for me? Do I need to install some XCode packages?
Thanks!
I suggest you search the folder of the project for those files, sometimes when copying a project the paths get screwed up because they were set as absolute paths and not relative paths.
If you can't find the files, it's most likely that the library is a private one used by the previous developers, and usually kept out of the project folder so they probably forgot to send it along. I'd suggest simply asking them to send the files over :).
There is also a slight chance they are not needed to run the file, in which case, just deleting them from the sidebar should make the project run.
Am I correct that boost's file recursion requires that the file using the recursion must be in the include path?
I don't see it anywhere in the documentation, but I just debugged a problem where this seems to be the case. This makes using this as a means to generate boilerplate code automatically somewhat limited when used for a library as the library header file may not be in the include path.
Any comments?
It looks to be true. So I wrote a library to deal with this situation. Here it is if anyone else is having the same problem: https://sourceforge.net/projects/relativeiterate/
Changed, updated, form is not used even though uses and project settings seem fine, old form files removed from disk.
Is this a bug in the IDE? I may just delete the form and copy it into another unit with a new name.
If it's using an old form it has to be getting it from somewhere--it doesn't appear out of thin air. Two scenarios come to mind:
1) It's somewhere where you don't realize. Search your system for files by that name.
2) Unless you do a build Delphi compiles based on timestamps. If the clock was wrong when it was compiled before the .dcu can have a more recent time and thus it gets skipped in compiling. I've hit this more than once with timezones.
A good way to find it is to first move the project to a different new folder and try to compile it. This should produce and error that will help you to find the culprit. If this does not work then it is settings like paths etc in your libraries that are at fault.
Also make sure that you deleted all ".dcu" files in the project before re-compiling.
No, it is not a bug in the IDE.
You are referencing that form in some setting in your project or environment, which you didn't find yet and which takes precedence to options you already tweaked.
Where do you need to go to resolve your problem? Well, that's difficult to say without looking at your development environment and your project settings.
I've had this happen before. It is always something referenced that I wasn't aware of.
You can do a grep for something from the form and see where it shows up.
Thanks for the input. The first one I tried, moving the files, mm2010, showed it was my code that was at fault.
Although the form/unit is not included in the project file (dpr), it is still referenced by some other unit. So the compiler links the res into the application. Look for the unit name you want to remove in other units' uses clauses.
J2ME lacks the java.util.Properties class. Although it is possible to put application settings in the JAD file this is not recommended for many properties. (Since, some platforms limits the size of JAD file.) I want to put a configuration file inside my jar file and parse it. And I do not want to go with XML because it will be overshooting for my case.
Question is, is there an already existing library for J2ME that can parse properties files or something similar such as INI file. Or would you recommend another method to solve the initial problem?
The best solution probably depends on what is going to be generating the properties files.
If you've got other non-JavaME projects using the same properties files, then stick with them, and write or find a parser. (There is a simple one from GoBible available on Google Code)
However you might find it just as easy to keep your configuration as static final String myproperty="myvalue"; in a Configuration.java file which you compile, and include in the jar instead, since you then do not need any special code to locate, open, read, and parse them.
You do then pick up a limitation on what you call them though, since you can no longer use the common dot separated namespacing idiom.