I could not create any events on the CIVI CRM page, the below warning messages are getting displayed.
Could not find configure event
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method HTML_QuickForm_RuleRegistry::singleton() should not be called statically, assuming $this from incompatible context in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php on line 388.
strict warning: Non-static method CRM_Core_Block::setTemplateValues() should not be called statically in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\CRM\Core\Block.php on line 587.
strict warning: Non-static method CRM_Core_Block::setTemplateValues() should not be called statically in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\CRM\Core\Block.php on line 587.
strict warning: Non-static method CRM_Core_Block::setTemplateDashboardValues() should not be called statically in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\CRM\Core\Block.php on line 291.
strict warning: Non-static method CRM_Core_Block::setTemplateValues() should not be called statically in C:\xampp\htdocs\drupal\sites\all\modules\civicrm\CRM\Core\Block.php on line 587.
Edit the following files:
C:\xampp\htdocs\drupal\sites\all\modules\civicrm\packages\HTML\QuickForm.php
C:\xampp\htdocs\drupal\sites\all\modules\civicrm\CRM\Core\Block.php
Change:
public function singleton
public function setTemplateValues
public function setTemplateDashboardValues
To:
public static function singleton
public static function setTemplateValues
public static function setTemplateDashboardValues
As you can see, if you want to call a method static, it needs to have that keyword in the declaration. Insure that the keyword $this is not used in any of those methods as well.
Related
I am learning about classes in C++ and know that non-static member functions have implicit this parameter. My first question is that does constructor also have an implicit this parameter just like non-static member functions. Note that i am not asking whether we can use this inside a ctor as i already know that we can use this inside a ctor.
Next, I know that inside a const qualified non-static member function for a class X, the type of this is const X*. And for a non-static member function(without const qualified), the type of this is X*. Similarly, inside the ctor the type of this is always X*. Here comes the deeper question.
We know that when we call a non-static member function(say like obj.func()), then the address of the object named obj is implicitly passed to the implicit this parameter of the method func. So this explains "where the this comes from in case of non-static member function".
Now, lets apply the same thing to constructors. For example, say we create an object of class X using default ctor like:
X x; //does the default ctor also have an implicit this parameter to which the address of x is passed?
My second question is: Does the same thing happen to ctors? Like, the address of x is passed to an implicit parameter of the default ctor. My current understanding is that ctors don't have an implicit this parameter. So when we write X x;, the address of x is not passed as an argument because the object is not created yet and so it doesn't make sense to pass its address. But from the standard we know that inside a ctor we can use the this pointer. So my second question essentially is that, if ctors don't have an implicit this parameter then where does the this in the statement this->p = 0; come from? We know that before using any name(like variable name) in C++, we must have a declaration for that name. So where is the declaration for this? Does the compiler implicitly declares the this in case of ctor? I mean, in case of non-static member function, i can understand that they have the declaration for this as the implicit this parameter but what happens in ctors? How inside ctors we're able to use the name this without having a declaration for that?
struct Name
{
private:
int p = 0;
int k = 0;
void func() //func is a non-static member function and so have an implicit this parameter
{
this->k = 0; // the "this" here comes from implicit this parameter
}
Name()
{
this->p = 0; //where does the "this" comes from here since ctor don't have implicit this parameter
}
};
My third question is that is the concept of implicit this parameter an implementation detail or does the standard says that non-static member function will have an implicit this parameter.
Summary
Do ctors have an implicit this parameter? This first question can also be phrased as "Do ctors also have an implicit object parameter?".
The standard says that we can use this inside a ctor. But where does that this come from. For example, in case of a non-static member function, we know that this comes from the implicit this parameter, but in case of ctors, since ctors don't have an implicit this parameter, where does that this that we're allowed to use inside ctor come from.
Is the concept of implicit this parameter an implementation detail or does the standard say that all non-static member functions have an implicit this parameter, in which case, ctors are also allowed by implementations to have an implicit this parameter.
Edit:
The most important part(IMO) of this question is that how are we able to use the name this inside a ctor? For example when we write:
this->p = 0; //here "this" behaves like a name
In the above statement this behaves like a name. And we know that before using any name(like variable name) in C++, we must have a declaration for that name. So where is the declaration for this? Does the compiler implicitly declares the this in case of ctor? I mean, in case of non-static member function, i can understand that they have the declaration for this as the implicit this parameter but what happens in ctors? How inside ctors we're able to use the name this without having a declaration for that?
From the perspective of the C++ standard
The standard only describes the semantics of the this keyword and not how its value gets there. That's completely abstracted away and an implementation has great flexibility in making it happen.
From the perspective of theoretical computer science
The address of the object under construction, available via the this keyword, absolutely is an input to the initialization procedure (called "constructor" in C++) for the object. So are addresses of virtual base subobjects, which C++ also makes available via the this keyword but cannot be calculated from the main input, so any such must be additional inputs.
Note that CS tends to use "parameter" with procedures more in the sense of template parameters than dynamic variable inputs. And CS uses "function" to mean a procedure without side effects. A C++ constructor is not a CS "function" and while templated constructors are possible (parametric procedures) the value of this is an ordinary input not a parameterization.
Neither is a C++ constructor a method -- there is no polymorphic target-type-dependent dispatch, and so in particular the this input is not used for dispatch.
From the perspective of ABI rules for parameter-passing
A C++ constructor is a special member function. There's no way to construct a function pointer for it or invoke it C-style; ABI requirements for C functions do not apply.
If the platform ABI explicitly describes C++ behaviors, then there will be one or more rules for passing the value(s) of this to a C++ constructor. Those rules may or may not specify a mechanism equivalent to other function arguments, but every ABI-compliant C++ compiler targeting that platform will pass this values as required by the special rules for constructors.
Notably, the ABI for passing this to a constructor isn't required to be equivalent to how this is passed to other (non-special and non-static) member functions, although practical ABIs may well use the same approach for both.
There's no such thing as "implicit this parameter" in the standard. The standard calls it an "implicit object parameter".
An implicit object parameter is only relevant to overload resolution, it doesn't "become" this. Separately, this is defined to have the same cv qualification as the member function.
Do ctors have an implicit this parameter? This first question can also be phrased as "Do ctors also have an implicit object parameter?".
No, from [over.match.funcs]
For the purposes of overload resolution, both static and non-static member functions have an implicit object parameter, but constructors do not.
But where does that this come from.
The object being constructed.
Is the concept of implicit this parameter an implementation detail or does the standard say that all non-static member functions have an implicit this parameter, in which case, ctors are also allowed by implementations to have an implicit this parameter.
The implicit object parameter is part of the rules of overload resolution, it doesn't influence this.
How inside ctors we're able to use the name this without having a declaration for that?
this is not a name, it is a language keyword. The language defines this in a non-static member function to be a prvalue expression. Unlike an unqualified-id (that names an object) in the same position, which are glvalue expressions.
That's the language-lawyer answer. Having said that, I do find that "implicit object parameter becomes this" is a useful mental model.
Recall that constructors (and destructors) can't be cv qualified, so there isn't anything for it to distinguish in a constructor, so it doesn't matter if it exists or not.
"this" is a keyword; it doesn't need declaring, but is always available in non-static member functions.
See e.g. the draft standard here.
The keyword this names a pointer to the object for which an implicit object member function is invoked or a non-static data member's initializer is evaluated.
Note that the mechanism behind this is unspecified.
In the Clang AST how to know if a DeclRefExpr in a method refers to a local or a non-static data member of the struct/class containing the method?
That is, if I were translating the C++ to C and I were explicitly inserting the 'this' parameter and I wanted to explicitly prefix all references to the members of the 'this' class by translating 'x' into 'this->x', how do I know for which DeclRefExprs to do this?
it seems that we want to call NamedDecl::isCXXInstanceMember() on the output of DeclRefExpr::getDecl()
but the context in which I wanted to know this makes it moot: Clang seems to insert explicit MemberExpr and CXXThisExpr expressions when a non-static data member is accessed
The specification does not seem to put any constraints on the member functions of a literal class type
I have two questions regarding this
Q1) Do I have complete liberty over what member functions I can put in?
Q2) How do I verify if a class is a literal type? (Possible method: Define a constexpr object of it and check if it compiles?)
The only constraints on literal classes I see are:
• All the data members must have literal type.
• The class must have at least one constexpr constructor.
• If a data member has an in-class initializer, the initializer for a member of built-in type must be a constant expression, or if the member has class type, the initializer must use the member’s own constexpr constructor.
• The class must use default definition for its destructor, which is the member that destroys objects of the class type
(Source: C++ Primer, 5th edition)
Q1. Yes, you can have any methods you like (excluding constructor/destructor which have constraints). Even including virtual methods, if the constructor is constexpr.
Q2. As you say, define a constexpr variable of that type. If there is no diagnostic message (and the compiler is conforming) then the type is definitely a LiteralType. Note that it is possible for the type to be literal but the code to fail compilation for some other reason.
The definition in the Standard seems slightly clearer to me than your quoted definition. For example, there are some cases where a constexpr constructor is not required (e.g. a closure or an aggregate).
In C++ 5.1.1/3 [expr.prim.general] it says:
The type and value category [of this] are defined within a static member function.
What does this mean? How is it relevant?
Note that:
this shall not appear in the declaration of a static member function
The language in the standard can be traced to n3282, which is a resolution for defects 1207 and 1017. In particular, the language appears in the proposed resolution for defect 1207, and thus should be considered in the context of the standard as it stood at the time that defect was addressed. At that time there was some concern over the rewriting of id-expressions into member access expressions using *this (9.3.1p3), in particular in the context of trailing-return-type declarations (see issue 945).
If we compare the proposed resolution to defect 1207 to the eventual language in n3282 and subsequently in the standard, there is one significant difference to 9.3.1p3:
Defect 1207:
When an id-expression (5.1 [expr.prim]) that is not part of a class member access syntax (5.2.5 [expr.ref]) and not used to form a pointer to member (5.3.1 [expr.unary.op]) is used in the declaration of a member function of class X, if name lookup (3.4 [basic.lookup]) resolves the name...
n3282 and C++11:
When an id-expression (5.1 [expr.prim]) that is not part of a class member access syntax (5.2.5 [expr.ref]) and not used to form a pointer to member (5.3.1 [expr.unary.op]) is used in a member of class X in a context where this can be used (5.1.1 [expr.prim.general]), if name lookup (3.4 [basic.lookup]) resolves the name [...]
It is apparent that the proposed resolution to defect 1207 carried the belief that id-expressions (to a static member) within a static member functions would need to be transformed to *this member access expressions and thus would need access to the type and value category of this. By the time n3282 was written this had been resolved in favour of the qualified-id transformation (also 9.3.1p3) which does not require this, but the language in 5.1.1p3 remained vestigially.
I would recommend raising this issue on the C++ standards discussion newsgroup; it may be possible to get the vestigial language removed editorially.
This question here piqued my interest a little. Is there anywhere in the C++ standard that specifies all declarations within a class must be parsed before any accompanying implementations of member functions? I've seen a few other questions similar to this but no references to the standard in any of the answers.
The Standard doesn't specify how the compiler should parse a translation unit. Instead, it specifies everywhere it is and is not valid to use any identifier to refer to a declaration.
3.3.2p5:
After the point of declaration of a class member, the member name can be looked up in the scope of its
class. [ Note: this is true even if the class is an incomplete class. ]
3.3.7p1:
The following rules describe the scope of names declared in classes.
The potential scope of a name declared in a class consists not only of the declarative region following the name’s point of declaration, but also of all function bodies, brace-or-equal-initializers of non-static data members, and default arguments in that class (including such things in nested classes).
A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule.
If reordering member declarations in a class yields an alternate valid program under (1) and (2), the program is ill-formed, no diagnostic is required.
A name declared within a member function hides a declaration of the same name whose scope extends to or past the end of the member function’s class.
The potential scope of a declaration that extends to or past the end of a class definition also extends to the regions defined by its member definitions, even if the members are defined lexically outside the class (this includes static data member definitions, nested class definitions, member function definitions (including the member function body and any portion of the declarator part of such definitions which follows the declarator-id, including a parameter-declaration-clause and any default arguments (8.3.6).
[class.mem] says:
-2- A class is considered a completely-defined object type (3.9) (or complete type) at the closing } of the class-specifier. Within the class member-specification, the class is regarded as complete within function bodies, default arguments, and brace-or-equal-initializers for non-static data members (including such things in nested classes). Otherwise it is regarded as incomplete within its own class member-specification.
For the class to be complete within function bodies then in general all declaration need to be parsed: without completely parsing all declaration you can't know if something that wasn't parsed would change the meaning. Although, possibly related to that is [basic.scope.class]/1 which says:
3) If reordering member declarations in a class yields an alternate valid program under (1) and (2), the program is ill-formed, no diagnostic is required.
That means certain declarations could be used without parsing the entire class, because if another later declaration altered the meaning then the program would be ill-formed.
Of course the "as if" rule allows the compiler to choose any implementation as long as the user can't tell the difference, so maybe a compiler could choose to parse function bodies and then parse definitions as needed, but it would be hard to tell what's needed to process the member function definition (consider a function call which might call one of several overloaded functions, possibly involving enable_if-type tricks.)
This is the draft which explains C++ Programming Language Standard.
Programming Language C++ PDF
I think page 220 has some explanations on member functions.