Le 19/07/14 14:22, Dmitry Yemanov a écrit :
19.07.2014 14:14, Roman Simakov wrote:
IMO FB must use system size_t.
We were using system size_t until Nickolay had committed FB_SIZE_T a few
days ago in attempt to avoid warnings. The bad thing is that it wasnt't
discussed.
Still doesn't build
I guess we need to define FB_USE_SIZE_T macros while configure. But
I'm not sure I understand a comment of Nikolay. How changing one place
can fix different places when 8 bytes are assigned to 4. Or in such
places we need to use 4 bytes size_t which FB_SIZE_T does? If so the
fix is simple and
On 07/21/14 13:43, Roman Simakov wrote:
2014-07-21 12:10 GMT+04:00 alexpeshk...@users.sourceforge.net:
+#define FB_ALIGN(n, b) ((n + size_t(b - 1)) ~size_t(b - 1))
Maybe the first argument also to cast to some expected data type?
May be. Here I've just fixed a build, but I see no reason for
21.07.2014 11:51, Alex Peshkoff wrote:
I see no reason for FB_ALIGN
to always remain a macro - template function seems to fit here fine.
Why template? First parameter is always pointer, second is always size_t.
There is no
need for template here.
--
WBR, SD.
21.07.2014 13:13, Alex Peshkoff wrote:
We were using system size_t until Nickolay had committed FB_SIZE_T a few
days ago in attempt to avoid warnings. The bad thing is that it wasnt't
discussed.
Not too late to begin discussion now.
I would sooner agree with the change and Nickolay's
On 07/21/14 14:11, Dimitry Sibiryakov wrote:
21.07.2014 11:51, Alex Peshkoff wrote:
I see no reason for FB_ALIGN
to always remain a macro - template function seems to fit here fine.
Why template? First parameter is always pointer,
In C pointers to different data types differ :)
21.07.2014 13:10, Alex Peshkoff wrote:
In C pointers to different data types differ
This macro/function can work with only one pointer type - char*. All other
pointers
here will produce wrong computations and thus have to be casted to char*
beforehand.
--
WBR, SD.
On 07/21/14 15:33, Dimitry Sibiryakov wrote:
21.07.2014 13:10, Alex Peshkoff wrote:
In C pointers to different data types differ
This macro/function can work with only one pointer type - char*. All
other pointers
here will produce wrong computations and thus have to be casted to char*
I was at vacations when this discussion took place and therefore could
not take part in it in time. Let me try to answer some questions that
appear important to me too.
First of all - formal definition of API is certainly not a set of C++
classes. Each firebird interface is a single pointer,
21.07.2014 16:32, Alex Peshkoff wrote:
First of all - formal definition of API is certainly not a set of C++
classes. Each firebird interface is a single pointer, pointing to the
table of virtual functions that are contained in this interface. First
parameter of each function is always a
On 07/21/14 17:09, Dmitry Yemanov wrote:
21.07.2014 16:32, Alex Peshkoff wrote:
First of all - formal definition of API is certainly not a set of C++
classes. Each firebird interface is a single pointer, pointing to the
table of virtual functions that are contained in this interface. First
On 07/21/14 14:35, Dmitry Yemanov wrote:
21.07.2014 13:13, Alex Peshkoff wrote:
We were using system size_t until Nickolay had committed FB_SIZE_T a few
days ago in attempt to avoid warnings. The bad thing is that it wasnt't
discussed.
Not too late to begin discussion now.
I would sooner
21.07.2014 18:16, Alex Peshkoff wrote:
I think we should wait for Nickolay's mind before doing some big changes.
I don't propose any big changes now, so far we're just discussing. Maybe
there will be other opinions posted here.
Dmitry
01.07.2014 20:05, Alex Peshkoff wrote:
And out of curiosity: what IPluginModule::getModule() is supposed to
return and why it
may be called at all?
self
More interesting question: what is returned by getModule() from internal
interfaces,
such as JAttachment?
--
WBR, SD.
21.07.2014 18:04, Alex Peshkoff wrote:
Ahh - it's related with multiple inheritance and rtti. Luckily we do not
use both in interfaces.
I didn't try your test app, but I can confirm the expected vtable layout
(at least for IProvider) in the debugger (for gcc 4.8.2).
As for Free Pascal, they
The point is not how specific C++ compilers behave, it is that there is
no standard for a vtable layout, and you cannot publish an interface
that depends on disassembling the output of an example compiler, and
expect it to be a stable interface to work with. The compiler devs will
change the
All,
Later this summer BroadView is moving offices, in the lead up to the move, we
need to reconfigure some of our network infrastructure to support a transition
plan to the new office.
As such, on Wednesday @ 8:30am EDT we will be making the first network change,
which will require a 15 to
I disagree both with the interface design and this critique. Neither, to my
experience, makes any sense.
It is the normal to define interfaces as pure virtual classes, in short, as
abstract interfaces. The Java guys had the intelligence and insight to define
language constructs that define
18 matches
Mail list logo
