eiffelroom - Eiffel - Comments

I'm not sure how I missed

clemahieu — Fri, 10 Oct 2008 15:07:26 -0700

I'm not sure how I missed this post. This is great news.

It seemed my comment got

paulbates — Tue, 07 Oct 2008 13:24:22 -0700

It seemed my comment got lost in the digital cosmos! Let me try again...

What would be the point compiling a GTK application to run on Windows, unless it was for legacy purposes? Surely you'd just be using EiffelVision2?

Great!

schoelle — Sun, 28 Sep 2008 09:46:55 -0700

Great! I am looking forward to see everything working.

Related question: has anybody tried to get GTK+ working on Windows? Compile GEL applications that run on all three platforms?

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++?

Oh yes, the BeBox

schoelle — Sat, 10 May 2008 07:10:30 -0700

My BeBox 2x133 is taking on dust. Perhaps I should reactivate it to see if I can get Eiffel to work on it ;-)

Nice job Manu, if I find some time I will have a look at your build - but it looks like the latest family extension is not keeping you sufficiently busy :D

The contract viewer's right-click issue

peter_gummer — Thu, 28 Feb 2008 04:12:39 -0800

Paul, you mention three possible fixes for the right-click issue seen in the sneak preview of the contract viewer.

The last would be sad, so let's not think about that.
The second would be disappointing: it's so neat that it pops up simply by hovering the mouse there.
The first is intriguing. You say that hovering the mouse over a feature would display a small beam. What would the user have to do, then, to open the contract viewer? Click on the beam? Move the mouse down a bit to hover over the beam? This sounds a bit disappointing too.

A fourth option would be to leave it as it is, but make sure that right-clicking works. Isn't this possible? If I try to right-click on a feature but the contract viewer has popped up unexpectedly, is there any reason why the right-click can't be forwarded to the feature stone underneath? (Not sure if I've got my pebble-drop metaphors mixed up there, but you know what I mean.)

Me, I'd want to activate it via a keyboard shortcut rather than a mouse-hover, of course ;-)

A few Notes

paulbates — Wed, 27 Feb 2008 16:47:14 -0800

We are aware of the right click issue and it will be addressed.

I put a preview of the contract viewer in the editor to ensure any annoyances are worked out before the release. I mentioned this in one of the 6.2 release notes, release 6.2.7.2075.

There are a few things that might happen with this:

The drop down is shrunk to a small beam under the feature name text, so it does not pop up accidentally or get in the way.
The pop up time out will be longer so it does not pop up too soon, with a key modifier to show it immediately.
It will be removed.

We need to get this right because in the future the mechanism will be used in various forms throughout EiffelStudio. As it stands, what you see probably wont be what is released. There is quite a bit of logic already there to determine when to show the token options. Any feedback is welcome, we want to get this right without being annoying.

In reference to Greg's remarks, it's not a tool tip. In the future you'll be editing contracts directly on the "assistance window". As I've said these types of windows will be placed through EiffelStudio in future releases, not just in the editor.

I like it if it works

peter_gummer — Wed, 27 Feb 2008 14:30:57 -0800

I have no problem with this innovation. Where I get annoyed as a user is when an innovation gets in the way of standard user interface conventions. (Pick and drop is the classic example of that. Until recently, it impeded the use of context menus, and even today there is no drag and drop.) In 6.2.7.2437, we have this nice preview of the contracts tooltip, and I like it, but a couple of times already it has popped up when I was attempting to right-click a feature.

The trouble with this sort of thing is that it's easy to prototype and get people saying "Wow!", but it's very difficult to get it right. So I'd be glad to see this in 6.2, as long as it's very thoroughly tested! I would expect to see an option in Preferences for turning it off.

I'm not sure if there is any

manus_eiffel — Mon, 25 Feb 2008 20:59:45 -0800

I'm not sure if there is any standard for tooltips, but if you look at Visual Studio they have something very similar. They do not have a button, but they have expandable tree views in the tool tip. Not exactly the same, but it looks like tooltips are not just messages anymore, you can interact with them.

Nice, but..

gcompestine — Mon, 25 Feb 2008 12:40:53 -0800

Shouldn't the "Edit Contracts..." button be in a popup menu instead of a tooltip?

This seems like a very non-standard add-on to tooltip functionality. I do think the tooltip is a good idea, and I also believe strongly that Eiffel Vision should be migrating closer to supporting standard behavior rather than adding more departures from it.

If it is documented as a standard for Windows or some other common user interface, could you please refer me to the document?

Thanks,

Greg