When compiling a project under CBuilder XE8 that uses the TeeChart components distributed with that IDE, I get long reams of errors like this:
[bcc32 Warning] GdiplusStringFormat.h(306): W8058 Cannot create pre-compiled header: initialized data in header
[bcc32 Warning] MI3Proc.cpp(719): W8080 'Gdiplus::FlatnessDefault' is declared but never used
[bcc32 Warning] MI3Proc.cpp(719): W8080 'Gdiplus::GenericSansSerifFontFamily' is declared but never used
[bcc32 Warning] MI3Proc.cpp(719): W8080 'Gdiplus::GenericSerifFontFamily' is declared but never used
[bcc32 Warning] MI3Proc.cpp(719): W8080 'Gdiplus::GenericMonospaceFontFamily' is declared but never used
[bcc32 Warning] MI3Proc.cpp(719): W8080 'Gdiplus::GenericSansSerifFontFamilyBuffer' is declared but never used
[bcc32 Warning] MI3Proc.cpp(719): W8080 'Gdiplus::GenericSerifFontFamilyBuffer' is declared but never used
[bcc32 Warning] MI3Proc.cpp(719): W8080 'Gdiplus::GenericMonospaceFontFamilyBuffer' is declared but never used
[bcc32 Warning] MI3Proc.cpp(719): W8080 'Gdiplus::GenericTypographicStringFormatBuffer' is declared but never used
[bcc32 Warning] MI3Proc.cpp(719): W8080 'Gdiplus::GenericDefaultStringFormatBuffer' is declared but never used
This problem is also reported on Steema's support forum at http://www.teechart.net/support/viewtopic.php?f=3&t=15374, but there is no followup.
I had a similar issue with TeeChart under CBuilder 4 (something like 20 years ago!). Hmmm.
I don't want to turn off the W8080 warning project-wide, as it helps keep my code clean, but is there any way to turn off the warnings just for the TeeChart unit?
Additionally, I'm not sure what to make of the W8058 error. The #pragma hdrstop precedes the include of VclTee.TeeGDIPlus.hpp, so this error should not be occurring.
EDIT:
Some more information I've discovered is that the offending variables are static/const global variable declared and initialized in GdiplusEnums.h and GdiplusHeaders.h (files copyright 2001 by Microsoft).
Temporarily disabling the 8080 warning does not work because somewhere in the chain of nested includes, the 8080 warning is reset to default. If you disable the 8080 warning in the call to the compiler (i.e. global options), then all 8080 warnings will cease, but then you don't catch your own mistakes. Even putting the entire cpp unit in a #pragma warn -8080 block will not stop the warnings!
The only way I've found to stop the warnings (without globally disabling the 8080 warning) is to put dummy code like this somewhere in each affected source unit (so that the variables are referenced).
void *pvDummy;
double dDummy;
BYTE *pBYTEDummy;
dDummy = Gdiplus::FlatnessDefault;
pvDummy = Gdiplus::GenericSansSerifFontFamily;
pvDummy = Gdiplus::GenericSerifFontFamily;
pvDummy = Gdiplus::GenericMonospaceFontFamily;
pBYTEDummy = Gdiplus::GenericSansSerifFontFamilyBuffer;
pBYTEDummy = Gdiplus::GenericSerifFontFamilyBuffer;
pBYTEDummy = Gdiplus::GenericMonospaceFontFamilyBuffer;
pBYTEDummy = Gdiplus::GenericTypographicStringFormatBuffer;
pBYTEDummy = Gdiplus::GenericDefaultStringFormatBuffer;
The method containing this code has to be in a #pragma warn -8004 block to avoid warnings about "xxx is assigned a value that is never used". Grrr.
This does offend some sense of good coding style, but there you go...
You can disable the W8080 (or any other warning) using the #pragma warn directive.
I would add it before the header that produces the warnings, so you don't modify the header. For example:
#pragma warn -8080
#include <TheOffendingHeader.h>
#pragma warn .8080
Related
Using C++ Builder 10.3 Update 2
I'm upgrading some existing software from classic Borland compiler to Clang 64.
The entire project consists of a number of static libraries, and some applications.
When building the final applications, I'm running into linker issues that look like this:
[ilink64 Error] Error: Unresolved external 'std::_Facet_base::_Facet_base()' referenced from XXX.A|xxx.o
[ilink64 Error] Error: Unresolved external 'vtable for std::locale::facet' referenced from XXX.A|xxx.o
[ilink64 Error] Error: Unresolved external 'vtable for std::ctype_base' referenced from XXX|xxx.o
The libraries are using std::stringstream, and std::readline, along with some other std library functions.
The general pattern that is causing the error is:
// mystaticlib.h
void foo();
// mystaticlib.cpp
#include <sstream>
void foo() {
stringstream ss;
// do some more stuff
}
// myapp.cpp
#include "mystaticlib.h"
void bar()
{
foo();
}
Is this a bug with the compiler/linker?
I've found these related questions (and more):
Undefined reference to vtable
Linking error: undefined reference to `vtable for XXX`
Linker error: undefined reference to vtable
But the answers generally boil down to "implement the missing functions".
Since this is the std library delivered with the product, I'm hesitant to start changing it.
I'm fairly familiar with C++ Builder, and C++ and I've tried investigating all the basic stuff.
This code did compile, link and run using C++ Builder 10.3 with the classic 32 bit compiler.
This is so low level that I'm having a hard time figuring out what is wrong.
Because of reasons, I would prefer not to update to 10.4 at this time.
I also saw that there is a 10.3.3 release, but I was hoping not to upgrade unless I specifically had to to fix this problem.
I heard that Objective-C is influenced by the "message passing mechanism" of SmallTalk.
Objective-C, like Smalltalk, can use dynamic typing: an object can be
sent a message that is not specified in its interface. This can allow
for increased flexibility, as it allows an object to "capture" a
message and send the message to a different object that can respond to
the message appropriately, or likewise send the message on to another
object.
And I felt for codes like [anObject someMethod], the binding of someMethod to the machine code may happen at run-time..
Therefore, I write a demo like this:
#import <Foundation/Foundation.h>
#interface Person : NSObject {
#private char *name;
}
#property (readwrite, assign) char *name;
- (void)sayHello;
#end
#implementation Person
#synthesize name;
- (void)sayHello {
printf("Hello, my name is %s!\n", [self name]);
}
#end
int main() {
Person *brad = [Person new];
brad.name = "Brad Cox";
[brad sayHello];
[brad sayHelloTest];
}
I tried [brad sayHelloTest] to send brad a message sayHelloTest which brad doesn't know how to handle with.. I expect the error will NOT happen at compile-time..
However, the compiler still throws an error:
main.m:24:11: error: instance method '-sayHelloTest' not found (return type defaults to 'id') [-Werror,-Wobjc-method-access]
[brad sayHelloTest];
^~~~~~~~~~~~
main.m:3:12: note: receiver is instance of class declared here
#interface Person : NSObject {
^
Change [(id)brad sayHelloTest] to [(id)brad sayHelloTest]; doesn't work either.. (The compiling command is clang -Wall -Werror -g -v main.m -lobjc -framework Foundation -o main)
In Objective-C, does the binding of method really happen at "run-time"? If so, why will there be a compiler error like this?
If the binding doesn't happen at "run-time", why was "Objective-C" called "dynamic typing language"?
Does anyone have any ideas about this?
One job of a compiler is to catch as many errors at compile time as possible. If it can tell that the call will fail at runtime, you generally want it to complain.
You can suppress this via casting to show that runtime resolution is happening:
[(id)brad sayHelloTest];
Because the IDE can infer the obvious error from the context.
When you write if (a = 1),you will get a warning. A good IDE should help you find mistakes as early as possible.
I figured out the reason finally..
It throw errors during compiling because -Werror flag is included, which will turn warning into error..
http://clang.llvm.org/docs/UsersManual.html#cmdoption-Werror
After I delete -Werror flag, everything works as expected and the error only happens at run-time.
It has become a compiler error only within the last five years for there to be no known declaration of a method. It has to do with Automatic Reference Counting. Under ARC, the compiler is now responsible for the reference-counting-based memory management that Cocoa uses.
Given that responsibilty, it must be able to see the declarations of methods for any messages before they are sent, so that it knows what retains and releases are appropriate.
The method resolution (the lookup of the method on the class) does still happen at runtime, and -- particularly if you disable ARC -- you can still take advantage of message forwarding.
One way around ARC's requirement was given by Marcelo Cantos -- cast the receiver to id. Another is to use performSelector:. A third -- though I can't recommend it -- is to use objc_msgSend() directly.
Note that the "binding" of the method does, and always did, happen at compile time. Methods are associated with classes, when the classes are defined. Messages are distinct from methods, and it is they that resolve at runtime to a method.
I'm getting this error:
/Class/GData/OAuth/GDataOAuthViewControllerTouch.m:116:22: Expected a type
That line is:
authentication:(GDataOAuthAuthentication *)auth
Inside of this block of code:
- (id)initWithScope:(NSString *)scope
language:(NSString *)language
requestTokenURL:(NSURL *)requestURL
authorizeTokenURL:(NSURL *)authorizeURL
accessTokenURL:(NSURL *)accessURL
authentication:(GDataOAuthAuthentication *)auth
appServiceName:(NSString *)keychainAppServiceName
delegate:(id)delegate
finishedSelector:(SEL)finishedSelector {
NSString *nibName = [[self class] authNibName];
I'm a newb XCode developer. So far I've created and compiled a calculator app based from an online class but that's it.
Is this a library that is not being included?
Background: The previous developer abandoned the project and the owner sent the project code to me. I'm trying to replace the existing graphics with new graphics and recompile it with support for iOS 6, which I thought I should be able to do without any coding, but have run into this error and many others when I opened the project. I have the latest XCode.
The :22 (and the position of the caret within the editor) tell you exactly where on the line the error is. In this case it's telling you that where it sees GDataOAuthAuthentication it was expecting a type. So, implicitly, it doesn't recognise that GDataOAuthAuthentication is a type.
Objective-C still sits upon compilation units ala C — each .m file is compiled in isolation then the lot are linked together. You use #import (or #include if you want; #import just guarantees the same file won't be included twice) to give each individual file visible sight of any external definitions it needs.
So, that's a long-winded way of reaching the same conclusion as Rick did five minutes ago: you've probably omitted a necessary #import.
A few things to look for:
Did you #import the file where the GDataOAuthAuthentication type is defined? (e.g. #import "GDataOAuthAuthentication.h")
Is there a variable named GDataOAuthAuthentication which is causing the compiler to think GDataOAuthAuthentication is a variable not a type?
I've inherited a new project, which has several retain cycle warnings caused by implicitly retaining self within various blocks.
In attempting to fix these, I've written
__weak typeof(self) weakSelf = self;
to create a weak reference for use within the block.
However, Xcode v. 5.1.1 is giving the cryptic warning
Lexical or Preprocessor Issue
Extension used
I'm at a loss here-- what does this mean and how can I get rid of it?
You get this warning for the use of typeof if "Pedantic Warnings" are enabled in the build settings.
From the "Quick Help" for this setting:
Description Issue all the warnings demanded by strict ISO C and ISO
C++; reject all programs that use forbidden extensions, and some other
programs that do not follow ISO C and ISO C++. For ISO C, follows the
version of the ISO C standard specified by any -std option used.
[GCC_WARN_PEDANTIC, -pedantic]
I am not an expert in (ISO) C standards, but according to
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html:
If you are writing a header file that must work when included in ISO C
programs, write __typeof__ instead of typeof. See Alternate Keywords.
and http://clang.llvm.org/docs/UsersManual.html:
The parser recognizes “asm” and “typeof” as keywords in gnu* modes;
the variants “__asm__” and “__typeof__” are recognized in all modes.
you can use __typeof__ instead
if you don't want to disable the warning:
__weak __typeof__(self) weakSelf = self;
Clang has several kinds of diagnostics, of which the three main kinds are errors, warnings, and notes.
Notes usually accompany certain warnings and errors, such as duplicate definitions:
error: conflicting types for 'square'
static double square(double x) {
^
note: previous declaration is here
static int square(int x);
^
What I want to know is, does Clang have any diagnostics—especially for Objective-C or C, but I'll settle for C++ if I have to—that consist of only a note, with no associated error or warning?
http://clang.llvm.org/docs/InternalsManual.html#the-diagnostic-kinds-td-files says:
These severities are mapped into a smaller set (the Diagnostic::Level
enum, {Ignored, Note, Warning, Error, Fatal}) of output levels by the
diagnostics subsystem based on various configuration options. Clang
internally supports a fully fine grained mapping mechanism that allows
you to map almost any diagnostic to the output level that you want.
The only diagnostics that cannot be mapped are NOTEs, which always
follow the severity of the previously emitted diagnostic and ERRORs,
which can only be mapped to Fatal (it is not possible to turn an error
into a warning, for example).
So unfortunately no; you can't do that without hacking Clang itself. Notes are intended only for linking to other diagnostics. I'd file a bug with the LLVM tracker; this would definitely be useful functionality.