Доведем DPL до кипения от Allen Bauer

← →
oxffff © (2008-01-18 10:19) [0]

http://blogs.codegear.com/abauer/2008/01/17/38849

← →
Семен Сурков (2008-01-18 10:59) [1]

трудися бы ты хоть дайджест приводить.

← →
Семен Сурков (2008-01-18 11:22) [2]

Суть такова.

Ален пишет, как самому создать полный аналог критической секции.
Я не совсем понял нафига, но вроде бы поэтому

>Another problem is that critical sections are (supposed to be) opaque
structures.

Странный вывод, однако.

Разрабатывался вот такой монитор http://en.wikipedia.org/wiki/Monitor_(synchronization)#Condition_variables.

Я так понял, что Дельфи будет иметь собственную библиотеку для многопоточного программирования. В общем похвально - писать win32 компилятор, который будет меньше зависеть от OC

PS Надеюсь кому-нибудь интересен еще Дельфи :)

← →
asdf © (2008-01-18 11:38) [3]

> PS Надеюсь кому-нибудь интересен еще Дельфи :)

Почему такой вопрос вообще может возникнуть?(это не претензия к автору)

Код очень прост, писать легко, выучить тоже. Уверен, 99,9 (а может 100)% приложений (кроме инет) сделать можно. Быстродействие? Кого оно сейчас волнует? Да и намного ли оно ниже, чем, скажем, у C++? Не знаю. Кинулись все за C#, а по моему дерьмо шарп этот и весь .Net. Поправьте, если не прав.

← →
Sandman25 (2008-01-18 11:49) [4]

asdf © (18.01.08 11:38) [3]

То же самое и о Basic сказать можно, так что не аргумент :)

← →
asdf © (2008-01-18 11:59) [5]

> Sandman25 (18.01.08 11:49) [4]

Ну и про Basic скажу, какая разница? Вопросв том, чем же это шарп лучше Delphi, что он сразу стал так популярен? Маркетинг грамотный? Или у него действительно есть такие достоинства, которые убивают Delphi?

PS. А синтаксис у басика корявый(имхо).

← →
DiamondShark © (2008-01-18 12:12) [6]

> а по моему дерьмо шарп этот и весь .Net. Поправьте, если
> не прав.

Ты не прав.

← →
DiamondShark © (2008-01-18 12:16) [7]

> Вопросв том, чем же это шарп лучше Delphi

Сам язык -- фигня, ничего революционного.
Дело в исполняющей среде.

← →
oxffff © (2008-01-18 12:22) [8]

> DiamondShark © (18.01.08 12:16) [7]

Где твои аргменты, а не просто утверждение?

P.S. Я не считаю .NET как в [3].

← →
asdf © (2008-01-18 12:51) [9]

> DiamondShark © (18.01.08 12:16) [7]

чем же хороша среда?

← →
asdf © (2008-01-18 12:52) [10]

Dellphi 2007 разве не обеспечивает то же самое?

← →
Игорь Шевченко © (2008-01-18 13:13) [11]

oxffff © (18.01.08 12:22) [8]

У тебя короче :)

← →
DiamondShark © (2008-01-18 14:06) [12]

> чем же хороша среда?

Тем, что она есть.
Можно изобретать сколь угодно навороченный ЯВУ, но как только программа скомпилирована, все твои высокоуровневые примочки -- классы, компоненты, модули и проч -- идут по бороде, получаешь кирпич машкода, и кушай его с маслом.
Это, конечно, не имеет никакого значения, пока каждый возится в своей песочнице. Но как только дело доходит до более-менее сложного объединения разрозненных компонент, вот тут-то и выплывают расписные утюги. И оказывается, что, несмотря на все финтифлюшки в языках, нет ничего лучше (не потому, что действительно лучше, а просто другого больше нет ничего) старой доброй тупой до неприличия бинарной совместимости, мать её.
COM, конечно, был крут, но это так, лёгкий флер духов на немытом теле.

ДотНету, конечно, далеко до достигнутого, скажем, в той же Oberon System, но, как говорится, за неимением гербовой...

← →
oxffff © (2008-01-18 14:31) [13]

> DiamondShark © (18.01.08 14:06) [12]

Не все так плохо. Нужно уметь готовить.

Managed and Unmanaged Code Interoperation

We have six basic scenarios here; unmanaged code is acting as
• An external (separate executable file) COM server, implemented through the COM
interoperability subsystem of the common language runtime and runtime callable
wrappers (RCWs).
• An external COM client, implemented through the same subsystem and COM callable
wrappers (CCWs).
• An external “traditional” server, implemented through the platform invocation
(P/Invoke) subsystem of the runtime.
• An embedded “traditional” server, implemented through a special case of P/Invoke
known as IJW (“it just works”) or local P/Invoke.
• An external “traditional” client, implemented through the unmanaged export of the
managed methods (inverse P/Invoke).
• An embedded “traditional” client, implemented through IJW (inverse local P/Invoke).
In this case a managed module contains embedded unmanaged native code, and the
entry point of the module is unmanaged, so the unmanaged code “takes the initiative”
from the start and subsequently calls the managed methods.

← →
oxffff © (2008-01-18 14:36) [14]

Пример на IL ASM. ;)

P/Invoke Thunks

In order to build a client thunk for managed code to call unmanaged code, the common
language runtime needs the following information:
• The name of the module exporting the unmanaged method—for example, Kernel32.dll
• The exported method’s name or ordinal in the export table of this unmanaged module
• Binary flags reflecting specifics of how the unmanaged method is called and how its
parameters are marshaled
All these items constitute the metadata item known as an implementation map, discussed
in the following section.
364 CHAPTER 18 ■ MANAGED AND UNMANAGED CODE INTEROPERATION
In general cases, the referenced unmanaged module must be located somewhere on the
path. However, there is a special case when it’s desirable to consider the unmanaged module
as part of the managed assembly and deploy them together. In this case, the unmanaged module
resides in the application directory (which doesn’t have to be on the path); the prime
module of the assembly must carry a File record associated with this unmanaged module.
The binary flag values and the respective ILAsm keywords are as follows:
• nomangle (0x0001). The exported method’s name must be matched literally.
• ansi (0x0002). The method parameters of type string must be marshaled as ANSI
zero-terminated strings unless explicitly specified otherwise.
• unicode (0x0004). The method parameters of type string must be marshaled as
Unicode strings.
• autochar (0x0006). The method parameters of type string must be marshaled as ANSI
or Unicode strings, depending on the underlying platform.
• bestfit:on (0x0010). Allow “best fit” guessing when converting the strings.
• bestfit:off (0x0020). Disallow “best fit” guessing.
• lasterr (0x0040). The native method supports the last error querying by the Win32 API
GetLastError.
• winapi (0x0100). The native method uses the calling convention standard for the underlying
platform.
• cdecl (0x0200). The native method uses the C/C++-style calling convention; the call
stack is cleaned up by the caller.
• stdcall (0x0300). The native method uses the standard Win32 API calling convention;
the call stack is cleaned up by the callee.
• thiscall (0x0400). The native method uses the C++ member method (non-vararg)
calling convention. The call stack is cleaned up by the callee, and the instance pointer
(this) is pushed on the stack last.
• fastcall (0x0500). The native method uses the fastcall calling convention. This is
much like stdcall where the first two parameters are passed in registers if possible.
• charmaperror:on (0x1000). Throw an exception when an unmappable character is
encountered in a string.
• charmaperror:off (0x2000). Don’t throw an exception when an unmappable character
is encountered.
The flags ansi, unicode, and autochar are mutually exclusive and so are the flags defining
the calling convention.
The name of the exported method can be replaced with the method’s ordinal in the
unmanaged module’s export table. The ordinal is specified as a decimal number, preceded by the # character—for example, #10.

If the specified name is a regular name rather than an ordinal, it is matched to the entries
of the Export Name table of the unmanaged module. If the nomangle flag is set, the name is
matched literally. Otherwise, things get more interesting.
Let’s suppose, for example, that the name is specified as Hello. If the strings are marshaled to
ANSI and the Export Name table does not contain Hello, the P/Invoke mechanism tries to find
HelloA. If the strings are marshaled as Unicode, the P/Invoke mechanism looks for HelloW; only if
HelloW is not found does P/Invoke look for Hello. If it still can’t find a match, it tries the mangled
name Hello@N, where N is a decimal representation of the total size of the method’s arguments in
bytes. For example, if method Hello has two 4-byte parameters (either integer or floating point),
the mangled name would be Hello@8. This kind of function name mangling is characteristic only
of the stdcall functions, so if the calling convention is different and the name is mangled in some
other way, the P/Invoke mechanism will not find the exported method.
You can see that the “name digging” methods employed by the P/Invoke mechanism are
intended for Windows API naming conventions and name mangling schemes of the C/C++
compiler.
The thunk is perceived by the managed code as simply another method, and hence it
must be declared as any method would be. The presence of the pinvokeimpl flag in the respective
Method record signals the runtime that this method is indeed a client thunk and not a true
managed method. You already encountered the following declaration of a P/Invoke thunk in
Chapter 1:
.method public static pinvokeimpl("msvcrt.dll" cdecl)
vararg int32 sscanf(string,int8*) cil managed { }
The parameters within the parentheses of the pinvokeimpl clause represent the implementation
map data. The string marshaling flag is not specified, and the marshaling defaults
to ANSI. The method name need not be specified because it is the same as the declared thunk
name. If you want to use sscanf but would rather call it Foo (sscanf is such a reptilian name!),
you could declare the thunk as follows:
.method public static pinvokeimpl("msvcrt.dll" as "sscanf" cdecl)
vararg int32 Foo(string,int8*) cil managed { }
The unmanaged method resides somewhere else and the thunk is generated by the runtime,
so the Method record of a “true” P/Invoke thunk has its RVA entry set to 0.

ЗЫ.
В итоге все через при пизд.. но по бинарной совместимости.

← →
oxffff © (2008-01-18 14:44) [15]

Providing Managed Methods
As Callbacks for Unmanaged Code
In a P/Invoke interaction, the initiative must come from the managed code’s side. The process
starts in managed mode and makes calls to the unmanaged functions. However, the exchange
can’t always go in only one direction; that model would be too simplistic to be usable.
Many unmanaged methods require callback functions, and the managed code must have
the means to provide those functions. Thus, it’s necessary to have a way to pass a managed
method pointer to an unmanaged function, permitting the unmanaged function to call the
managed method. The managed callback method might be simply a P/Invoke thunk of
another unmanaged method, but that changes nothing—it’s still a managed method.
The way to pass managed methods as callbacks to unmanaged functions involves the
use of delegates. The delegates are marshaled by P/Invoke thunks as unmanaged function
pointers, which makes them suitable for the task.
Let’s look at a sample to review the way delegates are used for callback specifications.
You can find this sample, Callback.il, on the Apress Web site. The sample implements a simple
program that sorts 15 integer values in ascending order, employing the well-known C function
qsort, called through P/Invoke. The difference between the P/Invoke calls you’ve encountered
so far and this one is that qsort requires a callback function, which compares the two elements
of the array being sorted, thus defining the sorting order.
I’ll let the sample speak for itself:
// I can"t pass the managed method pointer to the unmanaged function,
// and even the ldftn instruction will not help me.
// This delegate will serve as an appropriate vehicle.
.class public sealed CompareDelegate
extends [mscorlib]System.MulticastDelegate
{
.method public specialname
void .ctor(object Object,
native uint MethodPtr)
runtime {}
CHAPTER 18 ■ MANAGED AND UNMANAGED CODE INTEROPERATION 377
// Note the modopt modifier of the Invoke signature -- it"s very
// important. Without it, the calling convention of the callback
// function is marshaled as stdcall (callee cleans the stack).
// But qsort expects the callback function to have the cdecl
// calling convention (caller clears the stack). If we supply the
// callback with the stdcall calling convention, qsort blows
// the stack away and causes a memory access violation. You are
// welcome to comment out the modopt line and see what happens.
// Note also that the modopt modifier is placed on the delegate"s
// Invoke signature, not on the signature of the delegated method.
.method public virtual int32
modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl)
Invoke(void*, void*) runtime {}
// Well, I don"t really need asynchronous invocation here,
// but, you know, dura lex sed lex.
.method public newslot virtual
class [mscorlib]System.IAsyncResult
BeginInvoke(object,
class [mscorlib]System.AsyncCallback,
object) runtime {}
.method public newslot virtual
void EndInvoke(class [mscorlib]System.IAsyncResult)
runtime {}
}
// The hero of the occasion: the qsort function.
.method public static pinvokeimpl("msvcrt.dll" ansi cdecl)
void qsort(void*,int32,int32,class CompareDelegate) preservesig {}
// This is the comparison method I"m going to offer as
// a callback to qsort. What can be simpler than comparing
// two integers?
.method public static int32 compInt32(void* arg1,void* arg2)
{
// return(*arg1 - *arg2);
ldarg.0
ldind.i4
ldarg.1
ldind.i4
sub
ret

// And now, let"s get this show on the road.
.method public static void Exec()
{
.entrypoint
.locals init(class CompareDelegate)
// Print the unsorted values.
ldstr "Before Sorting:\n"
call vararg int32 printf(string)
pop
ldsflda valuetype SixtyBytes DataToSort
ldc.i4.s 15
call void printInt32(void*, int32)
// Create the delegate.
// Null object ref indicates the global method.
ldnull
ldftn int32 compInt32(void*,void*)
newobj instance void
CompareDelegate::.ctor(object,native uint)
stloc.0
// Invoke qsort.
ldsflda valuetype SixtyBytes DataToSort // Pointer to data
ldc.i4.s 15 // Number of items to sort
ldc.i4.4 // Size of an individual item
ldloc.0 // Callback function pointer (delegate)
call void qsort(void*,int32,int32,class CompareDelegate)
// Print the sorted values.
ldstr "After Sorting:\n"
call vararg int32 printf(string)
pop
ldsflda valuetype SixtyBytes DataToSort
ldc.i4.s 15
call void printInt32(void*, int32)
ret
}

← →
Игорь Шевченко © (2008-01-18 15:01) [16]

> CHAPTER 18

Нефигово бы и предыдущие 17 запостить

← →
Семен Сурков (2008-01-18 15:03) [17]

> Нефигово бы и предыдущие 17 запостить

:)

← →
oxffff © (2008-01-18 15:03) [18]

> Игорь Шевченко © (18.01.08 15:01) [16]

А вы читали эту книгу?

← →
DiamondShark © (2008-01-18 15:17) [19]

Хто тут?

← →
Игорь Шевченко © (2008-01-18 15:22) [20]

oxffff © (18.01.08 15:03) [18]

> А вы читали эту книгу?

Вопросы языкознания ? Конечно.

> DiamondShark © (18.01.08 15:17) [19]
> Хто тут?

Вот тебе про указатели, которых ты говоришь что нет в С# в другой ветке

Runtime pointer types
There are two kinds of pointers: unmanaged pointers and managed pointers. For pointers into the same array or
object (see Partition I), the following arithmetic operations are defined:
• Adding an integer to a pointer, where the integer is interpreted as a number of bytes, results in a
pointer of the same kind.
• Subtracting an integer (number of bytes) from a pointer results in a pointer of the same kind.
(Note that subtracting a pointer from an integer is not permitted.)
• Two pointers, regardless of kind, can be subtracted one from the other, producing a signed integer
that specifies the number of bytes between the addresses they reference.
None of these operations is allowed in verifiable code.
It is important to understand the impact on the garbage collector of using arithmetic on the different kinds of
pointers. Since unmanaged pointers shall never reference memory that is controlled by the garbage collector,
performing arithmetic on them can endanger the memory safety of the system (hence it is not verifiable), but
since they are not reported to the garbage collector there is no impact on its operation.
Managed pointers, however, are reported to the garbage collector. As part of garbage collection both the
contents of the location to which they point and the pointer itself can be modified. The garbage collector will
ignore managed pointers if they point into memory that is not under its control (the evaluation stack, the call
stack, static memory, or memory under the control of another allocator). If, however, a managed pointer refers
to memory controlled by the garbage collector it shall point to either a field of an object, an element of an
array, or the address of the element just past the end of an array. If address arithmetic is used to create a
managed pointer that refers to any other location (an object header or a gap in the allocated memory) the
garbage collector’s behavior is unspecified.
1.1.4.1 Unmanaged pointers
Unmanaged pointers are the traditional pointers used in languages like C and C++. There are no restrictions on
their use, although for the most part they result in code that cannot be verified. While it is perfectly valid to
mark locations that contain unmanaged pointers as though they were unsigned integers (and this is, in fact, how
they are treated by the CLI), it is often better to mark them as unmanaged pointers to a specific type of data.
This is done by using ELEMENT_TYPE_PTR in a signature for a return value, local variable or an argument or
by using a pointer type for a field or array element.
Unmanaged pointers are not reported to the garbage collector and can be used in any way that an integer can be
used.
• Unmanaged pointers should be treated as unsigned (i.e., using conv.ovf.u rather than conv.ovf.i,
etc.).
• Verifiable code cannot use unmanaged pointers to reference memory.
• Unverified code can pass an unmanaged pointer to a method that expects a managed pointer. This
is safe only if one of the following is true:
Partition III 5
a. The unmanaged pointer refers to memory that is not in memory managed by the garbage
collector.
b. The unmanaged pointer refers to a field within an object.
c. The unmanaged pointer refers to an element within an array.
d. The unmanaged pointer refers to the location where the element following the last element
in an array would be located.
1.1.4.2 Managed pointers (type &)
Managed pointers (&) can point to a local variable, a method argument, a field of an object, a field of a value
type, an element of an array, a static field, or the address where an element just past the end of an array would
be stored (for pointer indexes into managed arrays). Managed pointers cannot be null. (They shall be reported
to the garbage collector, even if they do not point to managed memory)
Managed pointers are specified by using ELEMENT_TYPE_BYREF in a signature for a return value, local
variable or an argument or by using a byref type for a field or array element.
• Managed pointers can be passed as arguments and stored in local variables.
• If you pass a parameter by reference, the corresponding argument is a managed pointer.
• Managed pointers cannot be stored in static variables, array elements, or fields of objects or value
types.
• Managed pointers are not interchangeable with object references.
• A managed pointer cannot point to another managed pointer, but it can point to an object
reference or a value type.
• Managed pointers that do not point to managed memory can be converted (using conv.u or
conv.ovf.u) into unmanaged pointers, but this is not verifiable.
• Unverified code that erroneously converts a managed pointer into an unmanaged pointer can
seriously compromise the integrity of the CLI. This conversion is safe if any of the following is
known to be true:
a. the managed pointer does not point into the garbage collector’s memory area
b. the memory referred to has been pinned for the entire time that the unmanaged pointer is in
use
c. a garbage collection cannot occur while the unmanaged pointer is in use
d. the garbage collector for the given implementation of the CLI is known to not move the referenced memory

> Игорь Шевченко © (18.01.08 15:22) [20]
> oxffff © (18.01.08 15:03) [18]
>
>
> > А вы читали эту книгу?
>
>
> Вопросы языкознания ? Конечно.

:).

Я серьезно. Хотите расширить кругозор?

oxffff © (18.01.08 15:34) [22]

Нет, я на буржуйском кругозор не расширяю - не получается. Я кругозор расширяю книгами на русском языке, валяясь на диване. Вполне серьезно.

> oxffff © (18.01.08 15:30) [21]

А-аа! Так ты просвещаешь заблудших?
Извини, про интероп, маршалинг и ансэйф код я в курсе.

Не о том речь была.

← →
Семен Сурков (2008-01-18 15:50) [25]

Сергей, вообще это свинство выкладывать большие куски анг. текста.
Выдели главное и скажи по-русски. А главное, определись - есть ли у тебя слушатель даже на русском.

> Игорь Шевченко © (18.01.08 15:42) [23]
> oxffff © (18.01.08 15:34) [22]
>
> Нет, я на буржуйском кругозор не расширяю - не получается.
> Я кругозор расширяю книгами на русском языке, валяясь на
> диване. Вполне серьезно.

Я тоже обычно читаю на русском, но в туалете, как и большиство русских людей . :)
Но на английском увы информации больше, поэтому приходится читать уже за компьютером.
Чертовски интересно узнать что-то новое.

> Семен Сурков (18.01.08 15:50) [25]

Возможно я не прав.
Однако!!! Возможно будет интересно части сообщества узнавать быстрее информацию из первоисточников.
А другой части сообщества стараться подтянуть свои знания в области того же английского языка. Разве это вредно?
Разжовывать и класть в ротик смысла не вижу.
По скольку кому интересно, он сам будет кропотливо и настойчиво разбираться не смотря на языковые барьеры.
Которые у меня также присутствуют, но я рад и горжусь тем, что родился в России.
И тем более что брать на себя ответственность по переводу я был не стал.
Но всяком случае читатель будет знать где искать информацию.

P.S. Но это только мое IMHO

oxffff © (18.01.08 16:01) [26]

> Я тоже обычно читаю на русском, но в туалете, как и большиство
> русских людей . :)

У меня в туалете дивана нету. Размеры не позволяют :)

> Но на английском увы информации больше, поэтому приходится
> читать уже за компьютером.
> Чертовски интересно узнать что-то новое.

Это все конечно так, но я английский знаю не на уровне носителей, поэтому приходится переводить, читая. Мало того, что падает скорость восприятия, не всегда получается охватить страницу или большой абзац в целом, на русском я страницами целиком читаю. Отсюда легко что-то пропустить, так что процесс усвоения затруднен относительно родного языка.
Доку конечно приходится и на буржуйском читать или для себя переводить, заодно в процессе перевода в мозги лучше впечатывается.

Доведем DPL до кипения от Allen Bauer - The Oracle at Delphi Найти похожие ветки