eiffelroom - Blog entry - Comments

It definitely looks very

manus_eiffel — Tue, 08 Jul 2008 00:58:40 -0700

It definitely looks very interesting, but it is quite a successive number of steps to go from the original C code down to flash. One has to try for sure!

LinkedIn Group created

francesco.ferreri — Mon, 07 Jul 2008 10:33:42 -0700

Have a look at:

http://www.linkedin.com/e/gis/136703/6D9E7425BFE4

and let me know what you think. Group description is limited to 300 characters, so I had to keep it essential.

Back in the days ...

schoelle — Mon, 07 Jul 2008 00:36:09 -0700

I can suggest either

manus_eiffel — Sun, 06 Jul 2008 02:47:03 -0700

I can suggest either eiffel.com/dev.eiffel.com or eiffelroom.org as a site to point back to. For the description, we can try something like partially extracted from Wikipedia:

<< Eiffel is an ISO-standardized, object-oriented programming language designed to enable programmers to efficiently develop extensible, reusable, reliable software.

The Eiffel language's design is closely connected with the Eiffel programming method. Both are based on a set of principles, including design by contract, command-query separation, uniform-access principle, single-choice principle, open-closed principle, and option-operand separation.

New language-design ideas, particularly through the ECMA/ISO standardization process, continue to be incorporated into the Eiffel language. >>

Here is a picture I took of

manus_eiffel — Sun, 06 Jul 2008 02:31:49 -0700

Here is a picture I took of the fire on Wednesday night:

LinkedIn Group

francesco.ferreri — Sat, 05 Jul 2008 11:15:58 -0700

If you like the idea, I can create an "Eiffel Users" group on LinkedIn and give you rights for administration. All I need is a captivating description for the group, and a website to link back (maybe this ?) suggestions are welcome ! Let me know ...

The Eiffel mailing list on

manus_eiffel — Thu, 03 Jul 2008 14:25:13 -0700

The Eiffel mailing list on Yahoo! groups has always had an increasing number of members since it was first created many years ago. So definitely the Eiffel community is growing. Usually once you get hooked on Eiffel, you get hooked forever :-)

Having the LinkedIn, or Facebook social networking for Eiffel is a nice way to show the world that the Eiffel community is thriving.

I agree with you and I vote

jvelilla — Thu, 03 Jul 2008 13:19:05 -0700

I agree with you and I vote for create a LinkedIn group.

I strongly agree with you: a

francesco.ferreri — Thu, 03 Jul 2008 10:22:11 -0700

I strongly agree with you: a relatively simple way to achieve your goal, at least in part, could be to take advantage of existing social networking sites such as LinkedIn, creating an Eiffel group on LinkedIn could be a first step along the way.

Regards

Ah ha, 99, very clever!

peter_gummer — Wed, 25 Jun 2008 05:42:46 -0700

It's the oldest trick in the book, 99: deterministic finalization.

Deterministic finalization, Max?

Yes, 99, they used to use it in the old days. People even used to like it back then; some people even complained when they took deterministic finalization away and gave everyone garbage collection instead. Can you believe it?

Yes, that's exactly what it

manus_eiffel — Mon, 23 Jun 2008 22:39:00 -0700

Yes, that's exactly what it is. I wonder how many C++ programmer knows about such a subtle semantics.

Surprisingly, today someone else posted another C++ odity here.

It seems like getName

maverick — Mon, 23 Jun 2008 18:45:09 -0700

It seems like getName creates a new string object and returns it by value. It is copied on the stack of my_routine for the sole purpose of evaluating the expression my_obj->getName().c_str().

After the evaluation, the object goes out of scope and is therefore destroyed. As I recall, c_str returns a pointer to the inner representation of the string object (probably for efficiency reasons, as most rationales in C/C++).

When the string object is destroyed, its inner representation is freed. The pointer fed to memcpy is therefore nothing but a dangling pointer which explains the erratic behavior you're talking of.

The fact that you store it in a local variable delays the freeing of the inner representation of the string so memcpy can do its work properly.

Am I close?

Simon

Not yet the answer but the

manus_eiffel — Mon, 23 Jun 2008 16:32:18 -0700

Not yet the answer but the code that works:

void my_routine (CppClass my_obj, int buffer_count, char * buffer) {

    std::string l_str = my_obj->getName();

    const char * l_cstr = l_str.c_str();

    memcpy(buffer, l_cstr, buffer_count);

}

Go figure!

Well, aside from Peter's

steven.m.wurster — Mon, 23 Jun 2008 06:37:26 -0700

Well, aside from Peter's comment about the actual size of the buffer, there is also the issue of not terminating the buffer. The platform may assign more space to the buffer than was allocated (for alignment purposes), and the contents of that extra space are undefined. If you do not terminate the buffer at location buffer_count then the contents of that space could be interpreted (most likely incorrectly) by the caller or whomever. Also don't forget that buffer_count within the routine should be one larger than the result of my_obj->getName().size(), and of course that's how large the buffer should be. You need the room for the termination. I'm also assuming that you are just working with char-based strings here, and not wide characters. You could be trying to copy a wide string into a char* for all I know, which means the size of the buffer needs to be even larger than I noted above.

On a side note, if all you want to do is copy the contents of a std::string, please put it into another std::string. Don't use char* if you don't have to. If you're working with an API that requires the use of const char*, then just pass the result of the c_str() function to that API. Don't bother with the annoyances of C-based memory management and C-based arrays if you can avoid it.

You've got me

peter_gummer — Mon, 23 Jun 2008 02:58:53 -0700

You've got me, Manu. I can't see anything wrong, other than the obvious, typical memcpy() problem that we have no way of knowing whether buffer really does have buffer_count bytes in order to avoid a buffer overflow.

Maybe some byte-alignment problem on certain platforms?

I look forward to seeing the answer to this mind-twister! Who needs Sudoku when we have C++?