I am watching the introduction video's from Apple about Metal and MetalKit.
The sample code for the shaders has these double brackets like [[buffer(0)]] arguments. Why are there two brackets? Does it mean anything or is it just to indicate that there is keyword "buffer" following? There is no such construct in standard c++, is there?
vertex Vertex vertex_func(constant Vertex *vertices [[buffer(0)]],
constant Uniforms &uniforms [[buffer(1)]],
uint vid [[vertex_id]])
Also what would be a good 1 or 2 week fun project as an introduction into GP-GPU? Something manageable for a novice with good math skills but no artistic skills.
These are called attributes, and their syntax and behavior are defined in section 7.6.1 of the C++ standard, Attribute syntax and semantics. They look like this in the grammar:
attribute-specifier:
[ [ attribute-list ] ]
alignment-specifier
The Metal shading language defines numerous attributes that allow you to associate various semantics with variables, struct/class members, and function arguments (including argument table bindings as in your question).
The Metal Shading Language Specification defers to the C++ standard on this, so the C++ standard really is the reference to consult:
The Metal programming language is based on the C++14 Specification
(a.k.a., the ISO/IEC JTC1/SC22/ WG21 N4431 Language Specification)
with specific extensions and restrictions. Please refer to the C++14
Specification for a detailed description of the language grammar.
With this [[ x ]] you declare att that are getting passed between shaders ans CPU
I quote:
The [[ … ]] syntax is used to declare attributes such as resource
locations, shader inputs, and built-in variables that are passed back
and forth between shaders and CPU
Related
I just came across attributes enclosed in square brackets for the first time, and I've been doing a little background reading: http://en.cppreference.com/w/cpp/language/attributes.
For gcc at least, there seem to be multiple techniques allowed:
__attribute__((some_attribute))
and
[[some_attribute]]
Is this correct? When is one technique allowed or not allowed, preferred or not preferred? What's the difference?
It looks like [[some_attribute]] is allowed as of C++11 only, right?
According to N4659:
10.6.1 Attribute syntax and semantics [dcl.attr.grammar]
Attributes specify additional information for various source
constructs such as types, variables, names, blocks, or translation
units.
attribute-specifier-seq:
attribute-specifier-seqopt attribute-specifier
attribute-specifier:
[ [ attribute-using-prefixopt attribute-list ] ]
alignment-specifier
So, [[...]] is a standardized syntax.
In opposite, __attribute__ ((attribute-list)) is a syntax of gcc extension:
An attribute specifier is of the form __attribute__ ((attribute-list)). An attribute list is a possibly empty comma-separated sequence of attributes, where each attribute is one of the following:
...
As attributes were introduced in C++11 and you use gcc with C++11 support (or newer), then both types of syntax are available for you.
The [[foo]] syntax was introduced with C++11. But many compilers had their own syntax before that (which in some cases also supports some non-standardized attributes).
So in short: [[foo]] is standard and should work everywhere with a conforming compiler. The other syntaxes are compiler specific.
I'm working on improving syntax highlighting for Ada in gtksourceview (currently, it is very outdated and very incomplete). An issue I'm having, is Ada is very positional, so matching many constructs requires matching those positions. I was able to do this in nano fairly easily.
So, let's consider a type declaration such as:
type Trit is range 0..2;
Keywords like "type", "is" and "range" are recognized (and were originally). However, type names were treated as keywords (a bad design decision, as Ada regularly defines new types, even for simple types like integers). What the use gets, is the types in Standard being colored, and all other types looking like normal text, defeating the purpose of highlighting. In some languages this might be a notable problem. However, the majority of type names occur after two regex patterns:
type\s+(\w|\.|_)+
:\s+(\w|\.|_)+
It might just be a matter of implementation (nano and gtksourceview seem to use different regex implementations). I thought the problem was recognizing spaces. As it turns out, putting the type context above the keyword context results in types now being highlighted, but the "type" keyword, or ":" operator are then not highlighted properly (they are highlighted as "type"). I was able to override this in nano, resulting in correct highlighting, but cannot seem to find out how gtksourceview does this.
Here you can see the old gtksourceview definition in action, which doesn't work for a file with many custom types. My nano definition in action sidebyside for comparison; matching by position is definately possible and works.
Here is what happens when I put the type context below the keyword context.
Here is what happens when I put the type context above the keyword context.
In both cases the context is the same, just a simple pattern to get started.
<context id="type" style-ref="type">
<match>(type)\s+\w+</match>
</context>
You may want to consider generating the parser from the formal description of the syntax of Ada in annex P of the Language Reference Manual.
Unfortunately this doesn't answer your question of how to formulate the syntax for a GtkSourceView.
Microsoft Visual C++ compiler has the property declaration construction
__declspec( property( get=get_func_name, put=put_func_name ) )
Is there a compiler independent version of Microsoft C++ __declspec(property(...)) or another analogs?
No.
As usual, an identifier preceded by __ is reserved to the compiler. In C++03 you have __cpluscplus (to identify C++ vs C), __FILE__ and __LINE__. All those are preprocessor entities.
In C++0x, the difference is blurred by the introduction of the __attribute__ word which is the first I know of that has semantics value, but it still does not do what you're looking for.
EDIT: Addressing #James spot on comment.
As Nicola Musatti says, there was a Borland proposal, primarily because Borland Delphi uses Properties heavily, and C++Builder (their C++ 'equivalent' to Delphi) therefore requires it.
In C++Builder, the code looks a bit like this.
__property __int64 Size = {read=GetSize, write=SetSize};
No. Similar mechanisms were proposed to the C++ standard committee but none was ever accepted (Here is one such proposal from Borland).
I've seen template based toy implementations, but they tend to be too inconvenient to be of practical use, the major problems being:
As nested class instances are not members of the enclosing class (as are Java inner class instances), you have to explicitly "connect" a property to its enclosing class, which makes declaration and initialization cumbersome.
There is no way to call function-like entities without parentheses, so you cannot invoke a custom-made property as if you were accessing a variable.
Is glBindBuffer equivelent to glBindBufferARB ?
Are the enums (like GL_ARRAY_BUFFER and GL_ARRAY_BUFFER_ARB) equivilent? Can I use non-_ARB enum in glBindBufferARB?
Can I mix + match glBindBuffer() calls with glBindBufferARB()?
ALSO: if a card supports the _ARB extension, does it always support the core GL function - even if its OpenGL version isn't up to date??
In general, it is not legal to do that kind of thing, because core functionality and extensions are not exchangeable, even if they have the same name (one notable example is primitive restart).
However, in this particular case, they happen to be exactly the same with the exact same constants, so... although it's not legal, it is "ok" to use them interchangeably (i.e. nobody will notice if you don't tell them).
You cannot in general assume that if an ARB extension is present that the core funciton will be present as well. There exist many ARB extensions that are there solely to allow OpenGL implementations which cannot implement a full version for some reason to nevertheless provide at least some functionality that the hardware can provide.
I've seen different code snippets using these types, but I haven't seen if they are defined in some <standard header file> or just defined in a "local header file" or even at file level.
So what Im wondering is: Is there any standard header file that defines these types? Or is there some standard definitions that everyone uses that I should copy?
I guess that a possible and common use to these types are representing coordinates, am I wrong?
Is there anything else I should think about if I want to use these to represent positions in a grid? Any reasons why or why not to use them?
EDIT:
Clarification: int2 means a pair of ints, float3 means a triplet of floats.
If these types were predefined somewhere it would be nice to use them instead of having to write it from scratch including the standard algebraic functions (operator+, operator-, etc.).
These types aren't a part of standard C++. They might either be defined in some third-party library, or you're looking at some other dialect or language.
GPU code (Shader languages such as GLSL, Cg or HLSL, or GPGPU stuff like CUDA or OpenCL) typically defines types like these though, as names for the corresponding SIMD datatypes.
They are used in CUDA (and openCL?) where you have specific sized floats and memory usage and alignment is a big deal.
AFAIK there is no standard header file that defines these types.
According to your description int2 means a pair of two ints which can be represented in C++ as std::pair<int, int>.
These types are not standard and I've never seen them. Are you sure they weren't used as (terrible choices of) identifiers instead of types?
Some non-standard types that are quite likely available anyway are int32_t, uint64_t, etc. (These are specified by C99, so most modern C++ compilers also let you use them in C++.)
I stay with the POSIX types defined in <stdint.h>. It seems like everyone defines their own names for things and I've had a project where the names collide. It's become a new paradigm for me to NOT define my own "pet" names for types.